Closed ingridwang closed 2 months ago
Thoughts on this @NSExceptional?
I personally don't see the need to drop older OS versions without something significant to gain. What APIs are we missing out on that we could only use after dropping support for older versions?
Yes, we have a lot of checks and stuff, but… that code is written already. It works. Why remove/change it?
Looking at the App Store, even Apple's own apps like Apple Music and iTunes require iOS 10 and later. I suppose there's no pressing reason to drop support, but in this case it seems like a good opportunity to clean up old code that's no longer useful.
I still have an iOS 9 device lying around; I take some comfort in knowing I can put an updated FLEX on it at any time for funzies :)
Do you mind if I modify this PR? I do want to merge some of these changes in a backwards compatible way, i.e. gating certain APIs with an if (@available(...))
check. If you leave this PR open I'll see if I can get this in a mergable state ASAP. Would be nice to take advantage of the new APIs where possible
Yeah sure! Sounds good. All the changes in the second commit are backwards compatible - those deprecated APIs' replacements are all available in iOS 9.
Hey, any update on this?
Btw, looks like openURL: (deprecated in iOS 10) is now a no-op in the iOS 18 SDK. (Release Notes, and updated Apple docs)
There's a FLEX usage here which I actually missed in my commit. I suppose technically this won't break anything for folks building on iOS 18 since they'd be getting the new API anyways, but this feels like an indication from Apple that this API will be completely removed in a future release, and should be cleaned up.
Bump on this
Hey, sorry, life is hectic now, I bought a house so I'm spending a lot of time on that lately
Btw, looks like openURL: (deprecated in iOS 10) is now a no-op in the iOS 18 SDK. (Release Notes, and updated Apple docs)
There's a FLEX usage here which I actually missed in my commit. I suppose technically this won't break anything for folks building on iOS 18 since they'd be getting the new API anyways, but this feels like an indication from Apple that this API will be completely removed in a future release, and should be cleaned up.
As the @available
check will only invoke that API on iOS 9 and below where it is not deprecated and not a no-op, I see no reason to remove it yet, along with the other iOS 10 gated code 😅 In the event we do drop iOS 9 support one day, that code can be safely deleted, but until then, it is safe as it is
I have updated your PR and will merge it now. Thanks!
Also, I just noticed you work at Facebook?! Do you guys have a more pressing reason for this project to drop iOS 9 than I do?
Thanks for merging! No pressing reason, we've just been cleaning up our own code and finding opportunities along the way to help clean up third-party code as well.
iOS 9 is nine years old, and by dropping support we can clean up several APIs which were deprecated in iOS 10.
I've also cleaned up a couple other deprecated APIs:
As a follow up question: is there interest in raising the min iOS version even further? There are lots of
@available
checks for iOS 11 and 13 as well.