Why I quit using SwiftUI

Success to me looks like steering clear of SwiftUI for now, and advocating for Apple to hire documentation editors/leaders who can 1) create SwiftUI documentation of code examples for how to escape out of SwiftUI to handle more-complex cases, and 2) accelerate Xcode speedups of SwiftUI testing-and-instrumentation techniques such as View testing (e.g. ViewInspector) and integration testing vs. unit testing (e.g. reactive vs. dependency injection vs. extension tests vs. protocol tests etc.)

A couple observations:

- SwiftUI is really complex

It's going to take you at least a year to get used to the declarative way it works, and be able to make UIs without struggling to figure out how to shuffle data around. If you look at SwiftUI examples/code, most of the complexity is hidden, but it's there, and you're going to have to interact with it to do anything non-trivial.

- Is SwiftUI the way?

SwiftUI has enabled me to build out huge amounts of beautiful UI quickly – faster than anything I've ever used. But you will run into things you can't do, forcing you have to fall back to AppKit/UIKit. And the area where AppKit/SwiftUI meet will disappoint and frustrate you. I just got done refactoring a huge amount of my app to use the "AppKit App Lifecycle" instead of the SwiftUI App lifecycle since I need some specific windowing behavior. Now I can't use .toolbar, .menu, and other stuff, which makes things much more complicated for me, and forces me to think about both SwiftUI/AppKit. Switching mental models like that, and trying to remember all the intricacies of both SwiftUI and AppKit is rough.

--------------

Regarding the performance issues of this specific post, my guess is they put everything into an ObservableObject, and used @Published properties to get bindings for their UI controls. This means any view with a reference to the ObservableObject gets re-rendered when @Published values change. Instead you need to silo your changes, so your entire App isn't redrawn every frame. This goes back to the complexity – it's not straightforward at all.

On Android, at least, Compose feels fully baked to us. Our shop is fully committed to new development on Compose UI; bridging tools for legacy components work great, and they work great for hosting new Compose views in our legacy framework as well. The Compose team is engaged with the community, and is generally ahead of the ball on problems real engineers are having.

In addition to all that, the structure of Compose has led to its new tooling being used in a variety of other domains. Engineers outside of Google are wiring Compose up to TUI frameworks, to platform-independent view APIs, and even running Compose without any UI at all as an asynchronous programming framework.

I don't have any experience with SwiftUI to compare it to. As an outsider, I know that the naysayers are sometimes louder than happy consumers of a new technology. But I will say this: there's a whole narrative in the Android world pointing out that Compose and Compose UI are two different things. Compose is available to use and work with even if you never touch the concrete UI framework Google has built.

Does any equivalent narrative exist in the iOS world? Or is SwiftUI mostly just a UI framework?

People don't think about it, but UIKit now has ~15 years of effort put into it, and got a serious boost from its shared roots with AppKit (even though big chunks of UIKit were freshly written, its structuring and API design were largely informed by AppKit), which has history tracing all the way back to the 1980s. Of course something as fresh out of the oven as SwiftUI is isn't going to be able to compare in terms of polish or capability.

So for now I'm sticking to UIKit in the apps I'm responsible for. I think SwiftUI's day in the sun is coming, but it's not here quite yet.

That doesn't mean that there aren't issues with how it's being engineered and documented, though. It has serious shortcomings that need to be shored up, and hopefully that happens with its maturation.

But it looks like the task was somewhat beyond the people who had the responsibility for rolling out SwiftUI at Apple.

We're several years in to SwiftUI.

Apple's in a tough spot now. I'm really glad I don't have anything too high-stakes dependent on it. (I only have a project with ~200 hours invested -- not zero! -- it's heavily UI, but it's tiny... maybe ~30-40 hours to port to UIKit, if needs be.)

For the rendering part, it depends, I'd say it should take between 0.5 and 2ms with many layers, a lot or transparency and not much care for optimization.

Very unexpected things happen, like items in a specific region in the App UI stop responding to clicks next time once you interact with them.

However I find it fine on iOS and the issues are usually around Apple changing something in the behaviour of the UI or API and breaking it, then you need to fix it for specific versions of the iOS. That's what you get when a framework is not mature yet, I guess.

That said, I don't think there's a turning back. It might be buggy but it definitely feels like the right way of building UI.

Oh, about the performance, you can build very sluggish or very responsive UI with SwiftUI because there's a night and day performance cost difference between "re-calculating and re-drawing" the UI and adjusting a property of it. Always try to structure your components in a way that changes happen by changing passed values instead of inserting or re-doing the views.

SwiftUI works quite a bit like React, many performance lessons from React will translate into SwiftUI.

If the bugs are bad enough I can always do something custom in UIKit via UIViewRepresentable.

