I’ve been working in the iOS ecosystem since about 2008. I’ve worked on projects of varying size and complexity, including YouTube’s iOS app, whose team I led for a couple of years. One of the reasons some of us care about iOS is that it lets us build high-quality user experiences. These experiences are supported by the ability to instantly respond to a variety of sophisticated user gestures; the ability to render to the screen at 60 FPS; and so on. These things matter, especially when you’re shipping to users who expect the very best from your application.

Unfortunately, just because you know how to write Swift or Objective-C doesn’t mean you’re free and clear. UIKit is very powerful, but it also makes it very easy to shoot yourself in the foot.

Writing apps for the web is no different — just because you know JavaScript doesn’t mean you’ll ship a high-performance app. Luckily, some very smart people have come up with component frameworks (React, Vue.js, Ember, etc.) that let developers ship high-quality web apps by simply following convention. These tools make it easy to reason about how an app should function, and then take care of doing the least amount of work to get that to happen (yay diffing!). On iOS, however, we’ve mostly been left out in the cold. That is, until Facebook took it on.

Seeing the value of component-based development on the web, Facebook released a variant of React that targeted native-app developers called React Native. They decided that rather than porting React to Objective-C or Swift, they would instead let developers write parts of their native apps in JavaScript, which would get executed in a virtual machine:

The only difference in the mobile environment is that instead of running React in the browser and rendering to divs and spans, we run it in an embedded instance of JavaScriptCore inside our apps and render to higher-level platform-specific components. (source)

This novel approach was driven by several guiding factors: it allows sharing the existing React code base, allows easier cross-platform development, and neat things like live reloading — all worthy objectives. Not on this list, though, is anything about maximizing performance or the resulting quality of user experience.

Some developers have hit this wall when building apps with React Native:

However, when we started building the iOS app, the performance of the chat’s scroll view wasn’t satisfactory, especially for some active chat groups. We decided to use ComponentKit for chat and write the necessary bridges instead. (source) This is a performance bottleneck that pure native apps don’t have, making it much easier for them to reach the holy grail of 60 FPS, especially on weaker devices … (source)

Due to this limitation, and the likely importance of performance for their main apps on iOS and Android, Facebook has either maintained or introduced native component frameworks. For example, Facebook recently announced Components for Android, which is a native port of React to Java. And on iOS, Facebook has continued investing in ComponentKit, a fully native variant of React.

Unlike Components for Android, ComponentKit was designed and announced before React Native, and has trailed in offering some of the key innovations offered by React like view reconciliation, live reloading, and markup-based rendering. More importantly though, ComponentKit is implemented in Objective-C++ and therefore cannot be used by anyone working in Swift.

While this may seem like a minor detail, it’s likely that most developers writing new iOS apps today will be choosing Swift (because Apple has invested considerably in it; because it’s designed to be very fast and type safe; because it’s a pleasure to write in; and so on), and thus will not be able to take advantage of the benefits of ComponentKit. This leaves only a JavaScript-based framework as a real option.

This is why I built TemplateKit.