Mobile App Developer Roadmap: iOS, Android and Cross-Platform

Mobile App Developer Roadmap: iOS, Android and Cross-Platform

A mobile developer spends most of the week on state management, list performance, API edge cases, and making a screen behave identically on a three-year-old Android phone and a current iPhone. Expect eight to fourteen months from a standing start to employable if you are studying seriously most days, and longer if you are learning your first programming language at the same time.

Updated for 2026. Salary figures are indicative and move quarterly.

What This Role Actually Does

People imagine mobile development as designing beautiful screens. The screens are maybe a fifth of the job.

The real daily work is state: what the app knows, when it knows it, and what happens when the network disappears halfway through. A surprising share of mobile bugs are not logic errors — they are lifecycle errors, where the operating system killed your app in the background and restored it into a state you never tested.

The second largest chunk is platform negotiation. Permissions, background execution limits, push notification delivery, deep links, and the fact that Android's manufacturer-specific battery optimisation will quietly kill your background work on some devices and not others.

Then there is release engineering, which nobody advertises. Signing keys, provisioning profiles, build variants, staged rollouts, crash triage after a release, and the phone call when version 3.2.0 crashes on launch for users on one specific OS version.

What people wrongly imagine it is: that you build an app once and it is done. Mobile apps are never done — the platforms ship a new major OS version every year, and each one deprecates something you depend on. A mobile codebase you ignore for eighteen months is a codebase you will have to partially rewrite.

The other misconception is that mobile is easier than web because the screens are smaller. It is not easier, it is differently hard. You cannot hotfix a bad release in ten minutes; you ship it to a store, wait for review, and then wait for users to actually update.

Native or Cross-Platform: The Decision Table

This is the first fork in the road, so take it deliberately.

The honest recommendation: pick Android with Kotlin if budget is your constraint, iOS with Swift if you already own a Mac and want the highest average pay, and Flutter or React Native if your goal is shipping your own product rather than passing a platform-specific interview.

You need a Mac for iOS. There is no legitimate way around this. Xcode is macOS-only, and every signed iOS build passes through it, even in Flutter and React Native projects. A used Apple Silicon Mac Mini is the cheapest honest entry point.

The Roadmap

Stage 1 — One language, properly

What to learn: Either Kotlin or Swift, to the point where classes, optionals or nullability, collections, closures or lambdas, generics, and async concurrency are comfortable. Add Git basics in the same stage — branch, commit, rebase, resolve a conflict.

Do not skim this. Almost every mobile developer who plateaus at junior level plateaued because they learned the framework without learning the language underneath it.

Realistic time: 6–10 weeks at 10–15 hours per week.

Free resources by name: the official Kotlin documentation and Kotlin Koans from JetBrains; Swift's own The Swift Programming Language book, free from Apple; Google's Android Basics with Compose course; freeCodeCamp for general programming fundamentals if this is your first language; The Odin Project if you are coming from zero and want structured habits, even though its focus is web.

Portfolio project: a command-line or single-screen app that consumes a public API and parses JSON into typed models. Unglamorous and exactly the skill you will use daily.

You are done when: you can read unfamiliar code in your chosen language and explain what it does without running it, and you can write an async function that handles both success and failure without copying a snippet.

Stage 2 — The UI framework and the lifecycle

What to learn: Jetpack Compose (Android) or SwiftUI (iOS). Declarative UI, state hoisting, lists with recycling, navigation, and — critically — the activity/fragment lifecycle on Android or the view controller lifecycle and scene phases on iOS.

Learn what happens when the OS kills your process in the background. Learn where state survives and where it does not.

Realistic time: 8–10 weeks.

Free resources by name: Android Developers official codelabs and the Now in Android open-source sample app from Google; Apple's Develop in Swift Tutorials and the SwiftUI Tutorials on developer.apple.com; Hacking with Swift's free 100 Days of SwiftUI; Ray Wenderlich / Kodeco free article tier for both platforms.

Portfolio project: a two-screen app — a list fetched from an API and a detail screen — that correctly restores its scroll position and selected item after the OS kills and restores it. Test this by enabling "Don't keep activities" in Android developer options.

You are done when: you can explain, without notes, exactly what happens to your app's state when a user gets a phone call mid-session and returns four minutes later.

Stage 3 — Data, networking, and offline

