Design over-the-air updates for a mobile app
PremiumMobile systemHard
- OTA updates
- JavaScript bundles
- Code signing
Quick answer
This mobile system interview question asks you to design over-the-air updates for a mobile app. Aim for a design that meets its requirements at the stated scale, then explain its main components, data flow and trade-offs. Interviewers want to see how you scope the problem, size it and defend each choice.
The problem
Design over-the-air (OTA) updates for a mobile app with a JavaScript layer over native code on iOS and Android. Teams ship JavaScript and asset fixes in hours, not store release cycles. The hard parts are matching updates to the native code they need, signing, staged rollout, and automatic rollback when an update crashes the app.
Native code changes still go through the App Store and Google Play. Apple allows downloaded interpreted code only if it does not change the app's main purpose; Google Play forbids downloading native code but allows code run by an interpreter, such as JavaScript.
What must the system do?
- Ship JavaScript fixes: Publish a new bundle and assets to a channel (production, beta) without a store release.
- Compatibility: An update reaches only app binaries whose native code it was built for.
How well must it do it?
- Never bricked: No update can leave the app unable to start.
- Authentic: Only updates signed by the team's release key are applied, even if the CDN is compromised.
What scale should you design for?
Use these numbers in your estimates.
The scale numbers unlock with this questionUnlock
Key concepts
- OTA updates
- JavaScript bundles
- Code signing
- Staged rollout
- Crash loop rollback
- Binary diff patches
How you’ll practise
- Requirements
- App architecture
- Data and offline sync
- Networking and push
- Performance, battery and releases
- Wrap-up
Lala, personalized to you, gives a hint when you ask and reviews your design when you are ready.
What do interviewers look for?
In any mobile system design round.
- Clarifies the requirements before drawing anything
- Uses a few numbers that actually change the design
- Draws a clear path from the client to storage
- Picks storage and caching with reasons, not by habit
- Explains what breaks first under load and how to fix it
- States trade-offs openly instead of claiming a perfect design
Questions people ask about this interview question
- Which design type is this question?
- It is a mobile system question. You design over-the-air updates for a mobile app and explain your choices the way you would in an interview.
- Is this question asked at entry level?
- It is marked Hard. It suits engineers preparing for senior interviews, where you are expected to drive the discussion and go deep on trade-offs.
- What should I cover first?
- Start with the requirements: what the system must do, how well it must do it and which numbers change the design. Agree on scope with the interviewer before you design anything.
- Can I practise it for free?
- It is a premium question. Sign up and unlock it once for 10 credits; it then stays unlocked. When you finish, Lala, your personalized AI mentor, can review your design for 30 credits.
Related questions
Updated · Written by the SevyDevy team