9 Things You Should Do or Know Before Building Native Apps

TDLR;

1. Header appversion for each request
2. Header appdevice
3. Header currentroute
4. Setup a pattern to display a message to your app on response to a backend request
5. Allow a user interaction/redirection from the backend
6. Send a request to your backend on each page change
7. Setup a Check Version and/or Force Update pattern
8. Keep things in the backend if you can
9. Beware of the version naming : a mistake is for life

Building a iOS/Android/macOS/whatever native app is not the same as building a web app.

With a web app running on browsers, if you want to deploy another version of the app, you just do it and instantly all users get the latest release.

But native app are packages installed on your device with a few consequences

• Before a new version is available on the stores, it can take a few hours or even days because native apps are checked by the store maintainers.
• It might even be rejected because of whatever check done by the store managers didn't pass.
• You can't remove or cancel a release of your app. Once it's deployed on the stores, it's for ever.

That's why before sending the first release of your app, you should setup a few safety measures in case something goes wrong with one of the available apps on the store. And believe me, chances are big that someday something will go wrong. At least once.

Things you should setup or know before sending a native app

Let's consider you build an app with a backend and a database.

1. Header appversion

For each and every request to the backend, find a way for the backend to know the app version in case you need to hotfix for specific versions of your app. Usually, I set a appversion: {my-app-version} in the Headers.

2. Header appdevice

Find also a way for the backend to know the device and/or OS it's running on (android/ios), just in case.
That's where I setup appdevice: {my-app-device} in the Headers too.

3. Header currentroute

Less important, but still useful in some cases, send the current page / current route to your backend. You might not see how it could be useful now, but remember, once you find it useful and your app is already deployed in production, it's too late.
I like headers, so I add a currentroute: {the-current-route} in the headers too.

4. Setup a pattern to display a message to your app on response to a backend request

Setup a way to be able to communicate to your app from the backend. For instance, I'm a JavaScript guy working with ExpressJS and React Native, and what I do in the front-end is, while I'm reading the response from the backend:

if (response.showAlert) {
  Alert.alert(response.showAlert.title, subtitle)
}

showAlert being an object of an alert in react native.

5. Allow a user interaction/redirection from the backend

Even more, within the showAlert object, you can (and should) be able to redirect the user to anything you want if he presses OK or Cancel or whatever action you defined.
For instance, I use React Navigation for navigating through the screens, therefore I usually add a onOkRedirect field on the showAlert object so that if this field exists, pressing on OK will trigger navigation.navigate(... onOkRedirect). But you can add onOkRedirectToUrl or anything in your mind.

6. Send a request to your backend on each page change

I also like to send a request on each page change, so that if I have a bug in one of the page, or if I want to send specific in-app message for a particular screen, I can.
In React Native and React Navigation, I listen to state change and send a request to the backend on each of the route changes.

7. Setup a Check Version and/or Force Update pattern

Because you don't want the user to have to download a new version every other day - it would be a cruel user experience - you might have to handle backward compatibility of your app in your backend. That's why appversion is so useful. But sometimes, you want to get rid of technical debt linked to this extra code, or you also might have a breaking change, or whatever : you need to force the user to update to the last version.

If you didn't plan it, it won't happen ! I see two options there

• either you have a middleware in your backend that check the version on each request and send back a showAlert to force the user to download the newest version of the app (and that's where the appdevice header is useful to redirect the user to the good store)
• either you have a request with the path /check-version located properly in your app so that if the version is not good, you have a beautifully designed screen inviting your user to download the new version of the app
• either both !

8. Keep things in the backend if you can

That's actually THE thing to remember while you're coding, together with the backward compatibility in mind.

You can't have the whole app in the backend, and have it downloaded at every app load : you definitely need a part of the code in the app, and another one in the backend.

But sometimes you hesitate : should I put this in the front or in the back ? When you do hesitate, opt in for the backend : you can change the backend any time, you can't change the front end anymore.

Think the native app as a displayer only, not a brain - live that part to the backend.

I also tend to put i18n in the backend too : it's too sad to have to redeploy a whole app because of a typo somewhere.

9. Beware of the version naming : a mistake is for life

Last but not least...

Android has a versionName and a versionCode, iOS has a CURRENT_PROJECT_VERSION and a MARKETING_VERSION, I don't know about the others : those need to be incremented when sending a new version to the stores.

Be careful : if you made a typo by writing 20.0.1 instead of 2.0.1, you won't be able to take it back, and from now on all the other version will have to be greater than 20.0.1.

Be also careful : one is to be only a number (CURRENT_PROJECT_VERSION and versionCode), the other one is {major}.{minor}.{patch}. If you make a mistake at the beginning, you also won't be able to take it back either. But don't worry too much about versioning here if you made a mistake : I think Facebook itself might have made a mistake as there are at version 345.0 on the store.

Conclusion

All of these tips are coming from mistakes I personally made. That's not small mistakes when you have a client to face with. Having an app in production is quite a journey : I hope I've helped you preparing it !