5 Things to Remember Before Shipping Version 1.0 of your Mobile App

Martin Rybak
Feb 13, 2018 · 6 min read
Image for post
Image for post
Developers launching an app.

A mobile app is a great way to build a premium user experience, but it comes at a cost. One of those costs is permanence. Unlike a web app which can be updated at any time, mobile apps, once published, are out there forever. Knowing this, here are a few tips I’ve learned over my career and which I encourage you to implement as early as in your initial 1.0 release.

1. Version your API

https://api.example.com/v1/products
https://api.example.com/v2/products

Now you can support older app versions concurrently with newer versions. However, there will still come a time when you won’t want to support multiple versions of your API. In that case, you need to…

2. Add a kill switch

A graceful way to handle this is to have your API server return a special status code, such as 301 (Moved Permanently) or 410 (Gone), for any requests made by deprecated versions of your app. When your app receives this status code, it should present a dialog reminding users to update, while entering read-only mode. Remember, you should still keep the app as usable as possible by allowing read-only access to any cached or local data stored on the device.

How does the server know which request is coming from a deprecated app version? If you use API versioning,you can simply make a particular API endpoint always return the special status code. However, a more granular approach is for your app to identify its platform, OS version, and app version in the User-Agent header of each HTTP request. It is up to you to come up with a format that contains what you need. For example:

User-Agent: MyApp/1.0.0(31) iOS/10.3
| | | | |
app name | build | os
version platform

When your server sees a request come in from a deprecated version, it should return the special status code. Even if you’re not using it on the server yet, I highly suggest to bake these host headers in as early as the initial 1.0 release of your app.

3. Log a user out remotely

Remember, even with a hard logout, there is nothing stopping a crafty determined employee from putting their phone in airplane mode (preventing the status code from being received), and extracting the data stored in their filesystem for nefarious purposes. Don’t store more than the minimum data that your app needs to function.

4. Support impersonating users

For example, you can create a secure web page where support staff can log in (this is typically your “admin portal”). On that page, support staff are able to look up a registered user and generate a short-lived token…the same token that the user normally receives when they log in (typically a JWT). Now you just need to get that token into the app. You can do that by designing the app to accept a custom URL scheme such as:

yourapp://token/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

When your support staff open that link on a device, the app should bypass the login flow and automatically log them in as that user. As with any impersonation tool, be sure to consider the security implications of this technique. Keep in mind industry-specific compliance regulations such as PCI and HIPAA. Be sure to restrict this functionality to certain staff only, generate short-lived tokens if possible, and don’t copy the token around insecurely. Even if you don’t have the admin portal ready on day one, you should at least build the custom URL handler for accepting tokens in the 1.0 version of your app.

Nowadays there are additional tools that can make your support staff’s lives easier. For example, you can use Appetize.io to run a real instance of your app inside a web browser (!). It has a free tier and is very flexible and can run different builds on different OS versions and devices. You can use their API to send them a build as part of your deployment pipeline. If you really want to be fancy, you can update that impersonation page in your admin portal so that support staff can select the user, device, OS , and app version, and with a click of a button, be taken to the app, automatically logged in.

For the next level of support, you can also consider in-app chat and screen sharing tools such as Zendesk or TeamViewer. Naturally, this has security implications so use this wisely.

5. Install crash reporting and analytics tools

Remember, when coming from a web-centric world, mobile apps are a different beast. Once you ship your app, the proverbial cat is out of the bag. To minimize future pain and frustration, it’s best to build in these considerations into the intial 1.0 release of your app. Good luck!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store