4 ms·

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

• samtheprogram 2y ago
  People I know who are iOS developers say differently. The Swift language itself is bloated? Compared to what? Golang?
  • wahnfrieden 2y ago
    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
    • kridsdale1 2y ago
      IMO UIKit is not production ready without Core Animation hacks. At least you have the option in all cases.
    • internetter 2y ago
      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.
  • emoII 2y ago
    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)?
    • geoffpado 2y ago
      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, _)`.
      • emoII 2y ago
        In other words, the former is syntactic sugar and having just the latter option would suffice
        • geoffpado 2y ago
          Yes, but I also don't want to have to go around writing Optional<Array<String>> everywhere, so syntactic sugar is fine.
• hn-acct 2y ago
  [flagged]
• brailsafe 2y ago
  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.
• sandoze 2y ago
  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.
  • wahnfrieden 2y ago
    Try doing performant infinite scrolling on macOS
    • sandoze 2y ago
      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.
      • wahnfrieden 2y ago
        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
        • 2y ago
• Apocryphon 2y ago
  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?
  • CharlesW 2y ago
    You can target Android with Swift/Swift UI with SKIP.tools (skip.tools) and SCADE (scade.io), both of which use native controls on Android as well.
    • Apocryphon 2y ago
      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.
      • invalidname 2y ago
        Why is Codename One lesser than Flutter? 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.
        • Apocryphon 2y ago
          Maybe it’s a marketing and perception thing. You’d hear more about PhoneGap or Cordova even than Codename One.