{"id":38313,"date":"2023-01-27T15:58:46","date_gmt":"2023-01-27T20:58:46","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=38313"},"modified":"2023-01-31T09:41:19","modified_gmt":"2023-01-31T14:41:19","slug":"swiftui-in-timing-app","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2023\/01\/27\/swiftui-in-timing-app\/","title":{"rendered":"SwiftUI in timing.is App"},"content":{"rendered":"

Bardi Golriz<\/a>:<\/p>\n

\n

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<\/em> it. Because like any commitment, you must let the majority rule. It was fun<\/em> at least 51% of the time. But let’s talk about the <= 49% that wasn’t.<\/p>\n

[…]<\/p>\n

[ScrollView<\/code>] 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<\/a>. I actually raised this in a WWDC lab with a SwiftUI engineer last year, and their recommendation was to 1) create a LazyVStack<\/code> with a ridiculously large data set in both directions and 2) scroll to today onAppear<\/code>. A creative workaround, except unfortunately scrollTo<\/code> behaves unreliably inside a LazyVStack<\/code>. It would usually not even come close to the intended target, occassionally missed it by a little, and rarely correctly.<\/p>\n

[…]<\/p>\n

Views will refresh unnecessarily. And in a calendar with an infinite scroll, this will lead to noticeable slowdowns. You’re always literally one @Published<\/code> property away from triggering one.<\/p>\n

[…]<\/p>\n

Finally, in case I forget again, remember an @EnvironmentObject<\/code> will 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 to Color.random<\/code>, a clever trick<\/a> by Peter Steinberger<\/a>.<\/p>\n

[…]<\/p>\n

when you are editing an entry, we want the title field’s cursor position to be at the beginning. But, alas, not possible.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n