A week ago, Microsoft released the public preview of native Windows 11 container support that requires no Docker. Combined with Apple’s recent 1.0 release of its container manager (Apple Container), both major desktop operating systems have now deeply integrated Linux containers as first-class citizens of the system.
This has sparked an interesting debate. Some see it as Linux’s ultimate victory: it never truly won the desktop market, yet it is now everywhere. Others ask the opposite question: when both Windows and macOS can run Linux containers smoothly and with little overhead, is this really a victory for Linux — or the beginning of its complete “commoditization” and “invisibility”?
These two views may seem contradictory, but they both point to the same fact: the role of Linux is changing.
In the past, when we talked about an operating system, we were usually talking about a complete platform — one with its own desktop, applications, development model, user habits, and ecosystem boundaries. Windows is a platform, macOS is a platform, and Linux distributions are, of course, platforms too. Around these platforms, people debated market share, user experience, compatibility, and that “Year of the Linux Desktop” joke that has been recycled for decades.
But containers have changed the structure of the question.
In modern software development, Linux increasingly appears not as “the operating system you are using,” but as “the default runtime environment.” Developers rarely say “I deployed to Linux.” They are far more likely to say “I deployed to Kubernetes,” “I’m running on the cloud,” or “I used a container image.”
This shift will become even more pronounced in the age of AI agents. As agents evolve from simple chat assistants into tools that actually execute tasks, what they need is no longer just a conversational interface, but a lightweight, instantly bootable, fully isolated, and easily disposable execution environment. Containers are a natural fit for this role. And as more and more tasks are carried out through agents, the interface where humans interact directly with the operating system is quietly losing weight — the outcome of the decades-long “desktop war” matters less and less.
Linux, then, is outgrowing its identity as a “platform.” It never won the desktop market share battle, yet it has made its way into the foundation of nearly every modern computing system. It never convinced everyone to switch to Linux, yet it has compelled every platform to support the way Linux runs.
The highest form of victory is not having everyone chant your name, but having everyone depend on you — while barely remembering you’re there. This is a victory where silence speaks louder than words.
Original
Debugging Notes on Two SwiftUI Animation Bugs
Easy-to-use animation has always been one of SwiftUI’s defining features. But the nature of a declarative framework is a double-edged sword: once an animation misbehaves, tracking down the cause is often trickier than in an imperative framework. This post records two SwiftUI animation bugs I ran into over the past two weeks—less a set of solutions than an account of the hunt itself, shared in the hope that the thought process proves useful the next time you face something similar.
Recent Recommendations
Task Property: Reusing Stateful Business Logic for SwiftUI Views
When encapsulating stateful business logic in SwiftUI, what comes to mind first? Putting it in the view? Writing a modifier? Rick Van Voorden offers a less common but distinctly SwiftUI-flavored perspective: using DynamicProperty to extract stateful business logic out of the view, encapsulating it as reusable dynamic properties and letting views return to a purer declarative expression.
The TaskProperty in the project is merely a helper primitive for managing the lifecycle of asynchronous Tasks within custom dynamic properties. It is practical, but not what the README really wants to emphasize. Starting from the question of “how to reuse stateful business logic,” the author gradually demonstrates that DynamicProperty is not just the mechanism behind @State, @Binding, and @Environment—it can also serve as a way to organize and reuse stateful business logic.
Articles about custom
DynamicPropertyare rare, and what distinguishes this one is that it does not stop at API instruction. Instead, it brings the question back to the organization of business logic itself: is there shareable stateful logic mixed into your Views? Could that logic be extracted into custom dynamic properties that sit closer to the SwiftUI lifecycle?
Why My SwiftUI Map Bounced in Heading-Follow Mode?
Emre Degirmenci ran into a classic SwiftUI + MapKit boundary problem in a TCA-based map application: in heading-follow mode, the map kept jittering, the camera jumped, and the tracking state even exited unexpectedly. Interestingly, the same Map component worked fine in another app built with MVVM, which shifted the question from “an implementation mistake” to “whether the state synchronization model is sound.”
The root cause is that MapKit generates high-frequency camera updates in heading-follow mode, while the original implementation wrote those updates back to the TCA Store through two-way binding, creating a loop of “MapKit drives → state updates → state drives MapKit again” that broke the system’s own continuous animation logic. The fix was to leave camera changes under MapKit’s own control and intervene explicitly only when necessary, thereby avoiding conflicts between state and system-driven behavior.
SwiftUI 3D is Flat
In UIKit / AppKit, Core Animation’s CATransformLayer provides a genuinely shared 3D space with depth sorting, so many developers naturally assume that SwiftUI’s rotation3DEffect and projectionEffect are built on a similar 3D scene. But Mihaela Mihaljević Jakić shows through an experiment that SwiftUI has no unified 3D space or depth-buffering mechanism. After 3D transformations, multiple views remain “independent 2D projections,” which leads to typical occlusion errors—for example, a back face covering a front face.
This behavior is not a defect; it looks more like a deliberate design choice in SwiftUI: constraining 3D capabilities to the projection level of individual views rather than introducing a full 3D scene and hierarchy system.
Introducing the Safari MCP server for web developers
In today’s AI coding agent ecosystem, browser automation has long been dominated by the Chrome / Chromium stack as the de facto standard (Playwright, Puppeteer, CDP, etc.), with Safari mostly serving as a compatibility-verification environment.
The Safari MCP server (Safari Technology Preview 247) aims to change that: it exposes Safari’s browser session capabilities to agents, giving them direct access to the DOM, network requests, console logs, screenshots, and page state, so that debugging and analysis can happen in Safari’s real runtime environment. This moves Safari into the main path of the agent toolchain, rather than relying on indirect inference from Chromium or cross-browser switching for verification.
noUI()
As AI agent tools work their way deeper into development and content-production workflows, the role of UI is being reexamined. Starting from a DOS-style command interface, Jordan Morgan poses a question worth pondering: when more and more operations can be performed directly by agents through natural language, does UI still need to exist in the form of an “explicit interface”?
The part of the article that fascinated me most is the interactive terminal interface the author built with JavaScript and CSS. This design is not merely an example or a demo—it embeds the article’s argument itself into an operable UI, drawing readers into the discussion of UI’s changing form precisely through the act of “using an interface.” Here, UI is not just a vehicle of expression; it becomes part of the argument.
What does Activity Monitor measure?
Since AI agents entered everyday development workflows, many developers have had a similar experience: the Mac’s fans spin up more often and memory pressure rises noticeably, yet the CPU / Energy figures shown in Activity Monitor often fail to match that intuition.
Through controlled experiments with powermetrics and a variety of real workloads, Howard Oakley shows that the CPU % in Activity Monitor is closer to a simple sum of each CPU core’s active residency than to a “utilization percentage” in the traditional sense; GPU % is likewise only an approximation of active residency; and Energy Impact mainly reflects a CPU-level power estimate—it neither includes the GPU nor captures how energy consumption changes over time particularly well.
Tools
Quiver: Learning Linear Algebra and Classical Machine Learning with Swift
Wayne Bishop has long maintained Swift Algorithms & Data Structures, an e-book on algorithms and data structures for Swift developers. In its latest fifth edition, the book has extended beyond traditional algorithms and data structures into vectors, matrices, and similarity computation; Quiver pushes that path further into numerical computing, statistics, and classical machine learning.
Quiver is a pure Swift, zero-dependency library for linear algebra, statistics, and classical machine learning. It directly extends the Swift standard library’s Array, emphasizing value semantics, Codable, Sendable, and lightweight on-device execution on Apple platforms. Its goal is not to replace the Python numerical ecosystem, but to give Swift developers an entry point for understanding linear algebra, training small models, and bringing the results back into an App—all in a familiar language. In the later chapters of Swift Algorithms & Data Structures, Wayne uses Quiver as the companion tool for the math and machine-learning fundamentals.
SwipeCell v3: A Native SwiftUI Swipe Menu
At WWDC 2026, SwiftUI’s new swipeActionsContainer() finally let swipe menus step outside of List, serving ScrollView, lazy stacks, and more custom containers. Unfortunately, this capability currently requires system versions corresponding to anyAppleOS 27.
SwipeCell was the first third-party library I wrote six years ago, when I had just entered Swift development. The old versions were naive, but they also accompanied me through the changes in SwiftUI’s swipe interactions over the years. I recently gave it a complete rewrite and released v3: the new API is more SwiftUI-idiomatic, the configuration is more complete, the interaction feel has been re-polished, and macOS support has been added.
SwipeCell v3 is currently published on the v3-beta branch and remains in beta. You are welcome to try it out and report any issues you encounter.