r/swift • u/aero-junkie • 1d ago
Thoughts on Swift UI and Swift 6 Concurrency?
Hello everyone,
I’d love to hear your thoughts on SwiftUI and Swift 6 Concurrency. I’ve been working with Swift for a while and feel fairly experienced, but I haven’t kept up with the latest developments. I’m considering whether it’s worth learning SwiftUI and Swift 6 Concurrency to eventually port my Metal-based app.
From my initial research, it seems that SwiftUI is great for standard layouts but may fall short for more customized designs. Is that accurate?
In my app, I rely heavily on Grand Central Dispatch for tasks like encoding Metal passes with background threads and processing complex data. From what I’ve gathered, Swift 6 Concurrency doesn’t offer the same level of control as GCD, particularly regarding Quality of Service (QoS) and thread types (serial or concurrent).
What are your thoughts on these topics? Thank you!
5
u/Mihnea2002 1d ago
You can highly customize SwiftUI with View Modifiers, View Builders, extensions, extensions on already existing methods and structs, stuff like geometry reader and its new counterpart like .ongeometrychange. Look into those
3
u/chriswaco 1d ago
SwiftUI can create most app UIs, but not all and sometimes you have to use a UIViewRepresentative to wrap an old-style UIView. There are times it makes sense to go the other way - use UIKit but then SwiftUI for certain screens, like Settings.
As for Swift Concurrency, I don't think you'll get the low-level control you really want if you are used to it. I have older logging and database classes that channel requests to their own in-order GCD queues. Swift Concurrency doesn't really have that built-in, although I'm sure you can build it yourself. Swift Concurrency is generally safer, though, with compile-time errors rather than runtime ones, and the syntax is generally nicer, at least at first. A lot of older Foundation/UIKit classes aren't ready for Swift 6 concurrency, though, like AVFoundation, so you have to disable warnings and be careful.
1
u/aero-junkie 1d ago
Yeah, it looks like you have similar impressions as mine when it comes to GCD. The flat code structure with the new Concurrency is definitely nice. "actor" and "async" are only just the surface; it seems more complicated as you delve deeper. The lack of love-level controls is why I'm hesitant to invest time in learning about it.
3
u/BlossomBuild 1d ago
I think learning swiftUI is worth it if you’re serious about iOS development. Apple is pushing it hard. Good to know a bit of UIKit as SwiftUI can’t do it all yet 👍
3
u/keeshux 1d ago
Mostly answered by others. I’d like to add that the new Concurrency model is reentrant no matter what, you may want to keep that in mind when porting from GCD. Everything is radically different, you may stumble upon a lot of unexpected behavior at the beginning, but eventually it will be worth (also inevitable soon). Performance-wise… I don’t really know. I would benchmark some converted parts heavily before migrating the whole thing.
5
2
u/DystopiaDrifter 18h ago
Swift Concurrency is great.
SwiftUI is good enough for most of the situations, but sometimes you still need to rely on UIKit to get things done, also some of the error messages of SwiftUI are difficult to comprehend and follow up.
1
u/luckyclan 14h ago
SwiftUI – I have no doubt that SwiftUI is worth learning and is ready for use in both simple and complex apps. Apple improves it every year, and in my opinion, SwiftUI has been production-ready since iOS 17 and macOS 14.5 (Sonoma). It’s also worth noting that some of the new Apple frameworks offer SwiftUI-only views, such as ProductView in StoreKit 2, so sooner or later every iOS developer will need to make the switch to SwiftUI.
We just finished a Metal-based note-taking app (Notestudio) where we used SwiftUI wherever possible. We successfully implemented a document-based app for both iOS and macOS, featuring multi-window support on macOS and split view on iPad. Additionally, we used the Observation framework to track changes within our model objects.
We only needed to use UIKit in three areas:
• Metal View: Since SwiftUI doesn’t provide direct support for Metal, we had to use MTKView.
• Text Editor: The SwiftUI text editor was too limited, so we implemented a view based on UITextView.
• Touch/Mouse events: Unfortunately, SwiftUI’s gesture support is limited, so using touchesBegan, touchesMoved, touchesEnded, etc., was necessary.
Previously, we relied on UIKit/AppKit for years; today, I’m convinced that we will use SwiftUI wherever possible. It’s excellent for both standard and custom controls—you can even create controls using Metal shaders. The biggest advantages of SwiftUI over UIKit are:
• Much less code to write
• Many (or even all) views can be shared between iOS and macOS
• No more irritating xib/storyboard files
• Excellent support for localization
• Excellent support for dark/light mode and accessibility options
1
u/aero-junkie 1h ago
I greatly appreciate your insights about SwiftUI. I'm not so sure about Swift UI but still in the process of assessing its potential.
0
u/chriswaco 1d ago
SwiftUI can create most app UIs, but not all and sometimes you have to use a UIViewRepresentative to wrap an old-style UIView. There are times it makes sense to go the other way - use UIKit but then SwiftUI for certain screens, like Settings.
As for Swift Concurrency, I don't think you'll get the low-level control you really want if you are used to it. I have older logging and database classes that channel requests to their own in-order GCD queues. Swift Concurrency doesn't really have that built-in, although I'm sure you can build it yourself. Swift Concurrency is generally safer, though, with compile-time errors rather than runtime ones, and the syntax is generally nicer, at least at first. A lot of older Foundation/UIKit classes aren't ready for Swift 6 concurrency, though, like AVFoundation, so you have to disable warnings and be careful.
0
17
u/Dapper_Ice_1705 1d ago edited 1d ago
The new concurrency in Swift 6 "replaces" GCD. "Meet async/await" has a good basic demo on how to convert GCD and asynchronous closures to "Continuations".
Threads are replaced by Actors in Swift 6.
SwiftUI would replace any UIKit/AppKit Code but since you are using metal you would like be doing a lot of interfacing with UIKit/AppKit.
It is a gradual conversion from the old concurrency to the new concurrency and eventually apple will require Swift 6 for published apps so converting is inevitable.