Building a Swift app from zero iOS experience with Claude Code sounds like bait, but the story lands because it is stubbornly unglamorous. Specs, plans, CI, UI tests, shell-command hooks, localization checks, real-device testing — all the annoying scaffolding is what kept the agent useful instead of just fast. The best line hiding in here is that the repository has to remember what the agent will forget, which, yes, applies to our human teams too.

Safari’s MCP server gives coding agents a browser window they can actually inspect: DOM, console output, screenshots, network requests, page content, interactions, the whole debugging loop. That matters even for those of us living mostly in native apps, because it points to the direction tools are going — agents with eyes, not just autocomplete with confidence. Fewer “try this and tell me what you see” loops is a very easy thing to root for.

Xcode Preview MCP sounds like exactly what agentic SwiftUI work needs: let the agent render the UI instead of guessing from code. Then reality shows up. Device selection is shaky, stale screenshots can slip through, and the workaround trail includes deprecated `PreviewProvider`, fingerprints, and extra metadata so an agent can know it is looking at the right thing. Messy? Definitely. Still probably the future of serious AI-assisted UI work.

System One models are pitched here as “smart `if` statements”, and honestly, that framing helps. Instead of asking a full LLM to generate text when all we need is a bounded judgement, Jev-style classifiers return typed answers, probabilities, and confidence fast enough to sit in real app flows. For our apps, this is the more interesting AI shape: not chat everywhere, but tiny decision points where fuzzy input meets structured output.

A proper deep dive into the dyld shared cache is not everybody’s idea of a cozy evening, but this one pays off. iOS 27 appears to remove redundant stub sections, rethink trampoline patterns, and scatter `objc_msgSend` copies through the cache so short branches can still reach. We may never touch this directly in app code, sure, but understanding where Apple squeezes performance out of the system makes the platform feel a little less like a black box.

`withTaskCancellationShield` is one of those small Swift concurrency additions that immediately answers a bunch of “yes, but what about cleanup?” questions. The useful bit is not magic cancellation prevention; it is hiding cancellation from a block so the work inside can finish cleanly, including child tasks. The catch is the new runtime requirement on iOS 27 and friends, so the back-deployment workaround discussion is the part many of our apps will care about first.

Swift on WebAssembly keeps feeling less like a side quest and more like real infrastructure work. WasmKit got a big speed bump, uWASI and JavaScriptKit keep filling in practical runtime gaps, and ElementaryUI is now pushing Swift UI ideas into custom elements. If our codebase ever needs to live outside Apple platforms without becoming a rewrite, this is the kind of steady, boring-in-the-best-way progress we want to see.

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.