Ultimate Checklist for Setting Your Mobile App Up for Success

We at MVPRockets have built over 7 Apps (all on flutter) in the last 1.5 years & have launched them into the market. Obviously, we have done our fair share of mistakes & have learnt from them. Learning from our mistakes, we have created a checklist of items that’s mandatory in all our flutter projects going forward.

While the newest project we have just begun is benefitting out of this checklist & we are certain that we are setting this project for success, we want to share this with the world & make it just a little bit easier for everyone else out there starting a mobile app project. While some of these may be specific to flutter, overall any app project could benefit out of this checklist.

It would also benefit to understand the nature of the issues with mobile apps that we are dealing with before going into the checklist itself

• The android versions are very fragmented – they have multiple major versions and minor versions. This issue is further compounded by the fact that each of the OEMs (like Samsung, OnePlus etc..) have their own renderings of different android versions
• There are phones and tablets and phablets in the market – with 1000s of screen sizes and resolutions (there are a bunch of blogs that talk about the most popular screen sizes and resolutions, you can check them out)
• Auto update – as an app developer, you have no control over which of your customers have enabled auto app update and who has not.
• Once the app is downloaded to their phone, you have very less control over how they are using the app, what works and what doesnt in their phone – debugging becomes a pain
• Given the multiple flavours of OS, screen resolutions etc, debugging an app is extremely difficult – that is if you are not set up for debugging with all data from day 1 on.

Now, lets get into the checklist itself.

Functional checklist

1. Firebase crashlytics – to know whenever there is an app crash at your customer’s phone – we at MVPRcckets use Firebase crashalytics – one point to remember here, always sync the user ID to the crash logs so that you can call the user and get more details to fix the issue
2. Logs for the app – Figure out a good framework for logging at various places for the flutter apps – we use a homegrown framework here
3. Force update – there would be bugs in the app – it is inevitable & in some cases, the user experience would be hampered by these bugs. So, there will be time you would want to move all your users into a newer, more stable version – “Force update” is a good way to do this – ensure that this framework is built into the product from day 1. It would also be a wise choice to enable force update for Android and iOS separately, meaning, you would want to force an update to the latest version only on Android and not on iOS. We use a home grown framework here.
4. FCM notification support – the beauty of apps is our ability to send in-app notifications. So, from day 1 – the best part – they are free. You would want notification support from day 1. We use Firebase fcm
5. Analytics – Ability to understand the behavior of users once they start using the product is vital to be able to understand and make any improvements required. So, analytics(events based) should be available from day 1. We use MoEngage or Webengage – the added advantage here is marketing to your users through FCM, SMS, Whatsapp, email etc..
6. Delete Account – Apple has mandated that all the iOS apps(that require registration & Sign in) should have an option for the users to delete their account – to uphold the privacy of the users – so, to ensure that our app gets accepted in the app store, ‘Ability to delete the account’ should be in the app
7. OS logs – Figuring out if the user has downloaded the iOS app or android App or coming from Web: oftentimes, we would want to know if the user is on iOS or android or on web (in case web, the device and browser details) – if possible, put this as a part of each of the API calls as well – might look like an overkill, but could save you a lot of time while debugging.
8. Dark/Light Theme – if you are interested in enabling dark/light theme, you can enable the app to contain this. Your boiler plate may force the app to light mode, but if the project demands dark theme, ability to handle the themes would help
9. Localization – though you may be supporting only one language, it is good to have the App strings come from a json file instead of it being hard coded in the code
10. Clear Cache – We have seen some issues in specific phones where the errors get sorted if you clear the cache. So, its a good practice to have the clear cache part taken care of in logout & uninstall

Tech Checklist

• Android bundle name and IOS package name decisions
• Supported Flavours – meaning, what are the different environments we would be using – like qa, UAT, pre-prod, prod etc.. & map all the assets to this flavor – this way you save a ton of time later as you start giving multiple versions of the app to your team for testing
• Build scripts – if you want to automate building local instances of the app for quick testing
• Routing – decisions on how the navigation be handled – like when we move from one page to another, should we push or pop etc..
• State management – Getx/Bloc etc.. decide on one and preferably, stick to one
• CI CD Tool
• Signing certificates
• App icons
• App names (a lot of the names are already taken up and you might want to do this check right upfront)
• Architecture decision on how the code be handled – We generally use Clean architecture

Hope this helps – would love to hear from you guys if there is something missing or any comments in general. Pls do let us know if this is helpful, we would also publish the other checklists we have – SEO checklist, Product launch checklist, Project checklist etc..

It took us quite a while to set this boilerplate up – but now, with the boilerplate, we are able to get all these set up in the first 1 week – which is a massive improvement from a minimum of 1.5 months we used to spend earlier, to research, experiment and set these up for each of the new projects. IF you would like to understand more about this or even borrow some of our insights, ping us on hello@mvprockets.com