About one year and a half ago, MOXY began its journey in the domain of mobile apps engineering. Even before that, as professionals that build digital solutions for the web and continuously monitor industry trends, we were conscious the web is not always the most adequate target platform to deliver certain kind of products and experiences. At the time, new business opportunities in the mobile market started to present themselves when some of our clients approached us to develop apps for them. We then realized it was time to realign our strategy and decided to seriously invest in exploring the mobile technology scene and train our team to develop and design apps for handheld devices targeting iOS and Android.
If we were to invest resources in learning how to develop to mobile platforms, we were to do it the way right way.
Above all, our premise was that the commitment towards what our clients entrusted us to build and the quality bar we set upon ourselves would have to remain the same: to deliver impactful experiences, visual appealing and polished apps which make us proud and our clients happy.
As such, the mobile development framework of choice would have to ideally comply with the following criteria:
React Native is an open-source cross-platform development framework created by Facebook and it was first released to the public in 2015. Armed with the possibility to build native apps using React, a UI library also created by Facebook, React Native’s popularity among web developers grew quickly, which led to the establishment of a thriving community and the proliferation of countless open-source libraries and learning material. Moreover, in the last five years, besides Facebook, several tech giants such as Uber, Microsoft and Shopify adopted React Native and continue to place their bets on it.
Naturally, it also deserved our attention.
As with everything in technology, our choices are motivated by trade-offs and risk is always involved. We ended up choosing React Native as it ticked the most boxes in our list of goals we set fourth above. The decisive factors behind our decision were:
Cross-platform development frameworks are very complex and none of them is perfect. React Native is no exception, but it continues to evolve with fast release cycles and has been getting better and better in the last couple of years. Furthermore, a major architectural shift, several performance improvements and optimizations are expected to land throughout this year. You can stay tuned by keeping an eye on the official blog for announcements and on the discussions and proposals repository to follow ongoing discussions and upcoming developments. Moreover, if you’re interested in having an outlook of the current state of React Native, feel free to check the article by LogRocket to learn more.
Beyond React Native, we did have a look at other contenders in the cross-platform space for native apps, namely Flutter and NativeScript, but, without disregarding their potential, both did not meet our criteria. Had we chosen to use Flutter, we would have to learn a new programming language, Dart, for core development and we determined such investment was not worth for us, at least for the time being. Spending time to learn, master and keep up with React Native, Android and iOS ecosystems was and still is enough of a challenge of its own. Thus, we put Flutter aside.
NativeScript, on the other hand, could have been a more interesting candidate as native APIs can be accessed from JavaScript seamlessly. Unlike React Native, where we have to write code in three different languages to bridge the JavaScript and the native realms, writing code in one language is a major upside from productivity and maintenance standpoints. Unfortunately, NativeScript lacked React support and still does to this day (only Angular and Vue are supported). React has been our library of choice for quite a while now, in which we heavily invested our team to consolidate its expertise; for this reason alone we discarded NativeScript as well, as it would not be convenient to switch to another stack.
Upon settling on React Native, our next task, most recently, was to evaluate and assess existing toolkits and frameworks that:
This was essential as in our first React Native projects we spent a lot of time (and money) over and over again to setup the basics before starting the actual development. We had to put an end to this approach and seek a more efficient and effective solution.
In our hunt, the Expo project caught our eye. Expo is open-source, free and one of the most complete solutions we found as it offers a SDK with dozens of APIs, a CLI which builds production-ready iOS and Android binaries and deploys them to the app stores, and much more. To build apps with Expo, developers have two workflows at their disposal: managed and bare. However, from our experience, all the apps we developed required us to have complete control over the native projects and we anticipate this scenario is not likely to change in the near future, so the managed approach does not work for us. Regardless, it was important for us to understand the several limitations of managed projects and lost benefits in bare projects, the most critical to us being listed below:
One last aspect worth noting about the managed workflow is that each version of the Expo SDK is tightly coupled to a specific React Native version and is subject to a time-based release cycle. This can be problematic for three reasons. First, to ensure compatibility and stability, React Native can’t be updated before Expo itself is and, as a result, we might miss on the latest fixes and new features in between. Second, if we’re tied to a React Native version we might not be able to support the latest Android or iOS major versions if an upgrade is required. Third and last, as each new version of the SDK is released on a quarterly timeframe, we might have to wait a while for bug fixes to be addressed. If there are delays during this process, things might get complicated.
To change things for the better, the Expo team humbly took one step back and has been taking several measures gradually:
The ideal workflow for us would be the possibility to enjoy the perks offered by the managed workflow combined with those offered by the bare one. In light of the current situation, as we weighed in the pros and cons, we concluded we wouldn’t gain much from using the bare workflow. We eventually decided to remove Expo from the equation for the time being and spin up a barebones React Native project enhanced with foundational features, popular libraries, tooling and conventions. To that end, we created a skeleton app with React Native’s CLI, which is more or less equivalent to an ejected Expo project but without web support (which we don’t need).
We like to keep our options open and, as such, we’re not shutting the door on Expo permanently. On the contrary, judging by the trajectory the project is being taken, there’s a high likelihood of us embracing it sometime in the future. We’ll be closely monitoring how things roll out in the coming months.
As a company that advocates for open-source, our vision was to design a boilerplate that would serve our own needs but, at the same time, could be consumed by the open-source community and leverage its efforts.
Enter React Native with MOXY.
moxystudio/react-native-with-moxy
MOXY's boilerplate to accelerate the setup of new React Native based mobile applications.
Following the rationale and principles behind our boilerplate for web projects, there are a few things included by default but some of them can be easily removed, adapted or even ignored as it is not our intention to lock anyone in. Developers are free to use as little or as much features as they like.
Below you can find the base feature set included:
@react-native-community/react-native-localize
.@react-native-community/react-native-svg
and react-native-svg-transformer
..env
files and access your variables from both JavaScript and native realms. Enabled by react-native-config
.react-native-bootsplash
.Documentation for React Native with MOXY.
We have baked in all these features and best practices into our boilerplate and many more are planned to come. Moreover, we have an optional set of recipes that can be followed to progressively add other features. One of such recipes is a walkthrough on how to integrate Redux, a popular global state manager.
Our endeavor is still in its infancy but there is so much more in store! Here’s a quick peek of what’s on the short-term roadmap:
react-native-unimodules
infrastructure to cherry-pick SDK modules as we go instead of bringing in the whole thing and seamlessly integrate each one in the boilerplate.Stay tuned! 💪
Meanwhile, you may visit the project’s website at https://react-native-with.moxy.tech/. Feel free to use it, give feedback and contribute! 🙏
With React Native with MOXY, our team has an efficient way to kickstart apps that meet our business offerings and clients’ requirements.
Now, the developer experience is consistent across projects and our engineers are able to onboard new or ongoing projects with minimal friction. We’re now able to iterate and ship faster with a higher degree of polishing, two things highly appreciated by our clients.
Check out the most recent app we built with React Native with MOXY:
Enables quick and easy configuration and analysis of Tridonic’s LED drivers.
At MOXY, we build websites and applications that our customers can feel proud of, instead of being embarrassed and frustrated. Our Engineered Design process helps our customers have a deeper understanding of their challenges, and provides a clear path for solving them through careful design and implementation.
Also published at https://medium.com/moxystudio/react-native-with-moxy-eedd789711ab