Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Allow to skip the deploy target version check #1241

Closed
Whirlwind opened this Issue Jul 30, 2013 · 25 comments

Comments

Projects
None yet

I have a question:
I use google map in my app and the google map only support 6.0 and later. :(
So I do something to support the ios 5.0: if the iOS is 5.0, I will use the apple map view and I will use the google map if it is 6.0 and later.

I know there is a keyword platform to set the deploy target version. But the version make it bad to my question:

I must set the platform to 6.0, otherwise pod install will not pass because the Google Map only support 6.0 and later! So I can NOT set it to 5.0!!

[!] The platform of the target `Pods` (iOS 5.0) is not compatible with `Google-Maps-iOS-SDK (1.4.0)` which has a minimum requirement of iOS 6.0.

And if I set the platform to 6.0, the all Pods target will be set to iOS 6.0!!

for Cocoapods v0.20.2, if my app's target version is iOS 5.0, the Pods target will be 5.0;
for Cocoapods v0.22.2, the Pods target will be 6.0, it ignore my app target setting.

How should I do?

Owner

fabiopelosin commented Aug 1, 2013

I think that you usage case is reasonable, however there is no easy way to do this in CP. The only workaround available at the moment is to modify the podspec.

@irrationalfab
for Cocoapods v0.20.2, if my app's target version is iOS 5.0, the Pods target will be 5.0;
for Cocoapods v0.22.2, the Pods target will be 6.0, it ignore my app target setting.

I hope CP check dependency in Podfile, and set the target to my main app's target version, it like v0.20.2.

@fabiopelosin fabiopelosin reopened this Aug 1, 2013

jzapater pushed a commit to jzapater/CocoaPods that referenced this issue Sep 17, 2013

Can somebody help me modify CP to set the target to my main app's target version?

Contributor

rivera-ernesto commented Oct 18, 2013

I think this is related to #1376.

Contributor

calimarkus commented Nov 5, 2013

As discussed on Twitter One Two, I was searching for a way to define for a single pod, that the minimum build target should be ignored.

I could imagine a tag like :ignore_platform, that would be used similar to :ignore_warnings.

My problem: I have a project with a deployment target of 5.0, which uses a lot pods that are also 5.0. Now I wanted to include another pod that has a minimum target of 6.0 (which I actually would only use on 6.0 and higher). But the pod system cancels the install now.

Another idea would be to be able to overwrite specific pod spec properties / build settings within the podfile. Like
pod 'AwesomePod', :overwrite => { :platform => 5.0 } (sry I have no idea of ruby)

Issue has been confirmed by @joelparsons

Contributor

rivera-ernesto commented Apr 16, 2014

Any update/best practice for this?

Just had again this problem with a new project and iOS 8 this summer will just worsen the situation.

was there ever an override implemented to solve this? if not, i very much agree with the above comment in that iOS 8 will further increase the need for this...

Contributor

rivera-ernesto commented Jun 18, 2014

I think that by default CocoaPods should just warn about using Pods with a required system higher than the deployment target.

Take Apple frameworks for instance. Nothing prevents you from including and linking against newer frameworks, it is just up to the developers to check at runtime the system version to avoid executing non-compatible code.

Contributor

AliSoftware commented Jun 18, 2014

On that case it is up to the maintainer of the podspec to specify the minimum deployment target possible, even if some of the methods are only available in higher iOS versions.

Take the podspec of the AFNetworking pod as an example. It specifies that it is still compatible with iOS6 — to be able to use common classes not requiring iOS7 — but it's up to the developer using this pod to check for class availability if they want to use things like AFHTTPSessionManager — which uses NSURLSession and thus requires iOS7.


But still if you want to use a pod that only provides features only available on iOS8 and for which the podspec thus specify a minimum deployment target of iOS8 one may need to force its integration into a project targeting iOS7 as long as they do the proper checks before calling/using it to only call it's methods when available at runtime.

brynjar commented Jun 30, 2014

In my case, the library developer has simply setup the podspec wrong.. it supports 6 and above but the podspec has a min of 7. So until the podspec is fixed, I have to wait, but I want to ignore it...

Contributor

rivera-ernesto commented Jul 1, 2014

My reasoning is that there's no way for CocoaPods to tell that a Pod can't be used with a given project solely based on the target platform version, and it is even worse to refuse installing it.

In contrast it is logic to refuse installing a ios-only project on a OS X project where CocoaPods can tell for sure that it is an error.

@fabiopelosin fabiopelosin changed the title from How do I skip the deploy target version check? to Allow to skip the deploy target version check Sep 15, 2014

This should really be integrated in CocoaPods in my opinion. It's completely developer's responsibility to write proper code (like make runtime checks for libraries that aren't supported on old OS versions), and not the dependency manager's.

Reflejo commented Jan 13, 2015

:ignore_platform sounds like the way to go. In the meantime, you can "workaround" the issue from your Podfile by setting the platform to ios8 and then a post_install:

# Hack to rollback the targets to iOS 7
post_install do |installer|
  installer.project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings["IPHONEOS_DEPLOYMENT_TARGET"] = "7.0"
    end
  end
end

Reflejo referenced this issue in SnapKit/SnapKit Jan 13, 2015

Any update/best practice for this?

Contributor

kylef commented Mar 30, 2015

I think @segiddins mentioned somewhere that this could become a warning and not an error.

@orta what do you think? Might make sense.

Owner

alloy commented Apr 6, 2015

Yeah, sound good 👍

@segiddins segiddins self-assigned this Apr 6, 2015

@segiddins segiddins added this to the 0.37.0 milestone Apr 6, 2015

@orta orta closed this in #3407 Apr 16, 2015

Contributor

mrezk commented Jan 5, 2016

@segiddins It seems there has been a regression here.

v0.39.0 throws the following message when trying to install a dependency with a higher deployment target:

[!] Unable to satisfy the following requirements:

- `MZFormSheetPresentationController (~> 2.2.0)` required by `Podfile`

Specs satisfying the `MZFormSheetPresentationController (~> 2.2.0)` dependency were found, but they required a higher minimum deployment target.
Owner

segiddins commented Jan 5, 2016

@mrezk that's intentional. Change the platform in your Podfile if you want CocoaPods to resolve for a different platform version

entonio commented Feb 23, 2016

@segiddins but wasn't that error changed to a warning by this ticket?

Owner

segiddins commented Feb 23, 2016

And then a different change was made.

entonio commented Feb 23, 2016

Silly me, I missed the huge 'reverted' tag up there with a link to the relevant discussion.

neobie commented Jul 10, 2016

Anyway to do this?
In traditional framework import, I can set the framework SDK as "optional" in "Linked Frameworks and Libraries" to support lower deployment target, and set conditional for not using the Framework in lower deployment.
Wish to know a way to do this in CocoaPods.

zvonicek commented Dec 9, 2016

Any progress on this? Apparently this is a blocker for many people (me included)...

Owner

benasher44 commented Dec 13, 2016

Hi @zvonicek! This issue is quite old. Would you mind filing a new issue and filling out the issue template? Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment