Using UnfairLock with Swift

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:

Mixing Metal with UIScrollView

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.

C++ for Swift developers

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:

Building UI without AutoLayout

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.

Understanding Manual Retain Release in Objective-C

You might often hear programmers claiming Automatic Reference Counting (ARC) is one of the best things that happened to Objective-C. It relieves you, the programmer, from typing out redundant code. It’s a convenience if you’ve ever written any Manual Retain Release (MRR) code. But if you joined the club later and haven’t actually every written any MRR code, you might get a wrong impression that MRR is verbosely spammed with calls to retain and release. One factor could be that people assume MRR code is equivalent to C style memory management, where you need to call malloc and free and then figure out complex ways to manage the ownership. Another factor could be because a lot of ARC vs MRR discussion overlook the fact that MRR already has reference counting, something equivalent of what was finally introduced in C++11 with smart pointers. Another confusion might have to do with the fact that ARC is not really clear on memory ownership rules. So some people might assume every assignment operation is either a transfer of ownership or claiming ownership, which isn’t entirely false, but not in the sense of how retain and release is designed to work.