The maths required for SwiftUI custom layout reminds me of the days before AutoLayout and the constraints based system. The good thing is that Simple Layout Engine already provides a nice system to handle all the maths involved. To demonstrate I would use build the subset of the demo app from the WWDC session on this topic: Compose custom layouts with SwiftUI.
UnfairLock seems to be causing a lot of confusion for Swift developers. Every once in a while I run across some incorrect implementation that reads like:
About mixing UIScrollView with MTKView. This is the trick I learned from WWDC 2012 Enhancing User Experience with Scroll Views session that talks about mixing UIScrollView with OpenGL. The idea is to simply use the MTKView to render whatever metal content we would like and then use the UIScrollView to provide with the scrolling effect. The benefit of using UIScrollView is that we get exactly the same dragging and bounciness behavior that iOS users expect.
Swift in a sense is very much like C++, and when I say C++ I mean C++11 and beyond. One could also say that Swift is cleaner C++, or C++ without the backwards compatibility baggage from the 80s. To give an idea here’s a minimal modern C++ code:
I love Auto Layout. It helps a lot when designing complex UI. But there are times when the UI is very simple and Auto Layout might feel a bit overkill, while other times the UI might be a bit too complex and Auto Layout actually starts affecting the app performance. Before auto layout there was another technique to creating UI, it’s called Springs and Struts (also known as Manual Layout to be in contrast with Auto Layout). I like Manual Layout a lot as well for its simplicity. Like with every other tool, there are trade-offs when selecting the best tool for the job, and it also applies when selecting Auto Layout vs Manual Layout.