30k lines of SwiftUI in production later
blog.timing.is
30k lines of SwiftUI in production later
1–10 of 124 posts
Re: 30k lines of SwiftUI in production later
#2What amazes me is that scrolling has never really been an issue in any native app? And yet here we are in 2023, with a native framework built for modern devices (where scrolling is the main interaction) that... inherits the worst behaviors of web of all things?
Re: 30k lines of SwiftUI in production later
#3I also fell in love with swift when I had to learn it trying metal. it just succs how you have to use xcode with it.
Re: 30k lines of SwiftUI in production later
#4I also fell in love with swift when I had to learn it trying metal. it just succs how you have to use xcode with it.
AFAIK, you can also use VS code or CLion.
Re: 30k lines of SwiftUI in production later
#5What amazes me is that scrolling has never really been an issue in any native app? And yet here we are in 2023, with a native framework built for modern devices (where scrolling is the main interaction) that... inherits the worst behaviors of web of all things?
My thoughts exactly. With the problems reported in the article, I wouldn't want to use SwiftUI, no matter who else declares it “ready for production”.
Re: 30k lines of SwiftUI in production later
#6I also fell in love with swift when I had to learn it trying metal. it just succs how you have to use xcode with it.
AFAIK, you can also use VS code or CLion.
I’m assuming you meant AppCode. It’s been discontinued: https://www.jetbrains.com/objc/
With VSCode, do you get live preview?
Re: 30k lines of SwiftUI in production later
#7What amazes me is that scrolling has never really been an issue in any native app? And yet here we are in 2023, with a native framework built for modern devices (where scrolling is the main interaction) that... inherits the worst behaviors of web of all things?
I think scrolling has always been an issue with native apps, it’s a fundamentally hard problems to solve on CPU and memory constraints device (although modern phones are neither). Scrolling allows the user to move through huge amounts of data in a very short period of time, loading that data in, rendering it, then animating, all at 30-60fps is difficult.
The reason I suspect people don’t think scrolling was ever an issue (especially on iOS, I doubt Androids will share the same view), is because Apple spent so much time getting it right for the original iPhone. Correctly identifying that scroll behaviour was a kind of “killer app” for touch screens.
But in order to make that scroll behaviour so rock solid. They heavily constrained the problem and did bunch of visual tricks to make it appear smoother that it actually was. Most notably, native scroll views generally required that every individual scroll element was an identical size and shape. So you could cheat during the scrolling process by not actually rendering all the content while scrolling, just rendering the UI chrome (which was identical for every scroll item), and loading the content once the scroll velocity was low enough that there was time to load and render the details before they needed to be displayed.
The other thing that happened, was basically stopping any other compute from occurring. When you scrolled on the original iPhone (and for many generations afterwards), your phone basically dropped everything and dedicated all its compute to just scrolling the view. Not even code to compute the content of scroll elements was executed, you were expected to have done that before the scrolling started. This was most obvious in Safari, where JS execution was halted, and even page rendering was halted, so if you scrolled beyond the boundaries of what had already been rendered, you just got white.
With modern frameworks (and especially the web) there’s been a strong desire to deliver scrolling with a completely arbitrary set of scroll elements, that can all be different shapes, sizes, colours and trigger all manner of background computation. Modern devices are broadly capable of delivering that, but care is needed to exceed the available compute. That’s different from historical native frameworks, where they simply didn’t let people have that kind of flexibility. You got the handful of options the framework gave, and that’s it (which is why older iOS app all had identical scroll UI).
Re: 30k lines of SwiftUI in production later
#8What amazes me is that scrolling has never really been an issue in any native app? And yet here we are in 2023, with a native framework built for modern devices (where scrolling is the main interaction) that... inherits the worst behaviors of web of all things?
I think scrolling has always been an issue with native apps, it’s a fundamentally hard problems to solve on CPU and memory constraints device (although modern phones are neither). Scrolling allows the user to move through huge amounts of data in a very short period of time, loading that data in, rendering it, then animating, all at 30-60fps is difficult. The reason I suspect people don’t think scrolling was ever an i…
UiTableView could use arbitrary height cells and smooth scroll a decade ago, as long as you could compute row height.
UiScrollView has always been harder to deal with.
Re: 30k lines of SwiftUI in production later
#9I also fell in love with swift when I had to learn it trying metal. it just succs how you have to use xcode with it.
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?
Re: 30k lines of SwiftUI in production later
#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.