iOS Developer's Roadmap to Android

If you've been working with Swift and SwiftUI as an iOS developer for years, moving to Android no longer feels like stepping into as foreign a world as it did two years ago. By mid-2026, the Kotlin and Swift ecosystems have converged more than ever before, and Google's official training curriculum offers a free path that starts from scratch without assuming any iOS experience as a prerequisite. In this article, I walk through, step by step, which concepts will feel familiar to you as an iOS developer learning Android, which ones genuinely need to be relearned, and how you can plan your first 30 days and beyond.

💡 Pro Tip: Don't start Android "from zero" — start from "the point where Kotlin is closest to Swift." Nullability and lambda syntax will put you at ease in the first week; the real challenge will show up in the architecture (UDF, ViewModel).

Table of Contents

• Three reasons the transition has gotten easier
• Concept map from Swift to Kotlin (optionals, protocols, coroutines)
• Syntax equivalence table
• Coroutines side by side with Swift concurrency
• Compose vs. SwiftUI: the mental-model difference
• UDF: this is where the real mental difference shows up
• Form factors and adaptive layout
• A concrete study plan for the first 30 days and beyond
• First month: Kotlin fundamentals and your first Compose screen
• Second month: architecture, networking, and data persistence
• The shared-core path: KMP and Swift-Android
• Two official paths: which core is shared
• expect/actual: separating platform-specific code
• What to showcase in your portfolio
• The certificate reality: store listing, not coding
• Four things to highlight in your portfolio
• 5 habits to avoid
• FAQ
• How does an iOS developer move to Android?
• How long does it take someone who knows Swift to learn Kotlin?
• Does becoming a dual-platform developer make career sense?
• Does learning Compose and SwiftUI at the same time cause confusion?
• Should I start with KMP or the Swift-Android SDK?
• Update (September 2026)
• Conclusion
• Sources

Three reasons the transition has gotten easier

By mid-2026, there are three concrete developments that make the move from iOS to Android noticeably easier than before.

First, Swift now officially runs on Android. Swift 6.3, released March 24, 2026, includes the first official Swift SDK for Android. Swift.org's announcement puts it this way: "Swift 6.3 includes the first official release of the Swift SDK for Android." With this SDK, Swift code can be integrated into existing Kotlin/Java Android apps via Swift Java and Swift Java JNI Core — the language you already know is now building a bridge to the other side too. The @c attribute in the same release is also worth noting — in Swift.org's words: "Swift 6.3 introduces the @c attribute, which lets you expose Swift functions and enums to C code in your project."

Second, Kotlin is answering this bridge in kind. Kotlin 2.4.0, released June 3, 2026, brought support for using Swift packages as dependencies inside Kotlin/Native, plus Swift export updates. JetBrains' announcement states: "Kotlin/Native: Support for Swift packages as dependencies, updates on Swift export, and the CMS GC enabled by default." The two ecosystems now recognize each other's package managers. The same release brought Java 26 support to Kotlin/JVM ("Kotlin/JVM: Support for Java 26 and annotations in metadata enabled by default") — if you've worked server-side with Swift (say, with Vapor), it's worth knowing Kotlin/JVM has a similar server-side ecosystem, since that same language knowledge applies if you ever move into backend Kotlin outside Android.

Third, Google's official curriculum doesn't treat iOS experience as a prerequisite. The "Android Basics with Compose" course only requires basic computer/math skills and a computer that can run Android Studio — no Swift or iOS knowledge is expected. This means an experienced mobile developer like you can start not from zero, but from "platform-specific details."

Concept map from Swift to Kotlin (optionals, protocols, coroutines)

The thing that saves the most time while learning Kotlin is being able to map it against Swift concepts already in your head. Unit 2 (21 hours) of Google's official "Android Basics with Compose" course starts exactly here: conditionals, nullability, classes, lambdas.

Syntax equivalence table

Coroutines side by side with Swift concurrency

When it comes to coroutines, the official course has a separate, more advanced unit for it: Unit 5 (9 hours) teaches coroutines together with network calls (HTTP/REST, Retrofit). Kotlin coroutines and Swift's async/await have different error-handling and cancellation rules; don't rely on the similarity and skip over these. The rules of structured concurrency aren't identical on both sides either, so compare behavior, not syntax. The two examples below show the same task in both languages:

