Mobile App Development

Who this is for

16 tasks running from concept through to store release and post-launch iteration. It's a project-management view of building a mobile app, not a technical one — useful for whoever is holding the timeline, whether that's a founder, a PM, or a developer wearing both hats.

Design before build, prototype before design

The wireframing and prototyping tasks sit early because changing a screen in a prototype costs an hour and changing it in shipped code costs a week. Get someone who isn't you to try the prototype before anyone writes production code. The confusions they hit are cheap now and expensive later.

Store review is a dependency you don't control

Both app stores can take days, and a rejection resets the clock. Build that into the schedule rather than treating submission as the last task before launch — plan to submit well before the date you've told anyone about, and read the review guidelines for the categories that trip people up: account deletion, subscription terms, permissions with unclear justification.

Have your store listing, screenshots, and privacy disclosures ready at submission time. They're commonly the thing holding up a build that's otherwise finished.

Test on real devices, and old ones

Simulators hide performance problems, and your own phone is newer than your median user's. Get the app onto a genuinely mid-range device before release; that's where the jank lives.

After release

The final tasks — crash monitoring, review responses, iteration — are the difference between an app that launched and an app that lives. Watch crash-free rates in week one and fix what's breaking before adding anything new.

Timing

Three to six months for a first version. Due dates help if you're coordinating designers or contractors.