From 9973b1b4cf60307e16571318fd0b6e388fb4666e Mon Sep 17 00:00:00 2001 From: Marc Prud'hommeaux Date: Wed, 2 Jul 2025 13:28:15 -0400 Subject: [PATCH 1/4] Create android.md --- visions/android.md | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 visions/android.md diff --git a/visions/android.md b/visions/android.md new file mode 100644 index 0000000000..f8be096a77 --- /dev/null +++ b/visions/android.md @@ -0,0 +1,2 @@ +# A Vision for Android Support in Swift + From f66485adbb649482f22afc35b2febf320391ae09 Mon Sep 17 00:00:00 2001 From: Marc Prud'hommeaux Date: Wed, 27 Aug 2025 14:03:20 -0400 Subject: [PATCH 2/4] Update android.md --- visions/android.md | 82 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 81 insertions(+), 1 deletion(-) diff --git a/visions/android.md b/visions/android.md index f8be096a77..44a254b795 100644 --- a/visions/android.md +++ b/visions/android.md @@ -1,2 +1,82 @@ -# A Vision for Android Support in Swift +# A Vision for Swift on Android +## Introduction + +The establishment of a dedicated [Android workgroup](https://www.swift.org/android-workgroup/) within the Swift open-source project signifies a major step towards making Android an officially supported platform for Swift development. This initiative aims to integrate Swift into the Android development landscape, offering developers a robust, performant, and memory-safe language alternative for building Android applications. + +Historically, using Swift for Android development involved relying on unofficial forks, custom toolchains, or third-party solutions. The new official effort seeks to streamline this process, providing consistent tooling and improved integration with Android's native APIs and conventions. This move is poised to increase Swift's adoption in the broader mobile development space, allowing for greater code sharing between iOS and Android projects and potentially reducing development costs for cross-platform applications. + +While Kotlin remains the recommended language for Android development, Swift's expansion offers a compelling choice for developers seeking a modern language with strong performance and safety guarantees. The ongoing work will focus on making Swift a first-class citizen on Android, ensuring that Swift applications feel native and perform optimally on the platform. + +## Use Cases for Swift on Android + +The potential applications of Swift on Android are diverse and extend beyond simply sharing code between iOS and Android. + +* Shared Business Logic: A prominent use case is sharing core business logic, algorithms, and data models across iOS and Android applications. This minimizes duplication of effort and ensures consistency in application behavior. +* Performance-Critical Modules: Swift's strong performance characteristics make it ideal for developing performance-sensitive components, such as image processing, audio manipulation, or computationally intensive tasks within an Android app, akin to using C++ via the NDK. +* Cross-Platform Libraries and SDKs: Developers can leverage Swift to build libraries and SDKs that can be easily integrated into existing Android (and iOS) applications, providing a consistent API surface across platforms. +* Full Native Applications: While requiring significant effort for UI, it's conceivable to build entire Android applications in Swift, using platform-native UI frameworks for each respective OS. + +## Build tool integration + +Integration with the existing Android build systems is essential in order to provide a friendly experience for developers. + +* Gradle Plugin: A strong recommendation is to provide a well-maintained Gradle plugin that simplifies the process of compiling Swift code for Android, managing dependencies, and integrating Swift libraries into Android projects. This should handle cross-compilation for various Android architectures. +* Dependency Management: Support for integrating Swift packages and other native dependencies within the Gradle build flow. +IDE and debugging support +Robust IDE and debugging support are critical for a productive developer experience. +* IDE Integration: Swift build integration with various Android-capable IDEs such as Android Studio and VSCode - this includes syntax highlighting, code completion, refactoring, and project navigation. +* Debugging: Improved debugging capabilities for Swift code on Android are a key focus. This involves enhancing integration with existing debugging tools and protocols. The aim is to make debugging Swift on Android as good as debugging Swift on other officially supported platforms, including support for Swift-specific metadata and expression evaluation. + +## App packaging support + +Packaging Swift code and its runtime into Android application packages (APKs) is necessary in order to create a distributable application. + +* APK Inclusion: Guidelines and tooling for correctly packaging compiled Swift binaries and necessary runtime libraries into the `lib/` folder of an APK. +* Android App Bundles (AABs): Support for generating optimized AABs that allow for efficient delivery of architecture-specific Swift code to end-user devices via the Play Store. + +## Testing support + +Comprehensive testing is important for maintaining code quality on any platform. Swift on Android should facilitate running test code on Android emulators and devices. + +* Unit and Integration Testing: Ensuring that the standard Swift testing frameworks (e.g., XCTest, Swift Testing) can be used effectively for unit and integration testing of Swift code on Android. +* Continuous Integration (CI): Establishing CI jobs within the Swift project that include Android testing as part of pull request checks, guaranteeing ongoing compatibility and stability. +Bridging support for Java and Kotlin +Interoperability between Swift and Android's primary languages (Java/Kotlin) is vital for integrating Swift into existing Android projects and accessing the rich Android SDK. +* Java Native Interface (JNI): JNI is the fundamental mechanism for communication between native (Swift) and Java/Kotlin code on Android. Bridging tools should simplify the use of JNI, abstracting away much of its complexity. +* Automatic Binding Generation: Tools that can automatically generate Swift bindings from Java/Kotlin APIs and vice versa will significantly improve developer experience. This should cover common data types and method signatures. +* Kotlin-specific Bridging: Given Kotlin's prominence on Android, specific bridging mechanisms that handle Kotlin-exclusive features (e.g., suspending functions, specific Jetpack Compose integrations) would be highly beneficial. Recommendations for best practices in designing Swift APIs for optimal interoperability with Kotlin will be provided. + +## Supported target architectures + +Swift on Android should target all major Android architectures. + +* ARM (armeabi-v7a, arm64-v8a): These are the most common architectures for Android devices and will be primary targets. +* x86/x86_64: Support for Android emulators and certain desktop-class Android devices. +* RISC-V: Once the RISC-V architecture matures and becomes a more prevalent target for Android devices, official support for riscv64 should be added, enabling Swift applications to run on this open-standard instruction set architecture. + +## NDK version support + +Alignment with Android NDK versions is important for stability and access to platform features. + +* Specific NDK Versions: Clearly define the supported Android NDK versions that Swift on Android targets, ensuring compatibility with the native toolchains and libraries provided by Google. +* LTS Releases: Prioritize support for Long Term Support (LTS) NDK releases to provide a stable development environment. + +## UI recommendations + +The official Swift on Android initiative will not provide a single UI framework, but will acknowledge and support various approaches. +The UI for Swift on Android applications will primarily rely on Android's native UI frameworks or existing cross-platform solutions. This means developers will likely choose from: + +* Jetpack Compose: Android's modern, declarative UI toolkit in Kotlin. Swift applications could interact with Compose through robust bridging layers. +* Android Views (XML-based): The traditional imperative UI system. +* Third-Party Cross-Platform UI Frameworks: Such as Flutter (with Swift as the business logic language via FlutterSwift) or potentially others that offer C/C++ interop, which Swift can leverage. +* Bridging Solutions: Tools like Skip.tools demonstrate how SwiftUI-like code can be transformed and rendered using Jetpack Compose on Android, offering a path to "native-feeling" cross-platform UI. + +The vision is to ensure Swift works well with these existing UI approaches, allowing developers to select the most suitable option for their project while leveraging Swift for the underlying logic. Documentation and best practices will guide developers in integrating Swift with their chosen UI framework. + +## Non-goals + +Defining what is not a goal is as important as defining what is. + +* Full SwiftUI/UIKit Port: A direct, full port of existing UI frameworks to Android is not a goal. While projects like Skip.tools demonstrate bridging SwiftUI to Jetpack Compose, the official Swift on Android effort will focus on language and core library support, not building our own cross-platform UI frameworks. +* Compilation to JVM Bytecode: Direct compilation of Swift to JVM bytecode is not an immediate goal. Swift's current compilation model targets native machine code, and leveraging the NDK allows for direct interaction with Android's native layer. While interesting for future exploration, the current focus is on a performant, native execution model. From 835d97f326c6116318abedcdf40cebf4101a75da Mon Sep 17 00:00:00 2001 From: Finagolfin Date: Wed, 3 Dec 2025 22:13:45 +0530 Subject: [PATCH 3/4] Describe Android for those unfamiliar with it and edit and streamline the vision doc --- visions/android.md | 83 +++++++++++++++++++--------------------------- 1 file changed, 35 insertions(+), 48 deletions(-) diff --git a/visions/android.md b/visions/android.md index 44a254b795..8344a9c8fa 100644 --- a/visions/android.md +++ b/visions/android.md @@ -2,81 +2,68 @@ ## Introduction -The establishment of a dedicated [Android workgroup](https://www.swift.org/android-workgroup/) within the Swift open-source project signifies a major step towards making Android an officially supported platform for Swift development. This initiative aims to integrate Swift into the Android development landscape, offering developers a robust, performant, and memory-safe language alternative for building Android applications. +The establishment of a dedicated [Android workgroup](https://www.swift.org/android-workgroup/) within the Swift open-source project marked a major step towards making Android an officially-supported platform for Swift development. The workgroup aims to further integrate Swift into Android development, offering developers a robust, performant, and memory-safe language alternative for building Android applications. -Historically, using Swift for Android development involved relying on unofficial forks, custom toolchains, or third-party solutions. The new official effort seeks to streamline this process, providing consistent tooling and improved integration with Android's native APIs and conventions. This move is poised to increase Swift's adoption in the broader mobile development space, allowing for greater code sharing between iOS and Android projects and potentially reducing development costs for cross-platform applications. +Previously, using Swift for Android development involved relying on unofficial SDKs, custom toolchains, or other third-party solutions. The workgroup seeks to streamline this build process, providing consistent official tooling and improved integration with Android's native APIs and conventions. This should increase Swift's adoption in the broader mobile development space, allowing for greater code sharing between iOS and Android projects and reducing development costs for cross-platform applications. -While Kotlin remains the recommended language for Android development, Swift's expansion offers a compelling choice for developers seeking a modern language with strong performance and safety guarantees. The ongoing work will focus on making Swift a first-class citizen on Android, ensuring that Swift applications feel native and perform optimally on the platform. +While Kotlin remains the recommended language for Android development, Swift's expansion offers a compelling choice for developers seeking a modern language with strong performance and safety guarantees. Ongoing work will focus on making Swift a first-class citizen on Android, ensuring that Swift applications feel native and perform optimally on the platform. + +## The Android platform + +For those unfamiliar with Android's technical underpinnings, it uses a forked linux kernel optimized for mobile use, replacing the GNU libc with its own Bionic libc and dynamic linker. There is no libc++ available on-device for all apps to use, but the Android Native Development Kit (NDK) comes with a version of the LLVM libc++ that can be bundled with each app that needs it. Most apps are written in Java or Kotlin and run on the Android RunTime (ART), distributed as bytecode and either compiled to machine code when installed or Just-In-Time (JIT) when run. + +C and C++ code are compiled Ahead-Of-Time (AOT) and packaged as native shared libraries- that's how Swift on Android is also distributed- which have to be accessed through the Java Native Interface (JNI), since most Android APIs are only made available through Java. + +All four of the Android target architectures work well with Swift- 64-bit arm64-v8a and x86_64 and 32-bit armeabi-v7a and x86- and we will support [the new RISC-V riscv64 arch](https://github.com/google/android-riscv64#status) as it gets rolled out. ## Use Cases for Swift on Android -The potential applications of Swift on Android are diverse and extend beyond simply sharing code between iOS and Android. +The potential applications of Swift on Android are diverse and extend beyond simply sharing code between iOS and Android: -* Shared Business Logic: A prominent use case is sharing core business logic, algorithms, and data models across iOS and Android applications. This minimizes duplication of effort and ensures consistency in application behavior. -* Performance-Critical Modules: Swift's strong performance characteristics make it ideal for developing performance-sensitive components, such as image processing, audio manipulation, or computationally intensive tasks within an Android app, akin to using C++ via the NDK. -* Cross-Platform Libraries and SDKs: Developers can leverage Swift to build libraries and SDKs that can be easily integrated into existing Android (and iOS) applications, providing a consistent API surface across platforms. -* Full Native Applications: While requiring significant effort for UI, it's conceivable to build entire Android applications in Swift, using platform-native UI frameworks for each respective OS. +* Shared Business Logic - Of course, the prominent use case is sharing core business logic, algorithms, and data models across iOS and Android applications. This minimizes duplication and ensures consistency in application behavior. +* Performance-Critical Modules - Swift's strong performance characteristics make it ideal for developing performance-sensitive components, such as image/audio processing, game engines, or other computationally-intensive tasks within an Android app, similar to using C or C++ via the NDK. +* Cross-Platform Libraries and SDKs - Developers can leverage Swift to build libraries and SDKs that can be easily integrated into existing Android and iOS applications, providing a consistent API surface across platforms. ## Build tool integration -Integration with the existing Android build systems is essential in order to provide a friendly experience for developers. - -* Gradle Plugin: A strong recommendation is to provide a well-maintained Gradle plugin that simplifies the process of compiling Swift code for Android, managing dependencies, and integrating Swift libraries into Android projects. This should handle cross-compilation for various Android architectures. -* Dependency Management: Support for integrating Swift packages and other native dependencies within the Gradle build flow. -IDE and debugging support -Robust IDE and debugging support are critical for a productive developer experience. -* IDE Integration: Swift build integration with various Android-capable IDEs such as Android Studio and VSCode - this includes syntax highlighting, code completion, refactoring, and project navigation. -* Debugging: Improved debugging capabilities for Swift code on Android are a key focus. This involves enhancing integration with existing debugging tools and protocols. The aim is to make debugging Swift on Android as good as debugging Swift on other officially supported platforms, including support for Swift-specific metadata and expression evaluation. +Integration with existing Android build systems and developer tools is essential in order to provide a usable experience for developers. Dependency management between Swift packages and Android-native dependencies within the existing Gradle build flow will be important. We are looking into providing a Gradle plugin that simplifies the process. -## App packaging support +Improved debugging capabilities for Swift libraries on Android are a key focus. This involves enhancing integration with existing debugging tools and protocols. The aim is to make debugging Swift on Android work as well as debugging Swift on other officially supported platforms, including support for Swift-specific metadata and expression evaluation. -Packaging Swift code and its runtime into Android application packages (APKs) is necessary in order to create a distributable application. +Integration of all these tools into various Android-capable IDEs and editors, such as Android Studio and VS Code - including syntax highlighting, code completion, refactoring, and project navigation- will need to be developed further. -* APK Inclusion: Guidelines and tooling for correctly packaging compiled Swift binaries and necessary runtime libraries into the `lib/` folder of an APK. -* Android App Bundles (AABs): Support for generating optimized AABs that allow for efficient delivery of architecture-specific Swift code to end-user devices via the Play Store. +## App packaging -## Testing support +Packaging Swift code and its runtime into Android application packages (APKs) is necessary in order to create a distributable application. Guidelines and tooling for correctly packaging compiled Swift binaries and necessary runtime libraries into the native `lib/` folder of an APK will be provided. -Comprehensive testing is important for maintaining code quality on any platform. Swift on Android should facilitate running test code on Android emulators and devices. +## Testing -* Unit and Integration Testing: Ensuring that the standard Swift testing frameworks (e.g., XCTest, Swift Testing) can be used effectively for unit and integration testing of Swift code on Android. -* Continuous Integration (CI): Establishing CI jobs within the Swift project that include Android testing as part of pull request checks, guaranteeing ongoing compatibility and stability. -Bridging support for Java and Kotlin -Interoperability between Swift and Android's primary languages (Java/Kotlin) is vital for integrating Swift into existing Android projects and accessing the rich Android SDK. -* Java Native Interface (JNI): JNI is the fundamental mechanism for communication between native (Swift) and Java/Kotlin code on Android. Bridging tools should simplify the use of JNI, abstracting away much of its complexity. -* Automatic Binding Generation: Tools that can automatically generate Swift bindings from Java/Kotlin APIs and vice versa will significantly improve developer experience. This should cover common data types and method signatures. -* Kotlin-specific Bridging: Given Kotlin's prominence on Android, specific bridging mechanisms that handle Kotlin-exclusive features (e.g., suspending functions, specific Jetpack Compose integrations) would be highly beneficial. Recommendations for best practices in designing Swift APIs for optimal interoperability with Kotlin will be provided. +Comprehensive testing is important for maintaining code quality on any platform, including running test code on Android emulators and devices. The standard Swift unit and integration testing frameworks, such as XCTest and Swift Testing, work well now, but we will iron out any remaining incompatibilities and establish more Continuous Integration (CI) jobs within the Swift project, such as including Android testing as part of pull request checks, to guarantee ongoing compatibility and stability. -## Supported target architectures +## Bridging to Java and Kotlin -Swift on Android should target all major Android architectures. +Interoperability between Swift and Android's primary languages- Java and Kotlin- is vital for integrating Swift into existing Android projects and accessing the rich Android SDK. Since JNI is the fundamental mechanism for communicating between native languages like Swift or C/C++ and Java/Kotlin, [automated bridging tools like swift-java](https://github.com/swiftlang/swift-java) should simplify the use of JNI, abstracting away much of its complexity. -* ARM (armeabi-v7a, arm64-v8a): These are the most common architectures for Android devices and will be primary targets. -* x86/x86_64: Support for Android emulators and certain desktop-class Android devices. -* RISC-V: Once the RISC-V architecture matures and becomes a more prevalent target for Android devices, official support for riscv64 should be added, enabling Swift applications to run on this open-standard instruction set architecture. +Given Kotlin's prominence on Android, specific bridging mechanisms that handle Kotlin-exclusive features (e.g., suspending functions, specific Jetpack Compose integrations) would be highly beneficial. Recommendations for best practices in designing Swift APIs for optimal interoperability with Kotlin will be provided. ## NDK version support -Alignment with Android NDK versions is important for stability and access to platform features. - -* Specific NDK Versions: Clearly define the supported Android NDK versions that Swift on Android targets, ensuring compatibility with the native toolchains and libraries provided by Google. -* LTS Releases: Prioritize support for Long Term Support (LTS) NDK releases to provide a stable development environment. +Alignment with Android NDK versions is important for stability and access to platform features. We clearly define the Android NDK versions that the latest Swift release/snapshots on Android are compatible with, prioritizing support for Long Term Support (LTS) releases to provide a stable development environment. ## UI recommendations -The official Swift on Android initiative will not provide a single UI framework, but will acknowledge and support various approaches. -The UI for Swift on Android applications will primarily rely on Android's native UI frameworks or existing cross-platform solutions. This means developers will likely choose from: +There will not be a single official UI framework, instead we will acknowledge and support various approaches: the UI for Swift on Android applications will primarily rely on Android's native UI frameworks or existing cross-platform solutions. This means developers will likely choose from: -* Jetpack Compose: Android's modern, declarative UI toolkit in Kotlin. Swift applications could interact with Compose through robust bridging layers. -* Android Views (XML-based): The traditional imperative UI system. -* Third-Party Cross-Platform UI Frameworks: Such as Flutter (with Swift as the business logic language via FlutterSwift) or potentially others that offer C/C++ interop, which Swift can leverage. -* Bridging Solutions: Tools like Skip.tools demonstrate how SwiftUI-like code can be transformed and rendered using Jetpack Compose on Android, offering a path to "native-feeling" cross-platform UI. +* Jetpack Compose - Android's modern, declarative UI toolkit in Kotlin: Swift applications could interact with Compose through robust bridging layers. +* Android Views (XML-based) - The traditional imperative UI +* Third-Party Cross-Platform UI Frameworks - Such as Flutter, with Swift as the business logic language via [FlutterSwift](https://github.com/PADL/FlutterSwift), or potentially others that offer C/C++ interop, which Swift can pull in. +* Bridging Solutions - Tools [such as Skip](https://github.com/skiptools) demonstrate how SwiftUI-like code can be transformed and rendered using Jetpack Compose on Android, offering a path to native cross-platform UI. -The vision is to ensure Swift works well with these existing UI approaches, allowing developers to select the most suitable option for their project while leveraging Swift for the underlying logic. Documentation and best practices will guide developers in integrating Swift with their chosen UI framework. +The goal is to ensure Swift works well with these existing UI approaches, allowing developers to select the most suitable option for their project while deploying Swift for the underlying logic. ## Non-goals -Defining what is not a goal is as important as defining what is. +Defining what is not a goal is as important as defining what is: -* Full SwiftUI/UIKit Port: A direct, full port of existing UI frameworks to Android is not a goal. While projects like Skip.tools demonstrate bridging SwiftUI to Jetpack Compose, the official Swift on Android effort will focus on language and core library support, not building our own cross-platform UI frameworks. -* Compilation to JVM Bytecode: Direct compilation of Swift to JVM bytecode is not an immediate goal. Swift's current compilation model targets native machine code, and leveraging the NDK allows for direct interaction with Android's native layer. While interesting for future exploration, the current focus is on a performant, native execution model. +* Full SwiftUI/UIKit Port - To reiterate, a direct, full port of existing UI frameworks to Android will not be attempted. The official Swift on Android effort will focus on language and core library support and integrating with existing UI frameworks, not building our own cross-platform UI framework. +* Compilation to JVM Bytecode - Direct compilation of Swift to JVM bytecode is not being contemplated. Swift's native AOT compilation model targets machine code, and employing the NDK allows for direct interaction with Android's native layer. From 2e6d7418dfd227e0d143be9ed95d8e1ee58ddc3b Mon Sep 17 00:00:00 2001 From: Marc Prud'hommeaux Date: Mon, 9 Feb 2026 08:36:25 -0500 Subject: [PATCH 4/4] Tweaks to android.md --- visions/android.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/visions/android.md b/visions/android.md index 8344a9c8fa..02a65b47ab 100644 --- a/visions/android.md +++ b/visions/android.md @@ -20,7 +20,7 @@ All four of the Android target architectures work well with Swift- 64-bit arm64- The potential applications of Swift on Android are diverse and extend beyond simply sharing code between iOS and Android: -* Shared Business Logic - Of course, the prominent use case is sharing core business logic, algorithms, and data models across iOS and Android applications. This minimizes duplication and ensures consistency in application behavior. +* Shared Business Logic - A prominent use case is sharing core business logic, algorithms, and data models across iOS and Android applications. This minimizes duplication and ensures consistency in application behavior. * Performance-Critical Modules - Swift's strong performance characteristics make it ideal for developing performance-sensitive components, such as image/audio processing, game engines, or other computationally-intensive tasks within an Android app, similar to using C or C++ via the NDK. * Cross-Platform Libraries and SDKs - Developers can leverage Swift to build libraries and SDKs that can be easily integrated into existing Android and iOS applications, providing a consistent API surface across platforms. @@ -57,7 +57,7 @@ There will not be a single official UI framework, instead we will acknowledge an * Jetpack Compose - Android's modern, declarative UI toolkit in Kotlin: Swift applications could interact with Compose through robust bridging layers. * Android Views (XML-based) - The traditional imperative UI * Third-Party Cross-Platform UI Frameworks - Such as Flutter, with Swift as the business logic language via [FlutterSwift](https://github.com/PADL/FlutterSwift), or potentially others that offer C/C++ interop, which Swift can pull in. -* Bridging Solutions - Tools [such as Skip](https://github.com/skiptools) demonstrate how SwiftUI-like code can be transformed and rendered using Jetpack Compose on Android, offering a path to native cross-platform UI. +* Bridging Solutions - Projects such as [Skip](https://github.com/skiptools) provide a declarative SwiftUI-like API surface atop Android's Jetpack Compose, offering a path to native shared cross-platform UI. The goal is to ensure Swift works well with these existing UI approaches, allowing developers to select the most suitable option for their project while deploying Swift for the underlying logic.