[HN Gopher] How Swift 5.3 enhances SwiftUI's DSL
___________________________________________________________________
How Swift 5.3 enhances SwiftUI's DSL
Author : yannikyeo
Score : 94 points
Date : 2020-09-13 17:36 UTC (5 hours ago)
(HTM) web link (www.swiftbysundell.com)
(TXT) w3m dump (www.swiftbysundell.com)
| krzat wrote:
| 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.
| trollied wrote:
| The compiler https://swift.org/swift-compiler/ is open source?
| https://github.com/apple/swift
|
| Or have I misunderstood your comment?
| djxfade wrote:
| Swift the language and its compiler is open source yes.
| However, the SwiftUI framework is not.
| [deleted]
| makecheck wrote:
| 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.
| [deleted]
| dceddia wrote:
| 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.
| jamil7 wrote:
| I've got two iOS apps in the app store that are mostly SwiftUI
| with some UIKit, it's definitely viable but I recently tried
| working on an idea for a macOS app I've had for a while and was
| disappointed. Big Sur improves things somewhat but I'd
| recommend learning AppKit as well. The approach I'm taking is
| to use the overall SwiftUI structure but wrap a lot of AppKit
| views for the crucial UI elements, I figured I can replace the
| AppKit pieces easily later on this way.
| luxurytent wrote:
| Do you have any recommendations for articles that explain how
| to include AppKit with SwiftUI? I'm new to iOS dev and have
| been building with Swift/SwiftUI almost exclusively, but not
| sure what's the right way here just yet.
| spideymans wrote:
| It's not too early to "commit" to SwiftUI. Just remember that
| "committing" doesn't mean writing every last bit of UI code in
| SwiftUI. At this stage, I think the best approach is to be
| using both UIKit and SwiftUI, and use whichever framework is
| better for implementing whatever specific features you're
| implementing.
|
| For example, say I'm presenting a modal with a simple form. I'd
| use UIKit's UINavigationContoller to present the modal view,
| and within the modal's view, I'd have a UIHostingController
| which encapsulates the SwiftUI-defined form user interface. I
| can define form layouts (and other simple layouts) much quicker
| in SwiftUI than I can in UIKit, so I'm finding SwiftUI to be
| very helpful in that regard.
| saagarjha wrote:
| You must commit to not use SwiftUI if you support an older
| OS. If your deployment target is last year or newer, then do
| you have the ability to pick and choose.
| cschep wrote:
| Committing to iOS 13 is a lot easier than SwiftUI in
| entirety.
| kitsunesoba wrote:
| 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.
| atarian wrote:
| I'm looking forward to when you can just build an app once and
| use it across iOS and Mac right out of the box. Catalyst seems
| like a good first step in that direction.
| kitsunesoba wrote:
| SwiftUI universal apps do this even better by automatically
| using the appropriate backing controls for the targeted
| platform -- e.g. a SwiftUI `Button` translates to `NSButton`
| on macOS and `UIButton` on iOS.
|
| I think it's ultimately what Apple intends to make the
| flagship way to develop on their platforms. Catalyst exists
| mostly as a way to pull existing iOS apps and iOS developers
| under the Mac umbrella.
| adamnemecek wrote:
| 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.
|
| Here's another nanovg based gui toolkit in cpp
| 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) is the
| way go with GUIs.
| readarticle wrote:
| Does the lack of arthritic, farsighted Arabic speaking users
| factor into it not being too hard or is that whole mess
| already built into the underlying libraries?
|
| UI platforms as a rule are always terrible, but there's
| inevitably a whole lot of baby in the bath water.
| adamnemecek wrote:
| It depends. How does Cocoa handle arthritic users?
|
| It's not baby with the bathwater, the second you want
| something cross platform, your choices are electron or qt?
| Neither is that great of an option.
| readarticle wrote:
| Common, customizable keyboard shortcuts & behaviors
| across the entire OS are huge for people with arthritis
| that can't use a mouse, Automator workflows that hook in
| and take care of repetitive tasks are common and
| eventually Siri Shortcuts will be available on macOS like
| iOS.
|
| Last year Voice Control: https://www.apple.com/macos/cata
| lina/docs/Voice_Control_Tech... came out and is
| absolutely stunning and free with accessibility labels.
|
| A custom UI would force them into "grid mode" on page 6
| off the bat while it's almost too easy if you just stay
| native, UI tests interact with the app through
| accessibility labels for example, and obviously we're all
| testing, right?
|
| Simply riding closely on the back of the behemoth that's
| weirdly good about accessibility gets one very far, very
| fast.
| adamnemecek wrote:
| Too bad this behemoth doesn't care about cross-platform.
| readarticle wrote:
| Too bad disabled users don't either.
|
| Cross platform wasn't even mentioned or implied in your
| original comment by the way, it was edited into the
| second one where you narrowed an "arthritic, farsighted
| Arabic speaking user" into "arthritic".
| adamnemecek wrote:
| It wasn't mentioned but that doesn't mean that I don't
| care about it.
| ajconway wrote:
| The other choice is to share business logic, reimplement
| UI for each platform independently, using platform-
| specific APIs.
|
| Cross-platform GUI always leads to compromise.
| adamnemecek wrote:
| I disagree.
| doteka wrote:
| Could you elaborate on what you found easy about writing a
| GUI toolkit? Not being snarky, but easy is the last word I
| would use to describe it.
| adamnemecek wrote:
| I didn't say easy, I said it's not too bad. Look at this
| toolkit for example https://github.com/yushroom/Fishgui.
| Once you have rendering (which nanovg handles), you just
| need some hierarchy, event handling, windowing and layout
| and you have a basic toolkit.
|
| I like the control a lot, with Cocoa, I felt really
| constrained sometimes.
| coldtea wrote:
| > _you just need some hierarchy, event handling,
| windowing and layout and you have a basic toolkit._
|
| Yeah. Once you add hierarchy, event handling, windowing,
| and layout to a rendering engine you pretty much have a
| basic toolkit.
|
| Kind of like once you've hand built a cpu, gpu, logic
| board, hard drive, and so on, on top of 3d-printing a
| case, you have a basic PC.
| adamnemecek wrote:
| This is a basic toolkit in like 3000 loc
| https://github.com/yushroom/Fishgui. It uses nanovg.
| millstone wrote:
| Now draw the rest of the owl!
|
| A key point of a shared UI toolkit is that users can
| bring their knowledge from one app to another. A standard
| Cocoa table view or text view has tons of advanced
| behaviors: type select, keyboard shortcuts, etc. It's
| worth the user's time to learn these because they work in
| every app.
|
| But apps where these don't work feel discordant and
| frustrating.
| adamnemecek wrote:
| You can mimic native behaviors. But these are different
| between say browser and native cocoa apps anyway.
| jen20 wrote:
| This is the precise reason I hate web apps with a
| passion. I want every app on my machine to behave
| predictably and have a uniform look and feel, not for
| every UI designer to be able to produce their own unique
| snowflake without regard for consistency.
| kergonath wrote:
| You won't ever produce a perfect imitation. UIs based on
| third-party toolkits are always a pain, stuck in the
| uncanny valley. They look somewhat like they should, but
| have all sorts of quirks that break useability: text
| fields that don't support standard shortcuts, weird
| layouts, wrong fonts, buttons that cannot be selected
| with the keyboard, etc.
|
| It is much, much better to use Apple's toolkits.
| adamnemecek wrote:
| How many shortcuts are there realistically? 50?
| saagarjha wrote:
| This is why many people are frustrated by web
| applications that do not mimic features they expect from
| native Cocoa apps.
| doteka wrote:
| That sounds like an insane amount of work to me to end up
| with something objectively worse from a usability
| standpoint. But to each their own.
| adamnemecek wrote:
| It's debatable how much worse usability is.
| PaulDavisThe1st wrote:
| text input (right to left, left to right, compose chars)
| ?
|
| tree views (with non-textual cells)?
|
| nested menus?
|
| file selection dialog?
| adamnemecek wrote:
| You should wrap native file dialogs. Text input direction
| isn't that big of a deal if your rendering supports it.
| Tree views are somewhat tricky but not that much harder
| than list views.
| jitl wrote:
| UI programming - and GUI toolkit programming - is all about
| breadth. There's a ton of things a UI needs to do, but most
| of those things are straightforward to implement, and
| there's usually a plethora of lower-level libraries to
| compose in any given area. So, it does take a lot of work
| to implement a UI (toolkit) but not much of it is a
| stumper. And, many areas of UI toolkit functionality can be
| ignored or have low-quality implementation for a long time.
| For example, a hobbyist writing their own UI toolkit can
| ignore accessibility, but still end up with something
| usable by the hobbyist. Or, the initial implementation can
| use only absolute layout. Or, the initial implementation
| can use only a single fixed-width bitmap ASCII font.
| [deleted]
| coldtea wrote:
| > _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).
| panic wrote:
| There are reasons not to upgrade. I'm staying on Mojave so I
| can keep using the 32-bit copy of Photoshop I bought years
| ago.
| laminendy wrote:
| very good intro, builder are more more used in framework public
| APIs, until this new DSL approach it was all about protocol
| fighting :)
| prezjordan wrote:
| 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 wrote:
| > 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.
| bsaul wrote:
| 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 wrote:
| It wraps UIKit in some instances. But not most.
| saagarjha wrote:
| I would say that most SwiftUI controls instantiate UIKit
| views under the hood.
| rahkiin wrote:
| UIKit or WatchKit or AppKit depending on the platform
| wtsnz wrote:
| Really welcome changes! These small quality of life improvements
| really make a difference.
| liuliu wrote:
| 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 wrote:
| 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
|
| Unfortunately my client's App still requires iOS 11.
| Nullabillity wrote:
| Guess they finally discovered Rx. And still screwed it up.
| saagarjha wrote:
| Perhaps you should mention what they did wrong, instead of
| being snarky?
| codnee wrote:
| 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
| mayoff wrote:
| CombineX was more complete last I checked.
|
| https://github.com/cx-org/CombineX
___________________________________________________________________
(page generated 2020-09-13 23:00 UTC)