
The State of SwiftUI - tosh
https://steipete.com/posts/state-of-swiftui/
======
hombre_fatal
Building clients on other platforms makes you appreciate the freedom we have
on the web.

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.

~~~
contextfree
How can this possibly be true? Web UI frameworks are built on top of the
browser platform, and browsers are built on top of native desktop platforms,
so aren't native desktop platforms inherently more flexible than web UI
frameworks?

~~~
zepto
You are completely correct.

If people want to use web technologies on the desktop, there is Electron.

The converse is not true.

~~~
noahtallen
Right, but only for macOS. I imagine most Swift/SwiftUI development targets
iOS, where web is really the only other target available.

~~~
zepto
There’s nothing stopping you from using web technologies to develop iOS apps
in exactly the same way.

Quite a few of the ‘cross platform’ toolkits work this way.

------
makecheck
I’d say that waiting a few years for stability is not so different from past
paradigm shifts.

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.

~~~
mpweiher
> version 10.6 and see how “nice” AppKit worked but it had already evolved

I started programming on NeXT in 1991 and AppKit was already very _nice_ (not
"nice") back then.

Target/action, for example, was a revelation, together with the responder
chain. Miles ahead of everything at the time as well as most if not all the
stuff that followed. Now we're back to tightly coupling everything and calling
it "progress".

------
choxi
I wrote a similar post but from the perspective of the developer experience
instead of performance and stability: [https://getglyph.app/blog/3-building-
glyph-a-year-with-swift...](https://getglyph.app/blog/3-building-glyph-a-year-
with-swiftui)

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.

~~~
samatman
I'd love to read it!

But using a thin font in grey on a white background makes that quite
impossible.

Please have some pity on people whose eyes aren't perfect.

~~~
Miiko
Here's much more readable version, produced by TRIM web service:

[https://beta.trimread.com/articles/38118](https://beta.trimread.com/articles/38118)

(you can also go to the main page of this site and enter the URL there)

------
matt2000
I appreciate the author putting this post together. I am, however, having
trouble squaring the overall positive tone of the piece with what seem like
multiple show stopping problems. The bottom line I am taking away from this is
you might not be able to ship your app at all if you use SwiftUI. Am I being
too harsh? Or does that seem accurate?

~~~
ollysb
I started building a side project in Swift/SwiftUI for the first time a few
months back. It has quite simply been the most painful development experience
to date (I've been a professional developer 16 years - front/back/many
languages). I've wasted a huge number of days trying to get the damn thing to
build reliably, or getting preview to work without hanging the machine or any
number of random issues that generally go away if you just rebuild the project
enough times... On a side project it's been a real motivation killer, instead
of building my app I spend my time trawling through bug reports and trying to
find workarounds for broken features. At this point I'm considering starting
from scratch with Flutter. /rant

~~~
ZeroCool2u
Flutter has been the most fun I've had writing mobile apps in a long time.
Generally just works and with just a bit more effort you can even get the
desktop version of your app running. Definitely recommend for a fun side
project.

~~~
jamil7
I’ve tried Flutter a few times and it doesn’t stick. Part of my issue is
finding the stock cupertino widgets to look kinda off and the material design
widgets to look out of place on iOS. Maybe Flutter is great for when you have
a custom design to implement or you’re primarily targeting Android? I also
strongly prefer Swift/Kotlin to Dart but I’m sure I’d get used to it.

------
alex_g
I spent a month working on a SwiftUI app back in April. I hit a point where I
was frustrated that I was wrestling with the limitations of the framework. I
put the project on hold and was considering moving to React Native or UIKit.

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.

------
usmannk
The author’s takeaway here is “If your target platform is iOS 14, you’re now
good to go with hobby projects or individual screens in SwiftUI.”

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.

~~~
jamil7
The way I've been doing it is to mix the two frameworks together and that
seems to be working out, it's easy enough to wrap UIKit views in a SwiftUI
project or go the otherway and introduce some SwiftUI components to a UIKit
app. I feel we won't see "complete" SwiftUI apps for another 2 years or so,
maybe thats the intention?

~~~
usmannk
Yeah, that's more or less the only way to go if you want to use SwiftUI.
Personally at that point I just prefer going full UIKit instead.

> I feel we won't see "complete" SwiftUI apps for another 2 years or so, maybe
> thats the intention?

Unsure about intention but it is definitely the expectation :)

