10 ms·

How Swift 5.3 enhances SwiftUI’s DSL

146 points by yannikyeo 6y ago

wtsnz 6y ago
Really welcome changes! These small quality of life improvements really make a difference.
krzat 6y ago
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.
- deleted 6y ago
  [deleted]
- trollied 6y ago
  The compiler https://swift.org/swift-compiler/ https://swift.org/swift-compiler/ is open source? https://github.com/apple/swift https://github.com/apple/swift Or have I misunderstood your comment?
  - djxfade 6y ago
    Swift the language and its compiler is open source yes. However, the SwiftUI framework is not.
- MattDamonSpace 6y ago
  Weren’t UIKit and AppKit before that closed source?
  - krzat 6y ago
    It did not use any compiler magic, and ObjC classes are very hackable.
  - djxfade 6y ago
    They still are, and so are SwiftUI
- skohan 6y ago
  This is one of the main reasons I have migrated to Rust for most new projects to be honest. I've been a big fan of Swift for years in terms of the balance it strikes between expressiveness and safety/correctness. But the way that function builders and property wrappers were somewhat hamfistedly jammed into the language to support SwiftUI has been a big turnoff. Previous iterations seemed like they had a very clear intentionality and priority around preserving the clarity of the language, but I'm less confident about the direction the language is currently taking in that respect. Also the relative fragility of large swift projects with multiple dependencies has been a recurring frustration. It's been refreshing to work with Cargo, and not have to worry about doing surgery on a project every time a language update is released.
- yoz-y 6y ago
  AFAIU all the magic used by SwiftUI is included in the open source compiler. AKA one should be able to reimplement SwiftUI on top of the OSS Swift language. Granted though, these features are not developed in the open.
dceddia 6y ago
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.
- kitsunesoba 6y ago
  SwiftUI is definitely not yet ready, particularly on macOS. Under iOS it can get the job done depending on the app in question. It's rapidly improving, though. The version of SwiftUI shipping in iOS 14 and Big Sur are massive improved compared to the current version. If Apple can keep that rate of improvement up, it will reach parity with UIKit/AppKit within another release or two.
- adamnemecek 6y ago
  I went pretty deep on swift mac UI development at some point but I was left disappointed. I've realized that building your own gui toolkit isn't that hard. Right now, I'm building my own toolkit in Rust with this Rust nanovg clone called gpucanvas https://github.com/cytecbg/gpucanvas https://github.com/cytecbg/gpucanvas. Here's another nanovg based gui toolkit in cpp https://github.com/wjakob/nanogui https://github.com/wjakob/nanogui Thanks to Rust macros, you can shape the language to be essentially whatever you want. I think that ECS (entity component system https://en.wikipedia.org/wiki/Entity_component_system https://en.wikipedia.org/wiki/Entity_component_system) is the way go with GUIs.
  - 6y ago
prezjordan 6y ago
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 6y ago
  > 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.
liuliu 6y ago
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 6y ago
  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.
  - Nullabillity 6y ago
    Guess they finally discovered Rx. And still screwed it up.
    - saagarjha 6y ago
      Perhaps you should mention what they did wrong, instead of being snarky?
  - codnee 6y ago
    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
    - 6y ago
deleted 6y ago
[deleted]
laminendy 6y ago
very good intro, builder are more more used in framework public APIs, until this new DSL approach it was all about protocol fighting :)
bsaul 6y ago
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 6y ago
  It wraps UIKit in some instances. But not most.
  - saagarjha 6y ago
    I would say that most SwiftUI controls instantiate UIKit views under the hood.
    - rahkiin 6y ago
      UIKit or WatchKit or AppKit depending on the platform
- pmattos 6y ago
  SwiftUI provides a completely new UI programming paradigm using the reactive model popularized by web frameworks, RxSwift, etc. Using UIKit is just Apple current implementation strategy right now. That doesn’t comprise the SwiftUI model & semantics in any meaningful way. It doesn’t feel at all like a wrapper over UIKit IMO. It’s a completely new beast...
