In issue 751 of iOS Dev Weekly, Dave Verwer announced that the newsletter, which has been running for nearly 15 years, will be handed over to a new team, while he will dedicate himself full-time to Swift Package Index. My own blog gained early attention thanks in part to recommendations from iOS Dev Weekly, and my commitment to writing a commentary for each issue of my newsletter was also greatly inspired by Dave Verwer. For many Apple platform developers, iOS Dev Weekly has long been more than a collection of links. It has been both a guidepost for the community and a long-term companion.
Rather than viewing this as “Dave leaving iOS Dev Weekly”, a phrase that inevitably carries a sense of farewell, I prefer to see it as a shift in focus: from curating the information flow of the Swift community to building infrastructure for the Swift ecosystem.
Swift Package Index was originally created by Dave Verwer and Sven A. Schmidt as the successor to, and a rewrite of, SwiftPM Library. When it first appeared, it was easy to understand it simply as a “website for finding Swift packages.” But after several years of development, SPI has clearly grown far beyond the scope of an ordinary index site. It not only records basic package information, but also uses real builds to verify compatibility across Swift versions and platforms, hosts DocC documentation, displays maintenance status, dependency relationships, licenses, tests, and package scores, and, through projects such as Ready for Swift 6, observes how the broader package ecosystem migrates toward new language features.
These capabilities may seem scattered, but in essence they all point to the same goal: making the Swift package ecosystem easier to evaluate, compare, and trust. For individual developers, choosing a dependency becomes a little less like opening a “blind box”. For teams, it becomes easier to assess risks before introducing third-party libraries. For package authors, SPI provides a public window for showcasing project health and documentation quality. A mature package ecosystem cannot exist on Package.swift alone. It also needs visible compatibility, continuous documentation, stable build verification, and a trust mechanism gradually built around all this information.
In Issue 135, I wrote that CocoaPods is on its way out, while SwiftPM has only just turned to its second chapter. With CocoaPods Trunk counting down toward becoming read-only, and ecosystems such as Flutter also moving toward SPM, the “unification” of dependency management on Apple platforms now seems increasingly close. But that does not mean SwiftPM has truly broken beyond its existing boundaries. It will certainly become the default answer on Apple platforms, but if Swift is to keep expanding into Linux, Android, Wasm, embedded systems, and other scenarios, SwiftPM will need to address more than just “whether dependencies can be installed.” The real question is whether the entire ecosystem is transparent, reliable, and sustainable enough.
In this regard, the value of SPI may be far greater than its name suggests. It can be an index, but also an ecosystem dashboard; it can be a documentation hosting platform, but also a compatibility lab. In the future, it may even take on a larger role in areas such as package collections, supply chain security, version immutability, and public registries. Dave has previously mentioned that SwiftPM registries could bring safer and faster distribution to Swift dependency management, while a public registry for open-source packages remains an important missing piece worth looking forward to.
iOS Dev Weekly records the weekly ripples of the Swift community, while Swift Package Index touches the waterline beneath those ripples. Dave’s shift may also suggest that the Swift ecosystem has entered a new stage: we still need excellent content curators, but we need even more infrastructure builders who can help the ecosystem continue running for the long term.
Recent Recommendations
Monads are Easy
Monad is probably one of the most infamous — and most intimidatingly explained — concepts in functional programming. But at its core, it really just solves one problem: how to safely and continuously compose computations around values that carry “context.” Krishna Kotecha explains Monad in a way that feels very approachable to Swift developers, using a warehouse book-scanning analogy: values are books, containers are boxes, map scans books one by one, while flatMap opens nested boxes and flattens everything back into a single box. Whether it’s Optional, Result, or Optional chaining, they all exhibit strong Monad-like behavior. In Swift, every ?. you write is essentially a flatMap disguised as syntax sugar.
Krishna Kotecha not only explains Monads in an intuitive way, but also includes excellent diagrams throughout the article. The “unboxing and repacking” visuals make the core idea behind
flatMapremarkably easy to grasp.
Type-Driven Design in Swift: Better Money Formatting
For many Swift developers, Type-Driven Design often stops at “preventing invalid parameters from being passed around.” But in more complex domains — such as finance, state machines, permissions, or orders — types themselves can become part of the business rules and domain constraints. In this article, Uwais Alqadri uses the separation of “raw money value” and “display value” as a starting point to explain why fintech applications should never perform calculations directly on Double values or formatted display strings. Through a series of practical examples, the article demonstrates how locale differences, currency precision, and rounding rules can introduce subtle but serious bugs, while also highlighting the value of Type-Driven Design in domain modeling.
Is AndroidX ViewModel the best choice for KMP projects?
For Swift developers, a ViewModel is usually just an object that holds view state and interaction logic. In SwiftUI, it can be an @Observable type or simply a reference type organized around view state; task lifecycles are typically managed by .task, the view hierarchy, or other SwiftUI-native mechanisms. But when Swift developers enter the Kotlin Multiplatform or Android ecosystem, it’s easy to underestimate what AndroidX ViewModel is actually responsible for: it’s not only the “ViewModel” in MVVM, but also part of Android’s lifecycle management, ViewModelStore, and coroutine scope system.
Gustavo Fão Valvassori walks through the historical background of Android ViewModel, explaining why it became tightly coupled to Activity / Fragment recreation, configuration changes, and viewModelScope, and further explores the friction this model can introduce when brought into KMP projects targeting native iOS UI. For Swift developers, the most valuable aspect of the article is not whether AndroidX ViewModel should be adopted directly, but rather understanding that the term “ViewModel” can carry very different architectural responsibilities across platforms.
Deprecating your own convenience API
To support different OS versions — or provide a consistent experience across old and new systems — developers often create wrappers, compatibility layers, or custom modifiers to smooth over platform differences. But as deployment targets rise over time, much of that code quietly turns into “dead code” nobody dares to remove. Majid Jabrayilov demonstrates a very practical SwiftUI technique using @available(..., deprecated:, obsoleted:) to explicitly define the lifecycle of these transitional APIs. Once the minimum deployment target increases, the compiler can automatically surface warnings or even errors, reminding developers to finally remove obsolete compatibility layers.
In a sense,
@availableis not only about API availability — it’s also a way to manage the expiration date of technical debt.
Hiding SwiftUI Views from Screen Capture
SwiftUI has long lacked a capability that sounds deceptively simple, yet is actually quite low-level and highly practical: allowing a View to remain visible on screen while being excluded from screenshots, screen recordings, AirPlay, or other system capture pipelines. Public APIs mainly provide “capture state detection,” rather than true per-view capture privacy protection. Kyle Ye, the developer behind OpenSwiftUI, walks through the entire stack — from public APIs, secure UITextField tricks, and the private CALayer.disableUpdateMask behavior, all the way down to SwiftUI’s internal DisplayList and RendererEffect mechanisms — eventually implementing a genuinely SwiftUI-style view extension. Instead of moving SwiftUI content into a secure text field subtree, the approach directly leverages SwiftUI’s existing screencaptureProhibited rendering property to exclude the corresponding layer from capture output.
A Public Symbol Server for Swift on Windows
The Browser Company recently made its Swift on Windows Symbol Server publicly available. Through this service, developers can directly fetch PDB symbol files for the Swift runtime and standard library inside native Windows debugging tools such as WinDBG, Visual Studio, and Windows Performance Analyzer, enabling fully symbolicated stack traces and much clearer crash analysis.
What makes the article particularly interesting, however, is not just how to configure a Symbol Server, but the broader explanation of Swift’s debugging infrastructure across platforms: from object file formats like Mach-O, ELF, and PE/COFF, to DWARF versus PDB/CodeView debug information systems, and the very different ways Darwin, Linux, and Windows manage symbols. For developers who have only worked on Apple platforms, this article offers a surprisingly clear reminder that making Swift truly cross-platform involves far more than simply “being able to compile and run.”
Replacing Bash with Swift in an AI Harness
As AI Agent tooling evolves, “letting models execute code” is gradually becoming less of a terminal wrapper problem and more of a runtime design problem. This article documents a fascinating experiment: Alejandro Martinez replaces Bash inside an AI Harness with an embeddable Swift interpreter, allowing the model to generate and execute Swift directly instead of shell scripts. Combined with SwiftScript and ShellKit, the project demonstrates how embedded interpreters, controlled working directories, and sandboxing can provide a much more constrained and controllable Swift Runtime for LLMs.
SwiftScript is a particularly interesting experimental project created by Oliver Drobnik: a fully Swift-written, embeddable Swift interpreter. It parses and executes Swift ASTs directly using
swift-syntax, rather than compiling binaries throughswiftc, making it feel much closer to JavaScriptCore or a Python-style embedded scripting runtime.
Hanging on the Promise of SwiftUI
Seven years after SwiftUI’s introduction, we still seem to be in a strange in-between state: it has become too important for Apple platform developers to ignore, yet it still feels incomplete enough that many real-world applications eventually fall back to AppKit or UIKit. In this article, Patrick McConnell expresses his complicated relationship with SwiftUI: it is good enough to make developers want to invest deeply in it, but that also makes its recurring “almost, but not quite there” limitations in extensibility, completeness, and lower-level capabilities especially frustrating.
I’ve always felt that SwiftUI will only truly mature once Apple itself fully commits to using it at scale across first-party applications. Third-party developers should not be treated as framework beta testers — they should be the first to benefit from the convenience and stability the framework promises.
Tools
App Store & Google Play Screenshots Generator
App Store & Google Play Screenshots Generator is an AI coding agent–oriented screenshot generation skill created by Parth Jadhav. Rather than simply offering templates, it turns the entire screenshot workflow — collecting product information, organizing marketing copy, choosing visual styles, local editing, and exporting multiple sizes — into an executable process.
The project generates a local Next.js + ShadCN editor for the current directory, supporting drag-and-drop ordering, inline title editing, real screenshot uploads, iOS / Android device switching, and persistent project state stored in a versionable app-store-screenshots.json file. Its most valuable idea is treating store screenshots explicitly as advertising assets: each screenshot should communicate a single selling point, prioritizing user benefit, emotion, and pain points over mechanically showcasing UI.
For indie developers, tools like this are genuinely useful. They won’t replace final visual judgment or platform guideline reviews, but they can consolidate a large amount of repetitive and error-prone screenshot work into a much more agent-friendly local workflow.
Editorio: A Native macOS Markdown & Code Editor
Tired of bloated Electron editors and the ever-growing subscription culture around note-taking apps, Lovre Crncevic decided to build a lightweight, fully native Markdown and code editor for himself.
Editorio uses Swift + AppKit for its native interface and a Rust-powered text engine for performance optimization. It supports live Markdown preview, project sidebars, minimaps, themes, and syntax highlighting for many programming languages. According to the author, Editorio typically uses around 40MB of memory while maintaining near-instant startup and file loading times. In some ways, it feels like a return to the classic era of “small and fast” Mac applications.
Lovre has promised that the app will remain free forever, and mentioned in a Reddit discussion that once the codebase is cleaned up further, he plans to open source Editorio on GitHub.
Event
Swift Mentorship Program 2026
The Swift Mentorship Program is an official community initiative that has become a recurring part of the Swift ecosystem in recent years. Its goal is to help more developers meaningfully participate in Swift open source development through direct mentorship from experienced contributors. Over a 10-week period, mentees work alongside mentors to complete real open-source contributions — whether to the Swift compiler itself or any Swift-based open-source project. Compared to simply reading tutorials or browsing issue trackers, this “guided first contribution” model provides a much more authentic open-source collaboration experience.
The program was originally driven by the Swift Contributor Experience Workgroup and has gradually evolved into a stable community activity. Beyond technical learning, it also helps lower barriers to entry, cultivate new contributors, and strengthen community connections. The Swift team explicitly encourages participation from groups such as Women in Swift, Black in Swift, and Pride in Swift.
The 2026 program has already opened, with mentor and mentee sign-ups beginning in May and June respectively, followed by the official 10-week mentorship cycle starting in July.