------
alexashka
Any software developer using _any_ software released by Apple within it's
first 2-3 years is a free beta tester.

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_.

~~~
Tainnor
You raise an interesting point, but it is my understanding that Swift is by
far not the only language that has a shaky foundation in terms of type theory.
Other type systems can at least be unsound, I don't know if any of them is
undecidable.

Even so, "undecidable" doesn't need to be a problem. It would be possible that
the undecidable Swift program is such a random mess that nobody would be
likely to write it by accident.

However, it is worth looking into more practical aspects of how Swift's type
system works, and there I share your concerns. Swift is the _only_ language I
have ever used where I have ever seen the error message "the type checker was
unable to infer the type of this expression" etc. - sometimes on dead simple
code. Worse, I once tried to write an expressive, generic, functional
framework, only to discover that it was completely unusable because the type
errors that Swift returned were simply wrong and to fix it you had to put in
type annotations in a bunch of places (without necessarily knowing where, just
from the error messages), making the whole API extremely verbose and not
particularly declarative anymore.

~~~
favorited
> Other type systems can at least be unsound, I don't know if any of them is
> undecidable.

Keep in mind that Swift's type system _is_ sound. It's just not decidable in
its current state.

~~~
Tainnor
Is that proven or just conjectured?

------
hugozap
I was very excited about SwiftUI and spent a lot of time learning from videos
and articles. In theory it's awesome and I was ready to create my first
project. Most Apple docs, videos and evangelists talk about how easy it is and
coming from React I was already familiar with the pattern.

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.

~~~
jamil7
Theres quite a few improvements now since iOS14 but maybe wait one more year
and I think you’d be closer to not needing UIKit.

------
Razengan
SwiftUI has been a godsend for me, particularly in a surprising application
that no one has mentioned: Games.

