You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
pods are always installed for iOS 8 deployment target instead of iOS 9 #7314
Create a new Xcode 9.2 project "example" for iOS Swift
Change deployment target to iOS 9.0
Use a Podfile with:
platform :ios, '9.0'
use_frameworks!
abstract_target 'default_pods' do
pod 'AFNetworking', '~> 3'
target 'example'
end
Run pod install or pod 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
CocoaPods 1.4.0.rc.1 (also reproduced with CocoaPods 1.3.1)
I found the following workaround, adding a post_install hook:
platform :ios, '9.0'
use_frameworks!
abstract_target 'default_pods' do
pod 'AFNetworking', '~> 3'
target 'example'
end
post_install do |pi|
pi.pods_project.targets.each do |t|
t.build_configurations.each do |config|
config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '9.0'
end
end
end
Reacted by Ergün KOÇAK, Eric Sellin, Chuck Imperato, Ezekiel Victor, naotty, Ribamar Santos, Ricky Tan, LJ86, Jake Wagstaff, Zain Sajjad and 36 more
Reacted by yoshi, Sloan, Kieran, Nick Hayward, chaitanya-neosoft, Matt "Kit" Hayes, Sam Becker, Arnold, Thomás Pereira PTC, Sebastian and 1 more
Reacted by Kim Ferrari, Arnold, username-maxim, Supanat-Toy, daniel-ioan-suia, Thomás Pereira PTC, SK and Sebastian
@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...
@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.
@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:
abstract_target 'default_pods' do
target 'One' do
platform :ios, '8.0'
end
target 'Two' do
platform :ios, '9.0'
end
end
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 pod install (or pod deintegrate && pod install) to get the post_install to execute at least once. It will not work with only pod update.
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 AFNetworking. In the podspec, there is a platforms":{"ios":"7.0","osx":"10.9","tvos":"9.0"}. So the pod target is deploy to iOS 7.0, and the macro will always be false! AFNetworking will always use the old api.
Reacted by Cœur, Dmitry Lobanov, BB9z and Stan Mots
@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.
[...] but it is not a good general policy that should be blindly applied to all pods.
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 ARCHS = "$(ARCHS_STANDARD_64_BIT)" in your app target. CocoaPods does automatically copy this setting to all Pods targets. (Xcode will give an "update to recommended settings" warning about this, but that seems like a lesser evil.)
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 👍
I found the following workaround, adding a post_install hook:
platform :ios, '9.0'
use_frameworks!
abstract_target 'default_pods' do
pod 'AFNetworking', '~> 3'
target 'example'
end
post_install do |pi|
pi.pods_project.targets.each do |t|
t.build_configurations.each do |config|
config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '9.0'
end
end
end
Well, the topic was closed by a bot, not because it was resolved.
If you wish for a solution that doesn't involve the workaround (see the second post, "Coeur commented on 8 Jan 2018"), then you'd need to create a new GitHub issue.
Activity
Coeur commentedon Jan 8, 2018
I found the following workaround, adding a post_install hook:
dnkoutso commentedon Jan 8, 2018
Can you please provide a sample project and use the template given to you when you file a new issue?
Coeur commentedon Jan 9, 2018
@dnkoutso Done, with a screenshot.
dnkoutso commentedon Jan 9, 2018
@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.
https://github.com/CocoaPods/Specs/blob/d0ec5a65e80656c8d78e12ff19f251df879e0bc2/Specs/a/7/5/AFNetworking/3.1.0/AFNetworking.podspec.json#L21
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...
dnkoutso commentedon Jan 9, 2018
Yes, Xcode 9 drops iOS 7.0 support so that's why you get iOS 8.0 instead despite the podspec mentioning
7.0https://stackoverflow.com/questions/45640715/how-to-set-up-xcode-9-for-iphone-4-and-iphone-4s-development
Coeur commentedon Jan 9, 2018
@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.
Jinxiansen commentedon Jan 11, 2018
@dnkoutso @Coeur
How to specify two different platforms in a pod,
I have two target, respectively, support for iOS 8 and iOS 9, how to distinguish?
dnkoutso commentedon Jan 11, 2018
I do not think this is supported currently.
Coeur commentedon Jan 12, 2018
@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
Coeur commentedon Apr 11, 2018
@Jinxiansen don't forget you have to do
pod install(orpod deintegrate && pod install) to get the post_install to execute at least once. It will not work with onlypod update.Whirlwind commentedon May 30, 2018
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
AFNetworking. In the podspec, there is aplatforms":{"ios":"7.0","osx":"10.9","tvos":"9.0"}. So the pod target is deploy to iOS 7.0, and the macro will always be false!AFNetworkingwill always use the old api.lolgear commentedon May 31, 2018
@dnkoutso
So, I have UICKeychainStore in Pods.xcodeproj.
Pods.xcodeproj has deployments targets:
Pods (Project) -> 9.0
UICKeychainStore -> 8.0
My App deployment target -> 9.3
I would like to keep them in sync in case of aesthetics.
@Coeur
If you can't reopen issue and it have not solved yet, it is time to make open-radar for CocoaPods.
39 remaining items
Coeur commentedon Jul 30, 2019
@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.
LinusU commentedon Jul 30, 2019
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? 🤔
icecrystal23 commentedon Jul 30, 2019
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.
Westacular commentedon Aug 2, 2019
@LinusU A workaround for the specific issue of dropping 32-bit code when targeting iOS 11+ is to set
ARCHS = "$(ARCHS_STANDARD_64_BIT)"in your app target. CocoaPods does automatically copy this setting to all Pods targets. (Xcode will give an "update to recommended settings" warning about this, but that seems like a lesser evil.)LinusU commentedon Aug 2, 2019
@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
ARCHS_STANDARD_64_BITif I targeted iOS 11+ 😄Hmm, I wonder why it doesn't use
ARCHS_STANDARD_64_BITfor iOS 11+ then 🤔stale commentedon Dec 22, 2019
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.
stale commentedon Dec 29, 2019
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 👍
MOD: fix Podfile warning
SohaibSiddique commentedon Apr 29, 2021
its working for me in 2021
MLukman commentedon Sep 3, 2021
Still happening today
Coeur commentedon Sep 4, 2021
Well, the topic was closed by a bot, not because it was resolved.
If you wish for a solution that doesn't involve the workaround (see the second post, "Coeur commented on 8 Jan 2018"), then you'd need to create a new GitHub issue.