[fluttter_tool] Set IPHONEOS_DEPLOYMENT_TARGET to 8 - #36117

cc @jmagman

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?

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.

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?

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)

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

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.

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.

@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 👍

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?

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

@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 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.

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.

#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.

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

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