We have already spent some time talking about our new apps, but so far we have stayed away from getting too technical. Not this time. So as Hans likes to say: let’s get technical!

Mobile app

When we first started talking about developing mobile apps for MediaLab a couple of years ago, the app store was still 99.9% filled with native apps. The so called “web apps” were slowly gaining traction, but the performance was said to be terrible. Having Javascript knowledge in-house it was obvious we wanted to discuss going down this route first. Why hire iOS/Android developers if we could do it ourselves? Oh, we were so naive.

To be fair, my colleague Yuriy did give it his best shot. With Sencha Touch, to be bundled with Phonegap, we planned to get our own app off the ground and got started. I believe we never even made it to an alpha version; it was obvious from the start the performance wasn’t anywhere close to our expectations. We accepted our losses and went for the native app soon after.

Native app

When our first (native) apps were published in the app store, we were happily surprised by how good they performed. Unlike with our own experiment, with the native apps we didn’t need to worry about photos larger than 5 MB or HD videos crashing. We started with a limited set of features with the plan to implement extra features in subsequent releases. Since most of our clients were using iOS at the time, priority to implement new features was given to the iOS platform. This left Android lagging behind more and more. By the time we decided to update our Android app, we found out the framework we used was becoming outdated and wouldn’t allow us to target newer SDK versions. Deprecated APIs needed to be removed and reimplemented differently. As our mobile apps were originally developed to work with our 4 categories (video, audio, pictures and others), it was also consuming a legacy API on our side. This would require significant development in both the iOS and Android code base as we now had one unified folder structure.

So, we wrote a new technical and functional design, got our Android & iOS developers involved to help us with estimating the total effort required, and early this year had our new plan ready. Our iOS app required a few minor updates to its core structure but nothing much, but Android was going to be a different story. The famous words were spoken: “We will need to rewrite it from scratch”. Crap.

“We will need to rewrite it from scratch” ~ The standard developer response if things get tough ~

Digital Chefs

At that point we were still planning on going down this route, however during a meeting in April this year, one of our board members told us about a recent project he did with the guys at Digital Chefs. They don't just do application development, but also have creative skills to help with user interaction and design. And…. they use React Native instead. Our previous experience made us hesitant at first… is the discussion about native apps really back on the table? After a demo of some React Native apps they built, we realized that things had changed quite a bit in a few years time. These weren’t the web apps we knew, these were decent robust apps that are hard to differentiate from apps written in Objective C or Java. In addition to the significantly lowered development costs of 1 React Native app versus 2 native apps, development time for new features would be drastically reduced since the core only needs to be done once.

React Native

Was React Native a solution to all our problems? Well, no. But if apps like Facebook, Instagram and Skype are using this technology in production, at least you know you don’t need to question its maturity. As with all development, you will still encounter difficulties and platform-dependent problems you need to solve. For example, multiple-image selection and status bar control are both very different on iOS and Android. A plugin by the React Native community may work for you, but depending on your requirements you may end up writing your own native implementation.

We bit the bullet and got our new apps built in React Native. We published them to the app store last month and feel confident that the new app is a good base to build on for the future. In the next months, we are going to find out if our expectations are realistic and we will try to iron out as many issues as we can. We may find we need to write more native implementations than hoped to get the functionality we like, but having one code base to look after is a big win on its own.

Get the app

If you haven’t already, download our new app for Android or iOS and give it a test drive yourself. We would be happy to hear your feedback. In 2019, we will be back with more about our React Native journey!

Pepijn

Jun 21, 2019
AppsDevelopment