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.

https://gist.github.com/phillipcaudell/269e1d9abe1dea1709327fc95560760f

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)

https://medium.com/airbnb-engineering/unlocking-swiftui-at-airbnb-ea58f50cde49

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: https://mastodon.notsobig.co/@phill/110939609793823190