9 ms·

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

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.
- doteka 6y ago
  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 6y ago
    I didn't say easy, I said it's not too bad. Look at this toolkit for example https://github.com/yushroom/Fishgui 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.
    - PaulDavisThe1st 6y ago
      text input (right to left, left to right, compose chars) ? tree views (with non-textual cells)? nested menus? file selection dialog?
      - adamnemecek 6y ago
        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.
    - millstone 6y ago
      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 6y ago
        You can mimic native behaviors. But these are different between say browser and native cocoa apps anyway.
atarian 6y ago
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 6y ago
  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.
  - PostThisTooFast 6y ago
    Yes. Catalyst is a kinda-clever but janky solution. It basically puts the iPad simulator on the screen.
jamil7 6y ago
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 6y ago
  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.
  - jamil7 6y ago
    Not really, unfortunately it's a lot harder to learn AppKit than UIKit due to the lack of online resources available. Try to find open source mac apps and read the source code and Apple's documentation are the only suggestions I can think of. I've seen a "Hacking with macOS" Udemy course that looks comprehensive although I can't recommend it as I haven't checked it out. With regards to wrapping AppKit views in SwiftUI the process is more or less the same as it is with UIKit.
    - luxurytent 6y ago
      Thank you!
spideymans 6y ago
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 6y ago
  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 6y ago
    Committing to iOS 13 is a lot easier than SwiftUI in entirety.
deleted 6y ago
[deleted]
coldtea 6y ago
>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 6y ago
  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.
  - wlesieutre 6y ago
    If/when you do upgrade, check out Affinity Photo or Pixelmator Pro for a non-subscription alternative
- pwinnski 6y ago
  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 6y ago
    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.
choxi 6y ago
I wrote a post about my experience using it for a year if you're curious: https://getglyph.app/blog/3-building-glyph-a-year-with-swiftui https://getglyph.app/blog/3-building-glyph-a-year-with-swift... I didn't speak to developing for macOS specifically. The tldr is that it's not quite production-ready but it's easy to mix SwiftUI with UIKit so you can adopt it incrementally. I really like Apple's vision for SwiftUI and they're catching up with missing features very quickly.
vhbit 6y ago
Read this before committing on macOS: https://steipete.com/posts/state-of-swiftui/ https://steipete.com/posts/state-of-swiftui/
yoz-y 6y ago
At the very least I’d recommend using SwiftUI instead of Storyboards. Even if all the rest is done in UIKit/AppKit

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.

doteka 6y ago
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 6y ago
  I didn't say easy, I said it's not too bad. Look at this toolkit for example https://github.com/yushroom/Fishgui 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.
  - PaulDavisThe1st 6y ago
    text input (right to left, left to right, compose chars) ? tree views (with non-textual cells)? nested menus? file selection dialog?
    - adamnemecek 6y ago
      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.
  - millstone 6y ago
    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 6y ago
      You can mimic native behaviors. But these are different between say browser and native cocoa apps anyway.

atarian 6y ago

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 6y ago
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.
- PostThisTooFast 6y ago
  Yes. Catalyst is a kinda-clever but janky solution. It basically puts the iPad simulator on the screen.

jamil7 6y ago

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 6y ago
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.
- jamil7 6y ago
  Not really, unfortunately it's a lot harder to learn AppKit than UIKit due to the lack of online resources available. Try to find open source mac apps and read the source code and Apple's documentation are the only suggestions I can think of. I've seen a "Hacking with macOS" Udemy course that looks comprehensive although I can't recommend it as I haven't checked it out. With regards to wrapping AppKit views in SwiftUI the process is more or less the same as it is with UIKit.
  - luxurytent 6y ago
    Thank you!

spideymans 6y ago

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 6y ago
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 6y ago
  Committing to iOS 13 is a lot easier than SwiftUI in entirety.

deleted 6y ago

[deleted]

coldtea 6y ago

>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 6y ago
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.
- wlesieutre 6y ago
  If/when you do upgrade, check out Affinity Photo or Pixelmator Pro for a non-subscription alternative
pwinnski 6y ago
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 6y ago
  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.

choxi 6y ago

I wrote a post about my experience using it for a year if you're curious: https://getglyph.app/blog/3-building-glyph-a-year-with-swiftui https://getglyph.app/blog/3-building-glyph-a-year-with-swift... I didn't speak to developing for macOS specifically. The tldr is that it's not quite production-ready but it's easy to mix SwiftUI with UIKit so you can adopt it incrementally. I really like Apple's vision for SwiftUI and they're catching up with missing features very quickly.

vhbit 6y ago

Read this before committing on macOS: https://steipete.com/posts/state-of-swiftui/ https://steipete.com/posts/state-of-swiftui/

yoz-y 6y ago

At the very least I’d recommend using SwiftUI instead of Storyboards. Even if all the rest is done in UIKit/AppKit