19 July 2018
Rethinking our mobile development stack
When we started building the Parkd application, we took some time to evaluate our frameworks and way of working. We had extensive knowledge and years of hands-on experience in Objective-C and Android development; the obvious choice would have been to build our mobile application using these. However, in 2016 Swift (Apple’s newly-released programming language) was swiftly replacing Objective C and more and more Android developers were experimenting with Kotlin (Kotlin is a statically typed programming language created by JetBrains and officially supported by Google). Using Swift or Kotlin would require all our native developers to learn a new language and framework. So, before rushing in and starting development, we dug even deeper. We asked ourselves the following question:
“What is our biggest problem and will these new technologies help us with that?”
After much deliberation, we came to the conclusion that the biggest problems we were facing were (a) the mismatch in features between iOS versions and Android versions and (b) the time it took to release new versions with a relatively small team. Sometimes both applications did totally different things because of misalignment between both platforms. We mitigated this problem by moving more and more code to the backend, but there was only so much we could move to the server without making it too bloated. The direction we had to take was clear: Cross Platform Mobile App Development.
Cross platform mobile app development
There were some interesting options: Microsoft had Xamarin (.NET), Adobe had Phonegap (or Cordova, which is the opensource version). Xamarin looked pretty nice, but had slow compilation times and back then (they do now) did not provide any means of live reloading your app on code update. We didn’t want to recompile everything every time our designer asks to move a component one pixel (…you know what designers are like!). On top of that, the open source community around Xamarin wasn’t very big, and didn’t seem to be growing. Our UI was based very much on custom components and we found them to be very hard to build in Xamarin.
We moved on and looked at Phonegap. The biggest advantage was obvious. We’d just have to build a mobile web application and package it into a phonegap application. When scaling the team, we’d easily find highly skilled web developers and use them for the mobile application too. It was super easy to create custom components because we had the entire toolbelt CSS and HTML had to offer. But… It was… super… SLOW! The flexibility came with one big disadvantage: everything was inside a webview instead of using native views.
Back in 2016, React Native was trending. It was rather new compared to the ones mentioned above, but it provided many interesting features we desperately needed. It was Facebook backed, so it would not just go away (let’s forget what they did to Parse 😅 and this is a totally different technology). We immediately fell in love with the framework. Every code change I did simply needed a small ⌘-R after saving. We could quickly prototype a small application that became the base of the Parkd application we have today.
The performance was not as fast as a native application, but it was pretty damn close thanks to the fact it uses native views. Most performance issues were fixed fast after moving out of development mode and optimizing navigation transitions. Furthermore it was easy creating custom components and leveraging the look and feel of the platform. One thing we had to get over was mixing Javascript and JSX. In React you no longer think in terms of view and template files, which are separated from the code. You just break up your application in small components which contains everything related to that component: code, UI and UX (yes, even CSS… although not everyone in our team agrees on that!).). It started out feeling a bit weird but once you got used to it, it felt great. You could easily find everything you needed and it severely improved our code navigability. React Native seemed to be the thing we needed – but it didn’t come without its issues
Every update of React Native could take our team days (and there were new versions coming in every week) and could break anything at any moment in time. Fortunately, this improved over time, because updates were less frequent. Not only that, we got better at it. Since we had no experience in Javascript whatsoever, we made mistakes… many mistakes. But that’s how we learn. But with constant refactoring and fixing broken windows as we go forward, the application is always improving.
Beyond mobile and the future
When we started working on our web platform for fleet managers. It was obvious that we would use React for our web applications. The first version of myParkd was built almost entirely on shared code with our mobile application. The entire model, and many of the services, could be reused. This way we could create our web platform lightning fast and it enabled us to easily perform cross team code reviews. We are constantly learning from each other and adapting our code with techniques coming from both domains.
At Parkd, we’re always trying to stay ahead of the curve. Looking backward, we made an excellent decision on React Native. A lot of mobile development companies have moved to React Native and on the web React reigns supreme. But we do not want to lose track of new technologies so we never stop looking for ways to improve. Even now, other interesting technologies are emerging. For example, we’re keeping our eyes open for Flutter by Google, a very interesting cross platform app framework that did not exist in 2016. One thing is certain. I don’t think Parkd will go back to native development in the near future, so, AirBnB, you’re on your own here! 😉