Blog

Fully Native Cross-Platform Swift Apps

Apr 25, 2025 - 8 min read - 1374 words

In our series on using native Swift on Android, we have covered the basics of the Swift-Android toolchain in Part 1, bridging between compiled Swift and Kotlin in Part 2, and the creation of a cross-platform app with a shared Swift model layer in Part 3.

We are pleased to unveil the culmination of all of this work: Skip 1.5 now has the ability to create a 100% native Swift and SwiftUI app for both iOS and Android! You can now enjoy the safety, efficiency, and expressiveness of pure Swift throughout your entire cross-platform app, including the ability to tap into the vast ecosystem of Swift packages to support your app development.

This blog post will go over the process of creating and developing a Swift cross-platform app, explore the underlying technologies, and discuss our current status and next steps.

Getting Started

Ensure that you are on a macOS 14+ machine with Xcode 16 ↗, Android Studio 2025 ↗, and Homebrew ↗ installed.

First, create and launch an Android emulator ↗ for testing.

Next, open Terminal and type the following commands to install Skip and the native Swift-Android toolchain.

$ brew install skiptools/skip/skip
$ skip upgrade
$ skip android sdk install

Verify that everything is working with an additional Terminal command:

$ skip checkup --native

You’re now ready to create your first fully native cross-platform Swift app:

$ skip init --native-app --open-xcode --appid=bundle.id.HowdySkip howdy-skip HowdySkip

Assuming the app initialized successfully, your project will open in Xcode. Run the app against an iPhone simulator destination (the first build may take some time) and your app will launch on both the iOS simulator and the running Android emulator at the same time!

The App Template

The skip init command creates a template app to get you started. It is a TabView containing a “Welcome” view, a list of editable and re-orderable “Items”, and a “Settings” view:

Screenshot of the Howdy Swift native app Welcome Tab

ContentView.swift

Rather than importing SwiftUI, you will notice that the Sources/HowdySkip/ContentView.swift ↗ file instead imports SkipFuseUI. When building for iOS, this simply redirects to a SwiftUI import. Skip’s philosophy is to not intrude on the iOS side of the application: on Darwin platforms you are still using direct, non-intermediated SwiftUI, just as if you were building an app without Skip at all.

On Android, however, the SkipFuseUI module bridges the SwiftUI API onto Jetpack Compose ↗, Android’s modern Kotlin ↗ UI toolkit. It does this through the intermediate SkipUI module. Bridging to pure Jetpack Compose gives Android users a fully native user experience rather than the uncanny-valley replica generated by many cross-platform frameworks.

Diagram of Skip's Swift-on-Android build process

Consult the SkipUI module’s documentation for a listing of currently-supported SwiftUI constructs on Android. You can also examine the ShowcaseFuse ↗ cross-platform sample app, which displays and exercises most supported SwiftUI components:

ViewModel.swift

The “Items” tab displays an editable list of items which are managed by Sources/HowdySkip/ViewModel.swift ↗, which handles loading and saving the list of items to a simple JSON file. This code uses standard Foundation types (URL, Data, Date, FileManager, JSONEncoder, JSONDecoder, etc.) to handle the management and persistence of the items. Note that unlike the SwiftUI in ContentView, none of this code is bridged into Kotlin: it is using the Apple swift-foundation ↗ types directly, just as on iOS.

Screenshot of the Howdy Swift native app List Tab

Despite only using native Foundation types, you will notice that ViewModel.swift imports SkipFuse. Just as SkipFuseUI bridges your UI to Android, SkipFuse bridges model-layer code. We use it here to enable our @Observable view model to communicate changes to the Jetpack Compose user interface. This is discussed further in Part 2 of the series. You generally don’t need to be concerned with the details other than to remember to import SkipFuse (or SkipFuseUI) any time you implement an @Observable.

Bridging into Kotlin and Compose

The final tab of the sample app is the “Settings” screen. This exposes various settings and displays some information about the app. It also presents a little heart emoji, which is blue on iOS and green on Android.

Screenshot of the Howdy Swift native app Settings Tab

We use the green heart emoji to demonstrate a powerful feature of Skip: the ability to embed code that directly calls Kotlin and Jetpack Compose APIs! Examining the SettingsView in ContentView.swift ↗, you will see the inclusion of a PlatformHeartView, whose implementation looks like this:

/// A view that shows a blue heart on iOS and a green heart on Android.
struct PlatformHeartView : View {
    var body: some View {
        #if !os(Android)
        Text(verbatim: "💙")
        #else
        ComposeView {
            HeartComposer()
        }
        #endif
    }
}

#if SKIP
/// Use a ContentComposer to integrate Compose content. This code will be transpiled to Kotlin.
struct HeartComposer : ContentComposer {
    @Composable func Compose(context: ComposeContext) {
        androidx.compose.material3.Text("💚", modifier: context.modifier)
    }
}
#endif

What is going on here? Notice that on Android, we’re rendering the heart with a ComposeView, a special SwiftUI view for including Jetpack Compose content in the form of a ContentComposer.

/// Encapsulation of Composable content.
public protocol ContentComposer {
    @Composable func Compose(context: ComposeContext)
}

But how can we define @Composable functions and call Android APIs from within our native Swift code?

The magic lies in Skip’s ability to transpile Swift code into Kotlin, and SkipFuse’s ability to bridge between Kotlin and your compiled Swift. Any code in a #if SKIP block will be transformed into the equivalent Kotlin, so it is free to call other Kotlin and Java APIs directly. The generated #if SKIP Kotlin will also be automatically bridged so that you can call it from your native Swift.

Diagram of Skip's custom Compose view embedding

Ecosystem Access

The ability to effectively embed Kotlin code is immensely powerful. It not only provides direct access Jetpack Compose and the Android SDK, but also enables you to tap into the complete Android ecosystem of libraries through Kotlin and Java dependencies.

Of course, using native Swift allows you to take advantage of the vast and growing ecosystem of available Swift packages as well. In our post on Bringing Swift Packages to Android we introduced the swift-everywhere.org ↗ site that tracks packages that are successfully building for Android. Since that post, community members have been implementing Android support, bringing the number of known packages that can be used on Android to 2,240! Popular projects like Alamofire ↗, flatbuffers ↗, SwiftSoup ↗, swift-protobuf ↗, and swift-sqlcipher ↗ (just to name a few) can be added directly to your app and used in the same way on both iOS and Android.

Skip’s unique ability to directly call both Swift and Kotlin/Java APIs separates it from most cross-platform development frameworks, where integrating with the host system often requires bespoke adapters and extra layers of indirection.

Skip Notes

As a demonstration and validation of this technology, we have published one of our sample apps, Skip Notes ↗, to both the Google Play Store and Apple App Store. This fully native Swift app integrates with the swift-sqlcipher ↗ database library to provide persistence for a simple list of notes.

↗ ↗ {: .centered }

Status and Next Steps

Despite being generally available, Skip’s native support is currently a technology preview. We are working on updating our documentation, finding and squashing remaining bugs and limitations, reducing build times, and generating smaller Android binaries. Even as a preview, however, you can build complete, production-ready cross-platform Swift apps, as Skip Notes demonstrates.

