# Swift Android Native package

**URL:** <https://forums.swift.org/t/swift-android-native-package/85915>\
**Category:** Android\
**Tags:** android, java\
**Created:** [April 9, 2026, 3:04pm UTC](https://forums.swift.org/t/swift-android-native-package/85915 "2026-04-09T15:04:16Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![marcprux](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/marcprux/32/12098_2.png) [@marcprux](https://forums.swift.org/u/marcprux)\
**Post date:** [April 9, 2026, 3:04pm UTC](https://forums.swift.org/t/swift-android-native-package/85915/1 "2026-04-09T15:04:17Z")

</div>

> [@Upcoming Android Workgroup Meeting: April 8, 2026](https://forums.swift.org/t/upcoming-android-workgroup-meeting-april-8-2026/85800/3):
>
> From @Finagolfin Topic: discuss positioning for [swift-android-native repo](https://github.com/swift-android-sdk/swift-android-native) that Marc brought up at last meeting

Following up on this, as well as the mention I made of the project on the [Swift/Java Interop Community Call #6: April 9th 2026](https://forums.swift.org/t/swift-java-interop-community-call-6-april-9th-2026/85385) call today, I wanted to open up discussion on the [GitHub - swift-android-sdk/swift-android-native: Access to the Android NDK from Swift · GitHub](https://github.com/swift-android-sdk/swift-android-native) repository and the potential for it to become a semi-official Swift package that acts as a basis for native integration on Android.

This project derives from the upstream [GitHub - skiptools/swift-android-native: Access to the Android NDK from Swift · GitHub](https://github.com/skiptools/swift-android-native) that is already being used in production Skip Fuse apps, and contains many [contributions](https://github.com/PureSwift/Android/pull/40) from @ColemanCDA's [GitHub - PureSwift/Android: Swift library for Android · GitHub](https://github.com/PureSwift/Android) project. It relies on the new [`swift-java-jni-core`](https://forums.swift.org/t/android-java-and-swiftjni/78890/7) package for the JNI integration that it needs to access some of the native features (like `AssetManager` needing the [`AndroidContext`](https://github.com/swift-android-sdk/swift-android-native?tab=readme-ov-file#androidcontext), which can only be reached through JNI).

The wrappers are fairly rote and ought to be non-controversial, and so this is a logical place where the Swift Android community might benefit from collaborating in a single place rather than every project developing their own parochial equivalents.

We would be interested in hearing feedback from various folk that have low-level Android platform integration requirements about whether this package might fit their needs.

I would also like to explore whether a project like this ought to be "promoted" to living in the `swiftlang` org, or if it is OK to leave it in the unofficial `swift-android-sdk` collaboration org that we've been using for various Android-related projects.

---

<div class="post-metadata">

**Author:** ![snej](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/snej/32/365_2.png) [@snej](https://forums.swift.org/u/snej)\
**Post date:** [April 9, 2026, 3:32pm UTC](https://forums.swift.org/t/swift-android-native-package/85915/2 "2026-04-09T15:32:43Z")

</div>

I’m prototyping a Swift rewrite of a cross-platform (Apple/Android/Linux) C++ codebase, and we’ll definitely be needing something like this for the Android integration. I can’t comment in detail because I’m not an Android developer, but I know our existing code uses a lot of NDK stuff as well as JNI.

---

<div class="post-metadata">

**Author:** ![ColemanCDA](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/colemancda/32/2454_2.png) [@ColemanCDA](https://forums.swift.org/u/ColemanCDA)\
**Post date:** [April 13, 2026, 3:00pm UTC](https://forums.swift.org/t/swift-android-native-package/85915/3 "2026-04-13T15:00:47Z")

</div>

If using JNI, I’d recommend [GitHub - PureSwift/Android: Swift library for Android · GitHub](https://github.com/PureSwift/Android) which is just Swift-Java generated code for the Android SDK. If you just use Native Activity and don’t use JNI itself much, then Swift-Java and swift-android-native should be enough. I’d also recommend taking a look at Skip [https://skip.dev](https://skip.dev) for SwiftUI on Android.

---

<div class="post-metadata">

**Author:** ![gabriele](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gabriele/32/27931_2.png) [@gabriele](https://forums.swift.org/u/gabriele)\
**Post date:** [April 17, 2026, 12:29pm UTC](https://forums.swift.org/t/swift-android-native-package/85915/4 "2026-04-17T12:29:49Z")

</div>

When you start using Swift on Android, you inevitably run into a whole set of questions: how to log to logcat, how to get the OS or app version, how to integrate assets, how to obtain the Java VM pointer, how to interact with Android’s main thread, etc.

Having a “reference” library like this is extremely useful. On one hand, it saves you from building your own little homemade setup with JNI and other cool things. But more importantly, it helps you understand what’s possible and find the answers you’re looking for. Just by reading the README here, I’ve already learned things I wish I had known from the start ;-)

Whether it should be part of [swiftlang.org](http://swiftlang.org) or not is open for discussion. But at the very least, we should make sure people know that such a resource exists, just like the examples in swift-android-examples or other key resources, whether they’re official, semi-official or third-party.

---

<div class="post-metadata">

**Author:** ![Joannis\_Orlandos](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joannis_orlandos/32/732_2.png) [@Joannis\_Orlandos](https://forums.swift.org/u/Joannis_Orlandos)\
**Post date:** [April 20, 2026, 7:37am UTC](https://forums.swift.org/t/swift-android-native-package/85915/5 "2026-04-20T07:37:04Z")

</div>

Bit late to the discussion, but I think we should have an official package like this.

We'll want to spend time on reviewing and finetuning API if this specific implementation is to stay. I think, like with SwiftNIO, it's hard to do a major once the ecosystem starts depending on it given it's so core for end users.
