Just two months after announcing that the Fuse edition would be free for indie developers, Skip Tools made another bold move: making its core engine, skipstone, completely free and open source. This decision marks a fundamental shift in Skip’s business model—from selling a product to relying on services and community sponsorships. The change reflects both the pressure of an underperforming commercial strategy and the team’s willingness to take risks. In an era dominated by AI and a largely entrenched developer tooling landscape, Skip chose to actively pivot rather than stand still.
Many technically strong and distinctive products fail to gain traction not because of their technology, but because of a lack of trust. As Skip itself points out, companies fear a “rug pull”: if the vendor shuts down or gets acquired, the products and tech stacks built on top of that tool may need to be rebuilt from scratch. By going open source, Skip aims to eliminate this trust barrier—placing itself on equal footing with other cross-platform tools, while also activating the community to help grow the ecosystem.
That said, while the community has largely praised Skip’s open-source decision, concerns remain. After giving up license keys as a stable revenue stream, can sponsorship alone sustain long-term development? History shows that while some open-source business models succeed, many do not. This concern is hardly unfounded. At the time of writing this issue—just days after the open-source announcement—discussion on social media was lively, yet Skip had only a handful of individual sponsors on GitHub. The gap between enthusiastic conversation and real financial support appears wider than expected. This may also explain why Skip ultimately chose to go open source: if developers cannot be convinced to pay for the tool, at least they might be persuaded to use it.
An interesting shift has emerged amid this mix of optimism and anxiety. The conversation has quietly moved from “Why pay for Skip instead of using free KMP?” to “Do you prefer writing Swift or Kotlin?” This change is significant. It suggests that Skip has successfully reframed the competition—from a debate over business models to one centered on language ecosystems. In doing so, the competitive arena expands from a single company to the entire Swift community. In this language-level contest, Skip has—perhaps intentionally, perhaps not—repositioned itself from a central protagonist to underlying infrastructure.
From the beginning, Skip was driven by the belief that there was a real commercial opportunity with sufficient returns. Without such expectations, it is unlikely that either the company or the community alone could have pushed Swift forward on non-Apple platforms so quickly. This path closely resembles how The Browser Company aggressively promoted Swift on Windows in pursuit of building the Arc browser.
As a Swift developer, I sincerely hope this pivot delivers the results Skip is aiming for. Open source is both an experiment in trust and an investment in the ecosystem. If you, too, hope to see Swift thrive beyond iOS, consider starting by becoming a individual sponsor ($10/month). This is not just support for Skip—it is a vote for the broader Swift cross-platform ecosystem. How far open-source Skip can go ultimately depends on how many people are willing to move from being observers to active participants.
Original
isolated(any) and #isolation: Letting Swift Closures Automatically Inherit Isolation
Swift 6 introduces many new features and keywords to its concurrency model. While some of them may rarely be used in day-to-day development, lacking an understanding of these concepts can leave you stuck in specific scenarios—even with AI assistance. This article walks through a real concurrency issue encountered during development and testing, demonstrating how @isolated(any) and the #isolation macro can be used to let functions inherit isolation automatically, allowing the compiler to infer the execution context of closures.
Recent Recommendations
A Deep Dive into SwiftData migrations
As apps evolve, changes to data models are almost inevitable, and performing safe data migrations remains a significant challenge for many developers. In this article, Donny Wals provides a comprehensive overview of SwiftData’s migration system, covering everything from basic versioning to complex custom migration strategies. He also shares several particularly valuable recommendations: even a V1 model should be wrapped in a VersionedSchema to prepare for future changes; new schema versions should be introduced only between App Store release cycles, rather than being modified repeatedly during development; and for lightweight migrations, even when SwiftData can handle them automatically, it is still advisable to explicitly define them in a SchemaMigrationPlan to make intentions clearer and easier to test.
One of the highlights of the article is its detailed explanation of when to use willMigrate versus didMigrate in MigrationStage.custom, along with a “bridge version” strategy for handling complex refactors, such as splitting entities.
Why MVVM-C with Coordinators does Scale -> A real-world SwiftUI perspective
Despite the title referencing “MVVM-C,” this is not simply an article defending a specific architectural pattern. Bruno Valente Pimentel redefines what “scalability” really means—arguing that it should not be measured by the number of screens or files, but by how well an architecture supports efficient collaboration and independent feature evolution. As the author puts it, “architecture is not about patterns, but about reducing fear”—the fear of changing code, collaborating with others, and evolving features.
No matter which architecture you prefer, when building SwiftUI apps you should seriously ask yourself: are we leveraging SwiftUI’s strengths, or trying to bend SwiftUI into the shape of UIKit as we know it?
TCA (Composable Architecture): The Honest Review
Following Bruno’s reevaluation of MVVM-C, Chandra Welim offers an objective assessment of another highly debated architecture: TCA. The article summarizes five key strengths of TCA (predictable state management, excellent testability, time-travel debugging, composability, and strong type safety) alongside five major challenges (learning curve, boilerplate, team adoption, overengineering for simple apps, and third-party dependencies). It also provides pragmatic guidance: TCA is a powerful tool, but it is not suitable for every scenario. For simple MVPs or teams without a functional programming background, traditional MVVM may be a more practical choice; for large-scale projects with complex state and a need for time-travel debugging, TCA can offer unmatched control. The core takeaway: TCA is worth it when you truly need it—but most apps don’t.
There is no silver bullet in architecture—only trade-offs in a specific context.
Improving the usability of C libraries in Swift
Although Swift is designed to interoperate with C, calling C APIs directly often results in a poor developer experience—exposing raw pointers, requiring manual memory management, and using naming conventions that feel foreign to Swift. To achieve a more “native” experience, developers often have to write and maintain cumbersome wrapper layers. In this article, Doug Gregor explains how API Notes and Clang Attributes can be used to “guide” the Swift compiler into generating Swift-friendly interfaces without modifying the underlying C library implementation.
The significance of this improvement lies in shifting the cost of “wrapping C libraries” from the logic layer (writing Swift glue code) to the declaration layer (authoring API Notes or adding annotations to headers). This is particularly important for the adoption of Embedded Swift, where existing C libraries are fundamental to the ecosystem. As the toolchain matures, developers may eventually need only a few annotations to use C libraries in Swift as if they were native. The article also provides regex-based automation scripts for generating API Notes in bulk from structured C headers.
Introduction to Building Swift for Yocto
For most iOS developers, Yocto may be unfamiliar, but it is the de facto standard in the embedded Linux world—offering precise control over every component included in a system. As Embedded Swift advances, integrating Swift into the Yocto ecosystem becomes a key challenge. Jesse L. Zamora demonstrates how to build a Swift runtime for Yocto using the recently revived meta-swift layer. Using a Raspberry Pi Zero 2 as an example, the article walks through the entire workflow, from setting up a Docker environment and building Yocto, to flashing the image and running Swift code on the device.
It is worth noting that a full build can take several hours and requires some familiarity with Yocto’s build system. However, the provided meta-swift-examples repository includes a Dockerized environment and one-click scripts that significantly lower the barrier to entry.
meta-swift is the Yocto layer for Swift. It had long been stalled at Swift 5.7, but thanks to community efforts, it now supports Swift 6.1.3.
TIL how to auto-move Xcode DEBUG builds to Applications
When developing apps that include App Intents, you may run into this issue: App Intents only appear in Shortcuts.app when the app is located in the /Applications directory. Since DEBUG builds are placed in DerivedData by default, this makes testing Shortcuts integration difficult. Carlo Zottmann previously relied on complex post-build scripts to move apps around, but in this article he shares a more “native” solution—using just three lines of .xcconfig to have Xcode automatically deploy build artifacts to a specified directory and clean them up properly when builds are removed.
This trick is useful not only for testing App Intents, but for any scenario where DEBUG builds need to live in a specific location.
Visualise anything with SwiftUI Charts
If you needed to build a custom, animated, and interactive circular stress indicator in SwiftUI, how would you approach it—using Shape, or Canvas? In this article, Kyryl Horbushko presents a creative solution by leveraging Swift Charts’ SectorMark to implement the component elegantly and efficiently.
Kyryl’s approach challenges the common assumption that Swift Charts are only suitable for traditional data visualization. For developers building complex dashboards in health or finance apps, this represents a highly instructive “dimensionality reduction” strategy—solving custom UI problems with a data visualization framework, while benefiting from built-in animations and interaction support.
Tools
Commander: A Focused Yet Flexible AI Coding Experience
I enjoy using CLI tools on macOS (such as Claude Code and Codex), but the visual experience of native terminal apps leaves much to be desired, so I usually rely on VS Code extensions to improve the workflow. However, one design choice in VS Code has consistently bothered me: even when the Claude Code panel is maximized, any file modifications made by the AI will still open new editor tabs or windows, disrupting the existing interaction flow.
Marcin Krzyżanowski’s macOS-native app Commander offers a compelling alternative. It provides a more polished interface than the terminal while preserving my “flow”—files are opened only when needed, and system-default apps can be used for viewing. Commander currently supports Claude Code and Codex, includes Git worktrees and code diff features, and is completely free. It occupies a sweet spot between the “focus” of the terminal and the “flexibility” of VS Code.
Oh My Agents: Centrally Managing Configuration for All AI Coding Assistants
With the rise of AI coding assistants like Claude Code, Cursor, Codex, and Windsurf, developers are facing a new challenge: managing scattered prompts, skills, and rules across multiple projects. Each agent has its own configuration format (CLAUDE.md, CURSOR.md, etc.), and manual copying is both inefficient and error-prone. Oh My Agents, created by Wei Wang (onevcat), addresses this problem directly.
Core features:
- Centralized management of all AI agent configurations
- Rule-based distribution with one-click syncing across projects
- Bidirectional sync, allowing project-level improvements to flow back into the central repository
- Change previews to prevent accidental overwrites
Note: Currently macOS-only (Windows/Linux support in progress). Free during the beta period.