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.
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! 😉