Cross-platform Swift and SwiftUI have been a dream of ours for a long time. We are immensely excited about the possibilities this unlocks for creating truly best-in-class apps for both iOS and Android from a single codebase!

Swift Everywhere: Bringing Swift Packages to Android

Jan 20, 2025 - 11 min read - 2237 words

Swift Android Logo {: style=“text-align: center; width: 200px; margin: auto;”}

Table of contents {:toc}

Introduction

In recent weeks, the Skip team has submitted patches to numerous Swift projects to add Android support to their packages. We’ve been tracking the progress of Android build-ability on our swift-everywhere.org ↗ web site, which catalogs a list of many popular Swift packages and whether they compile for Android. At the time of writing, nearly two thousand Swift packages are building successfully for Android, with more being added every day.

This article will go over what our experience porting Swift packages has taught us, and how you can apply this knowledge to turn your parochial Apple-only Swift package into a universal multi-platform package that can build for not just iOS and macOS, but also for Android.

Package Prerequisites

What sorts of Swift packages are good candidates for Android? The best litmus test is whether the package offers general-purpose functionality, as opposed to having an integral dependency on iOS-specific frameworks. Some examples of good candidates are:

Business logic
Algorithms and generic data structures
Networking utilities
Online web service and API clients
Data persistence
Parsers and formatters

On the flip side, examples of packages that would be challenging to bring to Android might be:

Custom UIKit components
HealthKit, CarPlay, Siri integration libraries
Other Apple-specific *Kit library integrations

Now, just because a Swift package is designed to work with an Apple-specific framework doesn’t mean that it is impossible to port to Android. It just means that it would be a signifiant amount of work and involve creating a bridge to the equivalent Kotlin or Java framework. This is by all means possible – and will be the topic of a future post – but the subject of this article is how to bring naturally portable Swift packages to Android.

Setup and Building

Say you have a conventional Swift package ↗ that contains a Package.swift file at the root and has the usual Sources/ and (hopefully) Tests/ folders that contain the individual targets and source files.

Does running swift build and swift test in the package directory work from the Terminal? If so, then you already have a cross-platform package that works on multiple platforms: iOS and macOS! That, by itself, is a good sign that your package might be suitable for Android. Many frameworks that are available on iOS are not present on macOS, so either your package doesn’t use too many iOS frameworks, or it is smart enough to only reference them conditionally (more on that below). But how do we build and test for Android?

First, install Skip and the native Android SDK by following the instructions in our documentation. Then try to build your Swift package with the Android toolchain. The very abbreviated quick start looks like:

$ brew install skiptools/skip/skip

…
skip was successfully installed!

$ skip android sdk install

[✓] Install Swift Android SDK (2.4s)

$ cd MySwiftPackage/
$ skip android build

Building for debugging...
[0/2] Write sources
…
[4/4] Emitting module DemoPackage
Build complete! (1.85s)

If you see “Build complete!” then congratulations! Your package already builds for Android, and you can move on to the Testing section. But if you encounter errors from the build command, you will need to port your package over to Android. Read on…

Porting your Swift Package

Wikipedia defines porting ↗ as the “process of adapting software for the purpose of achieving some form of execution in a computing environment that is different from the one that a given program (meant for such execution) was originally designed for”.

In other words, you made your Swift package with iOS in mind, and now you want it to work on Android. The following sections will go over some of the most common issues you may hit when first trying to build your package on this new platform.

Conditionally Importing and Using Platform-Specific Modules

Suppose your Swift package defines an Event protocol with a simple default implementation:

protocol Event {
    var dateRange: Range<Date> { get }
    var isConfirmed: Bool { get }
}

struct SimpleEvent : Hashable, Codable {
    let start, end: Date
    let confirmed
}

extension SimpleEvent : Event {
    var dateRange: Range<Date> { self.start..<self.end }
    var isConfirmed: Bool { confirmed }
}

Your package also includes an extension to implement Event using the iOS EventKit ↗ framework, like so:

import EventKit

extension EKEvent : Event {
    var dateRange: Range<Date> { self.startDate..<self.endDate }
    var isConfirmed: Bool { self.status == .confirmed }
}

EventKit is an Apple-only framework, so when you try to build the package for Android, you will hit an error:

$ skip android build

 7 | import EventKit
   |        `- error: no such module 'EventKit'

The solution to this is simple: wrap any code that references the missing module in #if canImport(EventKit), which conditionally compiles the code only when the specified module is available:

protocol Event {
    var dateRange: Range<Date> { get }
    var isConfirmed: Bool { get }
}

struct SimpleEvent : Hashable, Codable {
    let start, end: Date
    let confirmed
}

extension SimpleEvent : Event {
    var dateRange: Range<Date> { self.start..<self.end }
    var isConfirmed: Bool { confirmed }
}

#if canImport(EventKit)
import EventKit

extension EKEvent : Event {
    var dateRange: Range<Date> { self.startDate..<self.endDate }
    var isConfirmed: Bool { self.status == .confirmed }
}
#endif

Now you will have all the general functionality of the package available to Android, which you can adapt for any Android-specific data structures you may create in the future.

Importing the Foundation Sub-Modules

Consider the following simple utility that fetches a URL and decodes it into an Item struct:

import Foundation

struct Item: Decodable {
    let id: Int
    let name: String
}

func fetch(_ url: URL) async throws -> Item {
    let (data, response) = try await URLSession.shared.data(from: url)
    return try JSONDecoder().decode(Item.self, from: data)
}

You may be surprised to see this fail to compile for Android:

$ skip android build

Building for debugging...
Fetcher.swift:9:49: error: type 'URLSession' (aka 'AnyObject') has no member 'shared'
 7 |
 8 | func fetch(_ url: URL) async throws -> Item {
 9 |     let (data, response) = try await URLSession.shared.data(from: url)
   |                                                 `- error: type 'URLSession' (aka 'AnyObject') has no member 'shared'
10 |     return try JSONDecoder().decode(Item.self, from: data)
11 | }

This somewhat confusing error message just means that it can’t find the URLSession type, because it isn’t present in the Foundation module on Android.

On Darwin platforms (macOS, iOS, and other Apple operating systems), the Foundation module is an umbrella for a wide variety of functionality. But on other platforms, such as Android and Linux, Foundation is broken up into multiple separate sub-components:

FoundationEssentials: All the basic Foundation types: Date, Calendar, URL, IndexSet, etc.
FoundationInternationalization: DateFormatter, NumberFormatter, and other localization utilities
FoundationNetworking: URLSession, URLCache, and other networking utilities
FoundationXML: XMLParser

The solution to this is simple: add a conditional import of FoundationNetworking to any file that uses any networking functionality, like so:

import Foundation
#if canImport(FoundationNetworking)
import FoundationNetworking
#endif

struct Item: Decodable {
    let id: Int
    let name: String
}

func fetch(_ url: URL) async throws -> Item {
    let (data, response) = try await URLSession.shared.data(from: url)
    return try JSONDecoder().decode(Item.self, from: data)
}

This will include the required FoundationNetworking module for platforms like Android and Linux that need it, but quietly ignore it on Darwin platforms like iOS and macOS where the networking types are included with the monolithic Foundation framework.

Importing the Android Module

