WWDC 2026 is just 20 days away. Every year around this time, I usually see many developers sharing their WWDC wishlists, jotting down their predictions and expectations. But this year, at least by the time I was putting together this issue, there seemed to be noticeably fewer such posts than around the same time last year. Has developers’ anticipation for WWDC waned, or are more of us simply adopting the mindset of “keeping expectations low to be pleasantly surprised”?
Perhaps the issue isn’t a lack of anticipation, but rather that the traditional format of a wishlist is no longer quite sufficient. In the past, we looked forward to a specific API, framework, or feature. Now, however, as software development rapidly pivots toward the AI Agent era, our expectations themselves have become much harder to clearly articulate.
A year ago, few developers could have predicted that software development would enter the AI Agent era so swiftly. Even if we hoped for better AI support in Xcode, prior to the release of Xcode 26.3, we probably wouldn’t have imagined that Apple would provide such seamless Agent integration right within the IDE. Applications and APIs are no longer just interfaces for consumers or developers; they can now become objects for AI Agents to understand, invoke, and orchestrate. AI is no longer merely a development tool; it acts as a new participant, deeply involved in the very construction and utilization of software services.
I believe this perfectly captures why many developers feel a mix of anticipation and uncertainty heading into WWDC 2026. We hope to see updated features, more stable frameworks, and a clearer platform direction. Yet, at the same time, we are pondering how to maintain our uniqueness and indispensability as developers in this new paradigm, and how to build better services alongside AI.
Let’s wait and see just how many changes WWDC 2026 will bring.
BTW: Last week, I had the incredible honor of being featured in the recently announced Apple Developer Community Spotlight. As a content creator, receiving this recognition is both an encouragement and a driving force for me: a reminder to keep writing earnestly and continue delivering valuable content to all of you. A heartfelt thank you to everyone who has read, shared feedback, and supported me along the way.
Recent Recommendations
URLSession to Electrons: How Networking works on iOS
Most iOS developers know that a URLSessionDataTask does not actually begin until you call resume(). But what really happens after that? In this long-form article, Jacob Bartlett follows an ordinary network request all the way down the stack — from URLSession, CFNetwork, TCP/IP, and Wi-Fi to radio signals, antennas, and electromagnetic waves. Along the way, he connects concepts developers often use but rarely fully understand, including HTTP, DNS, TCP, QUIC, and IPv6, while also exploring Network.framework, the XNU TCP stack, Wi-Fi frame structures, and cellular scheduling mechanisms inside iOS.
A simple
resume()call may sit atop decades of protocol and infrastructure evolution. Modern software exists on layers upon layers of abstraction, and most of the time, we are simply fortunate enough to live in an era where those abstractions remain stable.
When AI and Xcode Fight: I Built a Tool to Keep the Peace
Xcode’s build system was never truly designed for parallel development. When multiple tasks build simultaneously, DerivedData, ModuleCache, SwiftPM caches, and even Simulators can collide with one another — and this problem becomes dramatically worse in multi-agent AI workflows. In this article, Maples7 introduces his solution: VibeChard. Built on Git Worktree, it creates isolated build sandboxes for each AI agent while separating DerivedData, ModuleCache, SwiftPM caches, and Simulator environments. Most interestingly, it does not require developers to modify build commands directly. Instead, it transparently intercepts xcodebuild via a PATH shim, allowing the entire toolchain — including Tuist and Fastlane — to operate inside isolated environments automatically.
More than just a utility, this project highlights a deeper issue emerging in the age of AI coding: as code generation speeds accelerate dramatically, traditional development toolchains must also evolve their isolation and infrastructure capabilities.
Has Swift Really Become a Mess? Some Honest Thoughts After Years of Using It
Swift becoming increasingly complex is an undeniable reality. But does that mean Swift has become a bad language? In this article, 迷途酱 revisits Swift’s “expansion” through the lens of real-world language evolution constraints. The author argues that much of the complexity people complain about comes from Swift simultaneously serving multiple roles: an application language, a systems language, a DSL host, and even a server-side language. Concurrency safety and ownership models themselves also belong to the category of “hard complexity” inherent to computer science.
The article discusses rapidly growing concepts such as Sendable, actor isolation, borrowing, and ~Copyable, while also candidly criticizing Swift’s concurrency keywords, increasingly dense generics syntax, and the “magic” behind SwiftUI. One particularly thought-provoking point is the idea that Swift is effectively “multiple layers of a language.” Most developers building everyday apps do not actually need to carry the full weight of the language’s complexity, yet WWDC sessions and official documentation often present all of these features side by side.
Writing shell scripts for Xcode Cloud
Xcode Cloud is easy to get started with, but in real-world projects many automation workflows still rely on shell scripts. Using “automatically creating a GitHub Release after archiving” as an example, Amy Delves demonstrates how to leverage Xcode Cloud environment variables to determine whether a build originated from the main branch, extract version and build numbers from an archive, and create releases via the GitHub API.
The example itself is fairly straightforward, but it nicely illustrates that Xcode Cloud is more than just a “click a few buttons to run tests” service. With environment variables, script hooks, and external APIs, it can support much richer release automation workflows.
Why CloudKit is amazing and why we’re leaving it
This is a surprisingly candid and nuanced retrospective on migrating away from CloudKit. Rather than criticizing it outright, César Pinto Castillo first acknowledges that for small teams, CloudKit offers an almost unbelievable combination of features: free sync, automatic authentication, end-to-end encryption, serverless infrastructure, and built-in sharing across Apple platforms.
But as their product evolved, CloudKit’s limitations became increasingly apparent: limited server-side observability, manual schema deployment steps, long-standing synchronization edge cases across Apple platforms, heavy reliance on iCloud accounts, and most importantly, the inability to truly expand toward the Web and cross-platform ecosystems. Eventually, César’s team migrated to a Supabase/Postgres-based synchronization architecture.
CloudKit remains one of the strongest moats in Apple’s ecosystem. But as apps grow more complex, datasets larger, and user expectations around synchronization latency higher, its boundaries are becoming increasingly visible. In pursuing “invisible sync,” Apple may also need to seriously rethink this infrastructure layer that has seen relatively little evolution over the years.
Training an LLM in Swift, Part 1: Taking matrix multiplication from Gflop/s to Tflop/s
Training an LLM in Swift sounds somewhat absurd at first glance, but Matt Gallagher delivers an impressively deep performance exploration. Starting from handwritten matrix multiplication — without relying on existing ML frameworks — he gradually optimizes a basic Swift implementation from 2.8 Gflop/s to 1.1 Tflop/s. Through a complete optimization journey, the article reveals what high-performance Swift actually looks like in practice: Swift can absolutely be fast, but as you approach hardware limits, you inevitably enter a world of UnsafeBufferPointer, SIMD, concurrent slicing, memory layout tuning, and GPU tile optimization.
The article is not advocating for handwritten ML kernels in production. On the contrary, Matt repeatedly emphasizes that developers should prefer mature frameworks such as Accelerate, BNNS, Core ML, and MPSGraph whenever possible.
Once Swift is pushed close to C-level performance, can it still preserve the readability and elegance that originally made Swift appealing? This article offers a remarkably concrete — and honest — answer.
Swift Is Great for Apps, Not for Training ML Models
While the previous article demonstrated how handwritten Swift matrix multiplication could be optimized all the way to Tflop/s territory, this article pours some cold water on the idea from a different angle. Mohammad Azam argues that Swift and Core ML are excellent for deploying machine learning models, but poorly suited for modern machine learning training workflows. He points out that the majority of effort in ML development is rarely spent on training itself, but rather on data cleaning, feature engineering, normalization, pipeline composition, and iterative experimentation — areas where the Python ecosystem remains vastly more mature and ergonomic.
Swift is not incapable of reaching into the lower layers of machine learning. But once the problem shifts from “performance” to “data science workflows,” the differences in language priorities and ecosystem maturity quickly become obvious. It also highlights one of Swift’s current dilemmas: while the language itself is capable of expanding into many domains, its surrounding ecosystem still struggles to provide equally smooth experiences outside of application development.
Tools
Swift MarkdownEngine
MarkdownEngine is a native editor engine extracted and open-sourced by the team behind Nodes, their macOS Markdown application. It is neither an HTML renderer nor a WebView wrapper. Instead, it is a source-style Markdown editor built on TextKit 2 and AppKit, then bridged into SwiftUI. The editor preserves plain Markdown text while providing live styling similar to Obsidian Live Preview or iA Writer. Features include wiki links, image embedding, syntax highlighting, LaTeX, task lists, Writing Tools support, and suppression of spell-checking for code, formulas, and links.
TextKit 2 documentation remains sparse and full of behavioral quirks. By open-sourcing an editor stack already used in Nodes.app, this project offers valuable reference material for developers building writing, note-taking, or knowledge-management apps on macOS.
Harness: Let AI Test Your App Like a Real User
Harness is a native macOS developer tool created by Alan Wizemann that can drive iOS Simulators, macOS apps, and Web apps. You describe a goal in natural language, choose a persona, and Harness allows an LLM agent to observe the UI through screenshots, perform clicks and text input, then generate replayable execution paths, success or failure reports, and categorized UX friction logs. Rather than simply letting AI “operate an app,” it feels more like a developer-focused user testing workstation that combines AI agents, screenshots, event logs, credential redaction, replay systems, and friction analysis.
The project is still in alpha. Web support currently depends on WebKit, and Set-of-Mark targeting for iOS/macOS is still planned for the future. As a result, it is better suited for exploring ambiguous UX issues and hidden usability dead-ends than replacing deterministic regression testing. Still, from its use of Swift 6, SwiftUI, SwiftData, actor-based execution flows, JSONL run logs, and cross-provider abstractions for Anthropic/OpenAI/Gemini models, it is already far beyond a simple demo — and a fascinating example of an AI-native developer tool.
Traditional UI testing excels at validating predefined flows created by developers. Harness is attempting to answer a different question: can a real user, with a specific goal and persona, actually complete a task successfully inside your interface?