Release interview questions
Release questions a Mobile developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A teammate enables bitcode “for App Store optimization.” What do you say in 2026?
The strongest answer: Bitcode is retired — Apple no longer accepts or recompiles it. We ship a normal device slice and let App Store thinning do the rest
Why it works: Exactly. Bitcode was removed. Do not resurrect a dead flag.
- Do not enable bitcode.
- Ship standard architectures.
- Thinning is the store’s job now.
- If a tutorial still says ENABLE_BITCODE, it is stale.
You are uploading a new Play app. What artifact do you send?
The strongest answer: An Android App Bundle (.aab) so Play can generate optimized APKs per device — not a single fat APK I built on my laptop for every ABI
Why it works: Exactly. New Play listings take an AAB. Let the store slice density and ABI.
- Ship an AAB to Play.
- Let Play generate per-device APKs.
- Sign with the upload key Play expects.
- Keep a mapping file if you will read crashes.
Who should produce the store-signed build?
The strongest answer: CI, from a tagged commit, with secrets in the vault — not a laptop that “just has the keystore”
Why it works: Exactly. Reproducible, tagged, secret-safe. Laptops are not a release pipeline.
- Release builds come from CI.
- Tag the commit you ship.
- Keep signing material out of git.
- Do not ship from a personal machine as the happy path.
Play / App Store review rejects the build: a permission is declared but never used in the flow they can see. What do you do?
The strongest answer: Remove the unused permission — or ship the feature that justifies it with a visible purpose — then resubmit with a note that matches the binary
Why it works: Exactly. The binary, the purpose string, and the visible product have to tell the same story.
- Declare only what the visible product uses.
- Purpose strings must match the flow.
- Do not ship “maybe later” permissions.
- Answer the rejection with a change in the binary.
Someone pastes the upload keystore password into the team chat. What do you do?
The strongest answer: Treat it as leaked: rotate what we can, move the secret to the vault, and stop shipping with a password that lived in chat history
Why it works: Exactly. Chat is not a vault. Rotate, relocate, and write down who can mint a store build.
- Signing material lives in a secret store.
- A paste in chat is a leak.
- Rotate; do not just delete the message.
- Do not commit keystores.
TestFlight / internal track crashes on launch for a subset of devices. Do you submit to the store?
The strongest answer: No — a launch crash on a real device matrix is a stop-ship until I know the OS / ABI / permission and have a build that opens
Why it works: Exactly. Launch crashes are the reviews you do not recover from. Fix, then submit.
- Launch must work on the matrix you claim.
- Do not submit a known launch crash.
- Capture OS, ABI, and a symbolicated stack.
- Hotfix after launch is not a plan for a boot crash.
A production crash is a sea of `a.b.c`. What did the release miss?
The strongest answer: Uploading Proguard / R8 / dSYM mapping for that exact version — mappings are per build, not “the last one we remember”
Why it works: Exactly. A mapping (or dSYM) for the build you shipped is how you read the crash.
- Upload mappings for every store build.
- Match version + build number.
- Keep R8 / strip; keep the map.
- dSYM for iOS, mapping.txt for Android.
An iOS build fails on CI: no matching provisioning profile for the bundle identifier. What does that mean, and how do you fix it properly?
The strongest answer: The profile on that machine does not match this bundle id, its capabilities or the signing certificate. Fix the source — the app id and its capabilities, and a profile and certificate CI can fetch itself
Why it works: Right — signing is identity plus entitlements plus the app id, and CI has to be able to obtain all three on its own.
- Signing is identity plus entitlements.
- Match bundle id, profile and certificate.
- Capabilities must match the profile.
- CI fetches credentials; people do not.
Play App Signing is on. Which key do you keep in CI?
The strongest answer: The upload key — Play re-signs with the app-signing key we do not hold — and I have a documented upload-key reset path
Why it works: Exactly. CI holds the upload key. Play holds the signing key. Reset is a runbook, not a myth.
- Upload key in the vault.
- App-signing key stays with Play when that mode is on.
- Document lost-upload-key recovery.
- Do not commit either key.
CI uses Fastlane. What still has to be true?
The strongest answer: The lane is deterministic, secrets come from the vault, and a human still owns store metadata and the “yes, ship” gate — Fastlane is automation, not authority
Why it works: Exactly. Automate the clicks. Keep the gate and the secrets honest.
- Vault the secrets.
- Keep a release approver.
- Do not commit Apple / Play passwords.
- Store upload runs the same checks as CI.
App Store Connect privacy answers do not match what the SDKs actually collect. What do you do?
The strongest answer: Audit every SDK, fix the nutrition labels and privacy manifest, and drop or replace anything we cannot justify — then resubmit
Why it works: Exactly. Labels and the privacy manifest must match the binary, including third parties.
- Inventory SDKs.
- Align labels, manifest, and code.
- Remove what you cannot declare.
- Do not copy another app’s privacy answers.
On Android, what is the difference between a build type and a product flavor, and what belongs in each?
The strongest answer: A build type is how it is built — debuggable, or optimised and signed for release. A flavor is what is built: a brand with its own id, name and endpoints. Each pair is a variant
Why it works: Exactly — how versus what, and the variant is the pair. That is what keeps configuration out of the code.
- Type is how; flavor is what.
- Build type: debuggable versus release.
- Flavor: brand, id, endpoints.
- Never hand-edit config before a release.
Who gets the build before external TestFlight / open testing?
The strongest answer: An internal track that matches store signing as closely as we can, on the matrix we claim — I do not use a debug-signed build as the last gate
Why it works: Exactly. Internal + store-like signing + the matrix. Then wider.
- Internal track, store-like artifact.
- Exercise App Links, pay, and push there.
- Then phased / external.
- Do not last-gate on debug.
Crash-free is fine but one cluster is 30% of reports. How do you triage?
The strongest answer: By user impact and a symbolicated root cause — I fix or mitigate the cluster before I chase unique snowflakes, and I do not mute the issue to “clean the dashboard”
Why it works: Exactly. Clusters first, impact second, mute never as a strategy.
- Sort by impact, not uniqueness.
- Symbolicate before you debate.
- Do not mute to hit a vanity crash-free.
- Mitigate if a full fix misses the train.
CI for iOS + Android is 45 minutes, mostly compiling the same modules. What do you do?
The strongest answer: Cache Gradle / Derived Data / pods with a key that includes the lockfiles, split the jobs, and fail the cache rather than poison it — I do not “just buy a bigger runner” as the first move
Why it works: Exactly. Cache with honest keys, split, and keep PR signal. Hardware is the second knob.
- Cache on lockfile keys.
- Do not poison the cache.
- Keep PR tests.
- Use a real macOS builder for iOS.
Legal wants a flow that “probably” fails a store guideline. Ship and argue, or change the product?
The strongest answer: Change the product or isolate the risk behind a clear, reviewable disclosure — I do not bet a listing on a thread that says “apps get away with it”
Why it works: Exactly. Listings are a business asset. Guideline risk is product work, not a dare.
- Treat removal as an outage.
- Design to the published rule.
- Disclose what you must.
- Do not cloak features from review.
A risky payments SDK bump is going to the store. How do you roll it out?
The strongest answer: Phased release + crash and pay-success watches + a halt rule — I do not go 100% on Friday because the build is “green on my phone”
Why it works: Exactly. Phased is a brake with instruments. Halt is a written rule.
- Use staged rollout.
- Watch pay-success and crash-free.
- Write the halt rule before you ship.
- Do not 100% a payments bump on a Friday.
You have white-label flavors and two OS families. How does CI stay honest?
The strongest answer: A graph: PR runs the default flavor + unit / smoke, nightly or label runs the long flavor matrix, and store lanes are explicit about which flavor they ship
Why it works: Exactly. Signal on PR, breadth on a longer train, store lanes that name the flavor.
- PR: default + fast tests.
- Nightly: flavor matrix.
- Store lane names the flavor.
- Do not let a shadow flavor be “the” release.
A bad mobile release is already on 10% of devices. What is faster than a store review?
The strongest answer: A remote feature flag / config to disable the deadly path, plus a halt on the staged rollout — I do not wait for a full store review to stop the bleeding
Why it works: Exactly. Flags and a halt. Store review is the next binary, not the first tourniquet.
- Ship kill-switches for risky paths.
- Halt the staged rollout.
- A new binary still goes through the store.
- Do not load unsigned native code from a URL.
A screen ships that VoiceOver cannot complete. Who blocks the release?
The strongest answer: The same people who would block a crash on the happy path — a11y is a release gate with a short checklist (name, order, contrast, Dynamic Type), not a “nice follow-up”
Why it works: Exactly. If a primary task is impossible with a screen reader, that is a defect, not a theme.
- Gate the primary tasks.
- Name, order, contrast, type size.
- Do not exile a11y to a backlog.
- Frontend and mobile share this bar.
An engineer who had the upload key leaves. What is the rotation story?
The strongest answer: Rotate the upload key through Play / Apple’s documented reset, put the new material only in the vault, revoke the old, and treat any copy that lived on a laptop as burned
Why it works: Exactly. People leave. Keys rotate. Laptops are not the system of record.
- Rotate when people or laptops change.
- Vault only.
- Revoke the old upload key.
- Play / Apple have a reset path — use it.
Who owns “we might lose the store listing”?
The strongest answer: A named owner (usually mobile + legal + the PM of the risky surface) with a written review of guideline, privacy, and payments risk before the feature is built — not a surprise in week two of review
Why it works: Exactly. Listing risk is a product risk. Own it before the code exists.
- Name an owner.
- Review guideline risk at design time.
- Include privacy and payments.
- Do not discover this at upload.
Apple’s privacy manifest / Play’s data safety keep drifting from the binary. What system do you install?
The strongest answer: An inventory of SDKs (an SBOM for the app) generated in CI, reviewed when a dependency changes, and blocked when the manifest / labels would lie — not a once-a-year spreadsheet
Why it works: Exactly. Treat collection as a bill of materials. CI is the source of truth.
- Generate an SDK inventory in CI.
- Block a lie in labels / manifest.
- Review on dependency change.
- Do not maintain this in a yearly doc.
A vendor demo uses a private / undocumented OS API that would make a feature shine. What do you do?
The strongest answer: Refuse it for production — private APIs break on OS update and fail review — and I will design to the public contract or cut the shine
Why it works: Exactly. Public APIs only. Shine is not worth a takedown or a boot loop after an OS Monday.
- Public APIs only.
- Design to the contract.
- Do not hide private calls behind flags or reflection.
- Cut the feature if the public API cannot do it.
You have six apps and two OS families. What does “CI for mobile” mean at that scale?
The strongest answer: A paved road: shared workflows, vaulted signing, cache keys, and store lanes — squads may opt into extras, they may not invent a laptop-only release path
Why it works: Exactly. A paved road beats heroics and beats a serial monster.
- Shared workflows and vaulted signing.
- Squads extend, they do not fork reality.
- Do not serialise the company.
- No laptop-only production path.
Crash-free users is 99.2% and leadership wants “four nines like the API.” What do you say?
The strongest answer: Mobile is a fleet of OS versions and devices; I will set an SLO with an error budget and a halt rule, not a vanity four nines I cannot defend — and I will split launch crashes from the long tail
Why it works: Exactly. An SLO and a budget. Do not invent a percentile you cannot operate.
- Set a mobile SLO, not an API copy.
- Split launch vs later.
- Spend the error budget on purpose.
- Do not mute your way to a chart.
The company Apple / Play account lives on one person’s personal email. What do you do?
The strongest answer: Move it to a company identity, hardware-key 2FA, a documented succession, and a break-glass that is not “text the founder on holiday” — the listing is a crown jewel
Why it works: Exactly. Identity, 2FA, succession. A personal inbox is a single point of failure.
- Company-owned identity.
- Hardware 2FA.
- A written successor.
- Do not dual-list as a backup plan.
A bad build is live; payments die on Android 14. Who is in the room and what is the first move?
The strongest answer: Halt the rollout, dark the flag, confirm blast radius (OS, version, payment), and communicate — a store binary is the next train, not the first sentence in the channel
Why it works: Exactly. Mitigate (halt, flag), scope, communicate. The binary comes when it comes.
- Halt and flag first.
- Scope OS / version / path.
- Talk to support and the business.
- The store binary is the follow-up.
Releases happen when a staff engineer is free. What do you install instead?
The strongest answer: A train: cadence, halt rules, staged rollout, and a deputy — heroes do not scale and they are why Friday nights exist
Why it works: Exactly. A train with a deputy and a halt. Cadence beats heroics.
- Set a cadence.
- Write halt rules.
- Name a deputy.
- Do not depend on one staff engineer’s evening.