UIKit-cross-platform runs iOS Swift UI code on Android

The problem is the twice-written app

The README states the motivation in plain terms. Currently in mobile development apps have to be written twice, for iOS and Android, or native performance has to be sacrificed with a cross-platform solution such as React Native. The framework aims to combine both advantages, having native performance and writing code only once but still keeping a native look and feel. That is a clear position on the platform trade-off, and it explains the technical choices that follow. The project describes itself as a UI framework for native apps, which enables code targeting iOS UIKit to run on other platforms, particularly on Android. The emphasis is on UI. That is a scoping decision rather than a limitation to be apologised for, and it tells you what to look for in the source. The repository has an SDL directory for the graphics layer, a Sources directory for the Swift implementation, a UIKit.xcodeproj and a UIKitTests directory, a UIKit_C_API directory, and a src directory that likely holds the platform specific pieces. There is also a Resources directory and a swift-android-toolchain directory, which is where the Android build support lives.

The five step path from an iOS project to an Android build

The workflow the README documents is short enough to follow without a tutorial, and the order matters because each step depends on the previous one. You create a new iOS project or open an existing one. You prepare that project following the linked preparation document. You add UIKit-cross-platform to the project, and then you run the create-android-project script from the root of your iOS project. Finally you open the generated android folder in Android Studio, install the SDKs if necessary, and press run. The script is the pivot point of the whole arrangement. It lives at UIKit/create-android-project in the repository root listing, alongside the CMakeLists.txt and the Package.swift. The point of generating the Android project rather than shipping a fixed template is that the generated project is derived from your specific iOS project, so the assets, build settings and source layout come along with it. The DemoApp in the samples directory runs on iOS, Android and Mac, and the README gives the exact steps for each: clone the project, run the recursive submodule update, open the DemoApp.xcodeproj in Xcode and run the DemoApp target for iOS or the DemoAppMac target for Mac, then open the android folder with Android Studio and run it on a connected device.

Submodules plus CMake plus Ninja is the build contract

Adding the framework to a project means adding it as a dependency along with its subdependencies, and the recommended mechanism is git submodules into a UIKit subdirectory:

git submodule add [email protected]:flowkey/UIKit-cross-platform.git UIKit && git submodule update --init --recursive UIKit

The recursive flag matters, because the framework carries its own subdependencies, and the repository has a.gitmodules file at the root. The build environment requirements are specific. You need CMake above 3.16 and Ninja, and on macOS the README gives the Homebrew commands:

brew install cmake && brew install ninja

You also need Android Studio, and inside it a defined set of SDK components. Under SDK Platforms you install the SDK for API Level 29, and under SDK Tools you install Android SDK Build Tools and NDK 30.0.16248370, ticking Show Package Details to see all available versions. There is one manual step that is easy to miss, which is creating a symlink in /usr/local/ndk/30.0.16248370/ pointing to the path of the NDK, using the ln command with the verbose, symbolic, interactive flags. That symlink is there because the NDK version the framework expects is a specific one, and a machine with several NDK versions installed needs the mapping. Pinning the NDK version rather than tracking the latest is a deliberate choice, since the toolchain is what actually has to reproduce Apple's build on the other side.

SDL_gpu sits between the Swift code and OpenGL

The architecture section is short and names the whole stack. UIKit-cross-platform renders with SDL_gpu, which translates down to lower-level OpenGL instructions. On Android, CMake compiles the Swift code into native binaries via Ninja, and those are called through the NDK. The chain therefore runs from your Swift view code, through a UIKit-shaped API, into SDL_gpu, into OpenGL, and on Android the compilation of that Swift into a native binary is handled by the Android toolchain rather than by the Swift compiler you use for iOS. The swift-android-toolchain directory in the repository root is the part that makes the last step possible, since Swift on Android is not a stock configuration and needs its own toolchain build. There is also an iOS Polyfills directory, which is the counterpart to that work, supplying the pieces of the Apple platform that Android does not have. The README points at a more detailed architecture document for anyone who needs to go deeper. A separate Materials Design Icons licence file is present, which tells you that the icon set ships under its own terms rather than under the project's MIT licence, a detail worth knowing if you redistribute.

The documentation strategy is Apple, which is both a strength and a risk

This framework uses the Apple UIKit API, and that single decision explains how the project handles documentation. Because the API surface mirrors Apple's, the official Apple Docs serve as documentation for the already implemented features. There is no separate API reference to read or keep in sync, which is a real saving for a project that reimplements a large framework. The risk is the obvious one. The Apple documentation describes a platform that this project only partially reproduces, and the readme's own wording, for the already implemented features, is careful on that point. A developer who reads the Apple docs for a class and finds it in the framework has learned the contract but not the fidelity of the implementation, and the readme does not publish a coverage matrix saying which classes and methods are done. The docs directory holds the documents that fill that gap, with a preparation document for iOS projects, an architecture document, a contributing guide, and a FAQs document linked from the troubleshooting section. The contributing guide and the issue tracker are the two places where gaps in coverage are likely to surface, and the README asks for both, with a note that contributions are very welcome.

What is missing and where the project stops

The scope statement is narrow by design, and a reader should read it carefully. This is a UI framework, not a full application stack. The README does not describe networking, data persistence, push notifications, background execution, media playback, permission handling or the store submission process, and none of that appears in the top level directory listing either. The two target platforms in the readme badge are Android and macOS, so the phrase cross-platform here means those two, not a wide matrix. The other limitation is the packaging reality. The repository publishes no GitHub releases, so there is no versioned artefact to depend on, and consumers are expected to add the repository as a submodule, which means they track a moving master branch and absorb the upgrade cost themselves. The submodules approach also puts the burden of dependency management on the consuming project, since the recursive update has to be run and any upstream change is a submodule bump. The honest comparison is with the alternatives rather than with other reimplementations. Rewriting a UI layer in a shared framework such as React Native lets you reuse one codebase across platforms, at the cost of abandoning the UIKit code you already have. Porting a UIKit app to Android natively keeps native performance on both platforms and costs you a second codebase. What this project offers is a third path, reusing the iOS view code with a toolchain that compiles Swift for Android, and the trade is that you inherit a young, unreleased project and a toolchain you assemble yourself.

Editorial conclusion

UIKit-cross-platform is worth a serious look if you already maintain an iOS app in Swift and need an Android version, because the value is in reusing the view layer you already have rather than in a new cross-platform abstraction. It is the wrong choice for a new app that has not been written in UIKit yet, since you would be adopting Apple's API surface on a platform where it was never designed to run, and the wrong choice for anything needing App Store or Play Store distribution guarantees, because this is a research project with no published releases. Verify first that the APIs your app actually uses are implemented rather than merely declared, that the Android NDK and SDK versions named in the setup instructions still match your toolchain, and that the Swift toolchain version on your machine matches the badge in the readme. The last push was on 2026-10-19.

Frequently asked questions

Official sources

1. flowkey/UIKit-cross-platform on GitHub
2. Issues
3. License: MIT
4. README