Some essential parts when making an App

In my experiences, I’m figuring out some essential parts, that need to be developed from the beginning of the App. At least, in the first version of the App (e.g: 1.0.0), all of these features need to be ready.

1. Feature Flag / Remote Config

This is a system where we can control the appearance of our features. The best practices (in my opinion) is, we need to add flagging system into each of our features. Usually, it will be handled from their entry point.

So for example, there is button that shown in our homepage. This button, when clicked, it will redirecting user into feature A.

We can give flagging for the appearance of this button. Or also, we can always showing the button, but when it clicked, and if the flag is currently OFF, we can show an alert, something like “sorry, this feature is currently disabled”.

Sample Dashboard.

Usually, we’re flagging a feature, and remotely control it appearance, to handle some cases, like:

• When the feature accidentally having a problems, we can turn it OFF
• When the feature is ready on the App side, but the Backend / APIs is not yet ready, so we can turn it OFF, and then when the backend is ready, we can turn it ON.
• When both App and Backend side was ready, but it still waiting for the legal / compliance things, like waiting the agreement to be ready, or the feature is still pending verification by the government. After the compliance is done, we can turn it ON.

There are many tools to supporting this system. The most popular ones (afaik) is Firebase Remote Config. It is free (afaik), and we can handle the flag to be having other values rather than Boolean. Also, we can filter the flag, to be ready on specific build number / version, only for specific platform, or only for some specific device. But, it lack of filtering based on user ID / segments (CMIIW).

Other tools that supporting based on user ID / segments is Leanplum, using service Leanplum Variables.

Or, we can have our system, end to end, from Back End to Front End. And we can customize it based on our need.

2. Handling force update

Force update means, stopping the user journey, when they use certain version. It’s important to handle this things. Usually, we need to do this when some specific versions are too old, or it contains major bugs that can’t be solved by backward compatibility from Back End side. Another reasons may be, we need to do stability on Back End or Front End side, and we need to have minimum versions for our users (so their journey will not blocked).

Usually, force update handled by, Back End checking the app version that used by the user. When it includes in list of App that need to be updated, they will returning status code 410 from many APIs. Then, when the App got that in any APIs, they will show popup or alert to users for updating their App.

Sample Alert when getting Force Update

3. Handling Force Logout

Sometimes, we need to force user to logout, when uncertain conditions is happen, like token expired for unknown reason, or uncertain bug occurred. It’s not a good journey for them, but better to prepare it on our App, as soon as possible.

Sample Alert when getting Force Logout

Usually, when we want to force user to be logout, in a certain conditions (that already set in our system), Back End will return status code 401 in all APIs, and then App detecting that, and user will be logged off.

4. Giving many fundamental values on the request headers of the request APIs

There are some attributes that need to be sent from App, to identifying current session in user. Some of them are:

• OS Name: for collecting Data, to determine / analyze some patterns
• OS Version: for collecting Data, to determine / analyze some patterns
• Device Model / Type: for collecting Data, to determine / analyze some patterns
• App Version: for collecting Data, to determine / analyze some patterns. Also usually used by parameters of force update
• Authorization: for the credential of the users

sample request header

5. Monitoring Request Logger

Usually it can be handled by Back End side. So the flow will be, whether Back End returning or receiving API response from App, they will record it into some tools, example: Kibana, Datadog.

But sometimes, Front End can manually record it. So basically, the process would be, when App sending request or receiving response from Back End, they will record it into some tools, like tools above.

Then we can creating dashboard or just querying it, for analysis many things, like uncertain response from Back End, or uncertain parameters values from Front End (combine with some Data that already sent by the App, e.g: OS Version and Device Model).

Sample Dashboard for Monitoring Request Logger

In my opinion, better to handled it by Backend side, so we can easily customize it sometimes, and it always be backward compatible.

6. Monitoring Crash Performance

Many tools are supporting this. The most popular one (I think?) is Firebase Crashlytics. The purpose is quite simple and obvious, to determine whether a crash is happen on our App, and then we can know what part that triggering it. Usually it also come with many useful data, like OS version, app version, user ID, file and line of the code that triggering the crash, and report time.

Sample Report when a Crash occured

I think that’s all that I can tell. There’s still many things that I think every App need to have, like Tracker Event (for analyzing user journey), having design system, and many more. But I think that it can comes in the middle of App Release journey / doesn’t need to be developed from the beginning.