Convert an iOS app to Android: what carries over, what is written new

Open the project and read it as a specification rather than as code.

The screen map. The navigation code is the list of screens and how they connect: tabs, stacks, modals, what opens what. This is the single most expensive thing to recover from an app with no documentation, and the project has it exactly.

The data model. The types the app passes around are the data model. Their names, fields and relationships are the Android data model too.

The API layer. Every endpoint the app calls, with its parameters and the shape of its response. The backend does not change for Android; this layer is rewritten in Kotlin against the same contract.

Strings and localisations. Every piece of copy, in every language the app ships, in files that an agent reads and a human can export.

Assets. Icons, images, colours and the type scale, which carry across as values.

Business rules. What counts as a valid input, what happens at the end of a trial, how a price is rounded. Scattered through the Swift, re-implemented in Kotlin, unchanged in meaning.

Analytics events. The names and properties the product team reports on. The Android app has to send the same ones or the dashboards split.

Every screen, in Jetpack Compose, from Android’s parts: Material components, the system back gesture, the navigation bar or rail instead of the iPhone’s tab bar, edge-to-edge layout. The same screen, not the same pixels.

Platform services. Push notifications (Firebase Cloud Messaging on Android where iOS uses Apple’s service), the permissions model, which asks differently and at different moments, background work, deep links.

Billing. In-app purchases and subscriptions go through Google Play Billing, with its own product catalogue in the Play Console. The paywall screen is new; the products behind it are configured again.

The store presence. A Google Play Console account ($25 once), the listing, screenshots in Android sizes, the data-safety form, and a review process that is different from Apple’s.

Foldables and tablets. Android has had foldables since 2019; if the iPhone app already has an iPad layout, the same adaptive-layout line in the spec covers the Galaxy Z Fold.

The established route. The developer reads the Xcode project as the spec, writes the Android app in Kotlin, and the two apps are maintained by two people from then on. It works when there is budget for a second engineer for as long as the app lives, and it is the only route where you can pay someone to also carry the product decisions. The handover document is the thing to produce first: the screen map and the API contract, written down, so the developer does not have to reverse-engineer them.

Kotlin Multiplatform lets the data model, the API layer and the business rules be written once in Kotlin and compiled for both platforms, with the UI written separately in SwiftUI and Compose (or shared with Compose Multiplatform at the cost of native idiom on iOS). For an existing Swift app this is a migration, not an addition: the shared code has to be extracted from the Swift first. It pays off for a team that will keep both apps for years and has Kotlin engineers; it is a large step for a product person with one iOS app. Native vs cross-platform has the trade-offs of every shared-code approach.

The route that did not exist two years ago. An agent reads the Xcode project the way the developer in route 1 would (screen map, data model, API, strings, rules) and rebuilds the app feature by feature in a structure that produces both platforms: each feature’s logic written once, rendered in SwiftUI on iPhone and Jetpack Compose on Android. The iOS app you have keeps shipping while the rebuild runs; when the new project reaches parity it replaces it, and from then on one project produces both.

In Modaal, this is the Xcode-project import: add the project, and Modaal recovers the screen map and shows it to you as a map you can read without opening a line of Swift; you check it, fix what it misread, and approve a plan. The agent then builds the Android app from the same project against the same backend, and the iOS side is re-created in the same structure, so the next feature is written once for both. The projects are on your disk, in Xcode and Android Studio, from the first feature. The second thing it gives you is a handover: once the app is in Modaal, a product manager or designer can keep adding features from a spec, with the plan approved before any code, without writing Swift or Kotlin. The import is rolling out to early-access users in October 2026; the list is on /web-to-native#early-access.

<!-- [CONFIRM-13] option (b): replace the previous paragraph with: "In Modaal, point the agent at the Xcode project with the first prompt; Plan mode writes the screen list and the feature plan you approve, and the agent builds in a structure where each feature's logic is written once for SwiftUI and Jetpack Compose. The projects are on your disk from the first feature, and a product manager or designer can keep adding features from a spec without writing Swift or Kotlin." -->

The Free plan covers one project with unlimited prompts on one platform; Pro is €9 per user per month billed annually (€15 monthly) and adds both platforms, TestFlight distribution and Git collaboration (/pricing).

You have a team and a budget for two engineers for years: route 1, with the handover document written first.

You have Kotlin engineers and a long roadmap on both platforms: route 2, planned as a migration.

You have one iOS app, no Android engineer, and a product person who wants to keep shipping on both: route 3. Start with the screen map; if it is right, the rest follows the plan.

You are not sure the Android version is worth it: do the screen map and the API contract first in any route. They are the spec, they cost the least, and they tell you how big the Android app is before anyone writes Kotlin.