SwiftUI in timing.is App
It took a few hours to fall in love with SwiftUI. So much so that we instantly decided to abandon a cross-platform codebase and go fully native on iOS. […] Towards the latter stages of development, we even re-considered our decision to go with it. At the end, we didn’t drop it for a couple of reasons. We were too deep into the process. Being a bootstrapped operation that was already severely behind schedule, we couldn’t afford to restart. But this wasn’t why. Despite the regular friction, we still loved it. Because like any commitment, you must let the majority rule. It was fun at least 51% of the time. But let’s talk about the <= 49% that wasn’t.
[…]
[
ScrollView] was the control that we wrestled with the most. An infinite scroll is expected in a calendar app. Executing this was relatively straightforward, but only moving forward in time. Because trying to load items on demand scrolling up resulted in a noticeable jitter. I asked on StackOverflow, and 2k views since, it’s apparent there’s no native approach that works. I actually raised this in a WWDC lab with a SwiftUI engineer last year, and their recommendation was to 1) create aLazyVStackwith a ridiculously large data set in both directions and 2) scroll to todayonAppear. A creative workaround, except unfortunatelyscrollTobehaves unreliably inside aLazyVStack. It would usually not even come close to the intended target, occassionally missed it by a little, and rarely correctly.[…]
Views will refresh unnecessarily. And in a calendar with an infinite scroll, this will lead to noticeable slowdowns. You’re always literally one
@Publishedproperty away from triggering one.[…]
Finally, in case I forget again, remember an
@EnvironmentObjectwill trigger a view update even if the view has no reference to any of its properties. An inexpensive way to determine unnecessary redraws is by setting the background colour of a view toColor.random, a clever trick by Peter Steinberger.[…]
when you are editing an entry, we want the title field’s cursor position to be at the beginning. But, alas, not possible.
Previously:
Update (2023-01-30): See also: Hacker News.
2 Comments RSS · Twitter · Mastodon
BTW, "Timing.app" is confusing - there's one of that very name for the Mac and for iOS - and they're from different makers.
Looks like another confirmation to my finding that SwiftUI is still not a good choice for views with large amounts of elements.
I talked about the same thing while building my own keyboard driven calendar called Grila: https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20but%20slow
