SwiftUI in 2022

Jake Sawyer:

Even if you already know a bit (or a lot) of SwiftUI, Stanford’s course is incredible, amazing, wonderful, AND FREE!

Nick Lockwood:

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”

Greg Pierce:

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.

Jonathan Badger:

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 or TextEditor 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

Christian Selig:

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. 😬

Scott Anguish:

It’s a nightmare. That’s what we found.

Steve Troughton-Smith:

SwiftUI remains incompetent at basic layout, something Playgrounds users are going to find out the hard way… 😅

Ron Avitzur:

I’m stuck diagnosing an infinite loop in SwiftUI layout for code that worked on macOS 11.

Steve Troughton-Smith:

I’m really excited about using SwiftUI in my apps.

SwiftUI is an unreliable mess that needs to be treated with oven mitts, and I won’t be increasing my reliance on it anytime soon.

That dichotomy is what makes the SwiftUI story so frustrating.

Oskar Groth:

We’re halfway into SwiftUI 3 and this is yet another example where it fails to provide us with a properly working default control.

Ron Avitzur:

Today in C++ → Swift: macOS 12 SwiftUI Focus

.focused($focus, equals: .mathBlock(id)) is not setting the first responder to my NSViewRepresentable NSView.

Should I expect it to?

Anyone have insight into how AppKit first responder interacts with Swift Focus for custom views?

Adam Kaump:

“Hey I got 90% of what I wanted really quick! Neat!” “…oh turns out that last 10% is basically impossible, eh?”

Marco Arment:

I like a lot of it. But it’s not simple, easy, or mature.

Its conceptual elegance and clean presentation-slide code are quickly ruined by common real-world needs.

And you frequently slam HARD into walls that you just can’t overcome.

Steve Troughton-Smith:

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

[…]

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

Simon B. Støvring:

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.

Josh Avant:

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.

If you have to make the choice today, I say choose UIKit.

(Unless your app isn’t intended to be mature, complex)

Helge Heß:

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. 🤷‍♀️

Helge Heß:

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.

Sam Deane:

SwiftUI lists can get really slow, due to all the clever diffing that goes on for animation.

There is a workaround, but it seems that it stops working if you put the list inside a NavigationView.

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

Paul Haddad:

It’s still terrible, takes at least twice as long to do anything for results that IMO are not as good as UIKit.

Hoà V. DINH:

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.

Marin Todorov:

💯 internet points for @steipete for making a landing page for this SwiftUI crasher that you didn’t cause and can’t fix 👌🏼

Russell Ivanovic:

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!

Marco Arment:

A day building in SwiftUI:

I would like a search bar in the navigation bar like every app

Oh that requires iOS 15

I would like it to activate when presented

Can’t do that without rebuilding with UIKit hacks

I would like it not to hide itself

Can’t do that, go back to UIKit

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.

Phillip Caudell:

Writing SwiftUI is like riding a bicycle downhill on a beautiful sunny day.

Until the bike suddenly explodes, killing you.

It makes building a production app in SwiftUI extremely difficult when the basic system controls don’t work.

There’s so much to love about SwiftUI, but still after several years the basics are still buggy as hell.

Ken Kocienda:

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.

Steve Troughton-Smith:

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

Michael Love:

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.

Ron Avitzur:

Today in AppKit → SwiftUI:

.keyboardShortcut(.upArrow) does not work with .buttonStyle(PlainButtonStyle())

but .leftArrow and .rightArrow do work

.upArrow works with .buttonStyle(BorderlessButtonStyle()).

Filed under: I do not even want to know the explanation behind this.

Kyle Howells:

I can’t help feeling SwiftUI was a massive mistake for Apple.

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. And then switching to Electron & React Native.

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

Improving Xcode’s tooling, bug fixes. They’d have 1 really nice "reliable" toolset for people to use.

Kyle Howells:

This is my main issue with SwiftUI. It’s a high level black box.

