Thoughts on SwiftUI After WWDC 2022
Dear Apple developers,
Buckle up, or get left behind.
💙,
Josh ShafferI’m super pleased that Apple has picked a direction, and is [slightly more consistently] pointing in a single direction.
However, even as someone who [mostly, on a good day] enjoys SwiftUI, this is probably writing a check that SwiftUI can’t quite cash.
I want to believe. Apple announced lots of changes that look great and seem to address common pain points. What’s less clear is whether the new stuff works as advertised and what the current feature and performance limitations are. From a Mac perspective, I sense that some problem areas are still outline views, focus, and large amounts of data.
In which ways is it safe to try SwiftUI because if it doesn’t work out you can easily revert that component to AppKit or UIKit? In which ways is that more risky because it affects the structure of the app such that it cannot easily be excised?
To me, the Cocoa-to-SwiftUI transition feels very different from the Classic-to-Cocoa transition because the first-party apps, especially for Mac, are not good examples to aspire to. It’s not clear to what extent this is due to the technology vs. design and QA choices that Apple is making. And it’s hard to tell what Apple itself thinks because its messaging style is to say that even early and obviously rough versions of new technologies like SwiftUI and Catalyst are ready for prime time and that the resulting apps are great.
Ideally, I would start using SwiftUI for new bits of UI that I add. Realistically, the new stuff requires macOS 13, which means it will be a long time before I can ship code that depends on it.
Apple clearly underlined SwiftUI is future of 3rd-party dev on its platforms, and that UIKit & AppKit are to be lumped in with ObjC/Interface Builder as legacy tech. What Apple didn’t show is how it might get to that idyllic fantasy-SwiftUI from the painful reality it is today
This is especially weird given how the “Build great desktop apps” stuff is all UIKit, and all the cool apps are being built are UIKit.
It would help if they rewrote a major productivity app in it. Something more complex than preferences or widgets or weather. How about Mail or Pages or Final Cut Pro. I don’t think any of those are possible with the current state of SwiftUI. And hence the skepticism.
I’m actually horrified by how bad System Settings is, it should be a flagship UI experience. Also, if they want to announce that SwiftUI is the best way to make apps then they could at least demonstrate it. Using System Settings reminds me of Shortcuts on Mac, where maybe it looks OK at first then it feels so clunky and wrong, like it’s pretending to be a native app.
So, developers, how is everybody feeling about this set of slides from WWDC’s SOTU, now you’ve had a week?
After listening to Craig on The Talk Show, I realized they really mean “best way” (in their vision) not “only way going forward” which is how I originally read it between the lines. It’s clear UIKit and AppKit will be around for a long time.
I heard exactly the opposite. Classic will be useful and a key technology for years, until it wasn’t. Carbon will be useful and a key technology for years, until it wasn’t. I heard an explicit statement that ObjC’s days are numbered.
My answer is from the perspective of a longtime member of the Apple community who has stopped developing for the platform. This set of slides confirms I won’t be going back.
Still seeing lots of people complain that despite Apple being very clear that SwiftUI is the future, they don’t think it’s good enough for them…
It is ready for production, you just need to use it enough to get comfortable with knowing when to fall back to App/UIKit.
[…]
But it also doesn’t fully replace App/UIKit (yet), so start using it incrementally when you can so you can gain that experience properly rather than rushing and failing when it’s too late.
So, are master-detail interfaces with multiple selection of 1,000 complex items loaded from a local database and bulk editing these items finally possible in Swift/SwiftUI 4? With reaction times < 1s? Or is Apple overselling again?
I’d love to hear your feedback on where you think SwiftUI is after all these changes.
- What are the most important missing features?
- Which bits are still tricky to learn and/or do?
- Are there parts where you still rely heavily on UIKit?
The joy of SwiftUI:
- no issue on simulator
- layout glitches on device
Exact same code
In fact, all the SwiftUI improvements announced at #WWDC22 motivated me to resurrect a project I nearly shipped earlier this year but decided not to because of SwiftUI not being ready. Now’s the time!
Previously:
- SwiftUI Changes at WWDC 2022
- System Settings
- SwiftUI in 2022
- How to Open a Window in SwiftUI
- Shortcuts for Mac
3 Comments RSS · Twitter
I don’t think Carbon-to-Cocoa is the right analogy. Cocoa was always pretty darn usable. Apart from the new name, it had been used for years to write NeXT, and NeXT apps. It was a bit of a culture shock for Toolbox (or PowerPlant) developers, but the outright limitations and drawbacks were relatively minor.
SwiftUI 1.0 was more like Mac OS X 10.0. It had a fantastic demo, but really only excelled in a few areas. For actual use, it was severely limiting.
SwiftUI may someday surpass AppKit/UIKit as the best way to write Mac apps, but they’ve burned a lot of developer goodwill along the way. I spent 2 decades filing bugs against Cocoa, and most of those never got fixed. Why should I spend any time filing bugs against SwiftUI now? Like Murtaugh, I’m too old for this shit.
SwiftUI is the best way to write apps huh? Then why is everyone shitting on System Settings?
Sharing cross platform model code makes a lot of sense. Sharing cross platform UI code is not when the platforms UIs are very different.
A preference label left aligned with a switch right aligned on an iPhone is reasonable. On Mac it is not unless the window’s width is constrained to the width of a phone. Instead on Mac, a checkbox is better 99% of the time.
So it seems simple to write a wrapper that abstracts that detail away…but it’s really not. If you have some control that on iPhone will map to a label/ switch that takes up exactly one row of content, mapping that to another platform with screens that do not have the same aspect ratio is not easy, if you want to actually take advantage of the screen real estate. If you do want to take advantage of the additional screen real estate on the Mac, you’ll often find that you have two layouts that are fundamentally different and abstracting that away is very difficult and in many cases probably impossible. So what are we going to get, something like CSS media queries?
Designing a semi-complex UI that scales just for all the different iPhone supported aspect ratios can be difficult. Wasn’t auto layout supposed to solve this like 6 years ago? And now they have SwiftUi and want to throw the Mac in the mix, they’re really asking for trouble.
