How to convert an Android application to iOS: a complete guide with examples

Transferring a mobile application from Android to iOS is a task that sooner or later faces any developer seeking to expand its audience. Despite the fact that both platforms operate in different programming languages ​​(Kotlin/Java vs Swift/Objective-C) and have fundamental differences in architecture, the conversion process can be optimized. The main thing is to understand the key differences: from design guidelines (Material Design vs Human Interface Guidelines) to the features of working with the hardware capabilities of devices.

Many people mistakenly believe that it is enough to simply rewrite the code in Swift —but this is just the tip of the iceberg. Under the hood there are nuances with libraries, API, system permissions and even the logic of interaction with the server. For example, processing push notifications on iOS requires integration with Apple Push Notification Service (APNs), while on Android is used Firebase Cloud Messaging (FCM). And adapting the interface to iPhone taking into account Safe Area and the absence of a hardware "Back" button may require reworking the navigation from scratch.

In this article we will examine 4 main approaches conversion, compare them in terms of time, cost and complexity, and also warn against common mistakes. You'll learn when it makes sense to use cross-platform frameworks like Flutter or React Nativeand when it's better to write native code from scratch. We will pay special attention to automatic converters (for example, J2ObjC from Google) - why they rarely give ideal results and in what 10% of cases their use is justified.

1. Key Differences Between Android and iOS: What to Consider Before Converting

Before you begin porting code, it is important to understand the fundamental differences between the platforms. They affect not only the technical part, but also the user experience.

Programming languages ​​and development environments:

• 📱 Android: Kotlin (recommended) or Java v Android Studio. Uses virtual machine ART.
• 🍎 iOS: Swift (priority) or Objective-C v Xcode. Compiled into native code for ARM64.

Architecture and components:

On Android applications are built on the basis of Activity i Fragment, while in iOS is used model UIViewController + UIView. For example, an analogue of RecyclerView on iOS is UITableView or UICollectionView, but their operating logic is radically different: on iOS often you have to manually manage the reuse of cells (dequeueReusableCell), whereas on Android it is automated.

Design and user interaction:

Guidelines Material Design i Human Interface Guidelines (HIG) dictate different approaches to animations, gestures and navigation. For example:

• ⬅️ On Android there is a hardware "Back" button, on iOS there is only a software one (and its behavior must be specified manually).
• 🔄 On iOS swipes are popular to return to the previous screen, on Android this is less common.
• 🎨 System fonts: Roboto vs San Francisco, different standards for indentation and line height.

2. Conversion methods: comparison of approaches

The choice of method depends on the budget, timing and performance requirements. Let's consider the pros and cons of each option.

Native development is the most reliable, but time-consuming method. Suitable for applications with high performance requirements (games, AR/VR, complex animations). For example, Instagram and Spotify were originally written separately for each platform.

Kotlin Multiplatform (KMP) allows you to separate business logic between platforms, leaving the UI native. This approach was chosen in Netflix i VMware for their cross-platform projects. The main advantage is that the common code works on both platforms without bridges (unlike Flutter).

Flutter and React Native accelerate development due to a single code base, but may lose in performance. For example, Airbnb refused from React Native due to problems with the integration of native modules.

Automatic converters (for example, J2ObjC from Google) translate Javacode into Objective-C, but do not support Kotlin and modern features iOS. utilities without a complex UI.

3. Step-by-step guide: conversion via Kotlin Multiplatform (KMP)

This method is optimal for applications where business logic is separated from the UI. Let's look at the process using the example of a simple notes application.

Step 1. Setup. project

Create a multi-platform project in Android Studio with support iOS:

// In the build.gradle.kts file (project level)
plugins {
id("org.jetbrains.kotlin.multiplatform") version "1.9.20"
}

Step 2. Code separation

Take out the overall logic (working with the database, network requests) into the module commonMain, and platform-dependent code - into androidMain and iosMain. For example:

// commonMain/kotlin/Note.kt
expect class DatabaseDriver {
fun saveNote(note: Note)
fun loadNotes(): List
}

Step 3. Implementation for iOS

In the module iosMain connect native dependencies via CocoaPods:

// iosApp/Podfile
target 'iosApp' do
pod 'SQLite.swift', '~> 0.14.1'
end

And implement DatabaseDriver for iOS:

// iosMain/kotlin/DatabaseDriver.kt
actual class DatabaseDriver {
actual fun saveNote(note: Note) {
// Implementation via SQLite.swift
}
}

Step 4. Integration with Xcode

Generate a framework for iOS and connect it to Xcode:

./gradlew :shared:embedAndSignAppleFrameworkForXcode

Create a multi-platform project in Android Studio|Put common logic into commonMain|Implement expect/actual for platform-dependent code|Configure CocoaPods for iOS dependencies|Generate a framework for Xcode-->

4. Typical mistakes and how to avoid them

Even experienced developers encounter pitfalls when porting. Here are the most common of them:

1. Ignoring guidelines Apple

Apple strictly moderates applications in App Store. For example, if your application uses a custom navigation with a bottom bar, this may be rejected: according to Android uses custom navigation with a bottom bar, on iOS this may be rejected: according to HIG, the bottom bar (Tab Bar) must contain no more than 5 elements, and the active element must be highlighted.

