> SwiftUI is a joy to work with and performance is great.

It really is, unless you want to draw outside the lines. If I want to do anything that isn’t explicitly in the SwiftUI model, it becomes Kludgeopolis, very quickly. There’s some things that can only be done with UIViewRepresentable, which I consider to be a bit of a “white flag.”

Also, because of the way that the rules are written, it’s difficult for me to segregate areas of functionality into extension blocks (like I do, with UIKit). I tend to have fairly long blocks of code, which is less than optimal.

But the performance really is excellent, and I can often get a lot done, with much less code, than UIKit.

Never worked with hybrid systems, like React, so the same might be true for them.

▲

oliverjanssen 3 hours ago | parent [-]

Totally agree – it can get messy once you go off the beaten path. But for most things you can build so much with just SwiftUI and a few Apple frameworks. No node_modules with 500+ dependencies. Coming from web dev that still feels like a luxury.

▲

willtemperley 2 hours ago | parent [-]

It’s easy to build high performance custom components, for example with Canvas which is excellent. However, at the top level of an app it’s got to be the standard way.

That may be a good thing for usability across apps but it feels like a low code platform sometimes.

	▲	oliverjanssen 3 minutes ago \| parent [-]
		Know what you mean. SwiftUI can feel similar – great for standard patterns, but you hit walls when you want something custom. Ended up mixing in UIKit for some edge cases. Trade-off I'm willing to make though. For a solo project, fast iteration beats pixel-perfect control.