-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pods are always installed for iOS 8 deployment target instead of iOS 9 #7314
Comments
I found the following workaround, adding a post_install hook:
|
Can you please provide a sample project and use the template given to you when you file a new issue? |
@dnkoutso Done, with a screenshot. |
@Coeur still dont think its a CocoaPods bug. The podspec of AFNetworking sets deployment target to 7.0 but I think because you are using Xcode 9.2 which does not contain iOS 7.0 it defaults to the next available version. Podspecs can define their own deployment target which gets set by the CocoaPods library. I do not see any particular issue with CocoaPods library here. Will close this one but please reply here if you feel strongly there is an issue here... |
Yes, Xcode 9 drops iOS 7.0 support so that's why you get iOS 8.0 instead despite the podspec mentioning |
@dnkoutso , you mean that in a Podspec, I can only forcibly define an exact Deployment Target, I can't simply define the minimal supported Deployment Target? When I write a Podspec, I use platforms.ios to define what is at least required to build, not to define what must be built. In all case, no matter the Podspec, it is an integration bug from CocoaPods to build for iOS 8+ when we want an iOS 9+ project. |
I do not think this is supported currently. |
@Jinxiansen , it doesn't even work for one single platform as described by this bug report. But if one day there is support for multi platforms, then the documentation will tell you. One suggestion could be:
It's pure suggestion for the future: this is in no way a working piece of configuration in 2018 |
@Jinxiansen don't forget you have to do |
I think the deployment target version should be equal to the user target version. If the pod target's deployment version is equal to iOS 9 which define by user target, the dependency will use their new api if they check the deploy version:
The code from the |
So, I have UICKeychainStore in Pods.xcodeproj. Pods.xcodeproj has deployments targets: Pods (Project) -> 9.0 My App deployment target -> 9.3 I would like to keep them in sync in case of aesthetics. @Coeur |
+1 I was hoping the deployment target would be defined according to the platform specified.
|
Coeur's multiple platforms script post_install do |pi|
# https://github.com/CocoaPods/CocoaPods/issues/7314
fix_deployment_target(pi)
end
def fix_deployment_target(pod_installer)
if !pod_installer
return
end
puts "Make the pods deployment target version the same as our target"
project = pod_installer.pods_project
deploymentMap = {}
project.build_configurations.each do |config|
deploymentMap[config.name] = config.build_settings['IPHONEOS_DEPLOYMENT_TARGET']
end
# p deploymentMap
project.targets.each do |t|
puts " #{t.name}"
t.build_configurations.each do |config|
oldTarget = config.build_settings['IPHONEOS_DEPLOYMENT_TARGET']
newTarget = deploymentMap[config.name]
if oldTarget == newTarget
next
end
puts " #{config.name} deployment target: #{oldTarget} => #{newTarget}"
config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = newTarget
end
end
end Add this to the
|
@BB9z, I'm unsure what you mean by "seems wrong", as I'm successfully using the 7 lines workaround from my January 8th post. But best thing would be to have the fix at CocoaPods level, so if you're confident you should make a pull request to fix CocoaPods regarding this. |
@Coeur assume we had a podfile: target 'One' do
platform :ios, '8.0'
pod 'A' # A has a deployment target 6.0, we want it build with 8.0
pod 'B' # B has a deployment target 7.0, we want it build with 8.0
end
target 'Two' do
platform :ios, '9.0'
pod 'A' # A has a deployment target 6.0, we want it build with 9.0
pod 'B' # B has a deployment target 7.0, we want it build with 9.0
end In my options, your script will define the deployment targets for "One" and "Two" respectively. But actually, you change nothing.
|
@BB9z The workaround from my January 8th post (second post of this thread) is certainly not for mixing deployment targets: it's for the issue reported in the preceeding post (first post of this thread), with a single desired deployment target (iOS 9 for instance). I don't understand why people are diverging the discussion on supporting multiple deployment target when it doesn't even work correctly for one single unique deployment target: if the target is built for 9.0, then the Pods should build for 9.0, not for 8.0. That's all there is in this issue report. It's nice to want to support more stuff, but it should come as fixes to the actual CocoaPods gem, not as complex workarounds in people's Podfile. This is an issue ticket, not a StackOverflow post. :) |
It seems that it would make sense to bump the deployment target to the user project's value if it is higher than the podspec's deployment target. @dnkoutso can you think of any issues that may arise from doing that? |
@amorde If person has one project/workspace for several targets ( for example, several "typical" targets ), these targets could be out of sync in "deployment target dimension", but Pods are shared between these "typical" targets. Typical targets are either app extensions or cloned apps ( some teams have clones of their main app for rebranding reasons before "big daddy money income"). |
ah, I forgot that a target can specify a deployment target lower than the project one. bummer. |
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
I believe the issue is duplicated with this one: #8069 but for my opinion current issue is better described |
I've posted this in #4859, but it seems very relevant here: Since I have a deployment target of iOS 12 in my main app, my app doesn't build arm 32-bit code, but since some of the pods have a much lower deployment target they do. This leaves me with linking errors when I'm trying to archive the app, and the only fix I've found is to bump the deployment target to 12 on all my pods as well. I think it would be very neat if CocoaPods could always propagate my platform :ios, '12.0' down to the individual pods deployment target. That way all pods would be optimized to run for the appropriate platform! |
@LinusU you are then consuming the Pods in a way not intended by the authors. You can choose to apply that workaround, but it is not a good general policy that should be blindly applied to all pods. |
@icecrystal23 you're probably wrong about that: pod authors may support MULTIPLE versions of iOS, while the podspec only let us define the minimum one. |
I don't really see how that is sustainable, should I only use pods that specifically targets iOS 12? That seems quite strange. Surely there should be no ill effects by compiling with a newer deployment target? 🤔 |
You guys are still acting like you can't run a library built for iOS 8 on iOS 12. You can. It is a minimum deployment target. Meaning the library supports iOS 8 and newer. I don't know what linker errors you are getting, but in general you can compile and link with older minimum targets just fine. |
@LinusU A workaround for the specific issue of dropping 32-bit code when targeting iOS 11+ is to set |
@Westacular that's amazing, thanks!! edit: I haven't been able to trigger this, would you mind elaborating on when it does that?
edit2: Ahhhh, read that the other way around, I thought that Xcode would ask me to go to Hmm, I wonder why it doesn't use |
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem 👍 |
its working for me in 2021 |
Still happening today |
Well, the topic was closed by a bot, not because it was resolved. |
Report
What did you do?
pod install
orpod update
What did you expect to happen?
AFNetworking is installed with a Deployment Target of iOS 9.0.
What happened instead?
AFNetworking is installed with a Deployment Target of iOS 8.0, which causes noticeable warnings like /Users/coeur/example/Pods/AFNetworking/AFNetworking/AFURLSessionManager.m:163:30: 'setResumingHandler:' is only available on iOS 9.0 or newer
Even if I manually change the Pods project Deployment Target to iOS 9.0, a simple
pod update
will reset it to iOS 8.0.CocoaPods Environment
Project that demonstrates the issue
https://github.com/Coeur/CocoaPods7314
The text was updated successfully, but these errors were encountered: