When planning a mobile app, it’s important to be aware that there are some things about a mobile client that are different from a web client.
Mobile clients are usually distributed through platforms like Apple’s App Store and Google’s Play Store. It is up to the end user to decide whether they accept automatic updates of the app or not. If the user doesn’t allow updates from the store, then that user is stuck on the version of the app that they downloaded, possibly forever.
In contrast, the web browser usually displays whatever new version of the frontend that you’ve deployed, unless you’ve got some caching bug. There’s not much the end user can do to avoid accepting new changes.
So you have to expect that each deployed version of your mobile client (app) may be live for a very long time, even after you’ve deployed many newer versions. If you’ve fixed a bug or added a feature, there will be people out there using an older version of the app that doesn’t have that fix or feature.
It’s an issue if you care about these users and your support team having to respond to them. It’s a more concerning issue if one of your old releases has a security bug, and you would like that release to be disabled.
One solution is to plan from the get-go how to force an update on the mobile app. Assuming you’ve got a backend server, you might have a REST API endpoint that is called by the app when it first opens. This endpoint tells the app the minimum version that is supported. The app then compares its version with that minimum version. If the app’s version is no longer supported, the app should inform the user of that fact. It’s a business decision to determine whether the app should forbid the user from interacting further with the app, or if the user should be allowed to interact further, knowing that the experience may be poor.
This type of advanced planning is why it helps not to just start throwing code together and deploying an app as soon as possible. I do love the concept of the MVP (minimum viable product)! Sometimes you want to gather momentum, and get shit done. However, with mobile apps, you need to keep in mind that the early shit in your MVP may be around for a very long time!
Planning in software is often done by a software architect or an experienced developer playing an architect’s role. There has to be good communication between the frontend and backend developers so that they coordinate the backend REST API and frontend behavior. If you’re using a full stack developer, that communication step is skipped, which saves time and misunderstandings! Sometimes a full stack developer can even play the role of architect, frontend, and backend developer. No matter what your dev team looks like, make sure you’ve got someone confirming that the behavior is correct before going live. The more independent tests and checks that you can run before launch, the less likely you’ll feel the pain of undiscovered bugs.