8 articles: Swift for Wasm September 2026 Updates, withTaskCancellationShield: Swift 6.4 new feature, Inside iOS 27's Reworked Stub Islands, and 5 more

A visual gallery for iPhone Duo layouts is exactly the kind of reference that saves time when your mental model starts lying to you. Instead of guessing how a `NavigationSplitView` behaves across portrait, landscape, closed, partially open, and fully open states, you can scan screenshots and compare the variants directly. It is not trying to be a deep essay, and that is fine — sometimes our apps need a quick “what does SwiftUI actually do here?” check before we start adding custom logic. Keep this one nearby when reviewing Duo layout changes.

`jev-foundation-models` plugs TypeSafe AI’s Jev decision model into Apple’s Foundation Models APIs, which is an interesting fit for cases where we need typed decisions, not another paragraph of generated text. The package maps `@Generable` structs and enums into fast boolean, choice, and score evaluations, then feeds the result back through `LanguageModelSession` with confidence metadata. I’m especially glad the README leads with the mobile API-key warning, because shipping secrets in an app binary is still not a clever shortcut, it is just a future incident. For triage, routing, deduping, and other “make a call from structured state” jobs, this is a neat bridge to watch.

New SwiftUI APIs arriving in iOS 27.1 are nice, but bumping the whole deployment target just to use `toolbarVerticalBehavior` is rarely how our apps work. The backport pattern here is intentionally small: wrap the new modifier behind availability checks, either under a `.backport` namespace or with a `ported` prefix that deprecates itself once the real API is safe to require. I prefer the deprecation approach because it leaves breadcrumbs for future cleanup, and future cleanup is where these little compatibility shims usually go to die. Use the new Duo behavior now, keep older OS support, and make the compiler remind you when the shim has outlived its usefulness.

A quick tour through the iOS 27.1 Duo APIs, with code you can paste into a small demo instead of just staring at documentation. The toolbar pieces line up with Apple’s new vertical bar model — per-item axis behavior, whole-presentation vertical behavior, compression choices, and the `toolbarVerticalEdge` environment value. The extra wrinkle is `ArrangementView`, which gives SwiftUI a native way to juggle primary and secondary content through split, overlay, and custom styles. Some of it still feels like we need real devices and real apps to develop taste, but that is exactly why small demos like this help.

Sheets on iPhone Duo mostly do the right thing, but “mostly” is where the product polish lives. Across closed, open, and partially folded poses, the system moves sheet controls, centers presentations, or slides UI away from the fold so actions do not land in awkward places. The practical takeaway is simple: start with standard sheets and system components, then disable vertical toolbar behavior for the cases where one lonely Close button steals too much width. It is a good reminder that Duo adaptation is less about inventing a new layout religion and more about checking the weird poses before our users do.

SwiftUI’s iPhone Duo toolbar story is getting more specific now: vertical bars, item axis behavior, compression priorities, and an escape hatch when the vertical layout makes a screen worse. The useful bit is not “new modifiers exist”, it is the judgment around when to let the system adapt and when to pin an item to horizontal space. `axisBehavior(_:)`, `toolbarVerticalEdge`, and `toolbarVerticalCompressionBehavior(_:)` give us just enough control without turning every toolbar into a custom layout project. I like this because it keeps our apps in the system’s lane, but still lets us say, “no, that slider really should not be crammed into the side bar.”

Xcode 27.2’s new `project.xcproj` format is one of those boring-looking changes that could save real pain in our codebase. The old `pbxproj` file has always been a merge-conflict magnet, full of flat object tables and IDs nobody wants to review. JSON alone is not the win here; the nicer part is that Apple reshaped the project graph so file membership and build settings read closer to what we actually changed. Not a revolution, no, but for teams still touching `.xcodeproj` directly — and for coding agents trying not to mangle it — this feels like overdue cleanup.

