[fluttter_tool] Set IPHONEOS_DEPLOYMENT_TARGET to 8 #36117

lookfirst · 2019-07-13T05:25:19Z

Description

Prevents this warning in xcode during build:

The iOS deployment target is set to 7.0, but the range of supported deployment target versions for this platform is 8.0 to 12.2.99. (in target 'Flutter')

I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
I signed the [CLA]
I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
I updated/added relevant documentation (doc comments with ///).
All existing and new tests are passing.
The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require Flutter developers to manually update their apps to accommodate your change?

Yes, this is a breaking change (Please read [Handling breaking changes]). Replace this with a link to the e-mail where you asked for input on this proposed change.
No, this is not a breaking change.

Prevents this warning in xcode during build: `The iOS deployment target is set to 7.0, but the range of supported deployment target versions for this platform is 8.0 to 12.2.99. (in target 'Flutter')`

jonahwilliams · 2019-07-25T17:03:26Z

cc @jmagman

jmagman

I don't think we want to force pods to 8.0 if the pod doesn't support it, or even worse force it down if it only supports a later version.
How about we add :inhibit_warnings to the pod install? I'm all for not clogging up my pristine project no-warning with deprecation warnings, etc from dependencies.

pod 'Flutter', :path => engine_dir, :inhibit_warnings => true

pod 'Flutter', :path => File.join(symlink, File.basename(p[:path])), :inhibit_warnings => true

And if you could add it to the following places to keep it all consistent that would be really helpful!

packages/flutter_tools/templates/cocoapods/Podfile-ios-swift:    pod p[:name], :path => File.join(symlink, 'ios')
packages/flutter_tools/templates/cocoapods/Podfile-ios-objc:    pod p[:name], :path => File.join(symlink, 'ios')
packages/flutter_tools/templates/cocoapods/Podfile-macos:      pod p[:name], :path => File.join(symlink, 'macos')

lookfirst · 2019-07-25T18:24:38Z

I don't think we want to force pods to 8.0 if the pod doesn't support it

The error message is saying that the range of supported deployment target versions for this platform is 8.0, so you kind of have to force it to 8, no?

jmagman · 2019-07-25T18:31:37Z

How about we add :inhibit_warnings to the pod install?

Actually, I just tried this and it doesn't suppress that warning.

After reading CocoaPods/CocoaPods#7314 I don't really want to imply libraries support a higher version than they claim to, or worse claim they support a higher version, but I also really hate warnings in dependencies you have no power to fix.

At a minimum, the the 8.0 version in the change doesn't match the version at the top.

# Uncomment this line to define a global platform for your project
# platform :ios, '9.0'

And now we're chasing a moving target of whatever Xcode decides is the minimum deploy version.
What if we did this:

config.build_settings.delete 'IPHONEOS_DEPLOYMENT_TARGET'

Then the individual pod targets will inherit IPHONEOS_DEPLOYMENT_TARGET either from the Pods project from that platform :ios call, or inherit from the SDK platform?

Whatever we do in this Podfile should be duplicated in Podfile-ios-swift and Podfile-macos.

jmagman · 2019-07-29T18:25:29Z

What if we did this:
config.build_settings.delete 'IPHONEOS_DEPLOYMENT_TARGET'
Then the individual pod targets will inherit IPHONEOS_DEPLOYMENT_TARGET either from the Pods project from that platform :ios call, or inherit from the SDK platform?

Whatever we do in this Podfile should be duplicated in Podfile-ios-swift and Podfile-macos.

@lookfirst What do you think about this proposal?

LinusU · 2019-07-29T21:25:00Z

I think that this value needs to be controlled by the end user, forcing it to 8.0 would not be good. It would break our project which uses API:s only available on iOS 12.0 and later.

I've posted about this before, here are some relevant threads:

#32791 (comment)
CocoaPods/CocoaPods#4859 (comment)
CocoaPods/CocoaPods#7314 (comment)

jmagman · 2019-07-29T21:33:35Z

I think that this value needs to be controlled by the end user, forcing it to 8.0 would not be good. It would break our project which uses API:s only available on iOS 12.0 and later.

@LinusU Would it work for your use-case if the pods did not have a deployment version, but instead inherited the value from the platform :ios specified in your Podfile?

with platform :ios, '12.0' becomes

lookfirst · 2019-07-30T02:07:53Z

I just discovered that https://github.com/flutter/plugins/tree/master/packages/google_sign_in requires 9.0 (there was warnings in Xcode when I included it), so now I'm past 8 anyway.

lookfirst · 2019-07-30T02:09:57Z

In order to move from 8 to 9, I had to edit the Podfile as well as the xcode project. It was a pain. If you can simplify it so that I just edit the Podfile, that would be great.

LinusU · 2019-07-30T09:58:21Z

@jmagman

Would it work for your use-case if the pods did not have a deployment version, but instead inherited the value from the platform :ios specified in your Podfile?

Yes, that would be perfect 👍

jmagman · 2019-07-30T17:04:06Z

In order to move from 8 to 9, I had to edit the Podfile as well as the xcode project. It was a pain. If you can simplify it so that I just edit the Podfile, that would be great.

@lookfirst Would you like me to take this over then?

christopherfujino · 2019-08-08T17:37:26Z

@jmagman Are you going to fix this in a separate PR?

jmagman · 2019-08-08T17:58:23Z

@jmagman Are you going to fix this in a separate PR?

I was going to just take this one over.

I started with:

post_install do |installer|
...
{{^withPluginHook}}
      # Inherit the deployment target from the `platform :ios` call above to avoid un-fixable warnings.
      config.build_settings.delete 'IPHONEOS_DEPLOYMENT_TARGET'
{{/withPluginHook}}

but it doubles down on the Podfile being a template, which goes against @xster's request for it to become dynamically generated here #9827

I need to find a mechanism to know if the app is a plugin example app AFTER the project is already generated, which there isn't right now AFAIK.

jmagman · 2019-08-08T19:28:34Z

@jmagman Are you going to fix this in a separate PR?

I was going to just take this one over.

Actually it looks like there's no way to transfer a PR to another fork. I will make a new one.

but it doubles down on the Podfile being a template, which goes against @xster's request for it to become dynamically generated here #9827

I guess that issue has been open awhile though and the Podfile are already templates, so we can add it to the list of behaviors that needs to be migrated if it ever becomes generated on flutter builds.

jmagman · 2019-08-08T19:37:44Z

Oh yeah, and the other issue is that the Podfile isn't added on create, it's actually added when the first plugin is added. So at that point withPluginHook isn't available, either.

xster · 2019-08-10T04:03:41Z

#9827 indeed probably needs a re-summary at the bottom. Based the issues I originally wanted us to fix, likely 75% of it is already done.

zanderso · 2019-09-05T17:09:45Z

@jmagman What is the status of this PR? Can in be closed?

jmagman · 2019-09-09T22:27:53Z

I documented the issue and proposed solutions in #40109. Closing this PR.

Set IPHONEOS_DEPLOYMENT_TARGET to 8

138a969

Prevents this warning in xcode during build: `The iOS deployment target is set to 7.0, but the range of supported deployment target versions for this platform is 8.0 to 12.2.99. (in target 'Flutter')`

fluttergithubbot added the tool Affects the "flutter" command-line tool. See also t: labels. label Jul 13, 2019

googlebot added the cla: yes label Jul 13, 2019

jmagman self-requested a review July 25, 2019 17:58

jmagman requested changes Jul 25, 2019

View reviewed changes

jmagman added t: xcode "xcodebuild" on iOS and general Xcode project management platform-ios iOS applications specifically labels Jul 25, 2019

jmagman mentioned this pull request Aug 27, 2019

Make module pod headers public #39275

Closed

9 tasks

zanderso added the p: tooling Affects the flutter_plugin_tools package label Aug 29, 2019

jmagman mentioned this pull request Sep 9, 2019

Plugin target deployments are out of range, causes Xcode warning #40109

Closed

jmagman closed this Sep 9, 2019

jmagman mentioned this pull request Aug 8, 2020

Increase plugin template minimum supported iOS version from 8.0 to 9.0 #63253

Closed

jmagman mentioned this pull request Sep 18, 2020

Flutter 1.22, FlutterFire, and Xcode 14 complains about IPHONEOS_DEPLOYMENT_TARGET #66103

Closed

jmagman mentioned this pull request Sep 24, 2020

Force plugins to inherit minimum iOS version from Flutter app #66590

Merged

10 tasks

github-actions bot locked as resolved and limited conversation to collaborators Aug 4, 2021

[fluttter_tool] Set IPHONEOS_DEPLOYMENT_TARGET to 8 #36117

[fluttter_tool] Set IPHONEOS_DEPLOYMENT_TARGET to 8 #36117

Uh oh!

Conversation

lookfirst commented Jul 13, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Breaking Change

Uh oh!

jonahwilliams commented Jul 25, 2019

Uh oh!

jmagman left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lookfirst commented Jul 25, 2019

Uh oh!

jmagman commented Jul 25, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jmagman commented Jul 29, 2019

Uh oh!

LinusU commented Jul 29, 2019

Uh oh!

jmagman commented Jul 29, 2019

Uh oh!

lookfirst commented Jul 30, 2019

Uh oh!

lookfirst commented Jul 30, 2019

Uh oh!

LinusU commented Jul 30, 2019

Uh oh!

jmagman commented Jul 30, 2019

Uh oh!

christopherfujino commented Aug 8, 2019

Uh oh!

jmagman commented Aug 8, 2019

Uh oh!

jmagman commented Aug 8, 2019

Uh oh!

jmagman commented Aug 8, 2019

Uh oh!

xster commented Aug 10, 2019

Uh oh!

zanderso commented Sep 5, 2019

Uh oh!

jmagman commented Sep 9, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

lookfirst commented Jul 13, 2019 •

edited

Loading

jmagman left a comment •

edited

Loading

jmagman commented Jul 25, 2019 •

edited

Loading