1// Kotlin — suspend function + coroutine scope
2suspend fun fetchUser(id: String): User {
3    return withContext(Dispatchers.IO) {
4        api.getUser(id)
5    }
6}
7 
8// Call: inside a coroutine scope
9viewModelScope.launch {
10    val user = fetchUser("42")
11    _uiState.value = UiState.Loaded(user)
12}

1// Swift — async function + Task
2func fetchUser(id: String) async throws -> User {
3    try await api.getUser(id)
4}
5 
6// Call: inside a Task
7Task {
8    let user = try await fetchUser(id: "42")
9    uiState = .loaded(user)
10}

suspend fun and async func, viewModelScope.launch and Task { } structurally serve a similar purpose: the caller waits for the asynchronous result without blocking the thread. But error handling (try/catch vs. Kotlin's Result type or exceptions), structured concurrency rules, and cancellation mechanisms differ in the details — it's healthier to learn these by writing code than by memorizing them.

Compose vs. SwiftUI: the mental-model difference

Google describes Jetpack Compose on its official course page like this: "…Compose simplifies and accelerates UI development on Android with less code, powerful tools, and intuitive Kotlin APIs." If you're familiar with SwiftUI, this description will feel familiar. The "Jetpack Compose for Android developers" course splits learning into five pathways: "Compose essentials," "Layouts, theming, and animation," "Architecture and state," "Accessibility, testing, and performance," and "Form factors."

UDF: this is where the real mental difference shows up

The real mental difference shows up in the architecture. Unit 4 (28 hours) of the official curriculum teaches ViewModel, StateFlow, and the UDF (unidirectional data flow) pattern together, as a separate block — alongside Compose navigation. In SwiftUI too, you can set up a similarly unidirectional data flow with @State/@Observable, but the fact that UDF is given this much emphasis on the Android side, as its own dedicated unit in the official curriculum, shows that Google treats it not as an "optional good practice" but as a fundamental architectural rule that must be learned.

1// Compose — state hoisting + UDF
2@Composable
3fun CounterScreen(viewModel: CounterViewModel = viewModel()) {
4    val uiState by viewModel.uiState.collectAsState()
5    Column {
6        Text("Count: ${uiState.count}")
7        Button(onClick = { viewModel.increment() }) {
8            Text("Increment")
9        }
10    }
11}
12 
13class CounterViewModel : ViewModel() {
14    private val _uiState = MutableStateFlow(CounterState())
15    val uiState: StateFlow<CounterState> = _uiState.asStateFlow()
16 
17    fun increment() {
18        _uiState.update { it.copy(count = it.count + 1) }
19    }
20}

The lesson here is this: the composable function doesn't hold its own state, it reads it from the ViewModel and passes the event (increment()) upward — exactly the definition of UDF. In SwiftUI, you can set up the same pattern with an @Observable class + Button(action:), but the Compose curriculum makes it mandatory from the start.

Form factors and adaptive layout

The name of the fifth pathway ("Form factors") is also notable: "Jetpack Compose for Android developers" lists it as a separate learning block. "Android Basics with Compose" also states it covers "adaptive layouts for different screen sizes." On iOS you're used to a single SwiftUI view behaving adaptively between iPhone and iPad; seeing this treated as a separate curriculum heading on Android shows phone/tablet/foldable diversity is a priority for Google too.

A concrete study plan for the first 30 days and beyond

Rather than making up a plan, I'm basing it directly on the hour breakdown of Google's official "Android Basics with Compose" course. The course is split into 8 units totaling roughly 100 hours; if you set aside ~1.5-2 hours a day, you'll finish the first three units (46 hours) within the first 30 days.

First month: Kotlin fundamentals and your first Compose screen

Once you finish these three units, the nullability and closure intuition from Swift will have settled into Kotlin syntax, and you'll be writing your first Compose screens. The following month continues naturally: Unit 4 (architecture: ViewModel/StateFlow/UDF, 28 hrs), Unit 5 (coroutines + networking, 9 hrs), Unit 6 (Room + DataStore, 10 hrs) — iOS/Swift experience is never a prerequisite anywhere in the course.

Second month: architecture, networking, and data persistence

You can draw a plan for the second month from the same hour breakdown:

This two-month plan covers most of the official course's 100 hours; in these final weeks you'll see the Android counterparts (Room, DataStore) of concepts you already know from SwiftData/CoreData and UserDefaults — the framework name changes, but "local database + simple key-value store" stays the same.

The shared-core path: KMP and Swift-Android

There are two separate, complementary official paths here; it's important not to mix them up.

Two official paths: which core is shared

Path A — Kotlin Multiplatform (KMP): Google's "Basics of Kotlin Multiplatform" pathway defines two official ways of bringing a shared Kotlin core to iOS: integrating the shared module directly into an Xcode project, or — in the official wording — "…release your shared KMP module as a standalone Swift Package for use by an iOS app, similar to any other Swift library." The pathway also covers moving the Room database to KMP as a concrete example that reduces code duplication.

Path B — Bringing Swift to Android: Swift 6.3's official Android SDK works in the opposite direction — it lets you integrate Swift code into an existing Kotlin/Java Android app. Kotlin 2.4.0's support for Swift package dependencies strengthens this bridge from the Kotlin side too.

In short: KMP = shared Kotlin core + iOS client; Swift-Android SDK = shared Swift core + Android client. Which one you choose depends on which language your team has deeper expertise in — both are officially released as of June 20, 2026 (the Swift SDK for Android moved from nightly previews to a stable release with Swift 6.3).

expect/actual: separating platform-specific code

The expect/actual pattern used in KMP to separate platform-specific code will remind a Swift developer of protocol + platform-specific implementation logic:

1// commonMain/kotlin/PlatformInfo.kt — shared interface
2expect class PlatformInfo() {
3    val osName: String
4}

1// androidMain/kotlin/PlatformInfo.kt — Android implementation
2actual class PlatformInfo actual constructor() {
3    actual val osName: String = "Android"
4}

1// iosMain/kotlin/PlatformInfo.kt — iOS implementation
2actual class PlatformInfo actual constructor() {
3    actual val osName: String = "iOS"
4}

What to showcase in your portfolio

The certificate reality: store listing, not coding

A clear distinction is needed here: Google does not have an "Android developer completion certificate" program that documents coding proficiency. The official certificate program it runs is the Google Play Store Listing Certificate — this is a store-listing/marketing certificate, not a coding proficiency credential.

Four things to highlight in your portfolio

When building your portfolio, I'd suggest prioritizing these four things:

• Mark the pathways you've completed. Compose's 5 pathways ("Compose essentials," "Layouts, theming, and animation," "Architecture and state," "Accessibility, testing, and performance," "Form factors") and the KMP pathway show your progress concretely.
• Show the same app on two platforms. A small project with a shared Room/data layer built via KMP, with both an Android and an iOS client, proves you genuinely understand "Path A."
• Show that you apply UDF deliberately. A screen written with ViewModel + StateFlow + unidirectional data flow lets you give an interview answer to "why this way" that's grounded in the official curriculum.
• Note that you've gone through a real publishing process in Play Console. Completing the Google Play Store Listing Certificate shows you know your way around the store-listing side too — a competency parallel to App Store Connect. The first time you log into Play Console, look for an equivalent of the "list → test → publish" flow you're used to in App Store Connect.

5 habits to avoid

The items below are practical observations I've drawn from the emphasis distribution in Google's official curriculum — the points an iOS-background developer trips over most often.

1. Skipping UDF and leaving state open to mutation from everywhere. The fact that the official curriculum treats ViewModel/StateFlow/UDF as a separate, 28-hour unit is a sign that this is considered a fundamental rule, not an "optional good practice."
2. Leaving accessibility for last. In the Compose course, Accessibility, Testing, and Performance are given together in the same pathway, as their own block — not a "nice to have" to be tacked on at the end.
3. Assuming coroutines are identical to Swift concurrency. Relying on the suspend/Task similarity and skipping over the details of error handling and cancellation leads to bugs.
4. Confusing KMP with the Swift-Android SDK. One is a shared Kotlin core, the other a shared Swift core — making an architectural decision without clarifying which direction the sharing goes ends up costing a major refactor down the line.
5. Leaving Room/DataStore for last. Unit 6 makes data persistence (Room) and key-value storage (DataStore) their own unit; a developer familiar with SwiftData/UserDefaults may breeze through this area, but the curriculum keeps it separate — it's not unimportant enough to skip.

FAQ

How does an iOS developer move to Android?

The fastest path: follow Google's official free curriculum in order — Kotlin and Compose fundamentals with "Android Basics with Compose," then architecture with "Jetpack Compose for Android developers," and optionally the shared-core approach with "Basics of Kotlin Multiplatform." None of these treat iOS or Swift experience as a prerequisite, so you can start right away.

How long does it take someone who knows Swift to learn Kotlin?

There's no fixed official duration, but the course's own hour breakdown offers a reference point: "Android Basics with Compose" is roughly 100 hours across 8 units. Thanks to nullability and lambda intuition carried over from Swift, you'll usually get through the first two units (Unit 1 + Unit 2, 31 hours) faster; most of the time goes into internalizing the architecture (UDF, ViewModel, 28 hours).

Does becoming a dual-platform developer make career sense?

The career decision depends on personal context; what's concrete on the technical front is this: Swift 6.3's official Android SDK and Kotlin 2.4.0's Swift package support show the two ecosystems converging technically, which means dual-platform competency has become less friction-heavy in terms of tooling support than before.

Does learning Compose and SwiftUI at the same time cause confusion?

Knowing that both frameworks share a "less code, declarative UI" philosophy reduces the confusion. The difficulty isn't in the frameworks themselves but in platform-specific architectural rules, like Android's emphasis on UDF.

Should I start with KMP or the Swift-Android SDK?

Look at your team's core language expertise: if you're stronger in Kotlin, moving a shared core to iOS with KMP creates less friction; if you're stronger in Swift, doing the reverse with Swift 6.3's Android SDK does. Both are officially supported as of June 20, 2026.

Update (September 2026)

The body of this article was written with the tools and versions current as of June 20, 2026. Since then, a few concrete developments have emerged that could affect the learning path:

• Swift 6.4 (September 15, 2026): Swift/Java interop was expanded, and Swift Build became SwiftPM's default build system — the Swift-Android bridge keeps solidifying since launch. Source: swift.org/blog/swift-6.4-released/
• AGP 9.2 + R8 (July 27, 2026): With the Android Gradle Plugin update, Kotlin Coroutines' performance on Android got 2x faster, per the official Android Developers blog. For someone newly learning coroutines, that's no extra friction — if anything, faster ground.
• Kotlin 2.5.0-Beta1 (September 23, 2026): New language features like companion extensions and companion blocks are in beta; this article's Kotlin 2.4.0-based examples remain valid, though a stable 2.5 may warrant a "what changed" note.
• AndroidX Security State Libraries (September 17, 2026): New security-state libraries were announced — worth noting as an advanced topic beyond this roadmap.

None of these items invalidate the core roadmap in the body of the article (Kotlin fundamentals → Compose → architecture → KMP); they just show that the tooling keeps evolving.

Conclusion

Swift 6.3's official Android SDK and Kotlin 2.4.0's Swift package support brought the two ecosystems noticeably closer by mid-2026 than in previous years. But what really makes the difference is that Google's "Android Basics with Compose" and "Jetpack Compose for Android developers" offer a free curriculum with a clear hour breakdown and no iOS prerequisite. With the nullability and closure intuition you bring from Swift, you can warm up to Kotlin fast and put your real energy into UDF and architecture.

To keep going, build broader context with 10 technologies to learn in 2026, see the shared-core approach in a real project with Kotlin Multiplatform 1.1 production case study, or go further with Compose Multiplatform Android-iOS production. Curious about the Kotlin compiler's new features? See Kotlin 2.1 K2 compiler and context parameters; for Compose performance, see Jetpack Compose 1.7 performance and strong skipping. Preparing for interviews? Some principles in iOS interview preparation apply on Android too.

Sources

• Swift 6.3 Released — announcement of the first official Swift SDK for Android.
• Swift 6.4 Released — Swift/Java interop expansion and the Swift Build default.
• Kotlin 2.4.0 — What's New — Kotlin/Native Swift package support and context parameters.
• Kotlin 2.4.0 GitHub Release — primary confirmation of the release date.
• Android Courses — Google's official course catalog — list of all pathways and courses.
• Android Basics with Compose — unit breakdown and hour plan.
• Basics of Kotlin Multiplatform pathway — KMP's two official iOS integration paths.
• Jetpack Compose for Android developers — the 5-pathway Compose curriculum.
• Google Play Store Listing Certificate — the official store-listing certificate.
• How R8 made Kotlin Coroutines on Android 2x faster — announcement of coroutines performance with AGP 9.2 + R8.
• Introducing the AndroidX Security State Libraries — announcement of the AndroidX Security State libraries.