Background 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: share a single code base across iOS and Android so we could ship faster and at a lower cost. Cross-platform: as an open-source driven company, the technology would have to be backed and maintained by an experienced and massive developer community. Open-source: the technology would have already reached a stage where it has become reliable to be used in production without major hassles. Maturity & stability: the development and debugging tools would have to be easy and pleasant to use. Using the same tools, libraries and languages we already use daily to develop websites would be a major plus as well. Developer experience: unlimited access to the native APIs which enable us to develop more specialized and sophisticated apps. Native capabilities: reasonable load times and smooth animations and transitions. Native-like performance: Why React Native? 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 , and adopted React Native and continue to place their bets on it. Uber Microsoft Shopify 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: The dominance of JavaScript from the frontend to the backend in our tech stack. The long standing usage of React for our web development projects and how much we love it! The possibility to utilize tools and libraries we were already familiar with such as ESLint, Babel, Jest, Redux and React Intl, to name a few. Our proficiency in JavaScript and React as a whole. Cross-platform development frameworks are very complex and none of them is perfect. React Native is no , 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 , several performance improvements and optimizations are expected to land throughout this year. You can stay tuned by keeping an eye on the for announcements and on the 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 to learn more. exception architectural shift official blog discussions and proposals repository LogRocket 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. React Native CLI vs. Expo Upon settling on React Native, our next task, most recently, was to evaluate and assess existing toolkits and frameworks that: Allowed us to easily kickstart new apps. Offered APIs and tools out-of-the box to speed up development and delivery. 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 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 . To build apps with Expo, developers have two at their disposal: and . 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 of managed projects and lost benefits in bare projects, the most critical to us being listed below: Expo much more workflows managed bare limitations The build service provided by the Expo CLI is not yet available to bare projects which, in our opinion, is a huge downside and the biggest. Building and deploying iOS and Android apps automatically to the app stores requires knowledge of how app signing works, native development toolchains and APIs or even third-party tools, such as . In managed projects, that process is simplified by hiding away all the complexity involved in the process. Fastlane There are many native APIs yet to be supported in the managed workflow. In the managed workflow, Expo bundles APIs and dependencies we may not even use which leads to an increase of the app binary’s size. Third-party modules which require native access can only be used in the bare workflow. If we want to use a push notification service other than Expo’s, it can only be done in the bare workflow. In the bare workflow, common configurations such as setting up a splash screen or app icons are not so straightforward. It is necessary to perform configurations in the native projects of each platform and use native tooling such Xcode’s Layout Editor, Android’s Image Asset Studio, etc. One last aspect worth noting about the managed workflow is that each version of the Expo SDK is 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. tightly coupled To change things for the better, the Expo team and has been taking several measures gradually: humbly took one step back Last year, Unimodules which allows us to selectively import modules from the Expo SDKs in any React Native app, be it a bare Expo project or not! This outstanding addition results from a change of direction driven by developer feedback and the long-term made by the Expo team to unify the development experience across both workflows. introduced commitment Building upon the above, the for looks promising as it plans to address many of the pressing pain points we outlined here towards the end of the year. roadmap 2020 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 Expo project but without web support (which we don’t need). ejected 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. A new boilerplate emerges 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 , 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. boilerplate for web projects Below you can find the base feature set included: (i18n): Multi-language support is added from the start, even if the project doesn’t initially require it. Powered by and . Internationalization React Intl @react-native-community/react-native-localize (a11y): Automatic checks are in place to enforce good practices and correctness on accessibility. Accessibility : Usage of to ensure code is consistent across the codebase. Code linting ESLint : Automated tests to validate correctness and to provide confidence upon code changes with and . Unit testing Jest Native Testing Library Import your SVG files just like any other module and use them as a React component. Powered by and . Streamlined SVG support: @react-native-community/react-native-svg react-native-svg-transformer Guidelines optimized for clear organization and separation of concerns. Sane and scalable directory layout: Straightforward, JavaScript-based solution to manage of your app’s routes and screen transitions with . Screen navigator: React Navigation v5 Twelve-factor your app’s config with files and access your variables from both JavaScript and native realms. Enabled by . Environment variables: .env react-native-config Provide your user’s a pleasant startup experience by displaying a welcome screen while JavaScript is loading or asynchronous operations run to completion. Powered by . Splash screen: react-native-bootsplash A changelog file adhering to the is automatically generated and kept up to date on each release. Changelog generation: Conventional Commits specification : A webpage with key documentation, including instructions on how to setup a new app.Documentation for React Native with MOXY. Documentation 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 , a popular global state manager. Redux What’s next? 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: Explore the market of error logging solutions such as BugSnag, Sentry and Firebase Crashlytics and develop integrations for a select few in the form of an abstraction layer to enable us to easily switch between implementations. Unhandled native and JS errors will be reported automatically. Error tracking & monitoring: Explore the market of solutions to measure and analyze user behaviors by keeping track of custom events, such as Firebase Analytics. We’re planning to integrate one such solution in the boilerplate by default and create a set of instructions on how to configure it. Analytics: : Users are never happy when an app crashes unexpectedly and closes abruptly without any feedback. In order to deliver a more professional experience, we have to intercept native and JS errors and display a proper screen to inform something went wrong. Handle crashes gracefully The of React Native has been around for about one month now so it’s time to upgrade from 0.61. Update to React Native 0.63: latest version Flipper is now on React Native 0.62 and onwards. is a great project has been serving us well, but Flipper offers a much superior user interface and developer experience. Furthermore, Flipper is extensible via its plugin API. Enable Flipper debugger integration: enabled by default React Native Debugger We have been exploring industry practices on how to handle the versioning of Android and iOS apps at scale and how it can be fit together with our Git workflows. Inspired by such practices, we will design and document our approach and employ it in the release management process. iOS and Android versioning strategy: Design a CI/CD pipeline in GitHub Actions to test, build and deliver iOS and Android apps to TestFlight and Google Play, respectively. We’re looking into using Fastlane to achieve this. We will provide detailed documentation on how to setup everything. Automatic deployment: Thanks to the efforts of the Expo team, we can leverage infrastructure to cherry-pick SDK modules as we go instead of bringing in the whole thing and seamlessly integrate each one in the boilerplate. Add support for Expo’s Unimodules: react-native-unimodules Stay tuned! 💪 Meanwhile, you may visit the project’s website at . Feel free to use it, give feedback and contribute! 🙏 https://react-native-with.moxy.tech/ Wrapping up 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: 4service NFC 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

bugsnag

Facebook

Google

Microsoft

Sentry

Target

Uber

Kickoff Your Application With js-libp2p

Too Long; Didn't Read

Enhancing React Native Applications with MOXY Boilerplate

Enhancing React Native Applications with MOXY Boilerplate

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Kickoff Your Application With js-libp2p

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

10 good rules for bad App

Kickoff Your Application With js-libp2p

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

10 good rules for bad App

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps