The week a feature is "launched" means very different things on different platforms. On the web it can be live within an hour of merging. On iOS and Android it waits for store review. On some Smart TV platforms it can take much longer, and some users won't update for months.
At Travelxp the OTT platform shipped on all four. Getting faster at releasing across them was a big part of what I worked on, first as a project manager running the release pipeline and later as a product manager. Most of what helped wasn't technical. It was being clear about what "released" meant for each platform.
Different platforms, different clocks
| Platform | Typical release speed | Rollback | What slows it down |
|---|---|---|---|
| Web | Fast | Easy | Mostly your own process |
| Android | Medium | Staged rollout helps, but installed builds stay | Store review, device variety |
| iOS | Medium | Similar to Android | Store review, guideline checks 1 |
| Smart TV | Slow | Hard | Certification, platform-specific SDKs, old hardware |
Once you accept that the clocks are different, you can stop pretending a feature launches everywhere on the same day. Plan the order deliberately.
Decide on parity per feature
Not every feature needs to exist on every platform. I'd sort features into three groups:
- Must match everywhere: account, subscription status, playback basics, anything where inconsistency confuses users or support.
- Can roll out in sequence: most new features. Ship on web first, learn, then mobile, then TV.
- Platform-specific: things that only make sense in one context, like downloads on mobile.
Writing this down in advance stops the argument about whether a feature is "done" when it's only on two platforms. I wrote about some TV-specific trade-offs in the Smart TV post.
Move control to the server where you can
The single most useful change for us was making more behaviour configurable from the server. If a feature can be turned on, off, or adjusted without a new app build, you can:
- Ship the code in a regular release and enable it later.
- Turn something off quickly if it misbehaves on one platform.
- Roll out to a portion of users first.
This doesn't remove the need for good testing, but it makes the slow platforms much less risky.
Keep a version support policy
Old app versions stick around, especially on TVs. At some point, supporting them holds back the backend and the product.
Agree on a policy: how many versions back you support, how you'll warn users, and when you'll force an update. Make it a deliberate decision with data on how many people are on each version, not something that happens when an old version finally breaks.
One release calendar
Keep one view of what's going out on each platform and when. Include store submission dates, expected approval windows and any freeze periods.
That calendar is what support, marketing and leadership actually need. They don't want to know about build numbers. They want to know when a user on a given device will see the change.
Track releases in your metrics
Tag your analytics with app version. When a metric moves, the first question should be "did a release just go out?" If you can break down by version, you'll answer that in minutes instead of days.
Releasing across platforms will never be as simple as releasing a website. It gets a lot calmer once everyone agrees that each platform has its own timeline, and plans around that instead of fighting it.