Apple’s Use of Swift and SwiftUI in iOS 18
Alexandre Colucci (Mastodon, Hacker News):
iOS 18 contains 6800 binaries, up from 6030 in iOS 17. That’s 770 new binaries.
[…]
Unsurprisingly, the number of apps adopting SwiftUI continues to grow this year. Notable mentions include:
- The new Passwords app
- The Siri.app which now uses SwiftUI
- The Calculator app, which received a notable overhaul
- The new Journal app introduced in iOS 17.2
[…]
iOS 18 now contains 592 binaries using SwiftUI and the number of binaries containing at least one line of Swift code increased by 50% between iOS 17 and iOS 18[…]
In iOS 16, only 4 apps used the SwiftUI-based app lifecycle, and this number grew to 14 in iOS 17. In iOS 18, 19 apps are now using the SwiftUI-based app lifecycle[…]
Migrating an app from the SwiftUI life cycle to AppKit makes me appreciate many of the niceties in SwiftUI. So much more boilerplate code in AppKit. But it’s great to be 100% in control of my windows and the menu bar.
Previously:
- Swift Foundation Unification
- SwiftUI at WWDC24
- Apple Passwords App in Sequoia and iOS 18
- Apple Launches Journal App
- Apple’s Use of Swift and SwiftUI in iOS 17
4 Comments RSS · Twitter · Mastodon
- Usage of Objective-C is still climbing.
- I'm not convinced by the idea to put the usage of Swift UI on the same charts as languages because there are probably a huge part of binaries without UI. The UIKit vs SwiftUI is better.
- considering that the Foundation framework is now internally Swift AFAIK, it would seem obvious that every Objective-C UIKit application is using Swift.
> Migrating an app from the SwiftUI life cycle to AppKit makes me appreciate many of the niceties in SwiftUI. So much more boilerplate code in AppKit. But it’s great to be 100% in control of my windows and the menu bar.
That’s the whole point of SwiftUI criticism. You get a tiny amount (in the grand scheme of an entire app’s codebase) of boilerplate reduction, at the expense you truly lose control of your app. That is a really bad tradeoff.
I don't actually buy that SwiftUI saves on boilerplate. It is a key idea of Cocoa that there is no boilerplate code. Instead you have premade images of wired up objects in the form of nibs. Which actually work as-is, contrary to SwiftUI previews.
