Really, the fact that Apple pushes swiftui as production ready is laughable. The framework is so ridden in bugs, does not play nicely with the other frameworks like photosui, and the language itself is incredibly bloated.
So many things wrong with this. Reminds me of the Objective-c vs Swift arguments from back in the day. The author mentions the initial release, as someone who held out migrating production apps to Swift until v3 I think we all know early adoption is going to be bumpy.
But as of iOS 15+ SwiftUI is very production ready. I’ve migrated two production applications from UIKit to SwiftUI. These have active users and are available on the App Store.
Bloated? The last migration resulted in 79k new lines of code written and 181k deletions after rewriting 80% of the application.
Photos album works out of the box. If you mean camera then there are some issues depending on your use case. Beauty of SwiftUI is we can wrap UIKit views and interop allowing it to play nicely with other frameworks.
If you’re supporting applications that target the last few iOS versions it’s time to learn the new paradigm. Do yourself a favor but most of all anyone who might inherit your codebase.
I primarily do iOS and iPadOS, but it’s far easier to bridge the gap between all the platforms than the experience I had in the past with UIKit/AppKit. My last MacOS app sadly does not do infinite scrolling.
Off the top of my head, I’d consider the approach. Is it a ScrollView? A LazyVStack? What do your view redraws look like?
Anyone working with Swift Strings back in Swift 1+2 was in for some shockingly bad performance. We adopt, we adapt, and the framework matures.
LazyVStack and ScrollView don't scale (no cell reuse / no unloading). The only option is List which has different behaviors and performance characteristics on macOS including issues with eager rendering
To be fair a LazyVStack handles cell reuse and unloading automatically which is why offscreen content that was previously viewed further back on the list will only maintain the root level state (children in the view hierarchy may and will lose state in order to save memory and energy). How that data is loaded and how you key off Identifiable is also important.
Apple’s own documentation discusses this in detail and for large data sets recommends the Lazy approach. If you’re using List you’re in for some issues.
Something like go, yes. Imo there is benefit to only being able to do things one way, and in swift there are a lot of ways to do everything. A trivial example: why can you bind variables in pattern matches with both case let .some(x) and case .some(let x)?
Because the former works with all associated values in a case, whereas the latter does not. `case let .some(x, y, z)` vs `case .some(let x, let y, let z)`. And the latter exists because you may want some to be immutable and others to be mutable: `case .some(let x, var y, _)`.
there's a meme that it has too many keywords, but this criticism is shallow. it also grew a lot of features quickly to prioritize SwiftUI support perhaps with unnecessary language complexity as a result.
I'm an iOS dev full-time now (bootstrapped) and SwiftUI is definitely not production ready if it means that it can be used without needing UIKit introspection hacks. I like it and ship all my work with it, but it is painfully broken and will take years more to mature
Yeah. You can get far using SwiftUI as your scaffold but you'll need to have introspection and/or UIKit components to do any app of reasonable complexity.
With all of the continued complaints about SwiftUI I almost wonder if,
the specter of the Google Graveyard aside, Flutter would be a better bet. Yeah, it might be a second-class non-native citizen on iOS, but if you’re gonna use a half-baked cross-platform solution why not use one that can also target Android?
I always hear about projects like this or even back before Swift, like Codename One which allows iOS apps to be written with Java and my question is- does anyone actually use these? Why do this rather than use React Native, Flutter, Kotlin Multiplatform, even .NET MAUI or whatever Microsoft is on? One would assume that if these were good solutions more people would be adopting them.
Plenty of companies/people use it. It's open source with commercial backing. It's free for commercial use. It existed well before flutter. Uses a language people actually use (Java) as opposed to Dart.
Why would people use flutter which is constantly in danger of being spring cleaned by Google since it makes absolutely no commercial sense. Without Google's support it becomes an unsustainable over engineered brick of code.
It doesn't have the same level of traction for sure. But it's still popular enough and has support unlike PhoneGap which was discontinued. There are advantages to working with smaller companies where you "know" the individual contributors.
It also came out way after PhoneGap and wasn't backed by a huge company with a huge marketing budget.
Skip is very new. It's interesting because it lets you use SwiftUI and results in human-maintainable Kotlin/Jetpack code, so you can walk away from the tool (although you can also now run Swift on Android too without transpiling)
I have no idea how well it works on iOS, but on Mac it's a sluggish black box api that could otherwise have some potential. There are workarounds, there are some nice components you can put together, but for me it was a little defeating to continue bashing my head against it.
But as of iOS 15+ SwiftUI is very production ready. I’ve migrated two production applications from UIKit to SwiftUI. These have active users and are available on the App Store.
Bloated? The last migration resulted in 79k new lines of code written and 181k deletions after rewriting 80% of the application.
Photos album works out of the box. If you mean camera then there are some issues depending on your use case. Beauty of SwiftUI is we can wrap UIKit views and interop allowing it to play nicely with other frameworks.
If you’re supporting applications that target the last few iOS versions it’s time to learn the new paradigm. Do yourself a favor but most of all anyone who might inherit your codebase.