Clients with both a website and a mobile app often don’t full understand the underlying differences between the two. Fixing a misspelled word in a website may take a few minutes to correct, but not on a mobile app. A “quick fix” on a mobile app often doesn’t equate to a short amount of time. Effectively maintaining a mobile app takes a lot more time and pre-planning than maintaining a website.
Whenever a developer fixes a website bug and deploys the fix, those changes usually go live anywhere from a few seconds to a few minutes depending on the website deployment process. At that time, all users of the website see the fix. If for some reason the bug did not get fixed, the developer repeats the process and deploys another change. Website developers all over the world do this every day: fix a bug, deploy the change, repeat.
Mobile apps have a more drawn out workflow. “Deploying” a bug fix for a mobile app means repackaging the app, uploading it to the appropriate app store, updating the store listing with “what’s new” text, waiting for an app review if needed, and having the updated app pushed out to all servers within the app store. From the time a developer uploads the app to the app store and it is ready for users to download takes a minimum of several hours. And in the case of an iOS app, it can take several days due to Apple’s review process.
For this reason, mobile apps tend to follow more of a scheduled release cycle. Depending on the app the release cycle could be weekly, monthly or possibly just a few times a year. Most developers try to combine as many bug fixes into one release as possible.
But just because you released an update to your app does not guarantee when or if the user will even download the update. This leads to the next major issue with mobile app maintenance, multiple app versions.
One headache that web developers don’t have to worry much about is multiple versions. Once the website code is completely push to the servers, all users should be viewing the same version of the website. When a website image or text is changed, all users should see that update the next time they load the website.
For mobile apps, that is not the case. A user will only see changes to your app when they download the latest version from the app store. Most users have app auto-updates enabled. But just having that enabled doesn’t mean they will get the update the second it becomes available. Users may have adjusted their device settings to only download when a WiFi connection is available. Or the device may not have enough storage space to download the update. Or the app may request new permissions and have to be manually approved before being downloading. For these reasons and many others, developers must prepare for having multiple versions of their app being actively used at one time.
One strategy we like to use is to make our apps as “dumb” as possible. Dumb doesn’t mean not useful, it means having the app do as little as possible and off load as much as you can to remote servers. By using remotely served data feeds, we can send fresh data to the app without having to publish an updated app version. And since the data feed is served by a central server, making updates to the data feed is fairly straight forward.
Another key point to maintaining multiple app versions is to have a strong QA process. Knowing that each release may have a long life in the wild, you need to try to make it as bug free as possible. Having a QA process helps reduce the number of app releases by allowing developers to catch and fix bugs before the app is published.
For good or bad, there aren’t a lot of places where website users can rate and review a website. If some bug happens on a website, the user normally tries to find a “contact us” form and send a message to the site admin.
Mobile app users on the other hand do have an easy place to leave comments, the app store. If you read through a lot of reviews on the app store you will notice a trend that a large portion of the reviews tend to be bug reports. While it is nice that these users notify the developer of the bug, these reviews often tend to accompany 1 star reviews, which harm the reputation of the app. Plus, app stores often do not provide a good way to respond to the reviewer. So even if you fixed the bug, you would not be able to tell the reviewer.
One easy way to counter this is to provide a feedback system inside of your app. This way, if the user has a problem, they can contact you instead of leaving a negative review in the app store. Not only does your feedback system let you converse directly with the app user, but it also helps reduce the number of “bug report” reviews inside the app store, which can help the rating score of your app increase.
Knowing that maintaining a mobile app presents different challenges from maintaining a website, you can plan accordingly by following a few simple rules:
- Batch bug fixes into releases
- Make your apps as “dumb” as possible
- Use a strong QA process before each release
- Include a user feedback system inside your app