Hacker Neue

Preferences
emoII parent
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.
sandoze
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
Try doing performant infinite scrolling on macOS
sandoze
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
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
sandoze
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.

6 More Comments →
samtheprogram
People I know who are iOS developers say differently.

The Swift language itself is bloated? Compared to what? Golang?

emoII OP
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
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 OP
In other words, the former is syntactic sugar and having just the latter option would suffice
geoffpado
Yes, but I also don't want to have to go around writing Optional<Array<String>> everywhere, so syntactic sugar is fine.
wahnfrieden
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
IMO UIKit is not production ready without Core Animation hacks.

At least you have the option in all cases.

internetter
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.
Apocryphon
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
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
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
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
Maybe it’s a marketing and perception thing. You’d hear more about PhoneGap or Cordova even than Codename One.
invalidname
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.

wahnfrieden
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)
brailsafe
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.
hn-acct (dead)

This item has no comments currently.

Keyboard Shortcuts

Story Lists

j
Next story
k
Previous story
Shift+j
Last story
Shift+k
First story
o Enter
Go to story URL
c
Go to comments
u
Go to author

Navigation

Shift+t
Go to top stories
Shift+n
Go to new stories
Shift+b
Go to best stories
Shift+a
Go to Ask HN
Shift+s
Go to Show HN

Miscellaneous

?
Show this modal