[https://twitter.com/InvadingOctopus/status/12792872846265794...](https://twitter.com/InvadingOctopus/status/1279287284626579458)

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.

------
captainredbeard
He interpreted the Instruments profiling incorrectly. The biggest cost (2s) is
coming from `closure #1: in
ViewRendererHost.render(interval:updateDisplayList:)`

> 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.

------
osy
Been writing an macOS app from scratch in SwiftUI (VM manager) and I can echo
much of these concerns. Especially the random crashes and performance. Some
other random issues I’ve ran into:

* 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...](https://stackoverflow.com/questions/58404725/why-does-my-swiftui-app-crash-when-navigating-backwards-after-placing-a-navigat/58466670#58466670)

* 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.

~~~
saagarjha
I suspect many of the cases where things are not documented as to what they'll
produce or how the layout will look are intentional, as SwiftUI seems to have
the (somewhat idealistic) goal of "looking right" and not only does it have to
infer intent from what you've written it also needs to be flexible enough to
adapt to Apple's design roadmap for the future. So there's no documentation,
not only because there are so many special case quirks they've added to
support layouts that are considered "best practice design" in UIKit that
nobody can really keep up or discover, but also because if they tie something
down too much they won't be able to change it to a new design or paradigm. I
suspect that they really want for 2022 to roll around and be able to come out
on the stage at a WWDC and say that all apps using SwiftUI already get support
on their new AR headset, and all standard controls have been mapped to
analogues on that platform. If you document NavigationView as being a vibrant
view on the top with a large title and a scroll view under it, you can't do
this.

Many of the bugs probably have more to do with the unshippability of macOS at
the moment.

------
layoutIfNeeded
UIKit was a beautiful design: a thin wrapper for touch handling over
CoreAnimation's butter-smooth rendering. A layout engine built from first
principles (the Cassowary linear constraint solver) rather than some
organically grown pile of hacks like the CSS box model or flexbox.

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...

~~~
favorited
> The original NeXTSTEP engineers wouldn't have let this happen...

There are literally senior vice presidents, who I assume had to sign off on
SwiftUI, who were NeXTSTEP engineers.

~~~
Austin_Conlon
Craig Federighi also mentioned in an interview that the declarative model with
bidirectional bindings was influenced by work at NeXT, referring to
WebObjects.

~~~
runawaybottle
Any links or details about this?

~~~
Austin_Conlon
It was just mentioned as an aside here:
[https://youtu.be/5ygYSdL42Zw?t=3039](https://youtu.be/5ygYSdL42Zw?t=3039).

------
kenjackson
Thank you for this post. I'm brand new to ios dev and I was contemplating
Interface Builder vs SwiftUI, and hesitatingly went with Interface Builder.
This article makes me feel a little better with the decision.

~~~
jamil7
If you want to get a job you’ll likely need IB anyway. The core of SwiftUI is
small enough right now that you can look into it on the side and wait another
year for it to mature.

------
Wowfunhappy
> These wrappers can cause issues, and as they’re written in Swift, there
> aren’t many possibilities to fix issues from the outside (unlike with
> swizzling in the earlier days).

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

~~~
monocularvision
Swizzling uses the Objective-C runtime, which in turns handles the message
passing mechanism. Unless you inherit from an NSObject, you can’t swizzle in
Swift.

~~~
favorited
Unless you're building something on your own, in which case there is an
(unoffically supported) attribute which you can use to opt-in to swizzling of
methods. The difference being you have to opt-in, so you can't swizzle someone
else's methods (unless they let you).

[https://twitter.com/jckarter/status/1135730593537249282?lang...](https://twitter.com/jckarter/status/1135730593537249282?lang=en)

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

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

~~~
tinus_hn
Incemening and decrementing is almost free, the cost is in allocating and
releasing memory. If you allocate and release so many objects this starts to
be an issue like here, with a GC the memory usage would be at the level of an
Electron app.

~~~
pjmlp
Only for developers that lack the understanding that just because there is a
GC that doesn't mean there aren't other means to manage memory, e.g. D, Nim,
C#/F#/VB, Eiffel, Go.

[https://github.com/ixy-languages/ixy-languages](https://github.com/ixy-
languages/ixy-languages)

As for Electron, as React Native team has proven, Electron isn't the best
example of JavaScript performance or memory usage, quite the opposite.

I can hardly wait the day that they manage to convince the VSCode team to
migrate to React Native.

------
msie
I wonder if it's worth developing Mac applications anymore. Apple's policies
are hostile to its own developers (increasing restrictions on third party
apps, the app store) and SwiftUI is not ready yet (for Mac development). I'm
mad at Apple a lot. Why give them my time?

~~~
zepto
Why take the time to even post?

~~~
msie
It's valid criticism.

~~~
zepto
Is it? It just sounds like a negative opinion, rather than anything that
qualifies as ‘criticism’.

------
stephc_int13
Apple teams have never been praised for the quality of their software
engineering.

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

~~~
selykg
That's sort of the opposite of my experience.

There are obvious cons, like (previously) having to learn a new language,
Objective-C, which has it's quirks. Documentation may not be very good in some
instances. Tooling (Xcode/Interface Builder) may not be as good, or as
complete, as tools like Visual Studio.

But of the pros, AppKit/UIKit do A LOT of work for you once you understand
things. Things may not be consistent between UIKit/AppKit due to some ability
to start over a bit with UIKit plus just different form factors and things,
but they are consistent amongst each other and the UI components are all very
high quality and flexible. The support libraries are also incredibly good.

SwiftUI should probably be labeled beta given it's not able to do everything
UIKit can do, but they've made big strides with the OS releases coming this
fall.

~~~
stephc_int13
Objective-C has been of the worst language I ever had to use. Fortunately it
is still possible to use good old C/C++ on iOS/macOS.

As a general rule, I don't like the way Apple wants to drag people into their
walled garden, with a tech stack that will be mostly useless outside of it.

Swift is like Objective-C of Metal, we can discuss their respective merits,
but it will never hide the fact that they are all bad cases of the infamous
NIH syndrome.

