Bugs happen, I get it, I write buggy software too. But my god, I have never in my 14 years of writing apps for iOS have the ground move beneath me as much as it has with #SwiftUI. A couple of issues every now and then I can forgive, but it's not. It's every update, something has broken or changed.

It may be a beautifully expressive framework, but it doesn't matter if it doesn't work reliably, all the time, every time.

Something is deeply and systemically wrong with it.

@phill Yup! The API is great and I defended it a bunch. It *can* be the future. But the implementation is buggy as hell!

They should’ve started with a smaller featureset, made it solid and added more over time.

Instead they started with almost everything and have been tweaking it ever since!

@phill The general bugginess and the differences in behaviour between the iOS versions in the main showstopper for SwiftUI usage in the commercial apps in my opinion.
Unlike personal projects, we do have to support at least 2-3 major OS versions back, not to mention all the minor ones. We cannot reasonably cut-off all the users that are not on the latest and greatest OS.

@shantara definitely agree on prior iOS support. I had begrudgingly accepted that I will be iOS 16 only, but I can't even do that! It's utter madness.

@phill leaving aside whether this bug should’ve shipped, what makes this so troubling is that you simply *cannot* downgrade. You can’t ship a custom SwiftUI version as a dependency. You get whatever your users have installed, and if Apple releases an OS update and it contains a change you have to workaround, you have zero days to prepare.

@chucker Surprise Driven Development™

@chucker @phill This sounds like all the same problems highlighted in https://www.construct.net/en/blogs/ashleys-blog-2/safari-releases-development-1616 of testing betas and seeing bugs and not knowing if they'll get fixed or if you can workaround them, or when they'll ship and Apple refusing to provide any transparency. It's *so* frustrating.

@phill that sucks, I hope you find a path. I’ve had to give up on almost every SwiftUI project I’ve had at one point or another.

The sad fact is that until Apple dogfoods it to the point where they are using it to build iWork and the Pro apps, it just isn’t ready. There are just too many massive gaps in terms of functionality and DX, and that goes triple on macOS.

@phill

Fundamentally I think SwiftUI is a mistake. It is leading to years of effort spent to just get to achieve the performance and stability that UIKit already had. I think we will look back at these as lost years. Instead of new features or improving stability, wasted years chasing the new hotness.

I don't think that 'declarative' UI layout is as clean a win as its proponents do. Furthermore, I believe we could have achieved many of the same improvements by continuing to improve UIKit

@amonduin I suppose the rational was to have some common API language across platforms, which I get. But it just seemed they did too much too fast. You’re right in that they probably could have added some of these things to UIKit/AppKit first (cell layouts spring to mind).

@phill I think UIKit could span across platforms as well (unless there is something about the AR headset that precludes UIKit). On the Mac Catalyst has made tremendous progress and I can only imagine how much better it would be if they weren't also trying to rebuild the Mac UI on top of SwiftUI at the same time.

Edit: I also think part of the rational is not wanting to be seen as falling behind. Declarative UI is seen as 'modern' even though it is as old as AppKit