Swift Android Workgroup Meeting Notes - 3 December 2025

Platform Android
1

Meeting Notes — Swift on Android Working Group

Date: December 3rd, 2025
Attendees: @Joannis_Orlandos , @Obbut , @Finagolfin , @marcprux , @etcwilde , @mishal_shah , @gabriele , @andriydruk , @madsodgaard
Note-takers: Robbert & Joannis (merged)

Hey folks, I've been lacking on posting our meeting notes. I'll try to backpost some older ones, but here's our most recent discussion.

The next meeting is tomorrow (17 December) at 6PM CET/9AM PST.
As always, our meetings are open to join - just send a DM for the link!

Topics

  1. Android NDK LTS transition
  2. CI and Android Emulator testing
  3. LLVM / LLDB state and debugging
  4. IDE support
  5. Lower Android API level support
  6. Swift 6.3 snapshots

1. Android NDK LTS (NDK 30)

Discussion

  • A new NDK LTS (30) is expected to be the next release.
  • No guarantees or release schedule from Google yet.
  • Key concern: C++ runtimes on Android are not ABI-stable across NDK versions.
  • Swift runtime must match the C++ runtime users link against.

Question raised:

  • What happens if Google releases a new NDK LTS mid–Swift SDK release?
    • Risk of runtime crashes or undefined behavior for users on mismatched NDKs.
    • Possible approaches discussed:
      • Separate Swift SDKs per NDK LTS (similar to Linux distro-specific SDKs).
    • SwiftPM assistance:
      • Detect NDK mismatches.
      • Warn users about incompatibilities.
  • Marc highlighted availability annotations require newer NDKs.
  • Acknowledge that NDK <-> Swift SDK alignment is a hard requirement due to (C++ runtime) ABI concerns.
  • Treat NDK LTS versions as first-class compatibility boundaries.

Current State

  • NDK 27 does not support availability annotations, but is latest LTS
  • NDK 28 / 29 Work correctly with availability annotations, but not LTS
  • Differences from 27 appear small (≈4 validation suite failures, mostly header changes).
  • Android Workgroup has thus far committed to support LTS NDKs

2. More Testing with the Android Emulator

Emulators Considered

  • Cuttlefish (new)
  • Goldfish (official Android SDK emulator)

CI Constraints

  • Linux CI:
    • Likely lacks nested virtualization required for performant QEMU-based emulation.
  • macOS CI:
    • Runs on bare metal (similar to EC2 Mac instances).
    • Supports virtualization.

Discussion

  • Linux Dockerfiles would need nested virtualization to support Android emulation on arm64.
    • Mishal prefers proof that Linux CI is insufficient before moving to macOS.
  • Marc’s Skip Android GitHub Action:
    • Already supports launching emulators on macOS and Linux.
    • Needs upstreaming into swiftlang workflows.
    • Emulator-based tests currently require workarounds:
      • Manual copying of resource files.
      • Workarounds needed when combining Swift Testing and XCTest.
        • Special flags + copying resource files manually
  • Free-tier Github CI runners appear sufficient based on Skip’s usage.

3. LLVM / LLDB and Debugging

  • Gabriele: swiftlang/llvm is behind upstream LLVM.
  • Swiftlang/LLVM branches from upstream yearly (around July), then adapted for Swift:
    • Necessary because upstream LLVM frequently breaks Swift.

Debugging

  • Swift debugging issues should:

    1. Be filed on swiftlang/llvm.
    2. Be fixed upstream in LLVM where possible.

  • Upstream LLDB works, but:

    • Swift symbol mangling issues remain.
    • Google maintains its own LLVM/LLDB forks.

  • Android’s LLDB server should be usable.

    • Connecting side (client) needs a Swift-aware LLDB client.

  • Current state:

    • LLDB-Client for Swift on Android has an unstable experience
    • Deadlocks and assertion failures common.
    • Many fixes exist upstream but are not yet merged into swiftlang/llvm

5. IDE Support

  • JetBrains:
    • Has closed-source Swift support used internally (Kotlin Multiplatform).
    • Open to a shared core, but:
      • Large effort.
      • Requires extracting closed-source code.
  • Android Studio:
    • Built by Google, not JetBrains.
    • Very good for Android development, but lacks in Swift
    • Poor experience today:
      • Suggests (incorrect) third-party Swift plugins, KMP
  • VS Code:
    • Quite promising short-term option.
    • Open source.
    • Existing Swift plugin.
    • Easier LLDB experimentation.
    • Lacks a (polished) Android experience

6. Lower Android API Level Support

  • No decision yet.
  • Mads interested in supporting API level 24.
  • Blockers:
    • Remaining posix_spawn methods need fixing.
    • Mads is working on a PR

7. Swift 6.3 Snapshots

  • Initial Swift 6.3 snapshot published.
  • Android was temporarily skipped in late-November builds due to failing tests.
  • Thanksgiving rush caused exceptions:
    • Two platforms (including Android) skipped so toolchains could still ship.
    • CI was passing again around the meeting time.
3 Likes
2

Two small updates:

2 Likes