Google has announced that starting September 2026, it will extend Play Store developer verification requirements to all Android app installation methods, fundamentally altering the platform’s open distribution model. This policy requires all developers distributing apps outside Google Play to register with Google, provide government-issued identification, and pay fees. The policy will first be implemented in Brazil, Indonesia, Singapore, and Thailand, before expanding globally in 2027. This represents Android’s most significant departure from its founding principles of an open ecosystem.
While Google emphasizes that the primary reason for implementing this policy is security—malware from internet-sideloaded sources is over 50 times more prevalent than apps on Google Play, and restricting arbitrary app sideloading can effectively combat fraud—Android ecosystem developers have expressed strong resistance to this change, unlike their Apple ecosystem counterparts who have long been accustomed to similar policies. Many developers state they are unwilling to provide identity documents to Google for legitimate privacy, political, or security reasons. For open-source app stores like F-Droid, this policy poses an existential crisis—the community estimates that approximately 85% of apps may be unable to adapt to the new requirements due to technical issues such as signing key conflicts.
From adjusting the AOSP public branch release cycle (Android core development will be entirely concentrated in internal branches, no longer partially developed and merged in real-time on AOSP’s public branch as before), raising AOSP licensing thresholds, strengthening Play Store app review processes, to now implementing developer verification for sideloaded apps, Google’s tightening of Android policies has gone further and further. This reflects both Google’s intent to transform Android into a “walled garden” similar to iOS, and its urgent need to deepen Android’s commercial value in response to unfavorable factors such as Chrome’s potential breakup and AI’s sustained impact on search business.
Perhaps the final differences between Android and iOS are disappearing—this is both a crisis and potentially an opportunity. Android’s widespread adoption benefited from its open nature, and under current circumstances, this may provide a favorable moment for some new platform or ecosystem to emerge. Of course, for commercial entities, open source versus closed source, openness versus closure, are merely means to achieve greater economic value, and they will flexibly switch between these strategies to maximize their interests. Therefore, even if new disruptors emerge, similar cycles will likely repeat in the future. Society develops through such spirals of change.
This Week’s Sponsor
Need to debug HTTPS on your iPhone?
Try Proxyman! The best-in-class macOS that helps you capture/debug HTTP(s) with a few clicks. Support iOS devices and Simulator.
Original
Using MainActor.assumeIsolated to Solve Legacy API Compatibility Issues with Swift 6
While Swift has offered strict concurrency checking for some time, many of Apple’s official APIs have yet to be fully adapted, and this situation may persist for quite a while. As Swift 6 gradually gains adoption, this problem becomes increasingly prominent: developers want to benefit from the concurrency safety guarantees provided by the Swift compiler, while struggling with how to make their code meet compilation requirements. This article will demonstrate the clever use of MainActor.assumeIsolated in specific scenarios through an implementation case with NSTextAttachmentViewProvider.
Recent Recommendations
When should you use an actor?
In Swift’s concurrency model, actor is a new kind of reference type designed to safely protect mutable state and avoid data races. Naturally, many developers are drawn to it once they understand its capabilities. However, as Matt Massicotte points out, actors come with trade-offs—such as enforced asynchronous access and Sendable requirements—and they’re not a one-size-fits-all replacement for GCD. In this article, the author dives deep into the type system and concurrency model to clarify where actors are appropriate, common misuses, and how to make better architectural decisions.
For more community insights, check out this Reddit thread.
SwiftUI is Stifling your App’s Maintainability and Testability
Unlike UIKit, SwiftUI doesn’t prescribe a clear architectural pattern. Its declarative style and reactive data flow challenge many of the traditional assumptions around organizing state and logic. In this article, Matteo Manferdini responds to popular opinions that claim MVVM is outdated or incompatible with SwiftUI. He systematically defends the use of view models, grounded in software design principles like encapsulation, SRP, and SOLID, and highlights the long-term testability and maintainability issues that arise from avoiding them.
Personally, I lean toward using view models when appropriate—but never for the sake of abstraction alone. In SwiftUI, overengineering can lead to unnecessary boilerplate and state complexity. Architecture should serve the app’s needs, not the other way around.
How Large is That File?
If your macOS app displays file or folder sizes, you’ve likely noticed discrepancies with what Finder shows. That’s not necessarily a bug in your code—Finder and system APIs often report different values and omit crucial parts of the file. In this article, Howard Oakley walks through the evolution of macOS file systems—from Classic Mac OS to APFS—to explain why the question “How large is that file?” remains surprisingly complicated.
Howard argues that macOS still relies on legacy logic from 25 years ago when calculating file size. Especially with modern features like extended attributes (xattrs) and resource forks, what you see in Finder can be incomplete or even misleading—posing challenges for developers dealing with backup systems, permissions, or disk usage audits.
Automating Swift Binary Releases Using GitHub Actions
When hosting code on GitHub, developers often want to provide ready-to-use binaries—sometimes instead of, or in addition to, source code. This process can be fully automated using GitHub Actions. In this guide, Tiago Henriques demonstrates how he uses GitHub CI/CD to automatically build and publish a macOS binary for his Swift command-line tool, SwiftDummyGen. It’s a practical reference for developers looking to streamline their release process.
Swift Default Value in String Interpolations
Optional values are a powerful feature in Swift, but they’ve always been awkward to deal with in string interpolation. Until now, developers had to use ?? (with type-matching constraints) or String(describing:) (which outputs "nil"). Swift 6.2 introduces a cleaner solution: a default: parameter in string interpolation, allowing developers to define fallback text for optional values.
In this article, Keith Harrison explains how this new feature works, along with a caveat—LocalizedStringKey doesn’t support it yet.
macOS Accessibility
Compared to iOS, macOS’s multi-window architecture introduces additional challenges for developers working on accessibility features—especially for third-party input methods. In this article, zonble shares his journey in implementing VoiceOver support for a macOS input method: from resolving focus-related issues that caused the candidate window to disappear, to using the NSAccessibility notification system to manually control VoiceOver behavior, and finally digging into system SQLite databases to retrieve phonetic annotations, radicals, and example words for Chinese characters.
The article blends hands-on implementation with low-level exploration, offering insights into how macOS accessibility truly works—while also shedding light on some of the “black box” behavior in how Apple handles spoken feedback for input methods.
By reverse-engineering several system SQLite databases, the author uncovers how macOS’s built-in input method provides phonetic descriptions and structural explanations for characters. Beyond being a practical trick, this discovery offers valuable inspiration for more advanced accessibility implementations.
Tools
OpenAttributeGraph Documentation
At the heart of SwiftUI lies a lesser-known but critical component: AttributeGraph. It powers dependency tracking and enables efficient, incremental UI updates. But because it’s private, developers have had limited access to its inner workings—until now.
The OpenAttributeGraph project, part of the OpenSwiftUI initiative, recently published comprehensive documentation explaining its open-source implementation. This helps developers better understand how SwiftUI manages state dependencies and serves as a foundation for both contributing to OpenSwiftUI and optimizing their own apps.
Subprocess
Swift officially introduces for the aging Process/NSTask APIs: Subprocess 0.1, a new library designed for cross-platform process management. Built with Swift’s concurrency model in mind, Subprocess supports native async/await, type-safe input/output, and consistent behavior across macOS, Linux, and Windows.
Whether you’re building CLI tools, server-side apps, or need to invoke system commands in a macOS app, Subprocess offers a clean and ergonomic interface:
let result = try await run(.name("ls"), output: .string(limit: 4096))
print(result.standardOutput ?? "")Currently requires Swift 6.1+ and does not yet support iOS. As part of the Swift Foundation project, Subprocess reflects a broader effort to modernize Swift’s core libraries.