English | EN 
Use Expo
Expo is a framework for building universal apps: iOS, Android and WebApps can all be built using Expo. You can use either TypeScript or JS. Using the managed workflow, Expo will reduce boilerplate code, and will handle over-the-air updates, the build process, and push notifications. During the development phase, it is packed with features that improve your quality of life: Incremental rebuilding, hot reload, and, most importantly, it all runs within the Expo Client. All you have to do is install the Expo Client, run expo start on your computer, and scan a QR code with your device to run your app.
The Expo SDK is fully-fledged and will cover most of your needs.
Add in NativeBase
While Expo handles well most of the system interactions, it doesn’t provide UI components. This is where NativeBase comes in: it provides a library of cross-platform UI components.
“Get truly native look and feel with platform specific design for Android and iOS over the same JavaScript code-base using NativeBase”
As it claims, it provides the basic UI Elements you would expect, and are not provided by React Native. All the components are based on a stylesheet. Out of the box, you can choose from three starting stylesheets: Platform, Material, CommonColor. Of course, you will need to override the styles to perform your branding, but rest assured, any major UI changes will be handled by NativeBase (such as changes to the safe areas due to the notch in recent phones)
Define strict formatting rules & choose a programming style
This is true both for TypeScript or JavaScript, but even more so in the latter case: ES6 enables you to do the same action in multiple ways. You can even mix async and promises in the same function. Wow, what a mess! Is this a reason why you should be using TS over JS? The answer isn’t as simple, and even in TS, you will run into the same issues within your programming team: everyone does things differently.
Luckily for us, linters and code formatters exist, so we can enforce some formatting rules, and some programming rules. For the formatting part, we can start by using a code formatter such as Prettier, and create our .prettierrc file. Here you will define if you should be using single or double quotes, the number of spaces and so on. Then configure your favorite IDE to format code on save. Gone are the days of those pesky commits with whiteline differences.
Now let’s get on to the linter: choose the appropriate linter for your language then? You should probably start by using a pretty restrictive ruleset. The Airbnb ruleset is pretty popular, and is a good starting point. From here, you might notice that some rules don’t suit your needs. If so, get your hands dirty and dig into the .eslintrc file, and tweak the rules.
Use Typechecking
Having your app crash because you passed the wrong prop to a component is never enjoyable. How can you avoid this? By declaring PropTypes: declare what each component is expecting. Now you will get nice warnings when you fail to initialize correctly a component.
Add in some automation
Our project is now built by Expo, enforces strict coding rules, and performs some simple validation.
Depending on how your branches are managed, maybe you would like to reject commits that don’t comply with your rules. To perform this automatically, we could use some pipelines.
New commits pushed to your feature branches: Run the linter and warn about the number of errors.
New merge on one of your protected branches: Run the linter, if errors, fail fast and reject the merge request. If no errors: start the build. If the build fails: reject. If the build succeeds: publish to a specific release channel using Expo’s Codepush capabilities.
Going further – E2E testing
If you want to go further, you can also automate some E2E testing. You could use Appium + Jest to run your tests, bundle the build and tests together, and run them on a device farm such as AWS Device Farm.
