9 Things You Should Do or Know Before Building Native Apps
Tags: ios, android, app, checklist
Published: 2021-12-04 14:59:09

---
title: 9 Things You Should Do or Know Before Building Native Apps
published: true
description: In only less than 10 more lines in your code, for a grid, sortable tree, multi-column...
tags: ios, android, app, checklist
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xxgnwcweje2kalr7k3h2.png
---

 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:

```js
if (response.showAlert) {
  Alert.alert(response.showAlert.title, subtitle)
}
```
`showAlert` being an object of an [alert in react native](https://reactnative.dev/docs/alert).

### 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](https://reactnavigation.org) 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 !