Tips for Creating a Scalable Minimum Viable Product for Android
Don’t start over your Minimum Viable Product from scratch after you’ve received good results. You’ll lose a lot of time. Try to make your product scalable from the very first version.
The Lalafo Android Team provides you with 5 tips on how to create a scalable Minimum Viable Product.
Update dialog
It’s very important for your users to have the latest version of your app. This is crucial because the latest release can include new features that increase user engagement, or even include migrating over to a new server. You can’t simply rely on auto-update via Google Play, because many users disable auto update or update only in WIFI mode.
It may take up to a month for the majority of users to migrate to the new version of your app. That’s why you should implement an update dialog, to notify users in the application when a new version is available. Using Google Play auto-update along with your notification will yield solid results.
There are 2 types of update dialog:
- Suggestion
This dialog is good for quickly updating users to the latest version of your app. For example, if you’ve redesigned the profile screen, or fixed a non-critical security bug, you could show this kind of dialog. With that said, don’t overuse it because that can annoy the user. Carefully consider what’s suitable for this type of alert.
2. Force
When a serious problem occurs, such as a security issue, you want to use the force update dialog. It’s not recommended to use this very often because it’s a non-cancellable mode.
Try to make all of your new versions backwards compatible, and use suggestion update dialogs for major changes. Sometimes new updates make older versions useless, and you should use the force update dialog.
API versioning
The API version has a significant impact on your ability to scale. You can use the force update dialog as described above, but I suggest you use a new API version, if there are changes that risk breaking the API consumer code. The new version should run concurrently with the older version of the API and provide migration code on mobile clients.
High-level libraries
High-level libraries always impose constraints on an app. A lot of developers try to avoid using them. Should we really be doing this? Some libraries aren’t so easy to cut out from our codebase like Mosby, RxJava, RxAndroid, Dagger, Retrofit. However, they help us develop an application very quickly. If we use these libraries correctly, while avoiding cross-cutting concerns, they won’t harm you.
For example, we used the image chooser library for selecting images for the gallery. It took less than an hour to integrate. After half a year, we improved our design and created a gallery screen on our own. We removed this library because it’s no longer needed. It was a very simple task and didn’t cause any problems.
Using high-level libraries while adhering to the Clean Architecture will speed up your release.
Minimum OS version
How much time do you spend on writing code that works on Android ICS, or lower, and Android Lollipop, or upper? It’s even impossible for functions such as Notifications(Heads-up, Media Playback on the Lock Screen), Material Design Motion etc.
In Lalafo the minimum OS version is the ICS. We don’t really know if it makes sense for us to support an ICS that takes only 1% of our users.
If you have a small team, you shouldn’t worry about so many versions of Android. Stay focused on your target. For example, if you’ll have a lot of animations in the app, choose a Lollipop or upper platform for quick development and only after the growth add a lower version if it makes sense.
Now there is a trend where companies launch Lite versions of an application. Facebook Lite and Skype Lite is a good example.
Rather than wait for the developing world’s network infrastructure to increase bandwidth, Facebook shrunk its app into a Lite version.
It’s different an APK file and has much less size. First of all, they removed the features that required a huge codebase for backward compatibilities, and resources for various types of devices.
It’s easy to downgrade an OS version for the Lite rather than for the regular version.
Early release
Don’t release an application on production, especially if it’s not yet complete. It’s a very simple rule to follow with the Google play console. There is alpha testing, beta testing and staged rollout. They help minimize user complaints from the console. Alpha is a, mostly, sort of, kind of, what it should do. You can finally release it with bugs and users aware are of it. Beta is the finished product, except for all the stuff we don’t realize we haven’t finished yet. Reviews of alpha and beta testing don’t fall into production and you also can provide a channel for testers to send you feedback. After your app has passed through the alpha and beta testing, you can use staged rollout. This type of release helps you update an application to a percentage of your users and increase this percentage over time.
Polishing always takes many months for medium sized projects and years for large ones.
Don’t make your production users angry with a lack of knowledge in the early release. Feedback from alpha and beta testers will help you to make improvements before full release.
