Last week was almost entirely firefighting. We use Neo4J as our graph query backend, and to speed things up we had been caching a large volume of relationship data in Redis. The problem: the cache kept growing, and so did the AWS bill.
Recently, I started building a video player that uses CoreText to render subtitles. However, when scrolling through the UI, the frame rate dropped to an unacceptable 15 FPS. To fix this, I created a demo that wraps a native text view with CoreText rendering, eventually optimizing the performance to a smooth 60 FPS.
I remember when I first graduated and started iOS game development, I used NSThread directly for multithreading. When GCD (Grand Central Dispatch) was introduced, it was very convenient to use, and I used it almost exclusively. occasionally, when tasks had dependencies, I would use NSOperation.
I hadn’t noticed loadViewIfNeeded before. Usually I just access vc.view to force the view to load. loadViewIfNeeded is definitely clearer and more explicit—it avoids accidental side-effects when you only want to load the view conditionally.
Many developers complain about SwiftUI because some of its behaviours feel counter-intuitive. For example, in the code at #1, if you comment out the .padding() modifier, the entire area above the search field turns red. That happens because the background of the search view bleeds into its parent container. If you don’t want the Search view’s background to affect the parent view, you have to break that view hierarchy connection.
Before iOS 16, you could get the ScrollView’s offset using the following code. However, if the UI becomes complex, the scrollViewOffset will not update while scrolling.
I wrapped my view in a NavigationStack and used .toolbarVisibility(.hidden, for: .tabBar) to navigate while hiding the tab bar. However, this causes an issue: the transition animation becomes stiff and unnatural. I haven’t found a good solution yet.