
How Swift 5.3 enhances SwiftUI’s DSL - yannikyeo
https://www.swiftbysundell.com/articles/how-swift-5-3-enhances-swiftui-dsl/
======
dceddia
I’m starting to learn macOS development and I’m a bit torn on SwiftUI. As
someone who’s primarily done web development the last few years, and
comfortable with React, SwiftUI is pretty appealing from the standpoint of
being a similar mental model.

On the other hand, it doesn’t quite feel ready. SwiftUI seems to be missing
enough components that I end up needing to know how to use the existing AppKit
stuff with autolayout, or know how things work under the hood to debug SwiftUI
oddities. On top of that, there are few resources out there for learning macOS
dev specifically — tons of stuff for iOS, which sorta translates, but not
perfectly. I’ve been learning from the Hacking with macOS book, which is very
good, and plenty of trial and error.

The other ding against SwiftUI for Mac dev seems to be that it’s only
supported in Catalina, and it seems an awful lot of Mac users have held back
from updating, so the user base might be diminished.

Most of these seem like temporary problems, but as a newcomer to this world
it’s hard to tell if it’s too early to commit to SwiftUI.

~~~
coldtea
> _The other ding against SwiftUI for Mac dev seems to be that it’s only
> supported in Catalina, and it seems an awful lot of Mac users have held back
> from updating, so the user base might be diminished._

The majority updates fast - even more so when a 2nd update (Big Sur) comes
out, few will hold to before Catalina.

With macOS it makes no sense to "hold out" from upgrading long. You are either
prepared to get on with the program and move on, or you're left behind, worse
than e.g. on Windows etc.

On the other hand, this makes the platform faster to move forward, adopt new
things, and keep a more consistent UI doing so (Windows still have 5-6 UI
layers from previous APIs/decades, depending on the app you use -- even for
internal MS apps, e.g. you can still open an ancient version of the control
panel from within the current one).

~~~
pwinnski
What you describe is the case for every MacOS upgrade _except_ Mojave to
Catalina, since that particular upgrade means losing access to all 32-bit
apps.

I'm normally a pretty quick upgrader, but the MacBook on which I'm typing now
will remain on Mojave until the day it dies.

~~~
Twisell
In retrospect however this move made total sense. When they will start
deploying custom silicon next year every application that run on Catalina will
be able to run on the new ARM Macs.

From Apple perspective it's way better that Catalina take all the blame and
not the new products and the technology they are betting on for the next
decade.

Also developers that care about MacOS platform were even more incentivized to
finally upgrade to 64-bits after the 10+ years deprecation warning so that
more Apps will be ready on day one for custom silicon.

~~~
simonh
The deprecation warnings started in 2018 with 10.13.4, not 10+ years ago.

~~~
Twisell
While maybe true 64bits was available for more than 10 year with Snow Leopard
(10.6) being the last OS supporting 32bits architecture (and dropping PowerPC
support At the same time). So let's say you could have seen this coming.

[https://en.m.wikipedia.org/wiki/Mac_OS_X_Snow_Leopard](https://en.m.wikipedia.org/wiki/Mac_OS_X_Snow_Leopard)

------
liuliu
One thing I am a bit upset is how Apple approaches SwiftUI / Combine, as these
two to me, are foundational pieces to the Swift language ecosystem.
Particularly:

1\. There is no way to bundle SwiftUI / Combine to the app so you can ship to
earlier iOS versions, making development exclusively done on newer OS version.
More over, for any bug fixes on SwiftUI / Combine, you have to wait for the OS
updates for the fix. Just updating your Xcode is not enough.

2\. While the SwiftUI required language features are all upstreamed to Swift
language, and core developers have been patient to articulate why. If SwiftUI
/ Combine development was done in public (i.e. open-source), bug-fixes and
language improvements will be much smoother.

To Apple, point 2 probably is a big leap. But they've done Swift open-source
release, and it works relatively well with a sizeable open-source ecosystem on
other platforms now.

~~~
valuearb
I missed WWDC 2019, was working in an entirely different field. And wow, I
can’t believe I missed this.

[https://developer.apple.com/documentation/combine](https://developer.apple.com/documentation/combine)

Unfortunately my client’s App still requires iOS 11.

~~~
codnee
If you are interested in Combine but need to support older versions of iOS,
you might want to check out
[https://github.com/OpenCombine/OpenCombine](https://github.com/OpenCombine/OpenCombine)

~~~
mayoff
CombineX was more complete last I checked.

[https://github.com/cx-org/CombineX](https://github.com/cx-org/CombineX)

------
makecheck
These are good changes. “View builders” are quite powerful but it was always
strange to be able to get so far so fast and then be hit by a weird limitation
involving fairly basic logic. Fortunately, there are work-arounds.

I’ve ported a few different AppKit interfaces to SwiftUI “1.0” on the Mac and
the tech is pretty impressive; I am looking forward to exploring the Big Sur
version of it.

The biggest problem they have right now is that subtle but important
_behaviors_ are being lost in the SwiftUI versions of controls, and they need
to add them back. You start to notice how maybe keyboard focus isn’t quite the
same, certain key bindings don’t work, tooltips aren’t present, etc. and it
adds up. It is really quite easy to get something _working_ in SwiftUI right
now but it is really hard to _polish_ it to the standards that Macs used to
have.

------
krzat
The amount of compiler magic used by SwiftUI is staggering. By itself it's not
a deal breaker, but closed source makes it almost impossible to understand
what is going on.

~~~
MattDamonSpace
Weren’t UIKit and AppKit before that closed source?

~~~
djxfade
They still are, and so are SwiftUI

------
bsaul
I really wonder where this is going.

Swift had to interop with objective-c right from the start, which itself had
to interop with C. SwiftUI feels like a wrapper over UIKit (or at the minimum
CoreFoundation).

All in all, it seems impossible that so many layers of compromise over so many
years, can lead to anything clean in the long run.

~~~
ericlewis
It wraps UIKit in some instances. But not most.

~~~
saagarjha
I would say that most SwiftUI controls instantiate UIKit views under the hood.

~~~
rahkiin
UIKit or WatchKit or AppKit depending on the platform

------
prezjordan
Love the ability to remove AnyView, that was a really confusing one for me the
first time I saw it.

I'm really impressed by SwiftUI, it seems like Apple took a couple hundred
really good UI engineers and threw them at this. Coming from a web background
it's really refreshing to have these APIs. Swift as a language is part of it,
changes to _JavaScript_ like those mentioned in this article would be hard to
come by (for good reason!)

~~~
captainredbeard
> it seems like Apple took a couple hundred really good UI engineers and threw
> them at this

Like all Apple efforts it was crafted by a small, tight knit cross-functional
group of stellar engineers.

------
wtsnz
Really welcome changes! These small quality of life improvements really make a
difference.

------
tester89
Honestly, I think Swift UI's mess of syntax really makes the case for lisp.
Four different function calling syntaxes? Trailing function calls? Jesus
Christ.

------
laminendy
very good intro, builder are more more used in framework public APIs, until
this new DSL approach it was all about protocol fighting :)

