{"id":35973,"date":"2022-05-24T15:04:48","date_gmt":"2022-05-24T19:04:48","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=35973"},"modified":"2022-06-06T11:13:46","modified_gmt":"2022-06-06T15:13:46","slug":"swiftui-in-2022","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/05\/24\/swiftui-in-2022\/","title":{"rendered":"SwiftUI in 2022"},"content":{"rendered":"

Jake Sawyer<\/a>:<\/p>\n

\n

Even if you already know a bit (or a lot) of SwiftUI, Stanford’s course<\/a> is incredible, amazing, wonderful, AND FREE!<\/p>\n<\/blockquote>\n\n

Nick Lockwood<\/a>:<\/p>\n

Half the iOS devs on my TL keep posting stuff like “here’s how I shipped an amazing full-featured cross-platform SwiftUI app in 10 minutes and the other half are like “Button presses have been broken in SwiftUI for 16 months and Apple hasn’t responded to my radar”<\/p><\/blockquote>\n\n

Greg Pierce<\/a>:<\/p>\n

\n

My SwiftUI development process starts with a clear definition of the problem and ends in a recursive loop of Google searches trying to figure out why the thing I did to fix A broke B, and the thing I did to fix B, broke C, etc.<\/p>\n<\/blockquote>\n\n

Jonathan Badger<\/a>:<\/p>\n

As a newbie to the framework, I enjoy the instant feedback that the canvas preview provides with each code modification and am thoroughly impressed by the elegance and simplicity of SwiftUI’s design. That being said, I have run into odd behaviors and challenging problems that make me want to tear my hair out at times. One such issue, which at first seems trivial, is how to dismiss the keyboard when a user taps an area on the screen that is outside the bounds of a TextField<\/a> or TextEditor<\/a> view. Here, I will discuss a few of the common issues surrounding keyboard dismissal and provide two solutions and workarounds that I have found after an embarrassing amount of googling and combing of StackOverflow<\/a><\/p><\/blockquote>\n\n

Christian Selig<\/a>:<\/p>\n

\n

Has anyone done a nice blog post on integrating SwiftUI as parts of an existing UIKit app and having them communicate nicely? (Many posts are all or nothing) Integrating it for bits and pieces sounds fun, but a bit intimidating. 😬<\/p>\n<\/blockquote>\n\n

Scott Anguish<\/a>:<\/p>\n

\n

It’s a nightmare. That’s what we found.<\/p>\n<\/blockquote>\n\n

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

\n

SwiftUI remains incompetent at basic layout, something Playgrounds users are going to find out the hard way… 😅<\/p>\n<\/blockquote>\n\n

Ron Avitzur<\/a>:<\/p>\n

\n

I’m stuck diagnosing an infinite loop in SwiftUI layout for code that worked on macOS 11.<\/p>\n<\/blockquote>\n\n

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

\n

I’m really<\/em> excited about using SwiftUI in my apps.<\/p>\n

SwiftUI is an unreliable mess that needs to be treated with oven mitts, and I won’t be increasing<\/em> my reliance on it anytime soon.<\/p>\n

That dichotomy is what makes the SwiftUI story so frustrating.<\/p>\n<\/blockquote>\n\n

Oskar Groth<\/a>:<\/p>\n

\n

We’re halfway into SwiftUI 3 and this is yet another example where it fails to provide us with a properly working default control.<\/p>\n<\/blockquote>\n\n

Ron Avitzur<\/a>:<\/p>\n

\n

Today in C++ → Swift: macOS 12 SwiftUI Focus<\/p>\n

.focused($focus, equals: .mathBlock(id))<\/code> is not setting the first responder to my NSViewRepresentable<\/code> NSView.<\/p>\n

Should I expect it to?<\/p>\n

Anyone have insight into how AppKit first responder interacts with Swift Focus for custom views?<\/p>\n<\/blockquote>\n\n

Adam Kaump<\/a>:<\/p>\n

\n

“Hey I got 90% of what I wanted really quick! Neat!”\n“…oh turns out that last 10% is basically impossible, eh?”<\/p>\n<\/blockquote>\n\n

Marco Arment<\/a>:<\/p>\n

\n

I like a lot of it. But it’s not simple, easy, or mature.<\/p>\n

Its conceptual elegance and clean presentation-slide code are quickly ruined by common real-world needs.<\/p>\n

And you frequently slam HARD into walls that you just can’t overcome.<\/p>\n<\/blockquote>\n\n

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

\n

I really do feel like every time I use SwiftUI, even in the simplest of places, it’s burying mines in my code that will be set off at some point in the future<\/p>\n

[…]<\/p>\n

Conundrum: do I spend the hours required to try different combinations of SwiftUI modifiers to hopefully find a fix for this layout issue, with potential of it breaking again in the future, or do I spend same hours porting to UIKit knowing I’ll likely never have to touch it again<\/p>\n<\/blockquote>\n\n

Simon B. Støvring<\/a>:<\/p>\n

\n

I wouldn’t use SwiftUI for core parts of a complex app yet but it’s safe to say that Runestone wouldn’t have so many settings if it wasn’t for SwiftUI. It’s so simple to build settings screens that look decent with SwiftUI.<\/p>\n<\/blockquote>\n\n

Josh Avant<\/a>:<\/p>\n

\n

Today, 2.5 years after release, there’s still validly a more-than-small amount of opinion that SwiftUI is not even Production Ready for mature, complex applications.<\/p>\n

If you have to make the choice today, I say choose UIKit.<\/p>\n

(Unless your app isn’t intended to be mature, complex)<\/p>\n<\/blockquote>\n\n

Helge Heß<\/a>:<\/p>\n

\n

There is very much to like about SwiftUI (and almost all my recent apps use it), but e.g. that it can’t do a very core and basic thing like navigation in its 3rd iteration properly is just embarrassing. 🤷‍♀️<\/p>\n<\/blockquote>\n\n

Helge Heß<\/a>:<\/p>\n

\n

The real difference is that one may have been missing API you’d want (not really), while SwiftUI has API all over but the provided stuff isn’t just bad but simply doesn’t work. Often even depending on context - i.e. it is an inconsistent mess from an API perspective.<\/p>\n<\/blockquote>\n\n

Sam Deane<\/a>:<\/p>\n

\n

SwiftUI lists can get really slow, due to all the clever diffing that goes on for animation.<\/p>\n

There is a workaround<\/a>, but it seems that it stops working if you put the list inside a NavigationView<\/code>.<\/p>\n<\/blockquote>\n

Let’s use value types instead of objects and then allocate a UUID for each one since they no longer have pointer identity.<\/p>\n\n

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

\n

It’s still terrible, takes at least twice as long to do anything for results that IMO are not as good as UIKit.<\/p>\n<\/blockquote>\n\n

Hoà V. DINH<\/a>:<\/p>\n

I’m going to rewrite an app that I wrote with SwiftUI back to regular Swift + UIKit because I’m hitting so many blockers when refining the details.<\/p><\/blockquote>\n\n

Marin Todorov<\/a>:<\/p>\n

💯 internet points for \n@steipete\n for making a landing page for this SwiftUI crasher that you didn’t cause and can’t fix 👌🏼\n<\/p><\/blockquote>\n\n

Russell Ivanovic<\/a>:<\/p>\n

\n

Let’s play a little game called “Will the SwiftUI preview load?”. It’s ok if you’re not an Apple Developer, you can play along!<\/p>\n<\/blockquote>\n\n

Marco Arment<\/a>:<\/p>\n

\n

A day building in SwiftUI:<\/p>\n

I would like a search bar in the navigation bar like every app<\/p>\n

Oh that requires iOS 15<\/p>\n

I would like it to activate when presented<\/p>\n

Can’t do that without rebuilding with UIKit hacks<\/p>\n

I would like it not to hide itself<\/p>\n

Can’t do that, go back to UIKit<\/p>\n

For every hour SwiftUI’s niceness has saved me, I’ve probably lost two more hours to the slow and buggy tooling, scouring the web to make up for its non-discoverability and poor documentation, hacking around its brick-wall limitations, or giving up and rewriting things in UIKit.<\/p>\n<\/blockquote>\n\n

Phillip Caudell<\/a>:<\/p>\n

\n

Writing SwiftUI is like riding a bicycle downhill on a beautiful sunny day.<\/p>\n

Until the bike suddenly explodes, killing you.<\/p>\n

It makes building a production app in SwiftUI extremely difficult when the basic system controls don’t work.<\/p>\n

There’s so much to love about SwiftUI, but still after several years the basics are still buggy as hell.<\/p>\n<\/blockquote>\n\n

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

\n

A tool like SwiftUI which can’t easily handle simple and well-understood tasks isn’t likely to scale to more complex and experimental tasks without seemingly endless frustration.<\/p>\n<\/blockquote>\n\n

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

\n

Abstracting developers from the ‘real’ goings-on is also a means of control on Apple’s part, to shrink us down into a little sandbox we can’t break out of. Can’t compete with system apps if we only have toy APIs<\/p>\n<\/blockquote>\n\n

Michael Love<\/a>:<\/p>\n

\n

Seems like an especially self-destructive policy on Apple’s part in this case, because it’s not clear they have much of a vision for what to actually do with AR apps and by abstracting us away they’re going to make it impossible for developers to help come up with one.<\/p>\n<\/blockquote>\n\n

Ron Avitzur<\/a>:<\/p>\n

\n

Today in AppKit → SwiftUI:<\/p>\n

.keyboardShortcut(.upArrow)<\/code> does not work with .buttonStyle(PlainButtonStyle())<\/code><\/p>\n

but .leftArrow<\/code> and .rightArrow<\/code> do work<\/p>\n

.upArrow<\/code> works with .buttonStyle(BorderlessButtonStyle())<\/code>.<\/p>\n

Filed under: I do not even want to know the explanation behind this.<\/p>\n<\/blockquote>\n\n

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

\n

I can’t help feeling SwiftUI was a massive mistake for Apple.<\/p>\n

I keep seeing blog posts and articles of people trying to write native iOS or macOS apps, using SwiftUI, abandoning it as: too buggy\/much work\/effort\/not worth it.\nAnd then switching to Electron & React Native.<\/p>\n

If Apple had just spent its effort on updating UIKit, adding more standard UI components modern apps use\/need.<\/p>\n

Improving Xcode’s tooling, bug fixes. They’d have 1 really nice \"reliable\" toolset for people to use.<\/p>\n<\/blockquote>\n\n

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

\n

This is my main issue with SwiftUI. It’s a high level black box.<\/p>\n

With UIKit I can: drop down to UIControl<\/code> easily if I want to replace UIButton<\/code>; make my own table view, drop down to CALayer<\/code>’s, customise the CALayer<\/code> a view uses, etc....<\/p>\n<\/blockquote>\n\n

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

And there in lies the problem of why I can never see SwiftUI is a real\/full replacement for any UI framework.<\/p>\n

Either it needs to allow you full control to build the thing.<\/p>\n

Or it needs to be a high level abstraction over top the real thing.<\/p>\n

Currently it’s sort of both badly.<\/p><\/blockquote>\n\n

Ron Avitzur<\/a>:<\/p>\n

\n

@FocusedValue<\/code> as seen in macOS menus is not changing reliably when switching windows despite my best attempts. However, setting a global in response to NSWindow.didBecomeKeyNotification<\/code> seems to work just fine.<\/p>\n<\/blockquote>\n\n

Majd Taby<\/a>:<\/p>\n

\n

We WERE going to include a SwiftUI component in our next update, but alas, I just rewrote it in UIKit.<\/p>\n

This was a result of three situations:<\/p>\n

1. Incomplete APIs in SwiftUI limiting our capabilities<\/p>\n

2. Coordinating the SwiftUI layout updates with UIKit ones was difficult and caused animation problems<\/p>\n

3. Our data model wasn’t designed for SwiftUI, and thus caused a lot of CPU thrash<\/p>\n<\/blockquote>\n\n

Jordan Singer<\/a>:<\/p>\n

\n

Learning SwiftUI unleashed creativity inside of me like no language ever has and brought joy back to building user interfaces.<\/p>\n

Here’s a thread of my experiments to show you what’s possible, to learn from, and code to remix👇<\/p>\n<\/blockquote>\n\n

Rony Fadel<\/a>:<\/p>\n

\n

SwiftUI forces you to think more deeply about architecture compared to UIKit.<\/p>\n

Abstraction hijackings (e.g. getting a reference to and conditional casting a parent or sibling vc) are not possible by virtue of how SwiftUI works.<\/p>\n<\/blockquote>\n\n

Ron Avitzur<\/a> (tweet<\/a>):<\/p>\n

\n

Is it possible to set the isAlternate<\/code> property on an NSMenuItem<\/code> in the macOS menubar to implement dynamic menu items in a SwiftUI document-based app which uses CommandMenu<\/code> to construct the menus?<\/p>\n<\/blockquote>\n\n

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

\n

The harsh reality of SwiftUI in 2022 is that it doesn’t enable a competent dev to build a better app. It gives you a lesser-than-native, less-reliable, less-compatible, less debuggable app — a two-tier system where 3rd-parties may never be able to compete with Apple’s own<\/p>\n

Short of major advancement at WWDC22 wrt to reliability, configurability & back-compat, I’m not sure SwiftUI will ever be the right technology for my apps. Its priorities are clearly elsewhere, and that’s OK. But that isn’t the future of anything, just a lower entry point<\/p>\n<\/blockquote>\n\n

Rony Fadel<\/a>:<\/p>\n

SwiftUI + Introspect gets us that much👌 closer, but I agree that we’re not there yet.\nRight now SwiftUI is a reactive shell on top UIKit with a number of gaping holes (Lists, Navigation, View presentation etc..)<\/p><\/blockquote>\n\n

Russell Ivanovic<\/a>:<\/p>\n

\n

As long as you’re ok with ignoring Autolayout errors. I get tonnes of those in my SwiftUI views and it’s like “what would you like me to do with that info…exactly?”<\/p>\n<\/blockquote>\n\n

Damien Petrilli<\/a>:<\/p>\n

\n

The Joy of SwiftUI:<\/p>\n

Animation in simulator:✅
\nAnimation in Swift Playgrounds on iPad:✅
\nAnimation in the App: freeze and lag.<\/p>\n

100% same code.<\/p>\n<\/blockquote>\n\n

Khoa Pham<\/a>:<\/p>\n

\n

Just finished refactoring a 115+ screens #SwiftUI app to UIKit navigation. Every screen has its own UIViewController and is self-contained.<\/p>\n

Feels so good<\/p>\n

As long as SwiftUI is still based on UIKit, using UIKit is a safer bet.<\/p>\n<\/blockquote>\n\n

Ron Avitzur<\/a>:<\/p>\n

\n

Looks like it is back to UIKit for the UIPanGestureRecognizer<\/code> for me.<\/p>\n<\/blockquote>\n\n

Simon B. Støvring<\/a>:<\/p>\n

\n

Many seem to either like SwiftUI or believe that it’ll get better down the road and be the future of UI development on iOS and iPadOS.<\/p>\n

Is there a possibility that SwiftUI is simply a bad idea for these platforms? That it won’t work?<\/p>\n

I’m starting to fear that as we’re adopting SwiftUI in our apps, we’re also compromising too much. Our UIs are getting simpler but more buggy. We’re becoming slobby.<\/p>\n

Maybe it’ll all work out in the end. I hope it will. But this is a fear that I currently have.<\/p>\n<\/blockquote>\n\n

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

\n

To my surprise (not.), yet another SwiftUI regression has begun to screw with my apps, this time affecting tab-focus and text fields. Appears to have cropped up either in the latest SDK or most recent macOS release. Worked fine when I shipped (& for 2 years), now does not.<\/p>\n

I think once I bail on SwiftUI that’ll be it for me for quite a while. I’ll check back in in 5, 8 years, like I did with Swift, and maybe it’ll be tolerable then. I have a lot of development in me before then, and I just can’t base any of it around SwiftUI<\/p>\n

Unlike early Swift, which was just clumsy to write but could still make a 1:1 version of your ObjC app, early SwiftUI is radioactive and eats holes in everything it touches. I feel like Apple will be paying this one off for a veery long time<\/p><\/blockquote>\n\n

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

\n

One place I can<\/em> recommend SwiftUI: as a preview wrapper for UIKit views & view controllers. This element is hugely useful even to developers who don’t use SwiftUI for any of their code<\/p>\n<\/blockquote>\n\n

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

\n

In March I removed the last traces of SwiftUI from an app, going back to 100% UIKit. I needed block element support in attributed strings.<\/p>\n

In March I also released a 100% SwiftUI app.<\/p>\n

Perhaps they are both good.<\/p>\n<\/blockquote>\n\n

Chris Eidhof<\/a>:<\/p>\n

\n

I was trying to create an NSImage<\/code> out of a simple SwiftUI View<\/code>. Turns out to be surprisingly difficult: dataWithPDF<\/code> is completely broken, cacheDisplay(in:to:)<\/code> has strange artifacts and good old CGWindowListCreateImage<\/code> works as expected.<\/p>\n<\/blockquote>\n\n

Ron Avitzur<\/a>:<\/p>\n

\n

Today’s API eldritch horror experience trying to implement the macOS Paste menu item so that it is enabled or disabled appropriately depending on what is on the clipboard.<\/p>\n

In AppKit, this is very easy.<\/p>\n

In SwiftUI, I’m lost in a maze of twisty APIs...<\/p>\n<\/blockquote>\n\n

Kuba Suder<\/a>:<\/p>\n

This talk is a bit of a mindfuck… I’m gonna have to watch it more than once. Is it just me, or is it… kinda unintuitive that the lifecycle of state variables in that subview depends on whether you write this as if\/else or with ternary operator “?:” ?<\/p><\/blockquote>\n\n

Marcin Krzyzanowski<\/a>:<\/p>\n

\n

overpromise under-deliver in one screen. the title itself is almost an oxymoron<\/p>\n<\/blockquote>\n\n

\nSteven Curtis<\/a>:<\/p>\n

Imagine using a version of Xcode with a major memory leak<\/a> attached to SwiftUI. If it’s Xcode 13 I think that’s fine, they’ll fix in in 13.1. What do you mean, they only fixed it in Xcode 13.2.1?<\/p>

[…]<\/p>

I want to decouple navigation from views. I don’t want to use UIHostingController<\/code> as I would like to create a completely native SwiftUI App. I need to have easy access to views using deep-linking where the screens depend on complex state, and can be accessed from multiple parts of the App.<\/p><\/blockquote>\n\n

James Thomson<\/a>:<\/p>\n

\n

Since installing 12.4, all the labels for my SwiftUI pickers have vanished. Affects my existing versions too. This is a Mac-idiom Catalyst app.<\/p>\n

That’s really not great 🙁<\/p>\n<\/blockquote>\n\n

Ron Avitzur<\/a>:<\/p>\n

\n

Replacing a SwiftUI ScrollView\/VStack with a List View was straightforward and provides swipe-to-delete, and drag-to-reorder rows. However, it also made scrolling the view impossible. Breakpoint on scrollTo does not fire. I fail to understand this.<\/p>\n<\/blockquote>\n\n

Paola Mata<\/a>:<\/p>\n

\n

All these hacks and workarounds for making SwiftUI do basic shit…<\/p>\n<\/blockquote>\n\n

See also: The evolution of SwiftUI<\/a>.<\/p>\n\n

Previously:<\/p>\n