2. Memory problems

There is no garbage collector - instead it is used iOS there is no garbage collector - it is used instead ARC (Automatic Reference Counting). If in Androidversion you actively used weak links (WeakReference), they need to be replaced with unowned or [weak self] in Swift, otherwise memory leaks will occur.

3. Incompatibility of libraries

Many popular Androidlibraries (for example, Retrofit or Room) do not have direct analogues on iOS. You'll have to look for alternatives:

• 🔄 Instead of Retrofit — Alamofire or native URLSession.
• 🗃️ Instead of Room — CoreData or Realm.
• 📊 Instead of Glide/Picasso — SDWebImage or UIImageView s URLSession.

4. Permissions and security

The iOS permission system is stricter. For example, to access Bluetooth or Camera you need not only to declare permissions in Info.plist, but also to request them at runtime. In this case Apple requires an explanation of the reason for the request (key NSPhotoLibraryUsageDescription).

5. Testing on real devices

Emulators Xcode do not always accurately reproduce the behavior on physical ones iPhone. s Touch ID/Face ID or ARKit will only appear on a real device. Apple requires testing on the latest versions iOS (at the time of publication - iOS 17+).

5. Automatic converters: is it worth using J2ObjC?

J2ObjC - a tool from Googlethat translates Java-code in Objective-C. It can save time, but is not suitable for everyone.

Pros:

• ⚡ Fast conversion of basic logic.
• 🔄 Supported by most Java-libraries (for example, Guava).
• 🛠️ Can be integrated with Xcode as a static library.

Disadvantages:

• 🚫 Does not support Kotlin (only Java 8).
• 🎨 Does not convert XML markup and Android-specific UI.
• 🐌 Generation Objective-C, not Swift (which complicates support).
• 🔧 Requires manual modification for iOS-specific features (for example, Grand Central Dispatch instead of RxJava).

When does it make sense to use?

Only if:

1. Your application is written in Java (not Kotlin).
2. UI is simple and can be rewritten from scratch for iOS.
3. You are ready to manually adapt the work with the network, database and multithreading.

Example command for conversion:

j2objc --use-arc \
--xcode-project-project MyApp \
--xcode-project-company-identifier com.mycompany \
-d ../ios/GeneratedSources \
--no-package-directories \
src/main/java/

6. Optimizing performance after conversion

Even if the application was successfully compiled and launched on iOS, this does not guarantee its effectiveness:

1. Memory and CPU

Use Instruments to Xcode to find memory leaks and bottlenecks:

• 🔍 Allocations — monitors memory allocation.
• ⚡ Time Profiler — analyzes loading CPU.
• 🖼️ Core Animation —checks the performance of animations.

2. Network requests

On iOS restrictions on background work For example, Background Fetch works no more than once every 15 minutes. (on Android the interval can be set flexibly). For optimization:

• 📡 Use URLSession s backgroundConfiguration.
• 🗃️ Cache responses using URLCache.
• 🔄 For WebSocket, use Network.framework instead of third-party libraries.

3. Graphics and animations

On iOS for smooth animations it is recommended:

• 🎭 Use Core Animation instead of custom ones UIView.animate.
• 🖌️ For complex drawings — Core Graphics or Metal.
• 📱 Disable unnecessary shadows and gradients (they eat up FPS on older devices).

4. Local data

CoreData may be slower Room for large amounts of data. Alternatives: - fast NoSQL database Use

• 🗃️ Realm — fast NoSQL database.
• 📊 SQLite.swift - a wrapper over the native one SQLite.

7. Publishing in the App Store: requirements and lifehacks

The moderation process is App Store stricter than in Google Play. Here are the key points that will help you avoid rejection:

1. Preparation of metadata

• 📌 Bundle ID must be unique (format: com.companyname.appname).
• 🖼️ Screenshots must be for all supported resolutions (iPhone, iPad, iPhone Plus).
• 🎥 Preview video (optional, but increases conversion).

2. Security requirements

• 🔒 All network requests must use HTTPS (exceptions require justification).
• 📱 If the application collects user data, a privacy policy is needed (Privacy Policy).
• 🍪 For tracking (for example Facebook SDK) permission request is required App Tracking Transparency (ATT).

3. Technical requirements

• 📱 Support for the latest versions iOS (at the time of publication - iOS 17).
• 🖥️ Supports all screen resolutions (including iPad, if universality is declared).
• 🔧 No critical crashes (no more than 0.1% crashes per 1000 starts are allowed).

4. Lifehacks to speed up moderation

• ✅ Upload the build to TestFlight for internal testing before sending for review.
• 📝 In the Review Notes field, specify test accounts and instructions for moderators.
• 🔄 If an application is rejected, respond to the email with details - this often speeds up a second review.

How much does publication cost?

One-time placement of an application in App Store costs $99 per year (subscription Apple Developer app). For comparison: a one-time payment of Google Play — $25.

FAQ: Frequently asked questions about converting Android → iOS

let dbPath = Bundle.main.path(forResource: "database", ofType: "db")
let docDir = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first!
let destPath = docDir.appendingPathComponent("database.db")
try? FileManager.default.copyItem(at: URL(fileURLWithPath: dbPath!), to: destPath)