makecheck 6y ago
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.
tester89 6y ago
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.

146 points by yannikyeo 6y ago

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

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.

deleted 6y ago
[deleted]
trollied 6y ago
The compiler https://swift.org/swift-compiler/ https://swift.org/swift-compiler/ is open source? https://github.com/apple/swift https://github.com/apple/swift Or have I misunderstood your comment?
- djxfade 6y ago
  Swift the language and its compiler is open source yes. However, the SwiftUI framework is not.
MattDamonSpace 6y ago
Weren’t UIKit and AppKit before that closed source?
- krzat 6y ago
  It did not use any compiler magic, and ObjC classes are very hackable.
- djxfade 6y ago
  They still are, and so are SwiftUI
skohan 6y ago
This is one of the main reasons I have migrated to Rust for most new projects to be honest. I've been a big fan of Swift for years in terms of the balance it strikes between expressiveness and safety/correctness. But the way that function builders and property wrappers were somewhat hamfistedly jammed into the language to support SwiftUI has been a big turnoff. Previous iterations seemed like they had a very clear intentionality and priority around preserving the clarity of the language, but I'm less confident about the direction the language is currently taking in that respect. Also the relative fragility of large swift projects with multiple dependencies has been a recurring frustration. It's been refreshing to work with Cargo, and not have to worry about doing surgery on a project every time a language update is released.
yoz-y 6y ago
AFAIU all the magic used by SwiftUI is included in the open source compiler. AKA one should be able to reimplement SwiftUI on top of the OSS Swift language. Granted though, these features are not developed in the open.

dceddia 6y ago

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.

kitsunesoba 6y ago
SwiftUI is definitely not yet ready, particularly on macOS. Under iOS it can get the job done depending on the app in question. It's rapidly improving, though. The version of SwiftUI shipping in iOS 14 and Big Sur are massive improved compared to the current version. If Apple can keep that rate of improvement up, it will reach parity with UIKit/AppKit within another release or two.
adamnemecek 6y ago
I went pretty deep on swift mac UI development at some point but I was left disappointed. I've realized that building your own gui toolkit isn't that hard. Right now, I'm building my own toolkit in Rust with this Rust nanovg clone called gpucanvas https://github.com/cytecbg/gpucanvas https://github.com/cytecbg/gpucanvas. Here's another nanovg based gui toolkit in cpp https://github.com/wjakob/nanogui https://github.com/wjakob/nanogui Thanks to Rust macros, you can shape the language to be essentially whatever you want. I think that ECS (entity component system https://en.wikipedia.org/wiki/Entity_component_system https://en.wikipedia.org/wiki/Entity_component_system) is the way go with GUIs.
- 6y ago

prezjordan 6y ago

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 6y ago
> 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.

liuliu 6y ago

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 6y ago
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.
- Nullabillity 6y ago
  Guess they finally discovered Rx. And still screwed it up.
  - saagarjha 6y ago
    Perhaps you should mention what they did wrong, instead of being snarky?
- codnee 6y ago
  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
  - 6y ago

deleted 6y ago

[deleted]

laminendy 6y ago

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

bsaul 6y ago

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 6y ago
It wraps UIKit in some instances. But not most.
- saagarjha 6y ago
  I would say that most SwiftUI controls instantiate UIKit views under the hood.
  - rahkiin 6y ago
    UIKit or WatchKit or AppKit depending on the platform
pmattos 6y ago
SwiftUI provides a completely new UI programming paradigm using the reactive model popularized by web frameworks, RxSwift, etc. Using UIKit is just Apple current implementation strategy right now. That doesn’t comprise the SwiftUI model & semantics in any meaningful way. It doesn’t feel at all like a wrapper over UIKit IMO. It’s a completely new beast...

makecheck 6y ago

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.

tester89 6y ago

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.