Swift has excellent integration with C, and many useful functions come in from the system’s C library, which is called Darwin on macOS and iOS. Take the simple example of calculating the hypotenuse of a triangle, which uses some math functions brought in from the standard C library:

import Darwin

func hypotenuse(a: Double, b: Double) -> Double {
    return sqrt(pow(a, 2) + pow(b, 2))
}

If you try to build this for Android, you will hit the error:

1 | import Darwin
  |        `- error: no such module 'Darwin'

This is because the Darwin module doesn’t exist for Android. It is instead simply called Android. Again, we solve this with our handy conditional canImport:

#if canImport(Darwin)
import Darwin
#elseif canImport(Android)
import Android
#else
#error("Unknown platform")
#endif

func hypotenuse(a: Double, b: Double) -> Double {
    return sqrt(pow(a, 2) + pow(b, 2))
}

In this case, we import either Darwin on iOS and macOS, or Android on Android. Both of these will provide access to the system’s standard C library.

Low-level C Issues

Simple C functions (like pow and sqrt) will generally be surfaced in exactly the same way on Darwin and Android platforms. But the definition of some functions and data structures in the Android C library can sometimes differ in subtle ways. For example, the following code uses the FILE type and fopen and fwrite C functions on Darwin platforms:

import Darwin

let fd: UnsafeMutablePointer<FILE> = fopen("file.txt", "w")
var buffer: [UInt8] = [1, 2, 3]
let count: Int = buffer.withUnsafeBufferPointer { ptr in
    fwrite(ptr.baseAddress, MemoryLayout<UInt8>.stride, ptr.count, fd)
}

This will fail to build for Android:

$ skip android build

FileWrite.swift:15:30: error: cannot find type 'FILE' in scope
13 | #endif
14 |
15 | let fd: UnsafeMutablePointer<FILE> = fopen("file.txt", "w")
   |                              `- error: cannot find type 'FILE' in scope
