We recently launched our first mobile app build using React Native, the hot new mobile framework by facebook. It is called “Makerist Mediathek” and it is an app for Makerist users to access all the video tutorials and PDF patterns that they bought on the Makerist website on their mobile devices and also download them for offline use.
Go, check it out on the iTunes store.
Beware, you will need to have a user account on the Makerist website to use the app, and for the best experience you should have bought a video course and/or pattern (there are also free courses/patterns).
In summary we were quite happy with React Native and what it allowed us to build, but let’s take a step back on how we got there.
Research
In the beginning we did some basic research on all the currently available options and frameworks (native, hybrid, etc.). Our two main criteria were that the solution should be “web developer friendly”, since we come from a web development background, and that it should allow sensible options for supporting multiple mobile platforms. Right around that time it was announced that React Native would be released at some point (see our blogpost on that), we had already made some good experiences with the React library on the web and its “learn once, use anywhere” approach to cross platform development seemed very intriguing to us.
Going hybrid first
Unfortunately, when development of the mobile app started, React Native was only just freshly released and still had some initial quirks (e.g. no video support). That’s why we decided to go with a React-based hybrid framework instead. This allowed us to get something running very quickly in the beginning, but still left the option of moving to React Native once we should be hitting any (performance) barriers of the hybrid platform.
At the time the React hybrid frameworks out there were touchstonejs and reapp. Both frameworks were still only a couple of months old, and we evaluated both. In the end reapp had the much better documentation, so we went with that one.
The captain leaves the ship
The experience with reapp was a bit rocky, but we did get something running. But then, after a month or so of development, the main contributor to reapp Nate Wienert announced that he stopped working on the framework and we had to realize that he was the only relevant contributor. So the bus factor of the project had been pretty much 1 – definitely a lesson learned for evaluating young open source projects.
Up to this day there hasn’t been any blogpost or message on the reapp website telling developers that the framework is no longer maintained, which we think is a rather poor way of discontinueing an open source project. If you are interested in React hybrid development right now we suggest looking at touchstonejs instead, which seems to be still maintained by a healthy number of core committers.
Back to square one
So we were back at the beginning and needed to reconsider our options. It had only been a little more than a month, but we took another look at React Native and were quite impressed by the progress it had made in this short amount of time (from version 0.4.x to 0.7.x). Even though it was still pre 1.0 and still quite young, we decided to take the risk and go with it.
Under the hood
Except for React Native we have been using redux which is one of the many implementations of the Flux application architecture. In the previous reapp version of app we had been using a different Flux implementation flummox and we have to say that we liked redux a lot better.
Due to the young age of React Native there we a couple of places where we needed to resort back to native code. Either we needed to write our own little “bridge” to make native APIs accessible to our React/JS code or we needed to make changes to existing plugins. Areas where this was necessary were the video player, file download progress, Airplay, and the PDF Viewer. For that it was really great to also have an experienced native developer (Christoph) on the team.
Summary
In summary we were quite pleased with React Native and the level of fidelity it brought to our mobile app. Other framework options that would have also have been a good fit for a development team coming from a web development context, would not have been able to deliver this level of native performance. It was also very nice to see how performance got better from each React Native release to the next. The team behind React Native is really doing some great work there.
Future
The mediathek app has currently only been released for iOS and the iPad form factor, and for that React Native was already a very good option. But it will become a great option once the app will be migrated to Android and we expect that very large parts of the code (mainly backend/API) can be reused. The implementation of the Android version of the Makerist Mediathek app is planned for next year and we hope that React Native will continue maturing just as well until then. Telling from the experience we made a couple of months and some minor versions can make a huge difference in React Native land.
If you have a mobile app that needs to be built or are also interested in building apps with React Native please get in contact with us. We would love to get in touch with you!
