From time to time we want to send some good news to our clients. We have a new sale for them, or we want to show off the brand new feature. The easiest way to do that is by sending a PUSH notification. Unfortunately, many users tune out notifications right after taking their phones out of the box. There is no tragedy if we are talking about some bonuses or happy hours in our services. If some critical update is waiting for them at the store and we have no way to let them know.

We shouldn’t resign! But we definitively should take care at first, during development, that our clients will receive our messages anyway. Here you can find some tips on how to do it.

Inner changelog

Many apps have small icons with changelog or news from authors/owners. This place is created just for your needs. If you want to inform your clients about still-hot-version, you publish a small note in this section. Content is getting through API, so it needs an Internet connection, but it’s very safe and non-invasive.

Such notifications, by their simplicity, are also, very often, overused. If you send too many posts in a short time, your clients will run away.

Let’s do this quietly

Code-pushes (also named Over-The-Air updates) are one of the most powerful things in JS-based mobile apps. In brief: our app checks (for example, on each launch) if there are some new sources on a given server; if they are - it downloads them in the background and runs a wholly refreshed app at the next launch.

This method is mostly used for hotfixing when the properly fixed version is still in a store review. It shouldn’t be overused, but sometimes it could be the only way to inform our client about critical updates.

As in the previous method, code-push needs:

• Internet connection - to download new sources; so, probably, it won’t work if in your offline-targeted app
• App restart - even if your fresh new sources are ready to download, the client has to kill the app and rerun it to trigger syncing. It’s hard to predict, especially on iPhones, where our apps have long lives frozen in the background
• Automagical changes - could be super annoying if you run your app and see the completely new design and buttons in totally different places. Code-push can save our lives when we deploy fixes through it, but you shouldn’t use it to releasing the new app!

There is a new version. Please, download it.

The last method is almost the same non-invasive as the first one, but a way effective. We have to put some hidden Update button at the top of our app and show it when users can download a new version from the store.

Showing the button is based on comparing the current version with the version from our API’s endpoint. We can store in the database the current version of our app, but also we can use services like AppMonsta and get our current version of the app directly from the store;

We’ll inform the user directly that there is something new, and he should download the latest version to hide this uncomfortable button from the main view.

It’s good to be prepared

As you can see, there are some methods to keep your users up to date. They base on beforehand prepared solutions (connecting to API, etc.). Only code-push could be our last resort in legacy, already published apps. However, it’s good to be prepared for such situations and predict places in our app to contact the client (even one-side). To have a chance to tell the client that some goodies are waiting for him in store.