What to learn: HTTP clients (Retrofit and OkHttp on Android, URLSession on iOS), JSON serialisation, local persistence (Room on Android, SwiftData or Core Data on iOS), caching strategy, and an explicit offline story.

Add dependency injection at a basic level — Hilt on Android, or plain initialiser injection on iOS. Add a repository layer so your UI never talks to the network directly.

Realistic time: 6–8 weeks.

Free resources by name: official Retrofit, Room, and SwiftData documentation; Google's Architecture Guide on developer.android.com, which is the single best free document on mobile app structure; Point-Free and objc.io free articles for iOS architecture.

Portfolio project: take your Stage 2 app and make it fully usable in airplane mode — cached data displays, writes queue locally and sync when connectivity returns, and the UI honestly tells the user what is stale.

You are done when: you can turn off wifi mid-session and your app degrades gracefully instead of showing a spinner forever or crashing on a null response.

Stage 4 — Ship one real app to a store

What to learn: Code signing, provisioning profiles or Play signing keys, app icons and adaptive icons, store listing copy and screenshots, privacy policy and data safety disclosures, App Store Review Guidelines and Google Play Developer Program Policies, staged rollout, and crash reporting.

This stage is the one that separates candidates. Most self-taught mobile developers never do it.

Realistic time: 4–6 weeks including at least one rejection cycle.

Costs to budget: Apple Developer Program at ninety-nine US dollars per year, recurring. Google Play developer registration at a one-time twenty-five US dollars. One physical test device that is not your daily phone, ideally a cheap older Android.

Free resources by name: App Store Connect Help and the Play Console Help documentation; Firebase Crashlytics free tier for crash reporting; Fastlane open-source docs for automating screenshots and uploads.

Portfolio project: a small, genuinely useful app — a habit tracker, a local transit timetable, a specialised calculator for a hobby you already have — published publicly with a real listing.

You are done when: the app is live, you have survived at least one review rejection, and you have shipped a second version fixing something a real user reported.

Stage 5 — Testing, performance, and CI

What to learn: Unit tests, UI tests (Espresso or Compose testing on Android, XCTest and XCUITest on iOS), test doubles, and a CI pipeline on GitHub Actions that builds and tests on every push.

Then performance: startup time, frame drops and jank, memory leaks, over-fetching, image loading, and app size. Learn the profilers — Android Studio Profiler and Instruments on Xcode.

Realistic time: 6–8 weeks.

Free resources by name: the Android Testing documentation and Macrobenchmark guides; Apple's Instruments documentation and WWDC session videos, which are free on the Apple Developer site; GitHub Actions documentation.

Portfolio project: add a CI pipeline to your published app that runs tests and produces a signed build artefact on every merge to main. Then cut your app's cold start time measurably and document the before and after in your README.

You are done when: you can point at a profiler trace and explain which specific call is costing you frames, rather than guessing.

Stage 6 — Cross-platform and the second platform

What to learn: Whichever of Flutter, React Native, or Kotlin Multiplatform fits your target jobs, plus at least a working reading knowledge of the platform you did not start with.

The point is not to become expert in both. It is to stop being helpless when a bug crosses the boundary.

Realistic time: 6–10 weeks.

Free resources by name: the official Flutter documentation and codelabs, which are unusually good; React Native official docs and the Expo documentation; Kotlin Multiplatform official tutorials from JetBrains.

Portfolio project: rebuild one screen of your published app in your chosen cross-platform framework and write an honest comparison post about what was faster, what was worse, and what you had to drop into native code for.

You are done when: you can explain to a non-technical manager, with specifics from your own project, why you would or would not choose cross-platform for a given product.

Stage 7 — Job readiness

What to learn: Mobile system design at interview level — offline sync, pagination, image caching, push architecture, feature flags, A/B testing, and analytics. Plus the standard data structures and algorithms round, which mobile interviews still include.

Realistic time: 6–8 weeks running alongside applications.

Free resources by name: NeetCode free problem lists; Stack Overflow's Developer Survey for market context; open-source apps to read seriously — Now in Android by Google and Signal's Android and iOS clients are both public and production-grade.

Portfolio project: your published app's README, rewritten as a case study — the problem, the architecture decision, what you rejected and why, the metrics.

You are done when: you can talk for fifteen minutes about a technical decision in your own app, including the part where you got it wrong first.

