8 things you need to know about deploying to AppStore

Nothing happens here hero

Did you know when our devs submit an app to the App Store, the approval process can take up to 5 days? (sometimes 3 days to be honest), and yes, you'll be a bit older at that time, I'm just kidding ), but make sure:

1. Your Team has:

  • Version number.

  • Release date (make sure to avoid Fridays or weekends in case Backend needs to be deployed along with mobile apps).

  • A list of features is included in the release.

  • Features and bug fixes are marked/tagged/labeled with their corresponding version in both Jira and GitHub (Raise your hand, start doing things great, don’t be shy, please shine by following standards and good practice)

2. All release candidate features have been QA’ed on stating (Firebase - We suggest this way, you can up to others) and pre-production (Apple TestFlight). Bear in mind:

Not all features tested on Staging can be tested the same way in Pre-Production. The reason is simple:

  • Most apps in Firebase point to a Backend staging server, the latest and newest backend version your Team is working on, the place where all children could play out with the application, DB, etc.

  • But, when the App is in TestFlight, most of the time, it is pointing to Production, from here you have 2 ways.

    • Production has not been updated with the latest changes in the backend, so you will be playing with the old endpoints. (Make sure to test them) The app should support this.

    • Production has the latest changes from the backend, so it should work as it worked when it was on staging, but you will be playing with real data, so not all tests should be executed, otherwise, you can affect reports, records, etc. Make a smoke test or scanning of the application.

3. Hotfixes are not treated the same as a regular planned app release; reason? Well, the time that it takes not only to submit (we already mentioned that at the top), but the time the app takes to appear in the Store can take up to 24 hours

4. The version you are releasing must match what you shared with your client.

5. If there are features you can't deploy, please make sure your team knows about it (Good communication ). You won't deploy endpoints or updates that are related to or developed to support those features.

6. Release notes must be clear and marketing-oriented (The client or its team must write those release notes). Koombea Team or your internal team should be only in charge of internal release notes, which could help the client with its own.

7. If you have the chance to download the app from production, DO IT, so you can scan really quick if there is something missing, at least in a visual aspect, to not affect real data or reports.

8.   Take care, sometimes App Stores play with our souls. Short Story (SS) I remember helping to deploy an app, we thought it was going to take 24 hrs, but it takes less than an hour, and guess what? Well, this version was deployed with an issue, that we could, fortunately, discover by scanning the version on production right away. We had to deploy a new version of the app and let the Client know about It, the Client was going to notice it anyway, so do not trust in deployment times.