If you are still working on iOS12 App in full mature UIKit, this is not a concern for you, but if you plan on making the step, hear me out:
New APIs, features and importantly fixes are restricted to new iOS versions
As Apple continues to release new iOS versions, we are excited about leveraging the latest from the WWDC — especially with SwiftUI. However, in the business world, where maintaining an existing user base and revenue is critical, app developers often face the big dilemma: how can we adopt modern tools while still supporting older iOS versions?
Supporting older iOS versions isn’t just a technical challenge — it’s a strategic decision that can affect a portion of your revenue and let go abandon a part of your audience. Many business apps need to be accessible to a diverse audience, who may not always update, or be on the latest OS. This means that for an app developer, we need to balance innovation with compatibility.
The Appeal of New iOS Features and APIs for Developers
Each year, Apple introduces new APIs that promise better performance, improved UX, and simplified workflows. SwiftUI, introduced with iOS 13, is one such example. It simplifies UI development and brings declarative syntax, which allows developers to build efficiently and rapidly interfaces.
However, SwiftUI is evolving, and many of its powerful features — like Collection APIs — are restricted to newer iOS versions. If your business app still needs to support older OS versions, you’re left with limited SwiftUI functionality, or you’re forced to fall back to UIKit framework. Either this, rewrite that component, and it’s behavior while using some hacky methods to accomplish your goals, or … drop support for the incompatible OS for that specific feature (Sad Face).
Let's take some example:
Grid — While we have ForEach List LazyGrid, Grid was introduced in iOS16, which is a new way to show a list of items in a two-dimensional layout. Technically, iOS lists, (SwiftUI included) are driven by either UITableView or UICollectionView, and based on Xcode View Inspector, Grid also uses UICollectionView. So theoretically, there is no technical limitation to make OS availability restriction on this new components.
If you are interested in a customizable grid component that displays a collection of data with a fully configurable, flexible layout, take a look at VGrid, a component I build to divert from this OS limitations. (Yes, supports iOS13).
ScrollView — we all know how robust, customizable UIScrollView actually is, right. Jumping on it’s SwiftUI sibling, you actually lose all the customization and behaviors you ever had. SwiftUI’s ScrollView was for a long time a container offering Scrolling behavior to your UI, and only that. ScrollViewProxy already existing from iOS14, but let’s not talk about it issues with LazyStacking components …
In WWDC23, Apple introduced a new batch of enhancements and features to the ScrollView, problem is — iOS17 and above :)
- containerRelativeFrame(_:)
- contentMargins(_:)
- scrollTargetLayout(_:)
- safeAreaPadding()
- scrollTransition()
You can check Paul Hudson always top articles that go in details here:
This set of modifiers actually made the ScrollView a powerful component where you can:
- Add padding to a horizontal list of items
- Enable Pagging
- Scroll to specific items (actually works)
- Observe item display in the viewport
- and more
BTW, if you are interested in observing the display of an item on the screen, and you don’t have access to the ScrollView’s new features, you can always use my implementation, and yes, it supports iOS13. Check it out:
Versioning and API restrictions
A firmware bundles Drivers, Deamons, Kexts, behaviors… but also Dynamic/Static Libraries and Applications. Those libraries act as an interface between the hardware/drivers and the software/applications. While the hardware is static for a given manufactured model, the software is way less static, given today achievements. Over The Air updates, even system reset (iOS18) is possible, so what is really the problem ?
SwiftUI as a framework is bundled with the firmware, means that it is distributed, enhanced or patched only with new firmware updates. Same with iOS default Apps like Phone, Calendar, Camera, etc. And this by design. So the decision was made in early stages about the packaging, and it remains as it is years later.
Exceptions exists though, we will talk about some later, but for now, let’s ask a more interesting question
What the others do ? I mean Google’s Android.
While Google have different constraints to manage, like Android’s compatibility and portability with large manufacturers, represent a major difference in Android vs iOS as firmware, and it could be behind Google’s most flexible API versioning systems.
Google Play Services:
An updatable piece of software that contains crucial frameworks, APIs, and tools used by the system and Applications. So that a store App is not tied anymore to an entire specific firmware, but a software layer, that is decoupled, maintained and upgraded as needed. As a software engineer, you would say: This, is how I should build a software, right ?
Because it has already been done
libswift_Concurrency.dylib, is the actual library that gets silently bundled into your app every time you submit it to TestFlight, and that how we have Swift Concurrency Support on iOS13.
Final Thoughts
Again, without going into details, making assumptions about Apple’s strategies, it’s marketing ;) etc. Supporting multiple OS versions should not be this challenging, each of the above deployment strategy has its pros and cons, and different aspects should be sacrificed for others. Unfortunately, developers needs to make for it either by dropping support, rewrite basic components, using hacky solutions, third party dependencies or private APIs in order to make for it.
This is my 2cents about Apple’s strategy, even though won’t change a thing. I welcome any feedback or input about the subject, and would love to know how you manage this aspect of your software, be on Android or iOS.
Reach me out on X.