Salary and Job Titles

Figures below are indicative ranges assembled from the kinds of sources hiring managers and candidates actually use — Levels.fyi for tech-company compensation, US Bureau of Labor Statistics occupational data for software developers generally, the Stack Overflow Developer Survey for self-reported global spread, and Glassdoor aggregates for mid-market employers. These are not a single dataset, they are a reasonable reading across several, and they move every quarter with the hiring market.

Three things that distort these numbers. Large US tech employers pay substantially above the mid-market range at every level, and their equity component can exceed base salary at senior levels. Canadian salaries in CAD are structurally lower than US figures even before the exchange rate, which is why the CAD column is not a conversion of the USD column. And iOS specialists have historically edged out Android specialists in US averages, though the gap narrows at senior levels where platform matters less than judgment.

Treat every number here as a starting point for your own research on Levels.fyi for your specific city and company tier, not as a quote.

Who Should Not Take This Path

If you resent maintenance work, you will hate mobile. Two mandatory OS upgrades a year, deprecations you did not ask for, and a permanent backlog of "works on every device except this one." A large fraction of your career is keeping something working, not building something new.

If you cannot tolerate slow feedback loops. You do not ship a fix in ten minutes. You ship to a store, wait for review, and then wait weeks for users to update. If a fast deploy-and-observe cycle is what makes programming enjoyable for you, backend or frontend web will suit you far better.

If device testing sounds tedious, it is worse than you think. Android fragmentation is real. You will reproduce bugs that only occur on one manufacturer's skin, on one OS version, with one battery-saver setting enabled.

If you want to avoid design entirely. Mobile developers are held to a higher visual standard than backend engineers. You do not have to be a designer, but you do need to care whether a control is off by four points.

If you are chasing the highest possible pay per year of experience, backend, infrastructure, and machine learning roles generally pay more at the same seniority. Mobile pays well. It is not the top of the market.

The Five Mistakes

1. Learning the UI framework before the language. People who jump straight into SwiftUI or Compose without solid Swift or Kotlin can build screens and cannot debug them. Every plateau I have seen traces back to this.

2. Never shipping. Five tutorial clones sitting in a simulator prove almost nothing. One published app with a store listing, a privacy policy, a crash dashboard, and a second version proves nearly everything.

3. Ignoring the lifecycle until it bites. State loss on process death is the single most common category of "mysterious" mobile bug, and it is entirely learnable in an afternoon.

4. Choosing cross-platform to avoid learning a platform. Flutter and React Native are legitimate professional choices. They are not a way to skip understanding Android and iOS, and the first native module bug will prove it.

5. Testing only on your own new phone. Your device is fast, has good network, a full battery, and the latest OS. Almost none of your users match that profile. Buy a cheap old Android and test on it deliberately.

Print This Section

MOBILE DEVELOPER ROADMAP — STAGE SUMMARY

1. LANGUAGE                 6-10 weeks   Kotlin or Swift, deeply + Git
   Done when: you can read unfamiliar code without running it

2. UI + LIFECYCLE           8-10 weeks   Compose or SwiftUI, process death
   Done when: you can explain state loss on background kill

3. DATA + OFFLINE           6-8  weeks   Retrofit/URLSession, Room/SwiftData
   Done when: your app works fully in airplane mode

4. SHIP TO A STORE          4-6  weeks   Signing, listing, review, crash reports
   Cost: Apple $99/yr recurring | Google Play $25 one-time
   Done when: live in a store + one rejection survived + v2 shipped

5. TESTING + PERFORMANCE    6-8  weeks   XCTest/Espresso, CI, profilers
   Done when: you can read a profiler trace, not guess

6. CROSS-PLATFORM           6-10 weeks   Flutter / React Native / KMP
   Done when: you can argue for or against it from your own data

7. JOB READY                6-8  weeks   Mobile system design + DSA + case study
   Done when: 15 min of honest talk about your own architecture

TOTAL: roughly 8-14 months at 10-15 hrs/week
YOU NEED A MAC FOR iOS. No legitimate workaround.

🔗 Read next: Frontend Developer Roadmap if you are deciding between mobile and web, and the pillar guide Tech Career Roadmaps Compared to see how mobile stacks up against every other path on pay, time to hire, and market depth.