In my experience, mobile is a completely different beast compared to web thanks to things like: - You ship a binary that you cannot revert. Mistakes are very expensive: which is not the case for web. - The App Store review process. - Localization often being shipped with the binary (and you can’t fix it once shipped) - The business impact for mobile apps can be large: your highest value customers often use the native apps

There are similarities, but web has the massive advantage that you can deploy a fix anytime, for your whole user base. With mobile, you need to tread much more carefully.

++ to this. Mobile is impossible to revert and hotfixes are orders of magnitude slower than web.

There are tactics to try and get it to look more similar (such as using RN, or making heavy use of feature flags), but ultimately app store review makes it a different beast.

This is why we built Screenplay (https://screenplay.dev/): to make mobile reversible and try to get releases to look more like web.

Some aspects of mobile (e.g. deploying binary, dealing with app stores) make it a more gated and complicated process. That, coupled with our team's domain experience in mobile, led us to focus there to start with. But you're totally right - there's a lot of overlap with any kind of deployment and we have an eye towards a future where Runway is the single place where teams ship everything they need to ship. Plus, there's extra value to unlock in coordinating releases across platforms - e.g. coordinating backend changes with app releases, or sync'ing product launches across web and mobile.

+1000 to focus on mobile first. Totally understandable :)

That being said, I think "more gated and complicated process" are the key here. Guess it's easy for web/backend developers to hold to the key and deploy as they see needed.

But for mobile, there are typically only a small set of gatekeeper at the entire company had the key to publish a new release to AppStore/PlayStore. Thus the more process is required.