Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

30k lines of SwiftUI in production later

blog.timing.is

Post reply on HN
Print view View original

61–70 of 124 posts

Re: 30k lines of SwiftUI in production later

#61

Post by newZWhoDis »

jb1991 wrote: post #24

I love declarative UIs and still long for the days I was writing early front-end React apps nearly a decade ago and how amazing it felt for a UI to behave that way. Years later, today I work primarily in iOS and would love to do this on that platform, but every time I read an article like this, my head hurts. Workarounds for workarounds, a great many special cases that are quite unexpected. I've gotten very fluent wi…

You won’t throw any of that away, you can structure your app around SwiftUI and drop in to UIKit for custom controls whenever you want.

This is a good idea for MapKit and web views at the moment, and probably the camera.

Re: 30k lines of SwiftUI in production later

#62

Post by newZWhoDis »

layer8 wrote: post #10

> we wanted to move our entry UI to open in a sheet and with immediate focus on the title TextField, but there’s a noticeable delay before the keyboard pops up. So we didn’t. > when you are editing an entry, we want the title field’s cursor position to be at the beginning. But, alas, not possible. That such basic functionality is not possible is astonishing. Especially the first one should be a common use case.

Something else is going on, I have no such delay with @Focus set onAppear { }

Re: 30k lines of SwiftUI in production later

#63

Post by ezfe »

Zanfa wrote: post #47
mrtksn wrote: post #9

Earlier quoted context omitted.

What's wrong with Xcode? Is it the usual "iPhone is preparing for development" type of annoyances? Is it the bugs that sometimes prevent you from compiling? Or is it something more fundamental like even when everything works fine you don't like it?

1) It's sloooooooooow 2) It's extremely buggy, like on a daily basis where something just doesn't work for any apparent reason that is usually either fixed by killing Xcode or removing derived data & then killing Xcode 3) Lack of plugins for even the most primitive of features like autoformatters 4) XML for build configs inside .xcodeproj 5) Why does it take half a day to update through the App Store? I mean it has s…

1) I use IntelliJ for my day job and find it much slower than Xcode

2) yes

3) I don't really use plugins in IntelliJ either - I do in VSCode but only because it's pretty useless without them

4) Not sure what the problem is with this, but I will say I prefer Package.swift projects for anything that isn't targeting a UI runtime

5) App Store update process just doesn't play well with 8GB applications. Either delete it and re-install from App Store or use something like Xcodes.app

Re: 30k lines of SwiftUI in production later

#64

Post by newZWhoDis »

DelightOne wrote: post #16

TLDR: 1) Don't watch too much state with Observable/EvironmentObject. When any watched property changes EVERYTHING RELOADS every time. 2) ScrollView.scrollTo is bugged with ForEach. 3) TextField and keyboard-interactions can be slow and buggy.

The trick for 1) is to use @Observed object on a state class inside your app struct then push to views via @Published combine streams so you can map/filter/reduce. Storing massive state in every view/child view/grandchild view is both stupid and wasteful.

2 and 3 I can’t reproduce.

Re: 30k lines of SwiftUI in production later

#65

Post by newZWhoDis »

pictur wrote: post #23

Is it possible to write an application of this scale with flutter without (or very little) infecting swift? probably can be written, but I would like to hear comments about what can be experienced in terms of performance and development.

30k LoC is not a particularly large app. I have SwiftUI apps in excess of 100k LoC and plenty have larger than that.

Just my 2 cents.

Re: 30k lines of SwiftUI in production later

#66

Post by ec109685 »

DelightOne wrote: post #16

TLDR: 1) Don't watch too much state with Observable/EvironmentObject. When any watched property changes EVERYTHING RELOADS every time. 2) ScrollView.scrollTo is bugged with ForEach. 3) TextField and keyboard-interactions can be slow and buggy.

This Equals behavior seems terribly unintuitive as well: https://swiftui-lab.com/equatableview/

When an object contains plain data, the equals interface is not used. That would so rough to debug the first time.

Re: 30k lines of SwiftUI in production later

#67

Post by pohuing »

kitsunesoba wrote: post #53
ohgodplsno wrote: post #49

Earlier quoted context omitted.

Jetpack Compose (Google's alternative on Android, that also works pretty much anywhere you can run a JVM and others like the web [1], terminals[2], powerpoints[3], iOS[4] if you squint, as well as pretty much anywhere you have an imperative API that you want to transform into a functional model[5]) is three years old and is infinitely more polished and has better tools than anything Apple has put out in all of SwiftU…

IIRC the reason why SwiftUI isn’t a separate library is that it’s developed in lockstep with Swift, meaning that each release is dependent on new features in its contemporary release of Swift. That’s a problem because they stopped building Swift into third party app packages a few years ago in effort to bring down app download sizes, but that means that apps have to deal with whatever version of Swift comes with the…

Couldn't they just separate swift runtimes from the os updates? I'm always baffled by how often features are tied to seemingly random os versions.

For example: You can't debug IOS 14.5 apps on Big Sur because Xcode for some reason needs Monterey. Though if you just spoof the required version in the xip's app manifest it'll work mostly fine.

Re: 30k lines of SwiftUI in production later

#69

Post by nodemaker »

newZWhoDis wrote: post #61
jb1991 wrote: post #24

I love declarative UIs and still long for the days I was writing early front-end React apps nearly a decade ago and how amazing it felt for a UI to behave that way. Years later, today I work primarily in iOS and would love to do this on that platform, but every time I read an article like this, my head hurts. Workarounds for workarounds, a great many special cases that are quite unexpected. I've gotten very fluent wi…

You won’t throw any of that away, you can structure your app around SwiftUI and drop in to UIKit for custom controls whenever you want. This is a good idea for MapKit and web views at the moment, and probably the camera.

Or you can structure your app in UIKit and build custom views and nice animations in SwiftUI. SwiftUI is a nice abstraction but a lot of it is really unnecessarily force fed by Apple because it helps them get more amateur developers into the platform.

Re: 30k lines of SwiftUI in production later

#70

Post by StewardMcOy »

newZWhoDis wrote: post #61
jb1991 wrote: post #24

I love declarative UIs and still long for the days I was writing early front-end React apps nearly a decade ago and how amazing it felt for a UI to behave that way. Years later, today I work primarily in iOS and would love to do this on that platform, but every time I read an article like this, my head hurts. Workarounds for workarounds, a great many special cases that are quite unexpected. I've gotten very fluent wi…

You won’t throw any of that away, you can structure your app around SwiftUI and drop in to UIKit for custom controls whenever you want. This is a good idea for MapKit and web views at the moment, and probably the camera.

It's a great solution when it works. MapKit and web views are good examples of it working well, but it can get buggy with anything more complicated, especially when mixing Views and UIViews in the same parent view. The worst part is that the behavior can change based on the OS version. You have to be proactive with testing your apps on the beta OS releases ASAP.

Also, and this might have been fixed already, but a couple years ago, there were problems getting updateUIView to run in response to ObservableObject updates.

The promise of UIViewRepresentable is a lot like SwiftUI itself. It's great when it works, but there's little you can do when it doesn't.

Post reply on HN