Apple’s Use of Swift and SwiftUI in iOS 18

- 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.

So the number of apps using the SwiftUI lifecycle is 19? Did I read that chart correctly?

What's interesting to me is that this tradeoff (reduced boilerplate, but lose control) was tried many times before, for example with the 4GL languages. Except for quick one-offs, it never worked out, even when it did work.

As Helge points out, the magic of Cocoa is that it manages to remove the boilerplate without actually losing any control. It keeps you on the straight-and-narrow not by preventing you from straying, but by making the intended paths so good that you have very little incentive to stray.

The incentives go both ways. The framework provider is strongly incentivized to make that intended path truly excellent, so the incentives for users not to stray remain in place. Because there is nothing preventing them from doing so except that excellence.

When your users are prevented from straying, that incentive for excellence is removed. While that's not the only problem with that approach, I think it does show through.

@Marcel I agree that that tradeoff has never worked. Do you think “but lose control” is a strategy or just a side effect of them reimplementing decades of API surface, which takes time? I mean it is certainly on purpose, as a consequence of the design, that the system is more opaque and there’s little that you can do with private API, but I see no reason in principle that they couldn’t add a lot of the delegate methods and properties that are missing.

I do think that the incentives are not set up properly. If you remove much of the ability to work around bugs and differences in OS versions but don’t correspondingly increase the framework quality you just end up with worse apps.