Apple’s use of Swift and SwiftUI in iOS 16 | Hacker News Reader

Apple’s use of Swift and SwiftUI in iOS 16

blog.timac.org

59 pointsWoodenChair12 comments

"When performing this analysis, one number surprised me: iOS 16 only contains 4 apps using the SwiftUI-based app lifecycle:

/Applications/Batteries.app/Batteries

/Applications/FTMInternal-4.app/FTMInternal-4

/private/var/staged_system_apps/Weather.app/Weather

/System/Library/CoreServices/AegirProxyApp.app/AegirProxyApp "

This makes sense since only apps (re)built from the ground up would use the SwiftUI lifecycle instead of the UIKit compatibility layer

There’s something about weather apps. Across platforms whether desktop apps or mobile or web, weather apps seem to get rewritten/refactored the most. I wonder why that is?

Is it because it’s perceived as a “lower risk” to try out new tech like SwiftUI on “smaller” features like weather? If it is, why is it so often weather and not for example calculator apps?

One example I can think of is the weather apps between Windows 8, 10 and 11.

Weather apps seem like a good UI playground. Lots of different types of widget, and if you change the UI it's not a big deal. Changing the UI for something more complex that people had to learn and now have to relearrn, in software that people work with (rather than just getting info from), tends to be really negative for users. Much less the case for a weather app I think than a calculator.

Yeah good points, thanks!

You should do the same for macOS! Cool analysis, I appreciate it

The author has done so, in August - https://blog.timac.org/2022/0818-state-of-appkit-catalyst-sw...

Swift passing C++ is a big deal

It is, Apple moving focus away from clang is one of the reasons why clang is now lagging ISO C++ support, in an honorable 3rd place, if we don't count all those UNIX, mainframe and embedded compilers that still exist outside of the big three.

C++ on Apple plaforms is mostly used for Metal Shading Language (a C++14 dialect), IO and Driver Kit (with IO Kit being an Embedded C++ dialect), and the minimum ISO required for LLVM (ISO C++17).

Google likewise is mostly focused on what their style guide allows, is adopting Rust and now ex-clang contributors came up with Carbon.

From all mainstream OS vendors, Microsoft is the only one that still doubles down on C++, no wonder that VC++ has the best support for ISO C++20.

So who if so many big actors are losing interest, who is driving the ISO committee? Are we bound to see more conservative standards in the future, or are the remaining people going to turn the place into even more of a madhouse?

About 350 people that go through the effort to submit papers, fight for them until the voting, everything that wins feature election lands into next ISO round.

Stuff being in ISO doesn't imply compiler vendors will bother with such features, see exported templates, which only EDG bothered with, everyone else ignored them, and eventually got replaced with external templates instead.

EDIT: Bjarne also has only one vote like everyone else, thus this paper from him is quite relevant, https://www.stroustrup.com/P0977-remember-the-vasa.pdf

> About 350 people that go through the effort to submit papers, fight for them until the voting, everything that wins feature election lands into next ISO round.

But what would be the point if major compilers refuse to implement these features? C++ is complex enough that it won't be easy (or even plausible?) for a new interested party to develop a high quality compiler. Is C++ going to become Microsoft's plaything?

Reply on news.ycombinator.com