With UIKit I can: drop down to UIControl easily if I want to replace UIButton; make my own table view, drop down to CALayer’s, customise the CALayer a view uses, etc....

Kyle Howells:

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

Either it needs to allow you full control to build the thing.

Or it needs to be a high level abstraction over top the real thing.

Currently it’s sort of both badly.

Ron Avitzur:

@FocusedValue 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 seems to work just fine.

Majd Taby:

We WERE going to include a SwiftUI component in our next update, but alas, I just rewrote it in UIKit.

This was a result of three situations:

1. Incomplete APIs in SwiftUI limiting our capabilities

2. Coordinating the SwiftUI layout updates with UIKit ones was difficult and caused animation problems

3. Our data model wasn’t designed for SwiftUI, and thus caused a lot of CPU thrash

Jordan Singer:

Learning SwiftUI unleashed creativity inside of me like no language ever has and brought joy back to building user interfaces.

Here’s a thread of my experiments to show you what’s possible, to learn from, and code to remix👇

Rony Fadel:

SwiftUI forces you to think more deeply about architecture compared to UIKit.

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.

Ron Avitzur (tweet):

Is it possible to set the isAlternate property on an NSMenuItem in the macOS menubar to implement dynamic menu items in a SwiftUI document-based app which uses CommandMenu to construct the menus?

Steve Troughton-Smith:

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

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

Rony Fadel:

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

Russell Ivanovic:

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?”

Damien Petrilli:

The Joy of SwiftUI:

Animation in simulator:✅
Animation in Swift Playgrounds on iPad:✅
Animation in the App: freeze and lag.

100% same code.

Khoa Pham:

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

Feels so good

As long as SwiftUI is still based on UIKit, using UIKit is a safer bet.

Ron Avitzur:

Looks like it is back to UIKit for the UIPanGestureRecognizer for me.

Simon B. Støvring:

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.

Is there a possibility that SwiftUI is simply a bad idea for these platforms? That it won’t work?

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.

Maybe it’ll all work out in the end. I hope it will. But this is a fear that I currently have.

Steve Troughton-Smith:

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.

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

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

Steve Troughton-Smith:

One place I can 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

Kyle Hughes:

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.

In March I also released a 100% SwiftUI app.

Perhaps they are both good.

Chris Eidhof:

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

Ron Avitzur:

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.

In AppKit, this is very easy.

In SwiftUI, I’m lost in a maze of twisty APIs...

Kuba Suder:

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 “?:” ?

Marcin Krzyzanowski:

overpromise under-deliver in one screen. the title itself is almost an oxymoron

Steven Curtis:

Imagine using a version of Xcode with a major memory leak 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?

[…]

I want to decouple navigation from views. I don’t want to use UIHostingController 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.

James Thomson:

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.

That’s really not great 🙁

Ron Avitzur:

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.

Paola Mata:

All these hacks and workarounds for making SwiftUI do basic shit…

See also: The evolution of SwiftUI.

Previously:

• How to Open a Window in SwiftUI
• SwiftUI Performance Tips
• Lifetime of State Properties in SwiftUI
• Micro.blog Moving iOS App to React Native
• How to Find Why a SwiftUI View Is Updating
• The Persistent Gravity of Cross Platform
• 1Password 8 for Mac Early Access
• SwiftUI Examples for macOS
• Shortcuts for Mac
• Apple Documentation and SwiftUI for Mac
• SwiftUI Layout Explained
• What Is Not So Great About SwiftUI
• The State of SwiftUI
• Emulating Equal-Size Constraints in SwiftUI

Update (2022-05-25): Steve Streza:

SwiftUI will be great once it’s production ready. Maybe that will be this year. Until that happens though, this post remains a spectacular cautionary tale of what happens when you go down that road.

Martin Pilkington:

There is a very strong argument to make that declarative UI frameworks are always going to be a case of “faster to get to good, difficult to get to great”

Building great software requires fine-grained control over the UI, but that’s kind of the antithesis of declarative UI.

