I’ve been dipping my toes into some iOS development recently. Nothing too crazy, just pairing with some colleagues and trying to see how we can jointly improve the technical design on both platforms 1.
It so happens that Apple just finished it’s annual conference WWDC, so I’ve been following the announcements closer this timer around. In that process, I ran across a tweet (from Jeff Nadeau who’s a developer working at Apple):
Sort of blown away by the take that a min OS target is harmful to a new framework. It’s absurdly small-minded; one or two years of adoption lag is nothing when the arc of such a system is measured in decades.
To set a little more context: the system Jeff talks about here is SwiftUi, a new framework library that will truly change the way iOS developers write their UI code. The niggle here is that SwiftUI is limited to just adopters of iOS 13.
This basically means:
- Since the adoption rate for new OS updates is about 2 years for iOS, iOS 13 (newest version) will take 2 years to roll out to most iPhones
- iPhones 6 and below will never be able to run apps built with SwiftUi (as iOS 13 will run on iPhone 6S and later only)
I found this bizarrely familiar since this was the exact same problem Google had with Android2 for the longest time. It was frustrating for Android developers because we would come back all excited from Google I/O, only to have the winds promptly taken out of our sails after we reviewed the horrendous state of OS adoption.
It would be pretty irresponsible to start using SwiftUi right now for app developers building apps today.
I do want to make it clear: this is not what Jeff is saying. He’s not suggesting everyone start using SwiftUi right now. The latter part of the tweet clarifies this:
… when the arc of such a system is measured in decades
2 years might just be the cost to pay for iOS developers to have an amazing framework like SwiftUi that will eventually make development cycles 4x better. Especially since a sea of change is measured in longer cycles (10 years?).
That being said, this is painful to hear for app developers today. 2 years is excruciatingly painful. Trust me, us Android developers have been there multiple times.
But this fragmentation problem is something that the Android team has experienced and countered. From the Android Jetpack docs:
Jetpack comprises the androidx.* package libraries, **unbundled from the platform APIs**. This means that it offers backward compatibility and is updated more frequently than the Android platform, making sure you always have access to the latest and greatest versions of the Jetpack components.
This means that when Jetpack Compose (Android’s SwiftUi) comes out, developers can start using it right away. They won’t have to wait for their users to adopt the newest OS update.
I’m curious if the existing iOS infrastructure didn’t allow such a mechanism or it was just a conscious decision to take SwiftUi forward faster, without being held back by the burdern of backwards compatibility.
- Even though Jetpack Compose was announced earlier, SwiftUi looks to be in far better shape as of today. Just look at the examples and documentation (also @RunChristinaRun says so)
- SwiftUi will works on iOS, MacOS, iPadOS, watchOS and tvOS. That’s incredible. Google hasn’t confirmed yet if JetPack Compose will work on more platforms, but the way it’s being built, it sounds like it might be possible
- If you know me, you’ll know why this title is kind of funny
- See supporting the iPhone SE resolution
I also diligently throw shade every time I see them struggle with Xcode trying to autocomplete something. It’s almost laughable how far ahead Android studio is. ↩︎
Granted the case of OS fragmentation on Android is exacerbated by the fact that OEMs control when the device gets an OS update (if at all). ↩︎