Now I’m confused, should I abandon it and go with the first hand solution? I would actually prefer that but this requires the new versions of the Apple platforms. Why wouldn’t Apple make these available downstream?
Because it probably relies on new stuff that's only in the new version of the operating system. Otherwise, you'd have to back port a chunk of your new stuff to the older operating system, creating a lot more work for little gain.
And why do all of that when over 80% of the installed base will be running iOS 17 within 8 months, so what are you really gaining?
Because Apple cannot figure out that their deployment model is hamstringing adoption of their technologies.
[0] https://github.com/apple/swift-evolution/blob/main/proposals...
https://www.macrumors.com/2023/06/01/apple-shares-ios-16-ado...
If the past is any indicator, the number will be over 90% by the time iOS 17 ships this fall.
Each release gets adopted faster than the previous version; there’s no reason to expect anything different this year.
Also, just about every new iOS release drops support for older iPhones; this isn’t new.
No longer requiring developer accounts to install the iOS 17 beta will only increase the rate of adoption—many millions of users who aren’t developers will be running it before the official release in September, unlike years past.
I'm rather getting a headache with new form factors (window insets, foldables, tablets being revived).
Also: Usually all google libs are backwards compatible to 21. The new ui system (Compose) just gets shipped with the app itself, increasing download/installation size. Apple does not do this afaik, they require a recent minimum OS version for compose ui.
Isn't really an issue these days. Almost everything Google puts out is in the Jetpack libraries and backported many major versions.
80% of iPhones run the latest OS precisely because they are dead serious about long term support for devices.
I‘ve been an iOS dev since iOS 4, and have always been put off by this sneaky way of planned obsolescence. Older iOS releases do get security fixes, but only a tiny fraction of the fixes newer versions get. I don’t find this applaudable.
Apple do seem to be shortening a bit, but as an app developer, we generally support iOS 2 versions behind unless there’s a particularly good feature we want to add to our workflow.
I don’t see much of interest to us in 17, I’m surprised there weren’t any major updates to arkit considering the announcement of Vision Pro
I think, as a dev, it’s reasonable to only target the last 2 versions on iOS, but this is owed to bespoke Apple‘s behavior regarding new APIs. Android devs usually need to support twice as much or more major versions, but it’s way less painful for them because the Support Library (now Jetpack) allows them to use a big part of the latest stuff.
For example, you can use Jetpack Compose (SwiftUI pendant) with min API level 21 which was released 9 years ago. If you have a phone from 2012 that happened to get an Android 5 update, you can run modern declarative UI on that. The first iPhone that can run SwiftUI is the 6s, released in 2015.
Jetpack is cool, but the reason it exists is because the Android OS update picture is appalling. Anyway it doesn’t really address security updates.
Every flagship iPhone since 2011 has received at least five years of OS updates. Some models have received more.
For instance, the 2016 OG $399 iPhone SE got six years of OS updates and just got another security update last month.
In comparison, the original Pixel phone also came out in 2016 and got it's last update at the end of 2019.
There does need to be improvement, but it's not the iPhone side that is badly lagging.