On October 24, the Swift Android Workgroup released the nightly preview version of the Swift SDK for Android. This marks the SDK’s transition from early internal testing to official support, representing a significant step forward in Swift’s cross-platform journey.
From a technical perspective, Swift for Android employs a cross-compilation approach built on three core components: the host toolchain, the Swift SDK for Android, and Android NDK 27d. Developers can compile Swift code into Android shared libraries and achieve interoperability with Java/Kotlin through JNI. In other words, Swift code can now run natively on the Android platform.
Beyond toolchain maturity, encouraging progress has emerged at the ecosystem level. According to Joannis Orlandos in the official announcement, over 25% of packages on the Swift Package Index have already completed Android adaptation. While this proportion may not seem large, it demonstrates the community’s positive response to cross-platform development. An increasing number of developers are proactively building Android compatibility into their third-party libraries.
Of course, questions remain: among the remaining 75% of packages, how many simply haven’t been adapted yet, and how many are temporarily incompatible due to deep integration with Apple’s ecosystem (such as dependencies on UIKit, AppKit, Core Data, and similar frameworks)? This will determine the ceiling for Swift in the Android ecosystem. For logic layers, networking layers, or data model layers, adaptation is relatively straightforward; however, cross-platform challenges remain considerable for UI layers and system integration layers.
As Bruno Valente Pimentel’s analysis reveals, the pathways for using Swift on Android have become relatively clear—whether through cross-compilation with the official SDK, transpilation from SwiftUI to Jetpack Compose via Skip.tools, or other integration approaches, developers can find entry points suited to their needs. While there’s still distance to cover before achieving an “out-of-the-box” development experience, the ecosystem’s foundational framework has taken shape, and Swift’s potential on the Android platform is no longer merely conceptual.
Notably, Marc Prud’hommeaux, founder of Skip, is also a core member of the Swift Android Workgroup. This multi-directional collaboration between official bodies, commercial forces, and the open-source community may be a key indicator of Swift’s maturing ecosystem. Meanwhile, the OpenSwiftUI project has also begun porting to the Android platform, offering an alternative open-source path for cross-platform UI development. Looking ahead, enhanced toolchains, migration services, education and training, and third-party libraries optimized for cross-platform performance all represent potential growth areas in this direction.
While the Swift Android SDK release remains in its nightly phase, it has already opened a new window for cross-platform development. For Swift developers, this represents not only new possibilities but also an invitation—to not merely witness Swift’s cross-platform growth, but to actively participate and become builders of the ecosystem.
Recent Recommendations
Replacing Combine’s subjects with AsyncStream in Swift
AsyncStream is inherently a one-to-one structure — when multiple for await loops consume the same stream, they compete for values instead of each receiving the full sequence. This differs fundamentally from Combine’s Subjects, which naturally broadcast to multiple subscribers. Natascha Fadeeva demonstrates how to emulate Combine-style multicasting by creating an independent AsyncStream instance for each subscriber while maintaining a unified cache of Continuations for broadcasting. This solution not only highlights the flexibility of Swift Concurrency but also reveals a deeper philosophical difference between the two asynchronous models.
The AsyncBroadcastSequence proposal in Swift Async Algorithms aims to standardize this capability with built-in features like history caching, backpressure control, and configurable lifecycle management. Meanwhile, AsyncCombine’s CurrentValueRelay takes a similar approach, restoring familiar APIs such as
sink,assign, andstore(in:)— ready to use out of the box.
Is SwiftData incompatible with MVVM?
Strictly speaking, this article isn’t about MVVM itself — it explores whether, and how, SwiftData operations (those involving ModelContext) can be moved from the View layer to the ViewModel layer. Matteo Manferdini focuses on the integration boundary between SwiftUI and SwiftData rather than architectural dogma. By dissecting how the @Query macro expands and how it interacts with the DynamicProperty protocol, the article clarifies several common misconceptions and demonstrates how to inject ModelContext safely into the SwiftUI lifecycle using a custom property wrapper. The takeaway: this separation is not only possible but also keeps the codebase cleaner and more maintainable.
AI Agents Comparison from an iOS Developer’s Perspective
In AI-assisted programming, the same model can perform drastically differently across tools. Tomasz Lizer benchmarked seven AI coding agents against a real iOS login bug, using identical prompts to compare speed, accuracy, and regression risk. The results were surprising: even with the same underlying model (Claude Sonnet 4.5), GitHub Copilot performed worst, while Claude Code and Cursor produced the best results.
This shows that context management and prompt engineering implementations often matter more than the foundation model itself. From an iOS developer’s viewpoint, the author concludes that Claude Code currently offers the most balanced and reliable experience — while Copilot’s competitive edge has noticeably faded.
Crafting Interactive Tiles in SwiftUI
This tutorial demonstrates how to build an interactive gradient tile grid in SwiftUI — as users touch the screen, nearby tiles round their corners dynamically while distant ones remain square. Uladzislau Volchyk constructs the effect step by step: from the basic grid to gesture handling, gradient coloring, and finally adding a subtle grain texture using a Metal shader. The project makes heavy use of recently introduced APIs like MeshGradient, visualEffect, and colorEffect, achieving professional-grade visuals with minimal code.
It’s hard to imagine how much boilerplate would be needed to reproduce the same effect without these new APIs. SwiftUI continues to evolve rapidly — even if developers can’t master every new feature, staying up to date with each release’s key additions can dramatically boost productivity.
Adding dSYMs from a Closed-Source Swift SDK to an App
dSYMs (Debug Symbol Files) serve as a “translation guide” that maps compiled machine code back to source symbols. Closed-source SDKs often omit them, making production crash reports impossible to symbolize — you see memory addresses instead of readable function names and line numbers. Daniel Saidi outlines a practical fix: SDK authors should build their XCFrameworks with DEBUG_INFORMATION_FORMAT=dwarf-with-dsym and distribute the dSYM alongside each release. App developers can then manually place the SDK’s dSYM into the .xcarchive/dSYMs folder before uploading to App Store Connect.
Uploading Asset Resources in the Background
Apps that sync large photo libraries to the cloud often share the same pain point: uploads only work while the app stays in the foreground. Starting with iOS 26.1, PhotoKit introduces the PHBackgroundResourceUploadExtension protocol, which finally lifts this limitation — allowing the system to continue uploading assets in the background, even when users switch apps or lock their devices. The API also manages network connectivity, power usage, and scheduling automatically, greatly improving reliability and user experience.
Unfortunately,
PHBackgroundResourceUploadExtensionisn’t a general-purpose background upload interface — it’s a system-managed mechanism restricted to PhotoKit resources (though targets can be any server). Hopefully, Apple will extend similar capabilities to SwiftData or Core Data’s CloudKit syncing, enabling seamless background data synchronization. That would finally free users from having to “keep the app open and wait for sync to finish” on new devices.
Concurrency Step-by-Step: Conforming to Protocols
With Swift 6.2, Apple introduces the Approachable Concurrency model — a collection of compiler options and default behaviors such as InferIsolatedConformances and NonisolatedNonsendingByDefault. Different configurations directly affect how isolation semantics apply to protocol conformances. In this deep dive, Matt Massicotte dissects how these options influence concurrency behavior and walks through various ways to resolve “isolation mismatch” issues when adding protocol conformances to actor-isolated types.
He also introduces his preferred approach, Non-Sendable First Design — explicitly marking types as nonisolated to ensure their instances remain “trapped” within the isolation domain where they were created, leading to clearer concurrency boundaries and safer designs.
Android Doesn’t Deserve Swift — But We Did It Anyway
At NSSpain, Pierluigi Cifani shared how his small team used the Skip toolchain to bring pure Swift development to Android. Using their e-commerce app Nuras as a case study, they managed to port complex features — including Bluetooth communication — within weeks, while sharing complete SwiftUI components across platforms. The result: their Android release velocity doubled.
Pierluigi admitted the process was tough but ultimately transformative. He closed with a call to the community: “Swift can — and should — be the way we build cross-platform apps. If we don’t succeed, inferior cross-platform solutions will be forced upon us.”
Tools
PureSQL – Type-Safe Code Generation from Pure SQL
If you believe that “SQL is already powerful enough — it just lacks type safety”, Wes Wickwire’s PureSQL is the tool you’ve been waiting for. Inspired by tools like sqlc (Go) and sqldelight (Android), PureSQL brings “type-safe code generation from raw SQL” to the Swift ecosystem.
Built around a dedicated compiler (available as an SPM plugin or CLI tool), PureSQL parses and validates your SQL files at compile time, automatically generating type-safe Swift data-access code. You get the precision and performance of native SQL with the compile-time safety and IDE support of modern Swift. For developers seeking full control over SQL without sacrificing type safety, PureSQL strikes an elegant balance.