At WWDC 26, Apple unveiled a new Apple Intelligence architecture. Gemini was introduced on the cloud side, while Apple also confirmed that its third-generation Apple Foundation Models were built in collaboration with Google. For a while, this made me think that bringing Apple Intelligence to China might actually become even more difficult.
But things moved faster than expected. In July, Apple Intelligence appeared on the latest list of generative AI services registered with China’s Cyberspace Administration of China (CAC). Then, just two days ago, Apple confirmed that Alibaba’s Qwen would be involved in the Chinese version of Apple Intelligence, and the integration briefly appeared in Apple’s official documentation. Although the document was temporarily taken down the day after going live on August 8, its detailed setup instructions and privacy descriptions had already revealed a fairly complete picture of how the integration would work. This suggests that the official launch of Apple Intelligence in China is now entering its final countdown.
In addition to Alibaba’s Qwen, the registration information also revealed that Baidu will participate deeply as a partner in the AI search and visual search capabilities of the Chinese version of Apple Intelligence. In other words, Apple can not only adjust the underlying models and service providers by region, but also rely on more than one partner within the same market.
As countries and regions continue to strengthen their requirements around privacy, data, and AI services, regional differences are becoming almost unavoidable. China is becoming Apple’s first major example of a new approach: keeping the overall Apple Intelligence product experience and developer interfaces relatively consistent, while selecting different underlying models based on local regulations and ecosystems. This model is likely to appear in more markets over time and could become an important part of Apple Intelligence’s global expansion.
For developers using Apple Intelligence APIs, this is also good news. If Apple can continue to maintain consistency at the API layer, developers should theoretically not need to maintain completely different implementations for different markets. It would also allow apps that rely heavily on Apple Intelligence capabilities to reach a much broader audience.
Gemini and Qwen may not be the two most prominent names in the Agent scenarios I use day to day, but both perform quite well in areas such as world knowledge and language understanding. Given that Apple Intelligence is currently more focused on system-level assistance, and that these partners also bring mature model infrastructure and extensive cloud service experience, Apple’s choices seem quite reasonable.
Apple Intelligence has become one of Apple’s most important entry points into the AI era. Its current capabilities are still somewhat short of my personal expectations, but starting in 2026, it is at least beginning to reach substantially more users around the world. Rather than focusing only on how many tasks it can complete today, I am more interested in seeing how Apple will use WWDC 2027 to bring AI more deeply into its hardware, operating systems, and services ecosystem.
Original
Controlling Orphans in SwiftUI Text: Uncovering the Undocumented avoidsOrphans
SwiftUI’s Text has a default behavior: when the last line of a paragraph contains only a single orphaned word or character, it automatically moves an entire word group from the previous line down to avoid leaving it alone. While this behavior is often helpful, it can also leave excessive whitespace on the preceding line, especially in narrow layouts or mixed Chinese–English text, disrupting the visual balance of the paragraph. UIKit allows developers to disable this behavior through NSParagraphStyle, but SwiftUI exposes no public API for doing so. This article uncovers an undocumented SwiftUI API that has existed for quite some time—avoidsOrphans—allowing developers to regain control over this behavior.
Recent Recommendations
An Even Closer Look at Protocols and Global Actors
As Swift’s concurrency model continues to evolve, some engineering decisions that once felt obvious are beginning to change alongside the language itself. In this article, Matt Massicotte goes beyond the familiar question of whether @MainActor belongs on a protocol or individual methods, using it as a starting point to explore API design in the era of Swift Concurrency. Rather than promoting a so-called “best practice,” Matt emphasizes a broader principle: isolation is a constraint, and constraints should arise from real requirements—not from habit.
Weekly Tuist News #1
As AI agents become increasingly integrated into the development workflow, engineering tools such as Tuist are becoming more important—even for independent developers.
Longtime Tuist community contributor Lee YoungJun has launched a new series, Weekly Tuist News, dedicated to tracking the Tuist ecosystem. Rather than simply summarizing release notes, the series combines community updates with the author’s hands-on experience. In its debut issue, he covers SwifterPM becoming the default dependency restoration method, new controls for target cache invalidation, and Tuist’s auth.md support for coding agents, along with practical observations from real-world usage.
Preview Multiple SwiftUI View States with #Preview(arguments:)
Most SwiftUI components have more than one meaningful state: empty, loading, error, permission-restricted, and so on. During development, we often end up maintaining multiple nearly identical #Preview declarations or placing every state into a single VStack. Xcode 27’s new #Preview(arguments:) API is designed specifically for this scenario, generating multiple independent previews from a collection of state data while allowing each one to be inspected individually in the Canvas.
In the article, Artem Novichkov also shares his approach to organizing previews: arguments should describe business states, not environments. Even as the API evolves, this separation between application state and runtime environment remains a valuable design principle.
Concentric Buttons with OS 27’s SwiftUI APIs
WWDC26 introduced GeometryProxy.concentricCornerRadii, allowing SwiftUI developers to access a container’s concentric corner radius information. However, ButtonBorderShape remains a closed type, making it impossible to create truly custom button border shapes directly. Alexander Weiß demonstrates how to leverage this new API together with onGeometryChange, a custom ViewModifier, and method overloading to build a concentric button solution that feels almost indistinguishable from a native SwiftUI API.
For new APIs such as
GeometryProxy.concentricCornerRadii, it usually takes only a few seconds to understand what they do. The real challenge comes when using them in production, where implementation details and framework limitations quickly surface. Rather than serving as an API introduction, this article explores those practical considerations and the scenarios where the API can be effectively applied.
Swift, AI, and the future of software development
AI has become an indispensable part of many developers’ workflows, but beyond improving productivity, it is also quietly changing the relationship between developers and their code. In this article, Tibor Bödecs candidly reflects on his own experience over the past year: embracing AI for its efficiency while missing the satisfaction of writing code and deeply understanding problems; believing that AI will continue to reshape software development while hoping it remains a tool that augments human thinking rather than replacing it.
Over the past months, I’ve found myself struggling with many of the same questions as Tibor Bödecs. While AI has taken away some of the joy and created a subtle sense of distance between myself, the code, and the products I build, I’ve also been working relentlessly to gain greater control over it—to make it an extension of my own thinking, rather than allowing myself to become an extension of it.
Tools
Gitwyn: A Git Client Designed Around the Xcode Workflow
Although Xcode’s built-in Git support has improved significantly over the past few releases, it still falls short in both usability and functionality for many everyday workflows. Developed by Karthik K, Gitwyn is a native Git client designed around the Xcode workflow. Press ⌘⇧E in any Xcode project to review changes, organize staged files, generate commit messages, and push code—all without leaving Xcode or switching to another Git tool.
One of Gitwyn’s standout features is its ability to generate commit messages locally using on-device Apple Intelligence based on staged changes. No network connection is required, and your source code never leaves your Mac. More importantly, it streamlines the entire flow of reviewing diffs, organizing commits, generating descriptions, and pushing changes, keeping Git operations within the Xcode development context.
VersionedDocC: Bringing Version Management to Swift-DocC
For years, every WWDC I would immediately open Apple’s developer documentation and use the “API Changes” feature to compare different Xcode and SDK releases, tracking newly introduced, modified, and deprecated APIs. Unfortunately, this incredibly useful capability disappeared after the documentation website redesign in 2025. Although the old comparison URLs still exist, they no longer present complete API changes.
Developed by Kyle Ye, VersionedDocC brings this capability back to DocC. It adds a release orchestration layer on top of the existing Swift toolchain, generating stable URLs for different versions, providing a version selector, displaying public API differences between adjacent releases based on symbol graphs, and avoiding repeated builds of historical documentation through immutable caching. The project also includes a SwiftPM plugin, GitHub Action, and GitHub Pages workflow, with support for multi-platform symbol graphs, external modules, and standalone DocC catalogs.
Swift Subprocess 1.0
After a year of iteration, Swift’s official swift-subprocess project released version 1.0 this week. It is a cross-platform subprocess library built on Swift Concurrency, providing a unified way to launch commands, supply input, stream output, and manage process termination and cancellation across macOS, Linux, Windows, Android, and BSD.
It is particularly well suited for Swift CLIs, build systems, server applications, developer tools, and macOS automation. Note that version 1.0 requires Swift 6.2 and is not intended for regular iOS applications. It also deliberately leaves higher-level features such as sandboxing, command authorization, and pseudo-terminals (PTYs) to other layers.
swift-subprocess also fills an important missing piece for building native AI agents in Swift: reliably executing external tools, continuously receiving their output, and properly managing subprocess lifecycles. The model decides what to do, while Subprocess provides a more controllable, observable, and Swifty way to execute those decisions.