16 | var buffer: [UInt8] = [1, 2, 3]
17 | let count: Int = buffer.withUnsafeBufferPointer { ptr in

FileWrite.swift:18:16: error: value of optional type 'UnsafePointer<UInt8>?' must be unwrapped to a value of type 'UnsafePointer<UInt8>'
16 | var buffer: [UInt8] = [1, 2, 3]
17 | let count: Int = buffer.withUnsafeBufferPointer { ptr in
18 |     fwrite(ptr.baseAddress, MemoryLayout<UInt8>.stride, ptr.count, fd)
   |                |- error: value of optional type 'UnsafePointer<UInt8>?' must be unwrapped to a value of type 'UnsafePointer<UInt8>'
   |                |- note: coalesce using '??' to provide a default when the optional value contains 'nil'
   |                `- note: force-unwrap using '!' to abort execution if the optional value contains 'nil'
19 | }
20 |

There are two separate issue here:

FILE doesn’t exist on Android, so UnsafeMutablePointer<FILE> must be replaced with OpaquePointer
Functions like fwrite that take a file pointer will not accept an optional, and so must be force-unwrapped from their pointer’s rawValue

The following conditional typealias will handle the first issue, and simply force-unwrapping the pointer’s address (which should be valid on all platforms) addresses the second:

#if canImport(Darwin)
import Darwin
#elseif canImport(Android)
import Android
#else
#error("Unknown platform")
#endif

#if os(Android)
typealias Descriptor = OpaquePointer
#else
typealias Descriptor = UnsafeMutablePointer<FILE>
#endif

let fd: Descriptor = fopen("file.txt", "w")
var buffer: [UInt8] = [1, 2, 3]
let count: Int = buffer.withUnsafeBufferPointer { ptr in
    fwrite(ptr.baseAddress!, MemoryLayout<UInt8>.stride, ptr.count, fd)
}

Unless you are developing very low-level code that interfaces with the platform’s C library, you will rarely encounter these sorts of issues. But when you do, it is good to know that the solutions tend the be fairly simple. The most difficult part is often just deciphering the compilation failure message.

Testing

So now your package builds for Android with the command: skip android build. Amazing!

But you are only halfway there: you need to make sure your code not only builds for Android, but that it actually works. Hopefully, your Swift package includes test cases in the Test/ folder, and running the tests locally on your macOS machine with swift test works. For example, with the swift-algorithms ↗ package:

$ swift test
Building for debugging...
[78/78] Linking swift-algorithmsPackageTests
Build complete! (12.67s)

Test Suite 'All tests' started at 2025-01-21 19:25:03.841.
Test Suite 'swift-algorithmsPackageTests.xctest' started at 2025-01-21 19:25:03.842.
Test Suite 'AdjacentPairsTests' started at 2025-01-21 19:25:03.842.
Test Case '-[SwiftAlgorithmsTests.AdjacentPairsTests testEmptySequence]' started.
Test Case '-[SwiftAlgorithmsTests.AdjacentPairsTests testEmptySequence]' passed (0.002 seconds).
Test Case '-[SwiftAlgorithmsTests.AdjacentPairsTests testIndexTraversals]' started.
Test Case '-[SwiftAlgorithmsTests.AdjacentPairsTests testIndexTraversals]' passed (0.002 seconds).
…
Test Suite 'All tests' passed at 2025-01-21 19:25:05.718.
 Executed 212 tests, with 0 failures (0 unexpected) in 1.870 (1.876) seconds

In order to run your tests on Android, you will need to either plug in an Android device (with USB debugging ↗ enabled), or else configure and launch an Android emulator, either from the command line or Android Studio ↗).

Once you have your Android development target setup, you can run your package’s test cases with the skip android test command, which will compile the test cases, bundle them up (along with any associated resources), copy them to the Android device or emulator, and then execute the test cases remotely.

For example, for the swift-algorithms package:

% skip android test
[0/1] Planning build
Building for debugging...
…
[83/84] Linking swift-algorithmsPackageTests.xctest

Build complete! (11.68s)

[✓] Check Swift Package (0.87s)
[✓] Connecting to Android (0.18s)
[✓] Copying test files (0.88s)

Test Suite 'All tests' started at 2025-01-21 21:02:09.086
Test Suite 'swift-algorithms-1C77777B-CEC3-4075-8853-E77CECFCF30B.xctest' started at 2025-01-21 21:02:09.105
Test Suite 'AdjacentPairsTests' started at 2025-01-21 21:02:09.105
Test Case 'AdjacentPairsTests.testEmptySequence' started at 2025-01-21 21:02:09.105
Test Case 'AdjacentPairsTests.testEmptySequence' passed (0.014 seconds)
Test Case 'AdjacentPairsTests.testIndexTraversals' started at 2025-01-21 21:02:09.120
Test Case 'AdjacentPairsTests.testIndexTraversals' passed (0.004 seconds)
…
Test Suite 'All tests' passed at 2025-01-21 21:02:21.697
     Executed 212 tests, with 0 failures (0 unexpected) in 12.579 (12.579) seconds

If there are any test failures, this is where you will delve into the details of your test case, isolate the problem, and apply fixes. There are many reasons why tests may fail, such as assumptions about the filesystem layout. These will need to be examined and resolved on a case-by-case basis.

Once all your tests pass, you’ve successfully brought your Swift package to Android!

Bonus: Continuous Integration

Once you have your package building and your tests passing, you will want to ensure that they continue to pass. Maintaining a package that supports multiple platforms can be more challenging than just a single platform, because often when a new feature is implemented or a bug is fixed, the change will only be tested on the platform the developer is currently working with. For example, if you are working on the iOS side of your application and make a bug fix in one of your packages, you may only test the changes on that one platform, but it may inadvertently break something on another platform.

This is where continuous integration (CI) can be useful. If you use GitHub as your package’s source code management system, you can utilize GitHub Actions ↗ to automatically build and test your package on multiple platforms whenever you push to the repository or, for example, whenever a pull request is created from a branch or fork.

In order to facilitate Android CI, we provide the swift-android-action ↗, which enables you to build and test your package against Android in a single line of configuration.

The following example of a .github/workflows/ci.yml script will build and test your package on each of macOS, iOS, Linux, and Android whenever a commit is pushed or a PR is created:

name: swift package ci
on:
  push:
    branches:
      - '*'
  workflow_dispatch:
  pull_request:
    branches:
      - '*'
jobs:
  linux-android:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: "Test Swift Package on Linux"
        run: swift test
      - name: "Test Swift Package on Android"
        uses: skiptools/swift-android-action@v2
  macos-ios:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v4
      - name: "Test Swift Package on macOS"
        run: swift test
      - name: "Test Swift Package on iOS"
        run: xcodebuild test -sdk "iphonesimulator" -destination "platform=iOS Simulator,name=iPhone 15" -scheme "$(xcodebuild -list -json | jq -r '.workspace.schemes[-1]')"

You can see this workflow in play in many of the packages on GitHub that support Android, such as Skip’s own swift-sqlcipher ↗ package.

In this way, you can be assured that once you have done the hard work of getting your package working with Android, it continues to work on all your supported platforms.

Conclusion

Expanding your Swift packages to support platforms beyond iOS may at first seem daunting, but using the advice from this article, you can follow a few simple steps that will put you on the right track:

Setup Skip and the Swift Android SDK
Try to build your package with skip android build
Identify build errors and resolve them with conditional imports and by accommodating platform differences
Set up an Android emulator or device for testing
Test your package with skip android test
Identify test failures and resolve them on a case-by-case basis

This is the sequence we have used to add Android support to dozens of popular Swift packages, such as GraphQL ↗, CryptoSwift ↗, and PromiseKit ↗. With nearly 2,000 Swift packages currently building for Android, we feel the platform has achieved enough critical mass to make Swift an attractive language for many parts of your apps on both major mobile platforms: iOS and Android. And if you have a popular GitHub package that builds for Android, expect it to show up at swift-everywhere.org ↗ in the near future!

Native Swift on Android Series

To learn more about running Swift on Android and how it integrates with Skip’s tools for creating dual-platform mobile apps, please see our ongoing blog series on the topic:

Part 1: A native Swift toolchain for Android
Part 2: Your first native Swift Android app
Part 3: Using a shared native Swift model to power separate SwiftUI iOS and Jetpack Compose Android apps
Coming soon: Bridging Kotlin and Java API for consumption by native Swift
Coming soon: Incorporating native Swift, C, and C++ dependencies into your cross-platform Swift apps

Native Swift on Android, Part 3: Sharing a Swift Model Layer

Dec 19, 2024 - 15 min read - 2748 words

Native Swift on Android, Part 3: Sharing a Swift Model Layer

Introduction

This is the third installment in our series exploring native Swift on Android. In Part 1 we discuss bringing the Swift compiler and toolchain to Android. Part 2 introduces Skip’s tooling and technology for Swift Android app development and leads you through the creation of your first cross-platform Swift app.

The app we create in Part 2 uses a compiled Swift model layer and a shared SwiftUI interface, which Skip transpiles ↗ to Jetpack Compose on Android. The following diagram illustrates this dual-platform, single-codebase architecture:

Skip Native Diagram {: .diagram-vector }

In this article, by contrast, we create separate iOS and Android apps. The iOS app and shared model layer are written in Swift and SwiftUI using Xcode. The Android app is written in Kotlin ↗ and Jetpack Compose ↗ using Android Studio, and it imports the compiled Swift model as a dependency. This structure allows you to reuse the lower layers of your app logic while fully embracing the standard IDEs and UI toolkits on each platform:

Skip Shared Model Diagram {: .diagram-vector }

TravelPosters

Simulators displaying the same app on iPhone and Android

Our sample apps in this installment are iOS and Android versions of TravelPosters, a simple scrolling grid displaying posters of famous cities. Each poster displays the city’s name and current temperature. You can mark your favorites, and these favorites are remembered across app launches.

The Shared Model

Our shared TravelPostersModel, therefore, has the following responsibilities:

Provide a list of cities. Each city must supply its name and a poster image URL.
Fetch the current temperature for each city.
Allow the addition and removal of cities from an observable set of favorites.
Persist and restore the set of favorites across uses of the app.

And given that our model will power both iOS and Android apps, we should add the following table-stakes Android requirements:

We must be able to access our Swift model API naturally in Kotlin, just as in Swift.
Our mutable set of favorites must be observable not only to SwiftUI state tracking, but to Jetpack Compose state tracking as well.

Fortunately, Swift is more than up to the task of meeting our model’s general requirements, and Skip’s SkipFuse technology will handle transparently bridging it all to Kotlin and Compose!

Installing Skip

If you plan on following along and you haven’t already installed Skip, follow Part 2’s installation instructions. This will quickly get you up and running with Skip, its requirements, and the native Swift Android toolchain.

Creating the Model Package

As a good, modern citizen of the Swift ecosystem, Skip works atop Swift Package Manager ↗. Our shared model will be a Swift package configured to use skipstone, the Skip build plugin. You could create this package and configure its use of Skip by hand, but Skip provides tooling to help.

First, create the folder structure we’ll use to hold our shared model as well as our iOS and Android apps. You do not have to house your apps together, but this is the structure we’ll use in this article.

mkdir travelposters
cd travelposters
mkdir iOS
mkdir Android

Now use the skip tool to create the shared model package:

skip init --native-model travel-posters-model TravelPostersModel

Output of running skip init --native-model

This command generates a travel-posters-model SwiftPM package containing the TravelPostersModel Swift module. The --native-model option ensures that the module will already be configured to compile natively on Android, and to bridge its public API to Kotlin. Our particular needs, however, require a couple of additional steps.

We know that parts of our model will be @Observable. In order for @Observables to work on Android, we need a dependency on skip-model. Edit the generated Package.swift to add it:

...
let package = Package(
    name: "travel-posters-model",
    ...
    dependencies: [
        .package(url: "https://source.skip.tools/skip.git", from: "1.2.0"),
        .package(url: "https://source.skip.tools/skip-model.git", from: "1.0.0"), // <-- Insert
        .package(url: "https://source.skip.tools/skip-fuse.git", "0.0.0"..<"2.0.0")
    ],
    targets: [
        .target(name: "TravelPostersModel",
            dependencies: [
                .product(name: "SkipFuse", package: "skip-fuse"),
                .product(name: "SkipModel", package: "skip-model")                // <-- Insert
            ],
            plugins: [.plugin(name: "skipstone", package: "skip")]),
        ...
    ]
)

The --native-model option we passed to skip init will configure Skip to automatically bridge our model’s public API from compiled Swift to Android’s ART ↗ Java runtime. This is done through the skip.yml configuration file included in every Skip module. By default, however, Skip assumes that you’ll be bridging to transpiled Swift and SwiftUI code. Instead, we’ll be consuming the model from pure Kotlin, so we want to optimize the bridging for Kotlin compatibility. We do this by editing the Sources/TravelPostersModel/Skip/skip.yml file to look like this:
```
skip:
  mode: 'native'
  bridging:
    enabled: true
    options: 'kotlincompat'
```

You can read more about the magic of bridging in the documentation.

With these updates in place, we’re now ready to iterate on our shared Swift model code!

Exploring the Code

The beauty of cross-platform Swift code is how boring it is. You can browse our model’s complete content on GitHub ↗, but it looks more or less exactly as you’d expect given the previously-enumerated requirements. It has some Codable structs to represent cities and weather:

public struct City : Identifiable, Codable {
    public typealias ID = Int

    public let id: ID
    public let name: String
    public let imageURL: URL
    ...
}

public struct WeatherConditions : Hashable, Codable {
    public let temperature: Double // 16.2
    public let windspeed: Double // 16.6
    ...
}

The model uses URLSession and JSONDecoder to fetch the current weather:

public struct Weather : Hashable, Codable {
    public let latitude: Double // e.g.: 42.36515
    public let longitude: Double // e.g.: -71.0618
    public let time: Double // e.g.: 0.6880760192871094
    ...
    public let conditions: WeatherConditions

    enum CodingKeys: String, CodingKey {
        case latitude = "latitude"
        case longitude = "longitude"
        case time = "generationtime_ms"
        ...
        case conditions = "current_weather"
    }

    public static func fetch(latitude: Double, longitude: Double) async throws -> Weather {
        let factor = pow(10.0, 4.0) // API expects a lat/lon rounded to 4 places
        let lat = Double(round(latitude * factor)) / factor
        let lon = Double(round(longitude * factor)) / factor
        let url = URL(string: "https://api.open-meteo.com/v1/forecast?latitude=\(lat)&longitude=\(lon)&current_weather=true")!

        var request = URLRequest(url: url)
        request.setValue("skipapp-sample", forHTTPHeaderField: "User-Agent")

        let (data, response) = try await URLSession.shared.data(for: request)
        return try JSONDecoder().decode(Weather.self, from: data)
    }
}

And it includes an @Observable CityManager to provide the list of cities and to persist favorites:

@Observable public final class CityManager {
    private static let favoritesURL = URL.applicationSupportDirectory.appendingPathComponent("favorites.json")

    public static let shared = CityManager()

    private init() {
        do {
            self.allCities = try JSONDecoder().decode([City].self, from: localCitiesJSON.data(using: .utf8)!).sorted { c1, c2 in
                c1.name < c2.name
            }
        } catch {
            logger.log("error loading cities: \(error)")
        }
        do {
            self.favoriteIDs = try JSONDecoder().decode([City.ID].self, from: Data(contentsOf: Self.favoritesURL))
            logger.log("loaded favorites: \(self.favoriteIDs)")
        } catch {
            logger.log("error loading favorites: \(error)")
        }
    }

    public var allCities: [City] = []

    public var favoriteIDs: [City.ID] = [] {
        didSet {
            logger.log("saving favorites: \(self.favoriteIDs)")
            do {
                try FileManager.default.createDirectory(at: Self.favoritesURL.deletingLastPathComponent(), withIntermediateDirectories: true)
                try JSONEncoder().encode(favoriteIDs).write(to: Self.favoritesURL)
            } catch {
                logger.log("error saving favorites: \(error)")
            }
        }
    }
}

private let localCitiesJSON = """
...
"""

While this code is generally pretty standard, it does contain a few concessions to the realities of current Swift support on Android:

In files that create an OSLog.Logger or that define an @Observable type, we also import SkipFuse. In fact, Skip will surface a build warning in Xcode if you attempt to define an @Observable in a bridged file that doesn’t import the SkipFuse framework!

SkipFuse is an umbrella framework that “fuses” the Swift and Android worlds. It makes sure that your OSLog messages are routed to Android’s Logcat logging service, that your @Observable state is tracked by Jetpack Compose, and more - all without changes to your normal code path.
You may notice other unfamiliar import patterns as well. For example, Foundation on Linux and Android is divided into Foundation, FoundationNetworking, FoundationInternationalization, and FoundationXML. So in Weather.swift ↗ where we use URLSession, we have the following imports:
```
import Foundation
#if canImport(FoundationNetworking)
import FoundationNetworking
#endif
```
Though we do not need them here, you may encounter #if os(Android) checks to conditionalize code for Android or Darwin platforms in other Android-supporting codebases, just as you’ll often find #if os(macOS) conditions in macOS-supporting codebases.
We’re loading our cities JSON from a static string, but more tyically you would load the contents from a resource. SkipFuse supports bundling Swift module resources as idiomatic Android assets ↗.
While many Swift packages like Apple’s swift-algorithms ↗ compile cleanly for Android out of the box, others will require minor changes, and still others - particularly those that tie into the hardware or use one of Apple’s many OS “Kits” - may never work on Android. Swift on Android is still in its infancy, and it will take time for developers to build and test their packages on this new-to-Swift platform.

You can read much more about both the advantages and the limitations of native Swift on Android in our full native Swift documentation. For the most part, though, relax and enjoy coding with the full power and expressiveness of Swift!

Testing

Due to limitations on build plugins, building the travel-posters-model package in Xcode does not perform an Android build. It only builds for iOS. Rather, there are two simple ways to build for Android: use skip export to create an Android library archive, which we explore later in this article, or run the unit tests.

Skip configures every native module with an extra unit test that builds the module for Android, transpiles your XCTests to JUnit tests, and runs them. Thus you’ll see two sets of results on every test run: first from XCTest and then from JUnit on Android. Frequently running your tests is a great way to catch both logic bugs and Android compilation errors early. Read more in the native testing documentation.

The iOS App

Because our model is a standard SwiftPM package, you incorporate and use it on iOS like any other package. We briefly outline the steps we took to create and configure our sample iOS app below. Feel free to skip this section!

Use Xcode to create a new Workspace in the travelposters directory alongside the travel-posters-model package.
Use Xcode to create a new App project in the travelposters/iOS directory. Close the project after creating it, because we’re going to add it to our Workspace instead.
Add the travel-posters-model package to your Workspace.
Add the iOS/TravelPosters/TravelPosters.xcodeproj app to your Workspace.
Add a package dependency from the app to the travel-posters-model local package.

You can now use your Xcode Workspace to iterate on both the shared model package and your iOS app. Browse the complete iOS TravelPosters app here ↗.

The Android App

We create our TravelPosters Android app using Android Studio, starting with the “Empty Activity” template. Tell Android Studio to place the app in our travelposters/Android folder.

Creating a new app project in Android Studio

Next, make Android/lib, Android/lib/debug, and Android/lib/release directories. This is where we’ll place our compiled Swift model and Skip libraries.

Creating directories for our compiled Swift model

We must also configure our project to use the new lib directories. Edit the app module’s build.gradle.kts file to add these and other necessary dependencies:

...
dependencies {
    ...

    implementation("org.jetbrains.kotlin:kotlin-reflect:2.1.0") // For reflection used by Skip
    implementation("io.coil-kt:coil-compose:2.7.0") // For AsyncImage used to display posters

    debugImplementation(fileTree(mapOf(
        "dir" to "../lib/debug",
        "include" to listOf("*.aar", "*.jar"),
        "exclude" to listOf<String>()
    )))
    releaseImplementation(fileTree(mapOf(
        "dir" to "../lib/release",
        "include" to listOf("*.aar", "*.jar"),
        "exclude" to listOf<String>()
    )))
}

To prevent errors in the deployed app, include the following in build.gradle.kts as well:

android {
    packaging {
        jniLibs {
            // doNotStrip is needed to prevent errors like: java.lang.UnsatisfiedLinkError: dlopen failed: empty/missing DT_HASH/DT_GNU_HASH in "/data/app/…/base.apk!/lib/arm64-v8a/libdispatch.so" (new hash type from the future?) (see: https://github.com/finagolfin/swift-android-sdk/issues/67)
            keepDebugSymbols.add("**/*.so")
        }
    }
}

Finally, our app needs internet access permissions to fetch weather and display remote images. Update its AndroidManifest.xml file:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <uses-permission android:name="android.permission.INTERNET" />

    ...
</manifest>

Find the complete TravelPosters Android app here ↗. The next sections detail how to export our shared model to the Android app and how to use it from our Kotlin code.

Exporting the Shared Model to Android

We’ve configured our Android app to look in the Android/lib/debug and Android/lib/release folders for our model, but how do we populate these folders?

The skip export command generates Android archives of a target Swift package and all of its dependencies. It has many options, which you can explore with skip export help. The following Terminal command builds our travel-posters-model and its dependencies for Android in debug mode and places the resulting .aar library archives in the Android/lib/debug directory:

skip export --project travel-posters-model -d Android/lib/debug/ --debug

To generate release archives instead:

skip export --project travel-posters-model -d Android/lib/release/ --release

Automation

There are many ways to automate this process, from simple scripting to git submodules to publishing the Android travel-posters-model output to a local Maven repository. Use whatever system fits your team’s workflow best.

For example, to re-build and re-launch the app after making changes to the Swift code, you might run:

skip export --project travel-posters-model -d Android/lib/debug/ --debug
gradle -p Android installDebug
adb shell am start -a android.intent.action.MAIN -c android.intent.category.LAUNCHER -n tools.skip.travelposters/tools.skip.travelposters.MainActivity

Using the Shared Model on Android

Now that we’ve set up the Android app to depend on our shared Swift model, what is it like to actually use the model in Kotlin and Compose code? The answer is that - thanks to SkipFuse bridging - it’s surprisingly natural!

Before we dive into using our model, though, we have to make a single call in our Android app’s main Activity to initialize integration. Skip has extended Foundation.ProcessInfo for this purpose:

...

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        skip.foundation.ProcessInfo.launch(context = this) // <-- INSERT

        enableEdgeToEdge(statusBarStyle = SystemBarStyle.dark(Color.TRANSPARENT))
        setContent {
            ...
        }
    }

    ...
}

No additional changes to Android’s normal startup code path are needed.

This article is not a tutorial on using Jetpack Compose. Rather, we will focus on the places where our Android UI interacts with Swift, starting with the CityList function for displaying the scrolling list of posters:

...
import travel.posters.model.CityManager // <-- 1

@Composable
fun CityList(...) {
    val cityManager = CityManager.shared // <-- 2
    LazyVerticalGrid(...) {
        for (city in cityManager.allCities) { // <-- 3
            item {
                CityPoster(city, isFavorite = { cityManager.favoriteIDs.contains(city.id) }, setFavorite = { isFavorite ->
                    // 4
                    val favoriteIDs = cityManager.favoriteIDs.toMutableList()
                    if (isFavorite && !favoriteIDs.contains(city.id)) {
                        favoriteIDs.add(city.id)
                        cityManager.favoriteIDs = favoriteIDs
                    } else if (!isFavorite) {
                        favoriteIDs.remove(city.id)
                        cityManager.favoriteIDs = favoriteIDs
                    }
                })
            }
        }
    }
}

We’ve annotated the code above with four numbered comments. Let’s explain each:

Our TravelPostersModel module is exposed to Kotlin in the travel.posters.model package. Skip simply divides your CamelCase Swift module names into ”.”-separated Kotlin package names. Single-word packages are reserved in Kotlin, so if your module name consists of a single word, Skip appends “.module”. For example, module Util turns into Kotlin package util.module.
Your Swift types and API have equivalent names and signatures in Kotlin.
The Swift CityManager.allCities property of type [City] bridges to a Kotlin kotlin.collections.List<City>. Consult the bridging reference to learn more about specific type mappings.
Here we’re performing standard Compose state hoisting to manage the favorites list. Notice that we simply update our model - we do not explicitly trigger a change to the UI. Like SwiftUI, Compose automatically reacts to change in observed state, and SkipFuse ensures that our @Observable CityManager is fully and transparently integrated in Compose state tracking.

Each item in the city list is a CityPoster. Let’s examine that function as well:

...
import travel.posters.model.City
import travel.posters.model.Weather

@Composable
fun CityPoster(city: City, isFavorite: () -> Boolean, setFavorite: (Boolean) -> Unit) {
    Box {
        val url = city.imageURL // <-- 1
        AsyncImage(...)
        ...
        Column(...) {
            Row(...) {
                ...
                Icon(imageVector = Icons.Filled.Star,
                    modifier = Modifier.clickable {
                        setFavorite(!isFavoriteState.value)
                    }
                )
                ...
                Text(text = city.name, ...)
                ...
                Box {
                    ...
                    LaunchedEffect(city.id, degrees) {
                        try { // <-- 2
                            val c = Weather.fetch( // <-- 3
                                latitude = city.latitude,
                                longitude = city.longitude
                            ).conditions.temperature
                            ...
                        } catch (exception: Exception) {
                            Log.e("TravelPosters", "Error fetching weather: $exception")
                        }
                    }
                    ...
                }
            }
        }
    }
}

Once again, we’ve added numbered comments to points of interest in the code above:

In addition to bridging your own types as well as built-in types like numbers, strings, arrays, and dictionaries, SkipFuse translates common Foundation types like Data, Date, URL, and UUID to their Kotlin equivalents. In this case the City.imageURL property of type Foundation.URL maps to a java.net.URI. Again, see the bridging reference for details.
Our Weather.fetch Swift function is marked throws. If the native call produces an error, the bridged Kotlin call with throw a standard Kotlin exception.
Weather.fetch is an async Swift function. Skip therefore generates a Kotlin suspend function and integrates the call with Kotlin coroutines. Hence the use of a LaunchedEffect in our Compose code.

As you can see, you invoke your Swift APIs naturally in Kotlin - almost exactly as if they were written in Kotlin themselves! Swift custom types, built-in types, and common Foundation types all translate to Kotlin/Java equivalents, thrown errors cause Kotlin exceptions, async Swift functions use Kotlin coroutines, etc. The goal is that using a module written in Swift should be almost indistinguishable from using a package written in Kotlin.

Next Steps

If you haven’t already, check out Part 1 and especially Part 2 of this series.

If you’d like to learn much more about SkipFuse, bridging, and native Swift on Android, consider reading our Native Swift Tech Preview documentation.

You may also be interested in the nascent swift-java ↗ project, which is designed to facilitate communication between server-side Swift and Java libraries. While that is a very different environment than Android apps interacting with modern Kotlin APIs, they do overlap, and you might find swift-java's bridging approach useful. We anticipate that as it matures, this bridge and Skip’s native bridging will begin to align more closely in their techniques and implementation details.

Native Swift on Android Series

Additional posts in the native Swift on Android series:

Part 1: A native Swift toolchain for Android
Part 2: Your first native Swift Android app
Part 3: Using a shared native Swift model to power separate SwiftUI iOS and Jetpack Compose Android apps
Coming soon: Bridging Kotlin and Java API for consumption by native Swift
Coming soon: Incorporating native Swift, C, and C++ dependencies into your cross-platform Swift apps

Conclusion

Many cross-platform solutions allow you to share code, but they typically come with serious downsides:

Performance issues from the use of interpreters and/or complex runtimes (Javascript)
High memory watermarks and unpredictable hitches caused by garbage collection (Javascript, Kotlin)
Lack of transparent integration with SwiftUI and/or Compose state tracking (C/C++)
Portability and memory safety concerns (C/C++)

Swift exhibits none of these problems. Its safety, efficiency, and expressiveness make it an ideal choice for cross-platform development. Swift is already a first-class citizen on Apple platforms, and Skip’s native tooling and technology ensures seamless integration with Android and Compose as well.

Whether you’re creating a single dual-platform app like we did in Part 1, separate iOS and Android apps with a shared model layer and bespoke interfaces like we did in this article, or anything in between, sharing code with Swift can save you significant time and effort when writing your app. More important than the up front savings, though, is the savings over time. A shared Swift codebase will eliminate endless hours of repeated bug fixes, enhancements, team coordination, and general maintenance over the life of your software.

December Skip Newsletter

Dec 17, 2024 - 3 min read - 541 words

Skip December Newsletter

Welcome to the December edition of the Skip.tools newsletter! This month we will showcase some of the improvements and advancements we've made to the Skip platform, along with some current events and a peek at our upcoming roadmap.

Skip and Compiled Swift on Android

The big news this month is the release of the Skip's native compiled Swift technology preview! Now you are not limited to just using transpiled packages in Skip apps: you can also embed fully native Swift using our Android toolchain and transparent bridge generation. The SkipFuse framework enables you to move seamlessly between native Swift and your transpiled Jetpack Compose user interface. This unlocks the entire universe of pure-Swift packages for use in your Android app! Read the introductory blog post at https://skip.tools/blog/skip-native-tech-preview/ and then browse the full documentation at https://skip.tools/docs/native/.

Screenshot of native toochain development

New SkipUI Features

SkipUI is the framework that turns your SwiftUI into Jetpack Compose for Android. It enables you to write a single user-interface for both platforms using their platform-native toolkits. SkipUI supports converting nearly all SwiftUI constructs into Compose, but there are sometimes minor deficiencies and quirks that need to be implemented separately for Android. Over the past weeks, we've improved SkipUI with:

Support for custom SVG images in asset catalogs
Enabling .alert() sheets to containTextField and SecureField views
Support for .rotation3DEffect for all views
Implementing .interactiveDismissDisabled to conditionally prevent interactive dismissal of sheets

You can always get the latest Skip features and fixes from right within Xcode, by simply clicking File > Packages > Update to Latest Versions. And if you are building from the command-line, swift package update will do the same thing.

Tip: Customizing with Android-only SwiftUI modifiers

SkipUI supports Android-specific SwiftUI modifiers to customize Material colors, components, and effects. Check out the "Material" section of our SkipUI documentation to see how: https://skip.tools/docs/modules/skip-ui/#material

Skip on Talking Kotlin

We were thrilled to join hosts Sebastian and Márton on the JetBrains Talking Kotlin podcast! The episode was just released, and you can listen to it at https://talkingkotlin.com/going-from-swift-to-kotlin-with-skip/ or watch it at https://www.youtube.com/watch?v=mig81rSWVqM. “Going from Swift to Kotlin with Skip: In a slightly unconventional episode, Sebastian and Márton talk to the founders of Skip, an iOS-to-Android, Swift-to-Kotlin transpiler solution. Marc and Abe have a background working on both Apple platforms and the JVM, and their latest project is a bridge across these two ecosystems.”

Android Police Interview

Another instance of Skip in the press was an interview with the popular Android Police publication, titled: “How the development wall between Android and iOS may soon come down”. You can read the whole thing at: https://www.androidpolice.com/skip-interview

That's all for now

You can follow us on Mastodon at https://mas.to/@skiptools, and join in the Skip discussions at http://community.skip.tools/. The Skip FAQ at https://skip.tools/docs/faq/ is there to answer any questions, and be sure to check out the video tours at https://skip.tools/tour/. And, as always, you can reach out directly to us on our Slack channel at https://skip.tools/slack/.

Happy Skipping!

Native Swift on Android, Part 2: Your First Swift Android App

Dec 3, 2024 - 9 min read - 1671 words

Native Swift on Android, Part 2: Your First Swift Android App

Introduction

Swift is Apple’s recommended language for app development, and with good reason. Its safety, efficiency, and expressiveness have made it easier than ever to build fast, polished, and robust apps for the Apple ecosystem. Recent stories about Swift on Windows ↗ and Swift on the Playdate ↗ highlight developers’ desire to take advantage of Swift on other platforms too. In this series, we explore writing native Swift apps for Android with Skip.

Since its 1.0 release earlier this year, Skip has allowed developers to create cross-platform iOS and Android apps in Swift and SwiftUI by transpiling ↗ your Swift to Android’s native Kotlin language. Now, the Skip team is thrilled to give you the ability to use native, compiled Swift for cross-platform development as well.

Part 1 of this series described bringing a native Swift toolchain to Android. Being able to compile Swift on Android, however, is only the first small step towards real-world applications. In this and other installments, we introduce the other pieces necessary to go from printing “Hello World” on the console to shipping real apps on the Play Store:

Integration of Swift functionality like logging and networking with the Android operating system.
Bridging technology for using Android’s Kotlin/Java API from Swift, and for using Swift API from Kotlin/Java.
The ability to power Jetpack Compose and shared SwiftUI user interfaces with native Swift @Observables.
Xcode integration and tooling to build and deploy across both iOS and Android.

The “Hello Swift” App

The best way to learn is often by example. This post introduces you to native Swift apps on Android by exploring the “Hello Swift” app. This is the starter app that Skip generates when you initialize a new project, and it provides a fully-configured launch point for your own cross-platform Swift app development.

Before we can explore the sample, though, we have to install the tools necessary to create it - including Swift for Android!

First, ensure that you are on a macOS 14+ machine with Xcode 16, Android Studio ↗, and Homebrew ↗ installed.

Next, open Terminal and type the following commands to install Skip and the native Android toolchain.

brew install skiptools/skip/skip
skip android sdk install

Finally, verify that everything is working with an additional Terminal command:

skip checkup --native

If everything passes successfully, you can now create your first cross-platform native Swift app with the command:

skip init --native-model --open-xcode --appid=com.xyz.HelloSwift hello-swift HelloSwift HelloSwiftModel

That’s a long one! This tells Skip to initialize a new native Swift starter app and open it in Xcode. The app will use the hello-swift project folder, and it will be divided into two modules: a HelloSwift UI layer and a HelloSwiftModel model layer.

When you enter this command, Skip will generate the project, perform some checks, and then the app will open in Xcode. Before running it, though, you must first launch the Android emulator by opening Android Studio.app and selecting the Virtual Device Manager from the ellipsis menu of the Welcome dialog. From there, use the plus toolbar button to Create Device (e.g., “Pixel 6”) and then Launch the emulator.

Screenshot of the Android Studio Device Manager

Finally, select your desired iOS simulator in Xcode, then build and run the “HelloSwift” target.

The first build will take some time to compile the Skip libraries, and you may be prompted with a dialog to affirm that you trust the Skip plugin. Once the build and run action completes, the app will open in the selected iOS simulator, and at the same time the generated Android app will launch in the currently-running Android emulator.

App Overview

“Hello Swift” is a very simple CRUD ↗ app that contains a list of dated items. You can browse the full source code in Xcode, or online in its GitHub repository ↗. At a high level, the Xcode project embeds a Swift Package Manager package called “HelloSwift”, which contains two targets:

The HelloSwift module contains the SwiftUI for the app’s user interface. It will run natively on iOS and be transpiled by Skip’s “SkipStone” build plugin into Kotlin and Jetpack Compose for Android.
HelloSwiftModel is a pure Swift module that contains an @Observable ViewModel class. It will be compiled natively for both iOS and Android using the Swift toolchain for each platform.

The app allows you to add new items with the plus button, and items can be deleted and re-arranged by swiping and dragging. Tapping an item navigates to a form with editable fields for the various properties: title, date, a favorites toggle, and notes. HelloSwiftModel defines an item as:

public struct Item : Identifiable, Hashable, Codable {
    public let id: UUID
    public var date: Date
    public var favorite: Bool
    public var title: String
    public var notes: String
}

These items are held by an @Observable ViewModel class:

@Observable public class ViewModel {
    public var items: [Item] = loadItems() {
        didSet { saveItems() }
    }
}

And in the HelloSwift SwiftUI layer, the notes are managed by a SwiftUI List within a NavigationStack:

public struct ContentView: View {
    @State var viewModel = ViewModel()

    public var body: some View {
        NavigationStack {
            List {
                ForEach(viewModel.items) { item in
                    NavigationLink(value: item) {
                        Label {
                            Text(item.itemTitle)
                        } icon: {
                            if item.favorite {
                                Image(systemName: "star.fill")
                                    .foregroundStyle(.yellow)
                            }
                        }
                    }
                }
                .onDelete { offsets in
                    viewModel.items.remove(atOffsets: offsets)
                }
                .onMove { fromOffsets, toOffset in
                    viewModel.items.move(fromOffsets: fromOffsets, toOffset: toOffset)
                }
            }
            .navigationTitle(Text("\(viewModel.items.count) Items"))
            .navigationDestination(for: Item.self) { item in
                ItemView(item: item, viewModel: $viewModel)
                    .navigationTitle(item.itemTitle)
            }
            .toolbar {
                ToolbarItemGroup {
                    Button {
                        withAnimation {
                            viewModel.items.insert(Item(), at: 0)
                        }
                    } label: {
                        Label("Add", systemImage: "plus")
                    }
                }
            }
        }
    }
}

Module Interaction

On iOS, both the HelloSwift and HelloSwiftModel targets are native Swift, so communication between the two layers is seamlessly handled by the Swift dependency. On Android, however, recall that the HelloSwift module’s SwiftUI is transpiled to Kotlin. That Kotlin needs to be able to interact with the HelloSwiftModel module’s compiled Swift, which involves bridging the two languages and runtimes.

Skip’s bridging solution is called “SkipFuse”. Using the SkipStone build plugin, SkipFuse automatically generates bridging code that enables transparent communication between the two layers. This is modeled in the following diagram, which illustrates how the two modules are combined into final iOS and Android app packages:

Skip Native Diagram {: .diagram-vector }

The details of Skip’s bridging are discussed in the documentation. To summarize, the bridging system parses the public types, properties, and functions of your Swift module and exposes them to the transpiled Kotlin layer of your user interface. It supports the Observation framework, so you can use @Observable classes to manage application state in a way that is tracked by your UI, ensuring that your data and user interface are always in sync.

The following screenshot shows a split view between the HelloSwift module’s ContentView.swift and the HelloSwiftModel module’s ViewModel.swift. It demonstrates how the user interface layer communicates with the model layer in exactly the same way on both iOS and Android, although the latter is crossing a language boundary:

Toolchain Mechanics

Skip integrates with the Xcode and Swift Package Manager build systems using the SkipStone Xcode plugin. This plugin transpiles your non-native modules from Swift to Kotlin, and it generates the needed bridging code for communication between your native Swift modules and Kotlin or Java.

The skip init command you used to create the “Hello Swift” app also adds a build script to the generated Xcode project. This build script launches Android’s Gradle ↗ build tool to compile and package the plugin’s output into an Android APK. When your project has native modules, this includes compiling the native code using the Android toolchain described in Part 1.

But how does Skip know which modules to transpile and which are native? Every Skip module must include a Skip/skip.yml configuration file in its source folder. Here is the configuration for a native Swift module whose public API is bridged to Kotlin:

skip:
  mode: 'native'
  bridging: true

Once you have specified that a module is bridging, the entire process is automatic. You can iterate on both your native and transpiled code and re-launch the app, and the bridging code will be updated without needing to run an external tool or perform any other manual process.

Next Steps

Now that you’ve created your first native Swift Android app, what’s next? Well, remember that this is just a starter app designed to get you up and running. It is meant to be torn apart and modified, so feel free to experiment by changing the model and UI in Xcode!

If you’d like to learn much more about SkipFuse, bridging, and native Swift on Android, consider reading our Native Swift Tech Preview documentation. Many of the topics it covers are the subjects of additional posts in this series. For example, while we saw “Hello Swift” bridge its native Swift model layer to its transpiled Kotlin user interface, we haven’t discussed bridging Kotlin API for use by native Swift at all. The documentation covers this in depth.

Native Swift on Android Series

Additional posts in the native Swift on Android series:

Part 1: A native Swift toolchain for Android
Part 2: Your first native Swift Android app
Part 3: Using a shared native Swift model to power separate SwiftUI iOS and Jetpack Compose Android apps
Coming soon: Bridging Kotlin and Java API for consumption by native Swift
Coming soon: Incorporating native Swift, C, and C++ dependencies into your cross-platform Swift apps

Conclusion

Swift’s safety, efficiency, and expressiveness make it an excellent development language, and its use across platforms is spreading. This series focuses on sharing native Swift code between iOS and Android with Skip. Part 1 introduced the native Swift toolchain for Android. Now in Part 2, you’ve created your first cross-platform Swift app. There is a lot of interesting territory that we haven’t yet explored, so check out Part 3 and beyond!