Project Management for Mobile App Development

The deadline you don't control

Most software deadlines are internal: a sprint ends, a release ships, and if it's a day late, it's a day late. Mobile has a deadline that isn't internal at all. A store review takes however long it takes, marketing has already told the world a date, and if the build isn't ready when the submission window closes, the app doesn't launch on that date. Full stop, regardless of how close the team got.

That single fact changes how the last two weeks of a release should be run. "Nearly done" isn't a useful state going into submission the way it is going into an ordinary sprint review. Either the build is submittable, meaning every screen tested on the OS versions and devices that matter and every string finalised, or it isn't. There's no partial credit from a review queue.

The other complication is that a mobile team is usually running two projects wearing one product name. iOS and Android share a roadmap and disagree on almost everything else: release cadence, review turnaround, platform-specific bugs that only ever show up on one of them.

A rejection makes the whole thing worse retroactively. A reviewer flags one screen, the resubmission goes back into the same queue, and a date that looked safe a week ago suddenly isn't. That's exactly the moment a team needs to know, at a glance, what else in the release is still genuinely at risk versus already solid.

Compare that to a normal engineering deadline, where slipping a day usually just means a slightly awkward Slack message. On mobile, the cost of that same day compounds: a missed submission window can mean the difference between launching alongside a marketing push and launching two weeks after it, quietly, to an audience that already stopped paying attention.

Two platforms, one board, honestly labelled

ShipSprint doesn't submit builds to a store. That step still happens in App Store Connect and Play Console, same as always. What it tracks is everything on either side of that moment: the feature work feeding each platform, the QA pass that has to close out before submission, and what's actually blocking a build from being ready versus what someone optimistically marked as done.

Splitting iOS and Android as parallel tracks on the same board, rather than one undifferentiated backlog, makes it visible early when one platform is running behind. That's useful information two weeks before a submission date, and nearly useless the day of.

The GitHub sync (Team plan and above) keeps that honest: a card only closes when the branch feeding it actually merges. A feature marked "done" in a standup because it demoed fine on a test device stays open on the board until the pull request lands. That's a smaller gap than it sounds, and it's a common source of submission-week surprises.

What a rejection actually costs, and how to plan for it

Teams that treat rejection as a possibility rather than a surprise tend to build slack into the plan on purpose, not by accident. A submission date set with zero days of margin assumes first-pass approval every time, and that's a bet most teams lose eventually.

Building that margin in is mostly a scheduling discipline: submit earlier than the announced date allows for, treat the days between submission and approval as buffer rather than free time to start the next sprint's features, and keep the fix-and-resubmit path as a tracked set of tasks rather than an ad hoc scramble the moment a rejection email arrives.

The forecast helps here too. Because it's rebuilt from actual velocity every sprint, a team that's historically needed a resubmission round can see that reflected in how much margin the projection assumes, instead of everyone re-learning the same lesson each release. That's a concrete example of what the forecast is for: it isn't just a countdown, it's a record of how this team actually performs, so the next date it suggests already accounts for the rough patches the last one hit.

There's also a version-fragmentation cost specific to mobile that a web team never deals with: a fix that ships doesn't reach every user at once the way a web deploy does. Some portion of the install base stays on the previous version until they update, sometimes for months. Tracking which fixes require a forced update versus which can wait for the next natural release cycle is its own small planning decision, and one worth making deliberately rather than by default.

What "submittable" actually requires

• A hard freeze date on new feature work, separate from the QA and bug-fix window that follows it
• Platform-specific test items tracked individually, not folded into one "test the app" card
• Store listing text, screenshots and release notes tracked as tasks with owners, not left until the night before
• A named owner for the actual submission step in each store's console, so it doesn't fall to whoever remembers
• Buffer days built into the plan between submission and the announced launch date, not assumed away

None of it removes the review queue's unpredictability. It just means the team's side of the work is finished with enough runway to absorb it.

Where this sits next to the rest of engineering

Mobile teams rarely work in isolation from backend and web: a feature usually needs an API before it needs a screen. That shared work is easiest to plan when it's visible on the same kind of board the rest of engineering uses; see how sprint and release tracking works for the backend side of the same product.

Everything here sits on the same per-seat pricing as the rest of ShipSprint (see plans), with the GitHub sync available from the Team tier up, which is where most mobile teams land anyway once they've outgrown the free plan's two-project limit.