The build runs perfectly on your phone and dies on the first tester's. Same code, one Android version older, a permission the emulator granted without asking, and a device whose manufacturer changed how background work is allowed to behave. Mobile development is the discipline of shipping software to hardware you do not control, through a store that reviews your work before anyone can install it.
That last part is what separates this job from web work and surprises almost everyone. You cannot hotfix a bad release at 2am. You submit, you wait, you hope the reviewer's device behaves like the one in your hand. Learning this trade means learning to be careful before release rather than fast after it.
Two Stores Decide Whether Your App Exists
A mobile app developer builds software that runs on a device someone carries, with a battery that runs out, a network that drops in a lift, and an operating system that updates whether the app is ready or not. The deliverable is an installable build that passes review, starts quickly, survives being backgrounded, and does not drain the phone by lunchtime.
The constraints are physical in a way web developers find unfamiliar. Memory is measured in hundreds of megabytes and the system will kill your process to reclaim it. Startup time is measured in milliseconds and users notice anything past a second. Storage is shared with photos. And every additional megabyte of download size costs you installs, because a meaningful share of users abandon a download that takes too long on a mobile connection.
Then there is the release pipeline, which is a skill of its own. Signing keys, provisioning profiles, version codes, staged rollouts, beta tracks, and a review process where a rejection can add days to a schedule that already slipped. A developer who has never shipped to a store tends to treat release as a button. It is closer to a procedure with preconditions, and most of the painful stories in this field come from skipping one of them.
Day to day, the work splits between interface, state and platform. You build a screen that has to work on a 5-inch phone and a tablet. You handle a login flow that must survive the user switching to their email app to fetch a code and coming back to a process that may or may not still exist. You read a crash report from a device model you have never seen and work out that the issue is a font metric on a specific manufacturer's build.
The role also sits closer to product than most engineering jobs. Mobile apps are judged by ratings, and ratings respond to things engineers consider cosmetic: a spinner that appears too late, a keyboard that covers the button, a permission prompt that arrives before the user understands why. Small interface decisions carry outsized weight, which is why the UI/UX area appears in this roadmap at all.
The gate into paid work is an app in a store, or a very good reason why not. A repository of screens is not evidence. A published app with real users, a crash-free rate you can quote, and a release you maintained through at least one operating system update is evidence, and it answers the question every mobile interviewer asks: have you shipped?
What Each Layer of an App Draws From the Catalog
Four areas feed this role, and each one owns a layer of the product.
Mobile Development is the platform layer: the languages, the frameworks, the tooling and the store mechanics. It holds 31 live entries, with 30 free and 1 paid. This is where the role is defined, and it is unusually well supplied at no cost, because both platform vendors publish their own documentation and training for free.
Software Engineering is how the app stays maintainable across the operating system updates that will break it. Version control, types, testing, and the habit of separating platform code from business logic so that a rewrite of one does not require a rewrite of the other. The catalog lists 36 resources here, 30 at no cost and 6 paid. Mobile codebases rot quickly when everything is wired directly into a view.
UI/UX Design governs the part users judge you on. Touch targets, thumb reach, contrast, empty states, and the platform conventions that make an app feel native rather than ported. That area carries 30 live resources, split into 20 free and 10 paid, and it has the highest paid share in this roadmap, which is worth knowing before you budget.
Databases & Backend covers where the data lives and syncs. Local storage, caching, sync conflict rules, authentication, and the API your app talks to. It holds 31 live entries with 27 free and 4 paid. Mobile developers do not need to build backends, but they do need to understand why a sync that works online breaks the first time two devices edit the same record.
Read together, the four areas map onto the layers of a single app. The platform layer decides what you can build. Software Engineering decides whether it survives the next year. UI/UX decides whether anyone keeps it installed. Databases & Backend decides whether the data is still correct when the network returns.
A Path From First Screen to Store Listing
The order below gets you to a store listing with something you would not be ashamed to show. Each stage ends with something that runs on a physical device.
Stage one: one platform, one language, one screen that installs. Choose a platform and stop deliberating. Android Basics in Kotlin (Google) (FREE) is the official on-ramp, written for people with no Android experience. Kotlin Playground (FREE) runs in a browser, which removes the install step while you learn syntax. Kotlin Koans (FREE) teaches the language through small exercises with tests. Android Studio (FREE) is the tool you will use, including the emulator and the profiler. For the Apple path, Apple Develop in Swift Tutorials (FREE) assumes nothing, and 100 Days of SwiftUI (Hacking with Swift) (FREE) is the paced version that most self-taught iOS developers actually finish. Finish when a screen you built yourself installs on a real phone and survives being rotated.
Stage two: learn the platform's own idioms instead of fighting them. This is where ported apps reveal themselves. Android Developers Documentation (FREE) covers lifecycle, permissions, intents and background limits, which are the four topics that break naive apps. Apple Developer Documentation (FREE) does the same for view lifecycles, app states and the permission model. Kotlin Documentation (FREE) is worth reading properly rather than searching, since coroutines and null safety are the two features that most change how you write code. Exercism Kotlin Track (FREE) gives mentored practice on the language outside the app. Finish when you can explain what happens to your screen when the user takes a phone call.
Stage three: state, storage and the network. Most real apps are a data problem with a screen on top. Flutter Codelabs (FREE) teaches state management and platform channels through complete projects, and the patterns transfer even if you never use Flutter. CS50's Mobile App Development with React Native (FREE) is a full course on building an app that talks to a backend, including the parts that break when the network does. Expo Documentation (FREE) covers the toolchain that makes React Native practical, including builds and over-the-air updates. FastAPI Documentation (FREE) gets you a working API in an evening when you need one. MongoDB University (FREE) covers the document model that most mobile backends end up using. Finish when your app reads and writes data, shows a clear state while offline, and recovers when the connection returns.
Sync is the part of that sentence people underestimate. Two devices editing the same record produce a conflict, and the app has to decide without asking the user a question they cannot answer. The practical defaults are worth knowing before you design the schema: last write wins is simple and quietly loses data, per-field merge is better for forms, and an append-only log of changes handles the cases where history matters. Choose one deliberately, write down why, and test it by turning off the network on both devices and editing the same row.
Stage four: make it feel like it belongs on the device. Apple Human Interface Guidelines (FREE) is the clearest writing available on touch targets, navigation and feedback. Material Design 3 (FREE) is the equivalent for Android, including the dynamic color system that makes an app look current. Laws of UX (FREE) explains why some layouts feel easier without turning the explanation into folklore. Checklist Design (FREE) turns interface review into a list you can actually run before a release. Figma Learn (Help Center) (FREE) is worth an afternoon even for developers, since you will receive designs in that format. Finish when you can hand your app to someone and watch them use it without instructions.
Stage five: ship it and keep it alive. Google Codelabs (FREE) covers the platform features you will need after launch, including notifications, authentication and Play Console tasks. Android Developers Training Courses (FREE) goes deeper on architecture and testing. Android Developers YouTube Channel (FREE) is where platform changes are explained before they break your build. Flutter YouTube Channel (FREE) serves the cross-platform path. iOS Dev Weekly (FREE) is the single best way to keep up with the Apple ecosystem without reading release notes. Awesome Flutter (FREE) and Awesome React Native (FREE) are curated lists, useful at the moment you need a library for something specific rather than a course. Finish when your app is live, has crash reporting wired up, and has survived one update.
Two numbers decide whether the app feels good, and neither is visible in a feature list. Startup time is the gap between the icon being tapped and the first useful screen, and every library initialized at launch spends from it. Download size is the number next to the install button, and it is the one number a user consciously evaluates. Both are measurable for free with the platform's own tooling, and both are easier to protect during development than to fix afterwards, because the fix is usually removing something you already built around.
Fixes for Problems That Arrive After Launch
Some entries answer questions that only appear after the first release.
For the signing and store maze, Android Developers Documentation (FREE) remains the authority, particularly the pages on app signing and release tracks, which are the two places beginners lose days. Apple Developer Documentation (FREE) covers certificates and provisioning, which are the least intuitive part of the iOS toolchain and the least well explained anywhere else.
For cross-platform decisions, Flutter Documentation (FREE) is unusually good at explaining what the framework does not do, which is the part that decides whether the approach suits your app. Dart Documentation (FREE) is the language underneath. DartPad (FREE) runs in a browser, which makes it the fastest way to answer a syntax question without opening an editor.
For interface work that has to survive small screens, Refactoring UI (PAID) is the fastest route from "this looks off" to naming the reason. Mobbin (PAID) holds screenshots of real app flows, which is faster than inventing a settings screen from first principles. Page Flows (PAID) records interactions rather than stills, which matters for onboarding and checkout. Godly (FREE) curates ambitious site and app design for calibration. Growth.Design Case Studies (FREE) explains, panel by panel, why an onboarding flow converts or loses people. Design Systems Repo (FREE) shows how component libraries are documented, which is what a growing app needs by its second year.
For the backend you will eventually need, Full Stack Open (FREE) is the best free bridge from a client to a server. Express.js Guide (FREE) gives you a minimal service quickly. PostgreSQL Tutorial (FREE) covers the queries you will write when the app grows past a single table. Select Star SQL (FREE) teaches those queries through questions rather than syntax lists. Backend Developer Roadmap (FREE) shows the shape of the discipline so you can ask better questions of whoever owns it.
For the commercial side, Build and Monetize Android Apps with ChatGPT: Complete AI Course (PAID) is the only paid entry in Mobile Development. It is worth considering only after you have shipped something and want a tour of monetization mechanics, since the material assumes an app exists.
What the Free Route Costs in Weeks
Mobile Development holds 30 no-cost entries against a single paid one, which makes this one of the cheapest areas in the catalog to learn from. Both platform vendors publish their own documentation and training without charge, and the frameworks in this roadmap are free and open source. A serious beginner can reach a published app without buying a course.
The costs that remain are not educational. A developer account for the Apple store carries an annual fee, and the Android console charges a one-time registration. A physical test device matters more than any course: an older Android phone is the single most useful purchase in this roadmap, because it will surface the layout and performance problems that a flagship hides.
Time is the honest constraint. A first published app takes most people four to eight months of part-time work, and the last six weeks are almost entirely store mechanics rather than features. Reaching a level where you can be trusted with someone else's production app takes twelve to eighteen months, and the variable that matters is not the number of apps but whether you maintained one through an operating system update.
What should exist before you apply anywhere: one published app with crash reporting, one release note describing a fix you shipped under pressure, one screen rebuilt from a design file, and a crash-free rate you can quote from memory. Those four things are more persuasive than a portfolio site, because they answer questions about maintenance rather than creation.
What money buys here: a test device, a developer account, and occasionally a paid library or course. What it does not buy: a spot in the store, which is earned by passing review, or retention, which is earned by the product.
The second year is where the economics change. Maintaining an app means paying the developer account fee again, rebuilding against a new platform version, and answering reviews that arrive months after launch. An app with a thousand users and no maintenance is a slow decline in ratings rather than a stable asset. Anyone planning to build a portfolio should plan to keep three apps alive rather than publish ten and abandon them, because an abandoned app with a broken login is worse evidence than no app at all.
Rejections, Crashes, and Ordinary Setbacks
Privacy disclosure is the other part of release that catches developers out. Both stores require a statement of what data the app collects and why, and a mismatch between that statement and the app's actual behavior is grounds for removal rather than a warning. The practical habit is to keep a list of every third-party library that touches user data, update it when a dependency changes, and write the disclosure from that list rather than from memory.
The first setback is a store rejection, and it is close to universal. Common causes are missing privacy disclosures, a screenshot that does not match the app, a login requirement with no demo account for the reviewer, or a permission the app requests without explaining it. None of these are code problems. All of them cost days. The fix is a release checklist written once and followed every time.
The second is an emulator-only workflow. The emulator is fast, generous and wrong. It grants permissions silently, has no thermal throttling, and never has a manufacturer's custom build. Every release should be tested on at least one physical device that is not yours, ideally an older one.
The third is ignoring offline behavior. Mobile networks drop, and a screen that shows a blank state when a request fails reads as a broken app rather than a disconnected one. Cache what you can, show what you have, and make the retry obvious.
The fourth is treating permissions as a formality. Asking for camera access on first launch, before the user understands why, is the fastest way to get a denial that is permanent. Ask at the moment of use, in context, with a sentence that explains the benefit.
The fifth is shipping without crash reporting. An app in the wild will crash on devices you cannot buy, and without a reporting tool you will learn about it through one-star reviews. Wire it up before the first release rather than after the first complaint.
The sixth is choosing cross-platform before knowing one platform. Frameworks hide platform behavior until something breaks, and then you need to know what the native layer would have done. Learn one platform properly first, then evaluate the shared-code option with actual judgment.
The seventh is the missing beta track. Both stores offer a way to release to a small group before everyone. Skipping it means your first hundred users are also your testers, and their reviews will say so.
The eighth is ignoring the keyboard. It covers the field the user is typing in, or it pushes the layout up and leaves it there, or it dismisses on a tap that was meant for a button. Keyboard handling is the most common source of one-star reviews that mention nothing else, and it is invisible to anyone testing on a device with a hardware keyboard attached.
The ninth is the annual operating system update, which arrives with a deprecation you did not plan for. A framework version stops being supported, a permission model changes, or a background behavior you relied on is restricted. Developers who treat the platform as stable spend a week in firefighting each year. The ones who read the release notes in advance spend an afternoon. Subscribing to one weekly digest is enough to see it coming, and the habit costs nothing.
Beyond the First Release
Go deeper in the four areas this roadmap rests on: Mobile Development, Software Engineering, UI/UX Design, and Databases & Backend. When a stage above felt thin, the matching area page is a better next stop than a new framework.
The neighboring roles are worth reading if your interest is shifting. A frontend developer works with the same interface problems but a far shorter release cycle and no review queue. A backend developer owns the API your app talks to and will thank you for pagination. A UI designer works in the design tool and hands over the frames you implement. The full list is at Browse by Profession.
If you want one action now, install your most recent build on the oldest phone you can borrow and use it for a day with the network throttled. The list you write down is your next month of work, and it will contain at least three things no tutorial would have taught you.
FAQ
Should I learn Flutter, React Native, or native development?
Learn native first if you can, because every cross-platform framework eventually asks you to understand the platform underneath. Choose Flutter for a single codebase across both stores with consistent rendering. Choose React Native if you already write JavaScript or TypeScript and want to reuse that. Choose native if you are targeting one platform, need deep hardware access, or want the largest pool of mobile job listings.
Do I need a Mac to build for iOS?
Yes, for the build and submission toolchain, though cloud build services exist and can carry you through a first release. Android development runs on any major desktop. If you are undecided and budget is tight, start on Android, where the entire path is free and the tooling is more forgiving.
How do I find testers for a first app?
Recruit five people who are not developers and let them install from a beta track. Watch them use it without helping. The first three will hit the same confusion, and that is your evidence. Local communities, classmates and friends of friends are enough. The purpose is not scale, it is seeing the app through hands that do not know where anything is.
Do I need my own backend for a simple app?
Not at first. Local storage carries a surprising amount of product, and a hosted service can cover authentication and sync without you running servers. Build a backend when you need data shared between devices or users, and use Full Stack Open (FREE) if you want to understand what you are adopting.
How long does store review take, and can I plan around it?
Review times vary by store and by season, and a rejection resets the clock. Plan releases with buffer rather than a deadline, keep a checklist for the common rejection causes, and never schedule a launch on the assumption that the first submission passes. The teams that ship predictably are the ones that submit early and often.
Is a paid course worth it for mobile development?
Rarely, because the free official material is unusually complete and the paid options in this area are thin. Spend the money on a test device and a developer account first. Buy a course only when you can name the specific gap, such as monetization mechanics or a framework you have already chosen.
SkillCache Editors · Updated November 13, 2026
