Apple’s use of Swift and SwiftUI in iOS 16

Re:Apple’s use of Swift and SwiftUI in iOS 16 by WoodenChair on Friday October 07, 2022 @04:02PM (#33126236)

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

[ Parent | on HN ]

Re:Apple’s use of Swift and SwiftUI in iOS 16 by bobulous on Friday October 07, 2022 @08:51PM (#33128781)

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

[ Parent | on HN ]

Re:Apple’s use of Swift and SwiftUI in iOS 16 by lloydatkinson on Saturday October 08, 2022 @02:14AM (#33130211)

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.

[ Parent | on HN ]

Re:Apple’s use of Swift and SwiftUI in iOS 16 by furyofantares on Saturday October 08, 2022 @10:18AM (#33132447)

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.

[ Parent | on HN ]

Re:Apple’s use of Swift and SwiftUI in iOS 16 by lloydatkinson on Saturday October 08, 2022 @03:33PM (#33135270)

Yeah good points, thanks!

[ Parent | on HN ]