Swift 6 strict concurrency can still leave a nasty hole when Objective-C APIs take plain callback blocks and run them on queues the Swift type system cannot see. The crashes here come from `BGTaskScheduler` and PhotoKit callbacks created inside `@MainActor` code, then invoked off the main actor before the `Task { @MainActor in ... }` body even gets a chance to run. That is the kind of bug that looks “obviously handled” in review, which is why the concrete grep targets and testing advice are useful. If our apps bridge into older Apple frameworks — and of course they do — this is worth reading with crash logs open.

8 articles: Swift 6 Gave Me Zero Warnings, but Two Objective-C Callbacks Still Crashed at Runtime, From pbxproj to xcproj: Xcode Project Configuration Gets a JSON Format, Configuring SwiftUI toolbars on iPhone Duo, and 5 more

BrewUI is Homebrew’s official macOS GUI, built in SwiftUI, and I’m happy it exists for a simple reason: not everyone wants package management to start in Terminal. The project is careful about transparency, showing what Homebrew is doing rather than turning installs and upgrades into a mystery button. It also has a very pragmatic environment model — clean zsh launch, explicit `brew.env` files, and a Configuration tab to explain what the app sees. A native SwiftUI app around a beloved command-line tool? That is a nice little macOS story, and maybe a useful reference for our own developer-facing utilities.

Large iOS codebases rarely stay neat, and this piece walks through the mess without pretending one repo strategy solves everything. Swift Package Manager is the center of gravity now, with private registries, binary XCFramework targets, CI tokens, automated version bumps, and the occasional Xcode workspace still doing useful work at the edges. The practical thread is consistency: exact versions, repeatable builds, shared compiler settings, and dependency updates that move through PRs instead of folklore. If our apps depend on a dozen internal libraries, “it builds on my machine” is not a process. It’s a warning sign.

There’s a tiny launch argument here that deserves a spot in every SwiftUI performance debugging checklist: `-LogForEachSlowPath YES`. It catches `ForEach` content inside lazy containers when SwiftUI can’t know the number of views per element without evaluating offscreen rows, which is exactly the kind of invisible work that makes lists feel haunted. The fix is not always “wrap it in a `VStack`”; sometimes we should filter the collection before `ForEach`, and sometimes grouping is the right move because the element still exists. Small detail, big payoff. Our lists are only lazy if we stop making SwiftUI guess.

SwiftUI animation is easy to use and weirdly easy to misunderstand, especially once “async” and Core Animation show up in the same conversation. This deep dive follows OpenSwiftUI’s iOS 18 animation model and makes the boundary clearer: SwiftUI samples animation values in the app process, then submits presentation updates; Core Animation still composites, but it is not necessarily owning the spring’s clock. That distinction matters when we’re chasing hitches in our apps. Don’t just blame “the animation” — trace state, graph updates, sampling, layer updates, and compositing like separate suspects.

A reusable SwiftUI skill for coding agents is exactly the sort of thing that starts sounding optional, right up until the third generated view ships with stale `onChange` patterns and confused state ownership. Version 5.0.0 adds verified Xcode 27 and SDK 27 guidance, with focused references for layout, accessibility, animation, state, lists, toolbars, WebKit, and more. The nice part is the shape: a compact skill file that pulls in deeper notes only when relevant, instead of stuffing every rule into one giant prompt. Our codebase gets better results, and our context window does not become a landfill.

Xcode 27 exporting Apple’s own agent skills is a small command with a pretty big implication: our external agents can now carry some of Apple’s platform guidance with them. The walkthrough shows how to dump those skills into Claude Code, Cursor, Codex, or a shared `~/.agents/skills` folder, then let the agent load SwiftUI, testing, UIKit modernization, or security guidance only when it needs it. I like this because it treats AI assistance less like magic and more like tooling we can configure. And honestly, who doesn’t want the agent to stop guessing at SwiftUI when Apple already wrote the notes?

Swift AWS Lambda Runtime 3.0.0 lands with the kind of changes server-side Swift teams will care about immediately: `nonisolated(nonsending)` by default, new lifecycle plugins, ZIP or OCI deployment, and task-local logging. The breaking change may sting a bit, sure, but keeping handler execution on the caller’s executor is the right kind of boring correctness. The new `lambda-init`, `lambda-build`, and `lambda-deploy` flow also makes Lambda feel less like a hand-rolled side quest. If our backend glue is going to be Swift too, this is the direction it needed to go.

