Why React-Native: Part Four
Part four takes a look at what new languages from Apple and Google mean for developers.
29th May 2018
Why React-Native: Part Four
Apple and Google Offer New Languages.
After several years of new product offerings of write once, run anywhere solutions that didn’t live up to their promise, product teams started to embrace the two code base methodology. But, they were still not happy with the languages being used. Obj-C had a high learning curve and Java for Android was cumbersome in many ways.
In 2014, Apple announced a new language to write iOS apps with, Swift. This took the development community completely by surprise. Swift was deemed a more modern and easier to learn language. It is a strongly typed language that forces you to pre-define and initialize everything by default. This was a complete reversal of the programming paradigm from Obj-C, which is a very dynamic, do whatever you want, language. Swift promised faster and more stable code, but, unfortunately, it was in beta for the first three years. The language changed every year (sometimes several times a year) and these changes were not always backwards compatible. The compile times were slow and the debugging tools were, well, buggy. But all that aside, it was still a much easier language to learn and use for new developers and it has since become the language of choice for new iOS projects. To note, it’s much more stable at this point.
Around the time Swift became stable, Google declared Kotlin as an officially supported language for developing Android apps. Kotlin was created in 2011 by JetBrains to run on the JVM alongside Java. The Android community had been using it for mobile development and it eventually became stable enough for Google to give it official support.
Kotlin and Swift, while coming from different teams around the same time (although Kotlin was first) were remarkably similar. So much so that if you knew one, you’d have a harder time remembering the differences than the similarities. But this shift in languages did little for the cross-platform development issues. You still had two separate code bases, but now you likely had two different languages in each of those code bases as you supported legacy code while writing new code in a new language.
This created additional problems within mobile teams and for future hiring. Current teams either really wanted to switch to the new languages, or really didn’t want to. And, more likely than not, you already had members of your team that felt strongly on one side or the other. Also, if you were looking to hire new developers, you needed them to know both languages, so they could read and fix old code while writing new code in the new language. In short, this move to new languages didn’t really solve any immediate problems, even if the hope was to reduce the learning curve to develop for one platform or the other.
Around this same time Facebook was working on a project that would simplify their own app development. In part five we’ll follow Facebooks path to React-Native.