The State of SwiftUI

Instead of waiting for Apple to fix SwiftUI, it's completely viable to bring your own abstractions, from React to Reason to Elm, to the web. And the cottage community that works on the most niche web abstraction is bigger than the Apple team allocated for SwiftUI.

It has its downsides, and sometimes we're all too eager to beat the drum of how bad the web can be, but it's also important to recognize the web as a fluke of history where we still have some control.

That said, I give Apple some credit for moving their own platform forward in a way that clearly borrows from what we've been doing with things like QML and React. I look forward to the day when my SwiftUI apps work well on both macOS and iOS. And it will be interesting if we reach a point where we don't need UIViewRepresentable because APIs like WKWebView have been adapted for the new declarative model.

Recall the early days of Mac OS X. It is easy to look back at something like version 10.6 and see how “nice” AppKit worked but it had already evolved quite a bit by then, over many years. If you go back further, like 10.2, you see many rough edges as the APIs were rapidly evolving.

In the beginning, Cocoa was clearly powerful but also surprisingly lacking in some areas compared to Carbon (at least, from a Mac-like UI point of view, as opposed to NeXT). Interface Builder had different UI element libraries for both APIs. Even the common UI elements between the two APIs were not necessarily identical: there were things you could do in one API but not the other. Furthermore, converting a Carbon program to a Cocoa program was a monumental task, requiring things to be downright rewritten for just a basic Cocoa foundation to work properly.

The big difference this time, in favor of Swift and SwiftUI, is that it is possible to integrate brand-new stuff very quickly. Right now, I can integrate: Objective-C, C++, AppKit, Swift, SwiftUI, and a wide variety of other things, and they all compile and link and run. There is nothing requiring me to rewrite 98% my Objective-C app just to integrate my first SwiftUI View. While YMMV, compared to past endeavors this appears to be a much more practical solution for jumping to a new technology.

I had a similar sentiment as the author here but am a little more bullish on it being ready for production. SwiftUI is clearly the future for Apple, it still has a lot of issues to work out, but you can start using it today pretty easily because there's a nice interface for integrating UIKit with SwiftUI.

I revisited the project after WWDC and found that some of the things I was frustrated with were improved and others just required a break and a fresh perspective to figure out. I recommend SwiftUI.

Swift's core team recently found out that they don't understand the type system they've created - they were fixing compiler 'bugs' for months without getting anywhere, until one of them finally realized hey, I should probably attempt to understand what we've built, not just 'fix' a never ending stream of bugs we seem to be having.

Turns out, the type system they built guarantees 100% that type checking is undecidable (in software developer terms, you can crash the compiler by typing perfectly legal Swift code and nobody at Apple knows how to fix it without breaking existing code because they didn't even know they built a language that has this property up until very recently). They figured this out after announcing a stable ABI by the way. Upon discovery, some of the core team members said the discovery was great/nice work.

It's not like we have people who use mathematics to prove properties of type systems without any shadow of a doubt or anything. I wonder how many of them are working on Swift or are employed at Apple, within their multi-billion dollar R&D budget... I wouldn't at all be surprised if the answer was zero, given that it was a software developer who knew a little math who made this discovery.

I think that’s generally pretty reasonable but in my experience you won’t even be able to reach the end of your hobby app without hitting some wall where a feature you want is simple in UIKit and not supported at all yet in SwiftUI. SwiftUI is great, the paradigm is refreshing but unfortunately it just isn’t ready yet.

Sadly, excitement lasted 1 month after I realized that it's not ready. Obscure error messages, random bugs in controls and other annoyances turned my initial excitement into frustration. I managed to make things work but had this feeling of it being fragile.

I see the potential, hopefully in a few years.

https://twitter.com/InvadingOctopus/status/12792872846265794...

It's amazing just how little effort and code is required to build complex scalable layouts that Just Work.

Yes, it does require you to Think Different and you will have to change how you approach UI design if you're coming from legacy frameworks.

That's where the most frustrating aspect of SwiftUI lies, apart from the early bugs and lack of consensus, and this is where some people give up: having to change how you think. Just like Swift itself.

> Of the 10 seconds captured, 30 percent of them are used for the various retain/release and malloc calls in Swift and Objective-C

This is not indicated in the profile screenshot, though I will concede that perhaps it's showing up from the "inverted" view or something.

* Different Betas changing the layout and style and meaning of different attributes. The change isn’t so bad as the documentation. Most of the functionality is sparely documented so it’s impossible to tell if something “broke” or was “fixed” in a new beta. Stuff like .overlay() vs ZStack and how they appear. Stuff like how .padding() is calculated with the default args. Stuff like what the default list modifier does.

* Last beta forgot to ship some symbols in SwiftUI.framework and .toolbar (a modifier to draw a toolbar) was missing. The fact that it slipped notice and nobody talked about makes me suspect nobody is actually using it.

* Common functionality like creating a new window with a different layout is missing. In fact it seems to revolve iOS where new window means same view in a new window.

* Weird quirks like if you dismiss a modal sheet before falling a background task would cause layout issues and random state changes. But if you dismiss the sheet after calling GCD it doesn’t happen. It’s likely a race condition somewhere. Another example https://stackoverflow.com/questions/58404725/why-does-my-swi...

* Missing components like the activity indicator and the new settings tab design for TabView

* You either have no control over the layout or so much control it overwhelms you. For example if you wrap a View with Form it generates a right justified label and left justified field. It works for checkboxes and pickers but it doesn’t work for every component. If you want the same alignment for everything you have to throw away the work done by Form and completely define your own layout rules for everything.

* If you look up how to do anything, the “accepted” answer always feels hacked together and nobody can explain why it works. For example, if you look up how to force center alignment on any object there’s a blog post that’s about 20 pages that propose some solution that’s 200 LOC.

* Day to day, I feel very limited by the framework. At almost every point, I had to compromise the design vision with “what’s possible” in SwiftUI. And note this is a very “simple” app that manages VMs and allows you to change settings. Everything uses basic controls and there’s nothing exotic.

All this aside I still enjoyed using SwiftUI on most days. When it works, it feels like the future. Unfortunately v1/v2 is still very early and it’s filled with bugs. But people need to use it to find and report the bugs. I hope, like Swift, we’ll eventually be at a point where everyone uses it because it’s an upgrade from the previous technology without any compromises.

I'm fairly certain that the elegance and flexibility of the UIKit model, and its uncompromising focus on user experience over developer experience was a key contributor to iOS's success over its competitors.

I'm very sad that with SwiftUI Apple gave in to the tide and started catering to React devs with this gimmick immediate-mode framework on top of their existing retained-mode toolkit. The original NeXTSTEP engineers wouldn't have let this happen...

I assume based on this Swift code can't be swizzled for some reason?

Yep, the blazing speed of reference counting over tracing GC.

Most people tend to confuse good design and good software, unfortunately.