Swift 6.4 is one of those releases where the headline is not one giant feature, but a lot of pressure being taken off real projects. Swift Build becoming the default in SwiftPM, Subprocess hitting 1.0, better Swift Testing migration, richer interop, faster Wasm bridging — it all points to Swift getting more comfortable outside the narrow “app language” box. For our apps, the async `defer`, cancellation shields, warning controls, and non-copyable collection work are the bits I’d actually expect to feel in code reviews. Less ceremony, fewer weird edges, and a language that keeps growing without pretending memory safety is optional.

8 articles: Swift 6.4 Released, [Lambda] : Swift AWS Lambda Runtime 3.0.0 released, How to Export and Use Xcode 27's Agent Skills in Claude Code, and 5 more

Weekly curated iOS and Swift articles with editorial commentary — now with an RSS feed.

A plant identifier is a nice excuse to see Foundation Models image attachments doing something concrete: pass an image, generate a structured plant name, then keep the conversation going with follow-up questions. The smart part is not re-analyzing the image every time; caching the identified plant keeps the UX from feeling like it is paying the same expensive bill again and again. There are rough edges, including model weirdness and real-device requirements on iOS 27, but that’s useful honesty. This is the kind of AI demo that maps cleanly to our own apps: identify once, ask many times, stream the answer when it gets longer.

RCS has been easy to ignore if most of your world lives inside iMessage, but cross-platform messaging is finally less awful on iPhone. The real-world test here — texting friends in Germany for a month and checking whether it stayed free — is more useful than another feature checklist. iOS 26 adding end-to-end encryption makes the story feel less like a grudging compatibility layer and more like something users may actually trust. Not glamorous, no, but our apps live in the same user expectations soup as Messages does.

SQLiteData feels like SwiftData for teams who still want the database to be real. You get familiar wrappers like @Table, @FetchAll, and @FetchOne, but underneath it’s SQLite, GRDB, type-safe queries, and CloudKit sync without pretending schema design doesn’t exist. I like that tradeoff: a little more upfront database thinking, a lot more control when our apps grow past the toy phase.

Swift Testing is settling in as the default path, and the migration story is getting clearer: `@Test`, `#expect`, `#require`, parameterized tests, attachments, and exit tests where the platform allows them. The big win is not just fewer assertion names to remember; failure output is closer to the expression we actually wrote, which helps when CI is yelling and coffee has not kicked in yet. XCTest still has a place for UI automation and performance work, so no need for a dramatic rewrite. But for most unit tests in our codebase, the modern shape is hard to argue against.

The little `UIViewRepresentable` WebView wrapper we’ve all copied between projects can start packing its bags. iOS 26 gives SwiftUI a native `WebView`, and `WebPage` covers the bits real apps need: title, loading state, progress, history, secure-content state, and async JavaScript. The catch is small but easy to miss — import both SwiftUI and WebKit, because this arrives through a cross-import overlay. Keep the old wrapper for older deployment targets, sure, but new code gets pleasantly boring here.

SwiftUI toolbars are getting a vocabulary for the thing we’ve all been faking: what matters when space runs out. `visibilityPriority`, `ToolbarOverflowMenu`, pinned trailing items, and minimization behavior give us knobs instead of hoping the framework guesses our hierarchy of actions correctly. That matters more now with resizable windows, search taking over chrome, and devices that may change shape mid-session. Who doesn’t like deleting a weird custom “more” button and letting the system carry the overflow story properly?

The foldable iPhone conversation is no longer just gadget gossip; it’s a layout problem with a hinge in the middle of it. The useful bits here are practical: trust size classes over device assumptions, test asymmetric safe areas, let system containers manage bars, and don’t hide core features behind some cute folded pose. I like the warning baked into all of this — if our app only works because we guessed the shape of the device, we’re already late. Duo support sounds flashy, but most of the work is just honest adaptive design.