The current project that I'm working on, is pretty big. It peaked at 40 screens, but I'm trying to get it down to half that.

I've been working on it for two years. I also wrote one of the backends (and most of another).

There was no way that I was going to start on a project of that complexity on SwiftUI, which, at the time I started, had only been demonstrated in a few small projects. I already knew that UIKit could do it.

But I think that SwiftUI will become the standard, sooner or later. I look forward to being able to write more reactive applications in it. In my experience, if I use UIKit, it's a fairly bad idea to stray from the old MVC model (This, I have learned. <Pulls up shirt> See this scar?).

I hope Apple never goes the way Microsoft did with their fad UI toolkits that utterly destroyed developer trust in native Windows development (MFC, WinForms, WPF, UWP, WinUI, .Net MAUI). They are pretty wise for keeping SwiftUI be the "for kids" vanity UI toolkit to lure in React webdevs, while keeping UIKit and AppKit for serious stuff.

Apple's sell for SwiftUI was "it's like going to a chef who knows how to cook for you" instead of "cooking yourself". But is that really a good thing? Do we really want to be taking less control of our applications when we write them?

The worst part is all these tutorials that have to combine SwiftUI and UIKit because the former is very buggy in certain cases, like navigation trees on iOS have really janky animations using SwiftUI. So you have to coordinate all your Views using UIKit. It just seems barely easier to use SwiftUI most of the time.

EDIT: Basically, in summary, it seems like a very complicated (look at the crazy language features they had to add for it) plus very opaque ("it magically does it for you just how you wanted") way to write the same apps you were already writing fine in UIKit and AppKit

That... is exactly the same thing with React. You don't notice everything is redrawn until suddenly everything is unbearably slow. And then it's useMemo etc. galore.

I'll withhold my judgement on SwiftUI for now though.

Well done

After two years with Xcode/Swift/SwiftUI I never succeeded in getting anything useful out of the profiler.

I ended up implementing a similar rate limiter, I think based on this here: https://weblog.west-wind.com/posts/2017/Jul/02/Debouncing-an... (I've never shipped it though.)

The art is to get the behavior just right. You want the first request to go through immediately, so on a single click the user sees low latency. But afterwards you need to throttle it so that it only updates every, say, 500 ms. And you must not forget to display the very latest state, if there is no new event after e.g. 50 ms.

This seems like one of those things that are really hard to get right and the toolkit developer should have solved for you. I've struggled with it a couple of times now.

The issue is that Apple sort of claims that this is all you really need to do, and that the framework will kind of handle it for you. In reality you need to be really careful about what's being updated to avoid spurious updates. Actual SwiftUI code for anything non-trivial necessarily requires some manual debouncing and equatable checks. I hear React Native often has the same issue, but there people have experience with applying memo when necessary. With SwiftUI it's considered "advanced" and bites people before they really know how to deal with it. And, of course, that's assuming that the dependency graph is working correctly: if it's not, you're often stuck and there's often not much you can do.

In my experience, you definitely have to minimize work done in Views and maybe avoid `@Published` properties on your model in favor of more explicit calls to `objectWillChange.send()` to signal when you really are ready for the Views to be updated. SwiftUI does not seem to do a very good job of coalescing by default.

btw, please add an RSS feed to your site. If you have one it's not discoverable via in-page links, link tags, or educated guessing.

You have to look closely to new requirements that they roll out every few months. You should use Apple products in your app or gtfo (e.g. login with Apple ID). You have to update your laptop every few years because Xcode (which is monumental PoS) requires new MacOS that your hardware doesn't support. And when you go through all this trouble, you have to literally beg Apply to admit a new version of your app. You even have to pay Apple to be able to write apps for their phones/tablets.

I'm so glad I jumped off iOS development a few years ago.

If you're a young developer and still not decided what area suits you the most, think twice before entering iOS and MacOS development.

I haven't really coded things since I was a kid and since I have an iPad/iPhone/iMac and wanted to learn how to code again and potentially use it as a side hustle or some sort of future money making opportunity, I decided to learn swift/swiftUI and i'm currently taking an online course, but when I read through hacker news, all I see is articles bashing it constantly.

The tooling will always be less mature than you can find elsewhere. And in the end, all you have is a thing that works only in the walled garden.

Of course this observation is not limited to any particular garden.

The lack of support for Video and Camera from SwiftUI was the most challenging part for me as a newbie  Mac dev.

Took me a few weekends to get the core part done (ML and algorithm), but hooking up all the UI components and connecting them with the video stream gave me so many headaches.

With that said, it was still much easier for me (complete newbie to  Mac App at the time) to learn and develop in SwiftUI than UIKit.

Hope SwiftUI keeps getting better and  keeps investing in the team.