Android vision document #2946
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,69 @@ | ||||||||||||||||||||
| # 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 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. | ||||||||||||||||||||
|
|
||||||||||||||||||||
| 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. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. Similarly, I don't know if the previous state is useful. The vision isn't really about what the workgroup is seeking to do but rather what the desired state is.
Suggested change
Once you simplify this, it immediately asks the question: what exactly does this mean. What needs to be streamlined, what tooling is missing, and how does the current status quo not match the Android APIs and conventions? |
||||||||||||||||||||
|
|
||||||||||||||||||||
| 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. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. This is about Swift and not Kotlin, I don't think that we need to reference that. Is the vision about ongoing work or a concrete state? i.e. is the vision that we do not have a stable point ever and will continually change the behaviour? |
||||||||||||||||||||
|
|
||||||||||||||||||||
| ## 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. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. I'm not sure that interleaving this context with the vision is helpful in explaining the vision though it can be useful in explaining the why.
Member
There was a problem hiding this comment. I suggest you take a look at the embedded or Wasm vision documents, which similarly explain how those new platforms for Swift work. Since most people don't know how Android works under the seams, this similarly situates the reader. |
||||||||||||||||||||
|
|
||||||||||||||||||||
| 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. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. I think that the distribution mechanism is not entirely tied indefinitely. While we should encourage dynamic linking, I believe that it should be possible to perform static linking. More importantly, the piece that is core to the message here is that JNI is a requirement for interop.
Suggested change
But, this feels like an incomplete thought. Okay, so it requires JNI, but what does that mean for the vision?
Member
There was a problem hiding this comment. This sentence makes no mention of static or dynamic linking of Swift, both of which we support. Rather, it explains how natively-compiled code like Swift or C has to be distributed on Android, which is sufficiently different from other platforms that run executables that it is worth calling out. As for how JNI ties into this vision, see the section on bridging below, where we specifically call out this term which we defined and explained here.
Member
There was a problem hiding this comment.
To me, that reads as Swift is dynamically linked.
Member
There was a problem hiding this comment. I mean, it specifically says it is how it is "distributed," and as you well know, the Android shared library we distribute can either statically or dynamically link the Swift runtime and user code into it. If you think more precise language is needed here, please suggest some.
Member
There was a problem hiding this comment. I did suggest something more concretely above :)
Member
There was a problem hiding this comment. That was before we discussed why this was written this way, when you simply took out all info about compilation and distribution, therefore there was no info on distribution in your previous suggestion. Instead, I asked how you think it could be stated more precisely. |
||||||||||||||||||||
|
|
||||||||||||||||||||
| 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. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment.
Suggested change
Member
There was a problem hiding this comment. I don't like these changes: no real reason to break out the arches in a full list like this, and it is incorrect to say rv64 is currently supported, as there is no shipping hardware yet. I don't think we should "support" all of them with the SDK either, as x86 is barely used and they have been contemplating when to drop it for years now, android/ndk#1772. Best to just say it works, as we do here, and leave it up to the SDK builders on whether they want to include 32-bit x86, as I understand you do with the Windows toolchain but we do not in the SDK bundle. As for working with the NDK devs, almost no chance of that, as they will readily tell you they are understaffed and cannot support outside languages.
Member
There was a problem hiding this comment. Well, if we are saying that X86 is entirely unsupported (and want to actively exclude it), then that is a reason for removing that support from the source tree to avoid the maintenance. I would argue that we should support it (similar to how people believe that the cost of maintaining the lower API levels is important). There are ABI differences and the emulator is extremely useful. We could make it more generic and simply say that see the NDK for the supported architectures and avoid creating an explicit list.
Member
There was a problem hiding this comment. Since you provide an Android x86 SDK with the Windows toolchain and run it through most of the compiler validation suite, I thought it was appropriate to list it and say it "works well," while leaving it up to the SDK bundlers whether to include it. Considering the very low usage numbers listed in that linked NDK issue on dropping it and it now being very easy to build the Android SDK from source yourself if you want it- except you'll have to skip the compiler validation suite with |
||||||||||||||||||||
|
|
||||||||||||||||||||
| ## Use Cases for Swift on Android | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. I think that we should re-title this - are we describing the use cases we see or the use cases that we should support?
Member
There was a problem hiding this comment. Is there a difference? 😉 Realistically, anything we mention here will be expected to be supported...
Member
There was a problem hiding this comment. I do think that there is a difference. These are not the only use cases, its the ones that are currently a focus. I think that this will change over time, and therefore I think that we should re-title this.
Member
There was a problem hiding this comment. Ok, please suggest a more appropriate title then, as the ones listed are simply ones we've seen. |
||||||||||||||||||||
|
|
||||||||||||||||||||
| 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 and ensures consistency in application behavior. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. Maybe mention cross platform beyond just mobile too? |
||||||||||||||||||||
| * 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. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. I'm not sure I fully understand the difference between this and "Shared Business Logic". Ultimately, the fact that you have cross-platform libraries and SDKs is what is enabling the shared business logic. I would consider collapsing the two.
Member
There was a problem hiding this comment. I agree that it is not a big difference, but there is a difference between companies porting their internal business logic and SDK vendors providing a common externally provided Swift SDK for multiple platforms. This line was likely added to emphasize that that would be supported too. |
||||||||||||||||||||
|
|
||||||||||||||||||||
| ## Build tool integration | ||||||||||||||||||||
|
|
||||||||||||||||||||
| 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. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. Rather than "we are looking into providing a Gradle plugin that simplifies the process", can we frame this as what we would like to see that integration look like?
Member
There was a problem hiding this comment. I don't think so, still too early, as too much depends on SwiftPM's planned new plugin model. The most we can say now is that we intend to tie into Gradle, the established Android build tool, in some way.
Member
There was a problem hiding this comment. I'm not sure I understand the response. You start by saying no, but then give exactly what I was looking for. It is perfectly fine to say that we intend to tie into Gradle, but what does that mean? Does it mean that we would have a set of Gradle rules, would it be some wrapper, would it be support for SPM to call into Gradle, etc. I would say that we actually don't want to say how it would work (aka the details of the SPM plugin model), that is what the evolution proposal would be aligning up.
Member
There was a problem hiding this comment. Sure, I gave you some idea informally by simply saying we're not sure, but that doesn't really say "what we would like to see that integration look like." I don't think we have any idea of whether it would be Gradle rules on the Android side or SwiftPM calling Gradle, as both are still being actively explored on both sides. 😃 Instead, all we can say for now is what we said here, that we "are looking into providing a Gradle plugin that simplifies the process."
Member
There was a problem hiding this comment. That is fine - I think that we can trim to that - "a Gradle plugin that simplifies integrating SPM built packages" is entirely a reasonable vision. |
||||||||||||||||||||
|
|
||||||||||||||||||||
| 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. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. The fact that debugging is a focus area is good, but not really a vision. Can we be more explicit about what the integration with existing tools and protocols looks like? I think that being more concrete about the desired state is important. What exactly does debugging Swift specific metadata mean?
Member
There was a problem hiding this comment. It is a vision in the sense that we are committing to getting the existing tools like lldb-swift working for Android, which Gabriele found significant problems with and has been fixing, swiftlang/llvm-project#10831. I don't think it is worth getting into the weeds beyond affirming that we'll get these existing Swift debugging tools working for Android now: writing more than that would only be necessary if we were writing a whole new tool like ds2, which we are not.
Member
There was a problem hiding this comment. I'm not sure what lldb-swift is (do you mean the Swift fork of LLDB?). I think that simply stating that lldb would be able to do remote debugging with Android is a perfectly cromulent statement of the vision. I'm suggesting that we be more crisp about what it is that we want to see.
Member
There was a problem hiding this comment. OK, we can be more specific on that, point taken. |
||||||||||||||||||||
|
|
||||||||||||||||||||
| 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. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. I think that this starts off right, but then leaves much to the imagination. What will need to be developed further? Do we have a vision of what the integration actually means? I can already "integrate with vim" - I can write the code, and use
Member
There was a problem hiding this comment. We don't fully know, but even for what we do, do we really want to dive into the weeds of the VS Code plugin model and how we will integrate with it? All most people care about is that we get that working, which a few of us have been looking into.
Member
There was a problem hiding this comment. I don't think that defining what it is that we mean as working, but we definitely should not be describing how that integration works.
Member
There was a problem hiding this comment. I think you may have made a mistake in your first clause about "mean as working," mind restating?
Member
There was a problem hiding this comment.
I'm just saying "get that working" is very ambiguous and can differ from person to person. We should be more clear about what we expect.
Member
There was a problem hiding this comment. We do list some commonly expected IDE tasks in this sentence so we were more specific than that, but considering integrating an existing language like Swift into another IDE is a laundry list of small features, felt that is enough to give the idea. If you think there's something else we should specify, let us know. |
||||||||||||||||||||
|
|
||||||||||||||||||||
| ## App packaging | ||||||||||||||||||||
|
|
||||||||||||||||||||
| 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/<arch>` folder of an APK will be provided. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. I think that this is a great start!
Suggested change
|
||||||||||||||||||||
|
|
||||||||||||||||||||
| ## Testing | ||||||||||||||||||||
|
|
||||||||||||||||||||
| 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. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. I wouldn't say "such as" - these are the current recommendations. Again, I don't think that we should be suggesting the actual work that the workgroup will do, but rather explain what we would like to see. Perhaps something like: Do we want believe that we need a solution for UI testing?
Member
There was a problem hiding this comment. Most of this document is precisely what we would like to see, but for core matters like testing that we have already started improving, I think it is good to say we will do it. Anyway, it is tough to delineate the two, as people are going to expect the workgroup to do anything listed here anyway. I don't think UI testing would make sense given the section on not having any one UI solution below. |
||||||||||||||||||||
|
|
||||||||||||||||||||
| ## Bridging to Java and Kotlin | ||||||||||||||||||||
|
|
||||||||||||||||||||
| 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. | ||||||||||||||||||||
|
|
||||||||||||||||||||
| 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. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. The only change I would recommend is that rather than "best practices ... will be provided" should be more "Documentation covering best practices for ... need to be provided to allow users to easily integrate multiple languages.". |
||||||||||||||||||||
|
|
||||||||||||||||||||
| ## NDK version support | ||||||||||||||||||||
|
|
||||||||||||||||||||
| 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. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. I think that we should extend this further to say that we want to have a consistent NDK requirements across host platforms. |
||||||||||||||||||||
|
|
||||||||||||||||||||
| ## UI recommendations | ||||||||||||||||||||
|
|
||||||||||||||||||||
| 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 | ||||||||||||||||||||
| * 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 - 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. | ||||||||||||||||||||
|
Comment on lines
+59
to
+60
Member
There was a problem hiding this comment. I'm not sure about the call outs to external projects. @shahmishal might be able to help shed some light on this.
Member
There was a problem hiding this comment. Both are OSS, so I think it should be fine, as people want to see concrete examples.
Member
There was a problem hiding this comment. Sure, but we have shied away from referring to OSS projects previously as well.
Member
There was a problem hiding this comment. OK, up to Mishal to clarify the guidelines on that then. |
||||||||||||||||||||
|
|
||||||||||||||||||||
| 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: | ||||||||||||||||||||
|
|
||||||||||||||||||||
| * 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. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. I think that this is the wrong way to approach this. While we don't believe that a UIKit replacement needs to be built, the community is free to build something like that.
Member
There was a problem hiding this comment. Of course, that is specifically mentioned above. This is specifically saying
Member
There was a problem hiding this comment. I think that for
Member
There was a problem hiding this comment.
Member
There was a problem hiding this comment.
|
||||||||||||||||||||
| * 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. | ||||||||||||||||||||
|
Member
There was a problem hiding this comment. I'm not sure where this comes from. There is no mention of anything even remotely in this direction in the document, so it feels like it comes from left-field. Is this something that has come up in the context of the Swift Java?
Member
There was a problem hiding this comment. In general, people assume that new Android languages will compile to JVM bytecode, like Kotlin does and we explained above, "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." This bullet point is emphasizing that in addition to what we wrote above, ie "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," we will not be pursuing the bytecode approach also, which eg Max suggested on the forums years ago.
Member
There was a problem hiding this comment. Interesting. I didn't know that had been proposed. Perhaps it is better to extract that into a foreword or separate section that explains how Android works and Swift interacts with that environment? More specifically, I think that what is being suggested is: the vision is to not change the fundamentals of Swift, which is a by design an AoT language and we do not intend to change that to a VM based language. If that is the intent of this, I think that this is something again to be very clear on, because it is very critical that users understand this. More than that, I don't think that it should be a side note in the negative form. That should be pretty clearly stated upfront. To be clear, I am not making a judgement on the direction, rather I'm just trying to ensure that the vision is clearly shared.
Member
There was a problem hiding this comment. We do clearly state that Swift will be built and distributed like C/C++ in the section above, but added this note at the end to shut the door on the workgroup trying the bytecode approach too. I don't think this is so important that it needs to be called out in a "separate section," as most app devs don't much care about AoT vs bytecode. For general understanding of readers, we added the explainer above, and for the small minority who may want or expect bytecode too, we added this note.
Member
There was a problem hiding this comment. I think that we are in agreement then. I don't think that it needs a separate section - it just needs to be clearly stated as a starting point. |
||||||||||||||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that there is value in this layout. It would make sense in a blog post, but for a vision document, it should focus entirely on the vision.