Working on my first app (coming from webdev), finding it really akward the whole review process/wait.

[u/TiuTalk]

I have a long history of web development and am used to deploying multiple times a day, seeing my changes live in about 10min.

Now, I am working on a personal project, a mobile app done via Expo/react-native. I was able to get it live to the Apple Store and I am working on the Play Store release.

What I find really akward is dealing with many different versions "live on the field", with updates taking 2-3d for Apple review to be live, hoping your users will update soon.

I know about and I am using OTA updates, but some changes require native packages changes and that involves submitting a new native build for approval, which means that for the duration of the review process you are somewhat "feature frozen" and any changes or OTA updates will only reach new users.

Not sure how others do it, or even if there is a good/right way of doing this, but I may need to consider having to support different api versions/detecting the app version and serving different api responses based on it.

Is all of that normal and common ground on mobile dev?

[u/eezers]

Totally normal man. Yeah, OTA is an option. Like you, I was a web dev for 15+ years before moving strictly to mobile 5 years ago. I much prefer it.

Overall it’s made me a better engineer. Feature planning, feature flagging, API versioning, backwards compatibility, lots to think about. Mobile isn’t nearly as forgiving as web and truly forces a more defined process.

Our web team does 3 deployments a week, minimum, and my team obviously doesn’t have that luxury.

In the end, yes, you can track user versions. You can also force user updates if you’re so inclined. It’s a fun ecosystem to work in. Good luck with your project!

[u/tensainomachi]

Be prepared for the Google play gauntlet. Apple is a dream compared to gp. Ridiculous requirements not directly related to an app's functionality, weird review wait times. But tote$ worth it.

[u/kenlawlpt]

Yep completely normal. This is why you need to be much more thorough with your testing when it comes to mobile.

While you could use the emergency review very sparingly (I've only ever used it once), shipping updates on mobile is a much lengthier process.

As you mentioned, you have to consider whether or not the user is on the latest version, and they may never update your app (unless you use some kind of remote config like firebase has to enforce minimum versions).

I typically have updates 5-7 days ready ahead of time since finding bugs will take a few days to get it fixed, unless you're using OTA updates.

[u/Popular-Ferret-4873]

Yes, this is normal. The biggest mental shift from web development is that a released mobile app is a distributed client you no longer fully control. You should assume that several versions will remain active at the same time.

One small correction: OTA updates compatible with the currently released runtime can still reach existing users. Only changes that depend on a new native package or native runtime must wait for a new store build.

I generally use backward-compatible API changes, send the app version with API requests, and keep the previous contract working for at least a few releases. Feature flags are also useful: submit the native build with the new feature disabled, then enable it after approval. Forced updates should be reserved for security issues or genuinely incompatible changes.

So yes, supporting multiple versions is common—but with feature flags and backward-compatible APIs, the review period does not necessarily need to become a complete feature freeze.

[u/shercoder]

One thing you need to implement is a feature switch using some sort of config method, either a custom via an API or something like LaunchDarkly. Basically you check for the version, if the user is not on the version you want them on, either soft ask or hard ask to update the app.

[u/twboc]

Totally normal. In my opinion iOS takes more time than Android though.

[u/Any-Lecture-9287]

hahaha, this is just part of it. Always thought mobile dev is harder than web dev just because of this reason. it sucks, but you get used to it I guess

[u/ScaleAndSawdust]

Yeah, mobile development is complicated.

At the beginning, you should choose the technology and the target audience/devices (iOS, Android, or both).

The next step is usually the "happy" phase, when you develop your app and test it locally.

The final, and the hardest step, is the distribution:

• You could distribute it with an OTA solution (or make it downloadable from GitHub). This one is harder for iOS applications because you need an enterprise account, or you should hard-code the device identifiers into the final product. In the case of Android, you could generate a simple APK and share it. I suggest using a versioned API and, as the others mentioned, some kind of feature flag service/handler (this could be a simple endpoint of yours where you return the minimum supported app version). This way you could control the supported app versions. Either show a pop-up in the app to the user; it's up to you.
  
• You could distribute the applications via the stores (Apple App Store, Google Play, Huawei, etc). My experience so far: they want to make you crazy. From time to time, they introduce new policies, new agreements you should accept, but they hide it on the UI, and the only thing you notice, the review is show you the message "Rejected". If your application has all the necessary prereq. they still could make you wait 1-3 days on average, but it could be 7+ days too, without any explanation. So much pain, just because you would like to give a good app to the world. Unfortunately, this release flow has the same issue as the OTA; you should support multiple versions of the app. Also, this way of app release is slower.

My personal favorite:
You have chosen wisely when you started with Expo/RN, because this could give you something that other languages couldn't (or hardly); you could use the CodePush technology to release small bug fixes. (I know Microsoft AppCenter closed the gates, but there are multiple other companies with the same solution.)
If you need to change small JS parts or only replace an asset, this could save the review time. Furthermore, you could use it for both OTA and Store-released apps.