Here's a prime example of what developers mean when they question "is SwiftUI ready for production?”

A simple menu. Left iOS 16.4. Right iOS 17.0.

One works. One fails. Same code.

I love SwiftUI, but it's this kind of thing that make me lose confidence in it.

No doubt you can ship amazing things with SwiftUI. I see many great examples of it.

But I also see many examples of developers pulling their hair out trying to understand why their app isn't behaving as expected.

Things that once worked now don't because of an OS update. Or some modifier begins interacting with something in an unexpected way. Or something isn't clearly documented.

Airbnb's recent article highlighted something I think about a lot:

"While Swift and its surrounding foundation have been open sourced, SwiftUI’s implementation remains a black box. If SwiftUI were open sourced, we could better understand the framework and debug more effectively.”

I don't think Apple will ever do it, but boy that would go a long way in fixing many of the issues SwiftUI has today.

(The whole article is great read, btw)

And look, Apple's frameworks have always had bugs. Many of us lived through UISearchDisplayController 💀

But there are two differences:

1. UIKit/AppKit's API surface is much larger. There are just more knobs and dials to turn when things aren't working. Abstracting complexity comes with a cost.

2. The frequency and severity of issues. It would be unimaginable if UINavigationController was left broken for several cycles, but that's exactly what's happened:

@phill Although I agree that all those change of behaviours between versions are annoying, I have to say that we all faced many problems with UIKit in a long past.

Countless hours in new iOS releases checking the hacks we needed to implement for something that UIKit didn’t support. Hours debating about dropping something in favor of a new API for newer iOS versions, etc.

I see the same happening with SwiftUI, just that this time we have much more platforms to discuss.

@phill I didn’t see people in the past discussing “oh is UIKit ready for production?” because that was the only option we ever had, so we collective had to invent clever ways around it and share in StackOverflow.

Now that we can openly discuss “why SwiftUI is not open-sourced” is already a long, long way from that past that it wasn’t even thinkable.

@rabc You're absolutely right that UIKit is not without its faults:

But we're in year 4 and the fundamentals like List and Navigation are still having significant issues. That is different.

@phill i'm writing my first swiftui app (for the company i work for)

There are some workarounds and mentality change to perform, but its doable

But our UI is almost all Custom, i think the main source of problem for swiftui is the usage of Navigation/TabBar ecc…

As UI Layout composition is really great, as abstraction layer i dunno

@GiorgioRomano anecdotally it does seem to be the boundaries of UIKit/AppKit that have the most issues.

And you're right, it’s phenomenal for layout composition 🙂

@phill @objc anytime I look at SwiftUI stack traces when troubleshooting they involve the C++ AGGraph that does not look feasible to debug in a reasonable amount of time.

Changes to the backing layer that sometimes are not even UIKit anymore also do not help, and even if it was UIKit, that’s closed source too.

The Swift language may be open source, but when I run into a compiler issue I’m unlikely to be able to fix it in source. I think this would be a similar case for non-large teams.

@giladronat @objc all very true and excellent points.

But I imagine just like Swift itself, you wouldn’t need to understand the source to benefit. Countless contributions from the community make it less likely for you to experience issues in the first place, either by direct fixes to the lang, or through the dissemination of knowledge.

@phill @objc definitely, and I agree that it _would_ be nice, and even personally I’m more keen to learn to contribute to a UI framework than I am to a compiler. I just don’t think it would have a significant impact on day to day development.

@phill @objc I also suspect from reverse engineering the framework throughout its iterations that Apple has been making sweeping changes to it fairly frequently. These changes would not fly easily in an open source environment without RFCs, suggestions, or disclosing the direction of the framework. I can imagine it would be a big commitment for them to reveal all future cards.

I’m optimistic for better debugging tools in the future, but not for open sourcing.

@giladronat 100%

Like I said I don't think it's something they would do. It's just hard not to draw comparisons to Apple's other OS efforts where it's been working out so well for everyone.

But who knows: they've surprised us before 😛

@phill it’s because Apple thinks what they made is really special. And it is not, it’s just a buggy UI Framework. It’s really frustrating.

@phill I think it’s just about ready for production on iPhone. iPad and Mac not yet. It really needs to be open source, at least in part.

@phill can’t say this is all that much different from UIKit. It’s just that sometimes there’s no way to fix it due to lack of API/access and you’re left waiting or redoing it in UIKit.

I still think using SwiftUI first is a net gain productivity wise. Assuming you’re staying close to Apple’s HIG.

@phill Yep, until SwiftUI will be stable across at least 3 OS releases, it's really hard to use it right now in larger, matura apps 🤔

Indie devs will have problems as well, it's ok to ship a new app with iOS 17 as requirement, but what about few years?


@kkolakowski @phill I feel like UIKit has only been “stable" since Apple's focus moved to SwiftUI. Before that, there was hardly a year without some change about NavigationBars, ScrollView insets or SafeAreas breaking everything…

@kaybutter @kkolakowski Sure, there were issues (see but I would argue the severity (and recourse) were very different.

One objective measure: my first Radar/Feedback was 2012. Historically I've done one or two a year. This year I've filed 13.

@phill an important question: did it stop working for the previously compiled binary, or only when you compiled with the latest SDK?

(The first one is not acceptable)

@phill Please file feedback for the SwiftUI team if you haven’t already.

@phill Looks a bit similar to what I see with toolbar actions that are marked as secondaryAction. These get grouped into a menu which when shown quite often seems to trigger an UIKit error (seen in the console) which then kills any other toolbar actions from working in that view. When the view is recreated the other actions work again.

Always lots of these "don't they even test any of their own shit" type of bugs with SwiftUI.

Sign in to participate in the conversation
The Not So Big Company

The home of The Not So Big Company on Mastodon.