Swift’s August roundup is very much a “look how far outside Xcode this language is wandering now” moment. Elementary and ElementaryUI push Swift deeper into web UI work, SwiftTUI brings state and animation ideas into terminal apps, and the Windows story keeps getting less theoretical. If our mental model of Swift is still mostly “the language we use for iOS screens,” this digest is a useful shove. The ecosystem is getting wider, messier, and more interesting — as it should.

8 articles: What's new in Swift: August 2026 Edition, iPhone Duo: First Developer Good-to-Knows, Adaptive SwiftUI toolbars in iOS 27, and 5 more

NobodyWho is pitching local AI inference across devices, with text, vision, speech-to-text, and text-to-speech models loaded from places like Hugging Face and called from Swift, React Native, Kotlin, Dart, Python, and more. The Swift sample is refreshingly direct: load a `GGUF` model, ask it something, await the completed response. For mobile teams, the appeal is obvious — private, offline-capable AI features without sending every user interaction across the network. Of course we still need to care about model size, latency, and battery, but this is the kind of tool that makes local-first AI feel less like a research project.

SwiftUI views rendered as Final Cut Pro effects is the sort of sentence that makes you stop and check you read it right. Using [SwiftUIFX](https://github.com/finnvoor/SwiftUIFX), the experiment builds SwiftUI components and renders them frame by frame onto video footage, which is not the usual plugin path most of us have in our heads. It’s scrappy and exploratory in the best way. Even if our day job never touches Final Cut Pro, seeing SwiftUI escape the app window is a healthy reminder that our UI tools are more portable than we tend to assume.

A nice little Swift Charts recipe inspired by the iOS Weather UV chart: gradient area, matching line, current-time marker, and a dimming layer over the part of the day that has already passed. The technique is useful because it’s not just prettier data, it tells the user what’s behind them and what’s still ahead at a glance. Our apps often need exactly this kind of visual hint, the small layer that makes a chart feel alive instead of pasted in. Bonus points for keeping accessibility in the conversation when the area and line represent the same data.

Swift Charts can build a proper sunburst diagram, but the fun is in the details: `SectorMark` rings, radius ratios, angular insets, grouped data layout, and accessibility labels that don’t get treated as an afterthought. The result is a multi-level donut chart where the outer rings still line up with their parent categories, which sounds simple until you try to fake it by hand. Who doesn’t like a chart that looks custom without becoming a pile of custom drawing code? This is a good reminder that Charts has more range than the usual bar-and-line dashboard screenshots suggest.

Apple’s guide lays out the official path for getting AppEntity types into Spotlight, with `IndexedEntity` doing a lot of the connective work. The big bit for our codebase is that Spotlight is no longer just a bag of searchable strings; it can carry structured app entities that Siri and other system experiences can reason about. That means the boring indexing layer suddenly matters a lot more. If our app has user-created objects, saved places, documents, workouts, recipes, whatever, this is the place to start making them visible to the system.

A practical walk through making Siri understand app data, not just launch a shortcut and wave vaguely at the app. Walk Mate’s favorite routes become App Entities with readable properties, Spotlight indexing, Shortcuts search, and a Maps handoff, which is exactly the kind of plumbing our apps need if we want Apple Intelligence to feel useful instead of decorative. I like how grounded this is: one saved walk, one name Siri can say, one route that opens where the user expects. App Intents can get abstract fast; this keeps the work close to something a person would actually ask for.

Foundation Models get much more real once the prompt can include an image, and the plate-scanner example makes the point without overcooking it. Define a `Generable` result type, pass instructions plus an `Attachment` into `LanguageModelSession`, and get structured output back that the UI can actually use. No giant cloud pipeline, no “AI strategy” meeting, just a feature-sized loop: image in, typed result out. That’s the kind of AI API surface I want in our apps — small enough to trust, useful enough to ship.

Swift for WebAssembly had one of those months where the changelog looks small until you notice the shape of it: WasmKit running a WASI guest and GDB stub on an ESP32, BridgeJS getting cleaner module imports and generic imported functions, ElementaryUI tightening up its SwiftPM/Vite story. That’s not “hello world in the browser” territory anymore. It’s Swift being pushed into edge workers, embedded targets, and frontend experiments with fewer apologies. Still rough in places, sure, but if our idea of Swift stops at apps and server binaries, we’re missing where the interesting pressure is building.

8 articles: Swift for Wasm August 2026 Updates, Building AI features using Foundation Models. Multimodal input., Teaching Siri to talk about your favorite walks in Walk Mate, and 5 more

Xcode refactoring is unreliable enough that digging through its menus trains us to stop trying. Binding Rename, Extract All Occurrences, and Extract to Method to memorable shortcuts flips that cost: try instantly, move on instantly if Xcode says no, and stay in flow on the rare happy path when it works.

A calendar heat map looks simple until dates from later weeks form a staircase and VoiceOver groups every Monday into one inaccessible column. Normalizing weekdays into a reference week fixes the geometry; replacing the plot’s accessibility children with a matching synthetic grid restores day-by-day navigation and month headings without throwing away Swift Charts’ date-based model.

Photo Editing extensions are a neat example of designing for non-destructive work: render a display-sized preview, persist the recipe as `PHAdjustmentData`, then apply it to the full-resolution asset only when the user commits. The old APIs show their age, but the constraints have not—share code carefully with the container app, avoid wasteful image buffers, and assume memory pressure will expose every lazy choice.

SwiftUI’s `backgroundTask` modifier makes `BGTaskScheduler` feel far less bolted on, especially now that handlers can use async/await and cooperative cancellation. The system still decides when work runs, though, so schedule from lifecycle transitions, use background `URLSession` for long transfers, and learn the debugger commands that simulate launch and expiration—or enjoy waiting indefinitely for iOS to cooperate.

App Intents are not some magical replacement for ASO, and treating them that way misses the point. For most indie apps, one open intent, one search intent, and one create intent behind an `AppShortcutsProvider` is enough to make the app genuinely usable from Siri, Spotlight, and Shortcuts—small work with a surprisingly broad system footprint.

Core AI fills the awkward space between Apple’s Foundation Models and traditional Core ML: bring a task-specific model, convert it to `.aimodel`, and keep inference on device. The architecture advice is the real keeper—compose small vision and language models, hide tensor plumbing behind narrow types, and treat download plus first-run specialization as product states rather than surprising the user with a spinner.

Swift finally has one hosted home for The Swift Programming Language, standard library APIs, Swift Testing, toolchain material, and platform guidance, built nightly with DocC. The useful bit is the split between `latest` release documentation and `main` development docs, with real versioning and a switcher still being worked out; Foundation is notably missing for now.

8 articles: Swift's New Documentation Site, Run Custom Models On Device With Core AI, App Intents for iOS 27: The Indie Playbook for the New Siri and Spotlight, and 5 more

This focused Cursor Agent Skill packages modern SwiftUI guidance for implementing and reviewing Liquid Glass with native iOS 26 APIs. Installation is straightforward through `npx skills add`, and the narrow scope is the selling point: one well-maintained skill with concrete pitfalls beats a giant prompt that pretends to know every corner of SwiftUI.

Navigation stops being “just UI” the moment the destination depends on role, account state, or permissions. Representing destinations as `Route` values and moving those decisions into a router—or a feature coordinator once the router starts becoming a junk drawer—turns them into fast Swift Testing assertions instead of brittle UI tests. That seam is small, but it pays off every time a product rule changes.

Resizable iPad windows and iPhone apps running on larger surfaces have made device-based layout assumptions properly obsolete. `onGeometryChange()` lets a view derive a small `Equatable` value—say, whether a card should switch orientation—from the space it actually receives, and only updates state when that value changes. Return the smallest signal you need and keep it independent from the measured layout, or you’ll build a feedback loop that thrashes during resizing.

If app launch feels slow, stop poking at random initialization code and measure it. Instruments’ App Launch template and the App Lifecycle pane show each launch phase with its duration, giving us a concrete place to start instead of another round of “it seems faster on my phone.”