Please keep the Firebase deployment target at iOS 9 - lowest supported by Xcode 12

[mman]

Beginning with Firebase release 7.0.0 the deployment target is set to minimum iOS 10.

Xcode 11 minimum deployment target is iOS 8, and Xcode 12 minimum deployment target is iOS 9.

I'd love to see Firebase (being a foundation project for others) to stick to the minimum deployment target of the past Xcode, that is iOS 8, or at least to the current shipping Xcode, that is iOS 9.

Especially because there is no apparent change in for example Crashlytics which works great on 6.34-spm-beta.

Is there any reason technical reason why we absolutely need bump to iOS 10? For Crashlytics?

thanks,
Martin

[ryanwilson]

Hi @mman,

Thanks for the report. Unfortunately there are quite a few complexities involved and I'm happy to share our reasoning below, and I have a few questions for you if you don't mind!

Before I get into it, we can certainly evaluate if it was a no-op for Crashlytics and see if there are any technical limitations or support issues with moving back to iOS 9 support for Crashlytics using CocoaPods, although it's not preferred due to reasons mentioned below. For SwiftPM, we can only set a single supported version across all SDKs in this repo so it'll have to stay at 10 for other products.

In terms of our approach, here are a few things we take into account:

• Usage. We have some data that shows iOS 9 usage is incredibly small, so we felt it was safe to bump to 10
• Support. We currently support 5 major versions, and that means the testing matrix and support level is high. Supporting an extra major version is just more work, more complex code (conditionals based on supported versions, API availability, deprecations we have to keep around, etc)
• Technical limitations and code complexities across all products
• We can't stay on iOS 8 due to Xcode issues like (The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 14.0.99. #6533) where Xcode 12 adds warnings when a low version is targeted
• Timing. Since our major version breaks are typically out of sync with Xcode releases, we could run into those issues mentioned above and be in a bad state for a while. Never know what Xcode 13 will bring unfortunately
• Consistency across all products and package managers:
  • In SwiftPM we can only specify a single iOS version for all our products, so it makes sense to have the same support floor for all distribution methods
• We try to break as infrequently as possible, so we don't get to update our min targeted version often. Last major release (6.X) we officially had a support version of iOS 9, but Crashlytics stayed on 8 since it was a no-op
• It's becoming more and more difficult to test older iOS versions: in Big Sur (which will likely be required for some Xcode 12.X version) the minimum iOS simulator available is 11.4
• Developers who really need the older version support can stay on the older SDKs and things should work as expected
• Plus some more I'm likely forgetting right now :)

A few questions for you if you don't mind to we can take these into account for future changes:

• What is the minimum iOS version you're supporting now, and why?
• Is there a reason you need to upgrade to 7.0, or just hoping to stay on top of your dependencies (which we always appreciate 😄 )?
• We did have a GitHub issue stating we were planning to move to iOS 10 (#$4847), but it's definitely not discoverable. Can you think of where a reasonable place we could put this be so we can get the feedback before breaking change time instead of after?

Thanks, and hope that gives some insight into why we bump the minimum supported iOS versions approximately every year.

[mman]

Thanks @ryanwilson for the detailed explanation. I am developing for iOS since iOS 2 and for Android since 4.0 so I'm pretty much aware of what complexities it brings wrt/ testing matrix etc.

Our app is kind of special, https://cloudbabymonitor.com/iosapp, as it targets every old device a family has at home, so our usage currently shows around 10% of various iOS 9 devices. Moving to iOS 10 is a no go for at least another year.

To explain my reasoning, I consider Firebase a foundation stone, as much as for example https://github.com/CocoaLumberjack/CocoaLumberjack, and for the foundation stones I think it is a smart strategy to target the same deployment target as the current shipping Xcode (or Xcode one year old) as to not force the depending apps to bring deployment target up arbitrarily. During the past years I have experienced every new Xcode .0 release to be buggy and brick my apps in various ways, so some people prefer to build using Xcode - 1 at least until Xcode .2 feels stable again.

For Firebase, I think this is made unnecessarily complex by bundling together way too many features that perhaps going into the future might be split into separate Swift packages. That way FirebaseComponentXXX requiring some advanced iOS 13 functionality does not need to bump up deployment target for Crashlytics. For example.

Just for the record, I'm now staying on 6.34-spm-beta branch and will therefore not be able to pick up any new changes and/or bug fixes anymore.

Here is the current version requirements for CocoaLumberjack just for the info:

let package = Package(
    name: "CocoaLumberjack",
    platforms: [
        .iOS(.v9),
        .macOS(.v10_10),
        .watchOS(.v3),
        .tvOS(.v9),
    ],

[willbattel]

For the sake of providing an additional opinion, I think one option that a lot of Firebase users would enjoy would be to offer a long-term "maintenance" cycle for previous major versions. While the primary development effort is on vX, vX-1 should continue receiving patches for any grievances outstanding or discovered before the primary effort eventually moves onto vX+1 and vX enters maintenance status with vX-1 finally being considered EoL.

This would allow Firebase users to stay on v6 (and, consequently, iOS 9) without the anxiety that comes from using EoL dependencies in production.

Similarly, I would also advocate for an increase in patch builds where bug fixes are back-ported to applicable minor versions within the same major version. This is out of scope for this issue so I won't go any deeper, but a separate discussion about that at some point in the future would be welcome.

[mman]

Definitely yes and +1 to @willbattel.

[paulb777]

Thanks for the feedback. We'll discuss what we want for a general policy.

At least for the near-term, we'll consider backporting any critical fixes to 6.x for the CocoaPods distribution and we've already done so for one FirebasePerformance issue.

[unitydevadtest]

+1
Around 8% of our users have iOS 9 devices.
We would like to keep Firebase Unity SDK in our Unity app, but we can't remove support for that amount of users.

[cathrynmataga]

Feeling the pain here too. We are an old app, and we have substantial revenue on ios9, can't give numbers, but it's real money. Not an option for me to kill it at this point.

[paulb777]

Thanks for the feedback here. We're not likely to change Swift Package Manager to support iOS 9, but we could consider selectively re-enabling iOS 9 support for some Firebase products via CocoaPods in addition to FirebaseAnalytics which continues to support iOS 9. Please let us know which Firebase products you need on iOS 9 to help with the assessment.

[cathrynmataga]

The only thing that's really a heartbreaker right now is FirebaseCrashlytics. I actually shipped an implementation for RemoteConfig, Messaging and Auth but we never really ended up using that in production.

[paulb777]

We'll investigate the feasibility of changing the Crashlytics CocoaPods distribution to re-enable iOS 9.