That isn’t to say you can’t have parts of UI be built declaratively, just that you can’t handle every case people will have with a full declarative framework

Aleksandar Vacić:

I expected such issues back in 2019 (the talk I gave at Pragmaconf) but did not see them taking this long to clear up.

The black box design and complete dependence on Apple to fix issues did not turn out good.

Michael Brown:

This absolutely does not reflect my experience of using SwiftUI. In the 8 months that I’ve been using it intensively the time it has saved me is immeasurable compared to the problems encountered. It is unquestionably better than using UIKit (which I have used since 2010).

matfx:

I have built a production app for a bank in SwiftUI (released in March 2021) but I can relate to all of things described.

Benedikt Terhechte:

Doesn’t even mention how invalid layouts crash SwiftUI apps at runtime!

vinibaggio:

SwiftUI is such a bummer. While I agree with the feelings that it makes UI development so fun and freeing, when you start running into issues, then the magic is shattered and you’re back to the harsh reality that computers are all broken.

Sam Deane:

I do still like SwiftUI a lot, and am using it in production apps.

I ended up making this to fix the List issues. It is crude but effective and does just enough of what I need.

I do still regularly hit brick walls, but a lot of the time I find them to reflect a strongly opinionated design philosophy, rather than just an accidental omission.

In other words, someone is deliberately preventing you from doing something they don’t think you should do.

R. Mark Volkmann:

I have never used UIKit and am a relatively new user of SwiftUI. So far I love it.

Steve Troughton-Smith:

After @jamesthomson’s tweet, it was with trepidation I upgraded to macOS 12.4 to see how the changes to SwiftUI have broken my own apps. Sure enough, all the labels have been removed from my pickers, in the shipping version of Pastel.

See also: Hacker News.

John Gruber (tweet):

I’d like to see leaps-and-bounds improvements announced this year.

Update (2022-05-26): Luc Vandal:

Overall, my experience with SwiftUI has been mostly positive. Of course there were times I wanted it to die in a but I was able to develop & release an app that is on the App Store & actually selling.

Kevin Hayes:

I’m not blind to its bugs and limitations but it’s definitely a net positive for me. It’s working out well in 1Password 8 for iOS, and my side projects are SwiftUI too.

Francisco Tolmasky:

It requires being an expert in it before you can predict its limitations (which often are bug-related and not necessarily “conceptual”). This would maybe be excusable for a beta release, but SwiftUI is now around 4 years old.

Arguably, its original sin is simply not being open source, and on top of that is trapped behind one of the most opaque bug-reporting mechanisms in the industry. Every minor hack involves tremendous reverse-engineering, which may then have to be replicated throughout the community, instead of being a GitHub issue and PR request like in Electron for example. There are of course upsides to the closed-source model, but in 2022, you have to deliver on those upsides if you want to make a strong case for your framework.

Richard Turton:

If you are working with an existing UIKit codebase and are SwiftUI-curious when it comes to adding or updating new features, this article should help answer your questions. I’m going to cover some of the technical details of how SwiftUI works and how state is managed, some tips on integrating SwiftUI into your existing code, and some common pain points.

Update (2022-05-31): Malcolm Hall:

Beginners think it’s not ready yet; experts know it will never work. Take for example MapKit, completely different delegation model vs UIKit. The SwiftUI wrapper is fundamentally broken and will never work perfectly until MapKit is fixed but that breaks existing apps = deadlock.

Another example is NSTableView / NSTableViewDelegate, cannot work with SwiftUI’s diffing model with over 100 rows, grinds to a halt. Which team is going to fix that?

Update (2022-06-06): See also: SwiftUI Is Fine.

iOS iOS 15 Mac macOS 12 Monterey Programming Swift Programming Language SwiftUI Top Posts

8 Comments RSS · Twitter

---

---

---

---

---

---

---

---

Leave a Comment

Name

E-mail (will not be published)

Web site

Δ