{"id":36266,"date":"2022-06-17T15:49:59","date_gmt":"2022-06-17T19:49:59","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=36266"},"modified":"2022-06-17T16:56:50","modified_gmt":"2022-06-17T20:56:50","slug":"thoughts-on-swiftui-after-wwdc-2022","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/06\/17\/thoughts-on-swiftui-after-wwdc-2022\/","title":{"rendered":"Thoughts on SwiftUI After WWDC 2022"},"content":{"rendered":"

Casey Liss<\/a>:<\/p>\n

\n

Dear Apple developers,<\/p>\n

Buckle up, or get left behind.<\/p>\n

💙,
\nJosh Shaffer<\/p>\n

I’m super pleased that Apple has picked a direction, and is [slightly more consistently] pointing in a single direction.<\/p>\n

However, even as someone who [mostly, on a good day] enjoys SwiftUI, this is probably writing a check that SwiftUI can’t quite cash.<\/p>\n<\/blockquote>\n\n

I want to believe. Apple announced lots of changes<\/a> 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.<\/p>\n

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?<\/p>\n

To me, the Cocoa-to-SwiftUI transition feels very different from the Classic<\/a>-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<\/em> because its messaging style is to say<\/em> that even early and obviously rough versions of new technologies like SwiftUI and Catalyst<\/a> are ready for prime time and that the resulting apps are great.<\/p>\n

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.<\/p>\n\n

Steve Troughton-Smith<\/a>:<\/p>\n

\n

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<\/em> it might get to that idyllic fantasy-SwiftUI from the painful reality it is today<\/p>\n<\/blockquote>\n\n

Kyle Howells<\/a>:<\/p>\n

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.<\/p><\/blockquote>\n\n

David Kopec<\/a>:<\/p>\n

\n

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.<\/p>\n<\/blockquote>\n\n

Steve Harris<\/a>:<\/p>\n

\n

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.<\/p>\n<\/blockquote>\n\n

Steve Troughton-Smith<\/a>:<\/p>\n

\n

So, developers, how is everybody feeling about this set of slides from WWDC’s SOTU, now you’ve had a week?<\/p>\n<\/blockquote>\n\n

David Kopec<\/a>:<\/p>\n

After listening to Craig on The Talk Show<\/a>, 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<\/em> time.<\/p><\/blockquote>\n\n

Avi Drissman<\/a>:<\/p>\n

\n

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.<\/p>\n<\/blockquote>\n\n

Ken Kocienda<\/a>:<\/p>\n

\n

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.<\/p>\n<\/blockquote>\n\n

Dimitri Bouniol<\/a>:<\/p>\n

\n

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…<\/p>\n

It is ready for production, you just need to use it enough to get comfortable with knowing when to fall back to App\/UIKit.<\/p>\n

[…]<\/p>\n

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.<\/p>\n<\/blockquote>\n\n

Ilja A. Iwas<\/a>:<\/p>\n

\n

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?<\/p>\n<\/blockquote>\n\n

Paul Hudson<\/a>:<\/p>\n

\n

I’d love to hear your<\/em> feedback on where you think SwiftUI is after all these changes.<\/p>\n