Beyond the Apple Ecosystem: The Reality of Swift on Android

Imagine writing an intricate, massive guidebook, but every time you want to publish it in a new country, you have to rewrite the entire book from scratch in a completely different language.

For years, that’s just been the tax you pay for building mobile apps. But recently, the mobile engineering world got a massive shake-up. With the release of Swift 6.3 and 6.4, Apple officially released a dedicated Software Development Kit (SDK) to run Swift code natively on Android that changed the math by introducing official toolchains to run Swift code natively on Android.

Working daily with both native iOS and Flutter projects, I’ve been tracking this closely. There is a lot of hype out there, so let’s cut through the marketing fluff and look at how this actually works, where it trips up, and if it’s worth your time.

The Big Misconception: The Engine vs. The Paint

When non-developers hear “Swift on Android,” they usually picture a magic button that takes an iPhone app and instantly turns it into an Android app. That is not what is happening here.

To make sense of this, it helps to split an app into two parts: the Engine (the invisible logic, math, and API calls) and the Paint (the actual UI screens and buttons).

Get Charu Gupta’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

With Swift’s new Android support, you are only sharing the Engine. You can take the invisible Swift logic from your iPhone app and drop it into your Android app. However, you still have to build the Paint (the user interface) entirely from scratch using Android’s native visual tools (Jetpack Compose).

What This Looks Like in Code

Thanks to the Swift Android Workgroup, you don’t have to manually write absolute nightmare JNI (Java Native Interface) code anymore. You just expose your Swift function with a tag:

import Foundation

// Exposing a shared calculation directly to the Android layer
@_cdecl("Java_com_portfolio_app_CoreLogic_calculateTax")
public func calculateTax(amount: Double) -> Double {
    return amount * 1.18 // Straightforward Swift math
}

On the Android side, the Kotlin developer just calls it as normal external code. The heavy calculations happen in Swift, but the button the user presses to trigger it is pure Android.

// MainActivity.kt - Android Native UI Connection
package com.portfolio.app

import android.os.Bundle
import androidx.activity.ComponentActivity

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        
        // Calling our compiled Swift binary directly through JNI
        System.loadLibrary("SharedCore") 
        val totalAmount = CoreLogic.calculateTax(100.0)
        
        // Render totalAmount natively using Jetpack Compose...
    }
}

Real-World Trade-Offs

Let’s skip the theoretical pros and cons and look at actual production scenarios:

• Go with Swift on Android if: You are an enterprise team with a massive, highly complex iOS app (like a banking app with custom local encryption rules). Reusing that heavy Swift backend code guarantees your data stays identical across platforms, while letting both teams build highly polished, platform-specific native UIs.
• Go with Flutter if: You are a startup or a lean product team that needs to ship an app to both stores in two months. Writing two separate UI layers in SwiftUI and Jetpack Compose takes twice the time. Flutter’s unified UI layer wins the speed race every single time.

The Flutter Reality Check

Because I live in both worlds, comparing this to Flutter is fascinating.

The Flutter Way: Flutter is a unified ecosystem. You use one language (Dart) to build both the Engine and the Paint. The custom rendering engine draws the exact same pixels on both screens. It is incredibly fast for launching an MVP because you design the screen once and you’re done.

The Swift Way: Swift on Android is like sharing a car engine between a Porsche and a Jeep. The underlying machinery is identical, but the exterior chassis is custom-built for each ecosystem so it feels completely natural to the user.

The Verdict

Is Swift on Android going to kill Flutter or React Native? Not even close. The developer tooling for running Swift inside Android Studio is still incredibly early and clunky compared to the seamless experience of Flutter’s Hot Reload.

Honestly, it’s just exciting to see the ecosystem evolve like this. We are finally getting past the rigid ‘native vs. cross-platform’ arguments. Now, when planning an architecture, we have the flexibility to look at the app and decide exactly where to draw the line between shared logic and native UI.