“It just works” is doing a lot of quiet work in that sentence.

This week’s reads are about the rules hiding underneath four things that feel automatic: how SwiftUI decides a view needs to redraw, which property wrapper actually owns your object, what git really deletes when you force-push over two weeks of work, and what happens when you stop clicking through Xcode and start scripting it directly.

Hit reply and tell us: what’s the last “it just works” feature that turned out to have rules you had to learn the hard way?

Every “It Just Works” Has Rules You Haven’t Learned Yet.

with Divya Ravi — Technical Editor, iOS engineer

Every framework sells you a story. SwiftUI redraws the right views. Git deletes what you tell it to delete. Xcode is where you click things until the app runs. The story is convenient right up until the moment it’s wrong, and then you find out the story was never the whole mechanism — just the part someone decided you didn’t need to see.

Natalia Panferova’s piece on SwiftUI data dependencies is a good place to start, because “SwiftUI re-renders when state changes” is the kind of sentence that’s true enough to stop you from asking a better question. Which state? Tracked how? Through what boundary? Panferova walks through the actual dependency graph SwiftUI builds, and once you’ve seen it, the mysterious extra redraw — or worse, the redraw that never happens — stops being mysterious. It was never magic. It was a rule you hadn’t read yet.

Antoine van der Lee’s @StateObject-versus-@ObservedObject piece sits right next to that one, because ownership is exactly the kind of thing SwiftUI lets you get away with ignoring until you can’t. Both wrappers will compile. Both will often behave identically in a demo. The difference only shows up when the view holding an @ObservedObject gets recreated and your “persistent” state quietly resets — at which point you learn, expensively, that one of these wrappers was never supposed to be the source of truth.

Then there’s Daniel Saidi’s story, which is the most viscerally relatable thing I’ve read this month: an errant git reset and force-push erased two weeks of work on a real project. I felt that in my chest reading it. But the resolution is the actual lesson — git doesn’t delete commits when you delete a ref, it just stops pointing at them. The work was never gone. It was unreachable, which is a very different thing from destroyed, and knowing that difference is the kind of fact that turns a five-alarm panic into a five-minute recovery.

Artem Novichkov’s MCP-driven Xcode piece rounds this out from a different angle. Instead of learning a hidden rule the hard way, he’s exploiting one on purpose: Xcode and the simulator were never really “a GUI,” they’re a set of programmable interfaces that a GUI happens to sit in front of. Once you talk to that layer directly — prompt to build to simulator, no clicking — a lot of what felt like “the way Xcode works” turns out to have been “the way the GUI chose to expose Xcode.” Different thing entirely.

None of these are really stories about bugs. They’re stories about the gap between the interface you were handed and the system actually running underneath it — and about what happens once someone bothers to close that gap for you. The dependency graph, the ownership model, the ref/object split, the automatable toolchain: all of it was always there, documented or discoverable, just not part of the story anyone tells you on day one.

I don’t think the answer is to distrust every abstraction you use. Most of them earn the trust, most of the time. But it’s worth noticing which ones you’ve never actually verified — which “it just works” you’ve been repeating because it’s convenient, not because you checked. The rules are usually learnable in an afternoon. The bill for not knowing them tends to come due at a much worse time.

Hit reply and tell me: what’s an “it just works” in your stack that you’ve never actually gone and verified?

Related reading on this week's theme 📚

@StateObject Vs. @ObservedObject: The Differences Explained

Antoine van der Lee breaks down the ownership rules behind SwiftUI's two reference-type property wrappers — which one actually creates the object, which one just observes it, and why picking the wrong one causes state to quietly reset when a view gets recreated.

📍Level: Intermediate

SwiftUI Data Dependencies And Their Effect On View Updates

Natalia Panferova goes past "SwiftUI re-renders when state changes" to the actual dependency graph that decides whether a change gets noticed at all — essential reading for anyone who's ever debugged a view that wouldn't update, or updated when it had no reason to.

📍Level: Intermediate

Some Things Are Never Truly Lost

After an errant git reset and force-push wiped two weeks of work from a real project, Daniel Saidi discovered that deleting a ref isn't deleting the commits behind it — and walks through recovering the entire branch with a single command.

📍Level: Beginner

Headless Xcode: From Prompt To Simulator With MCP

Artem Novichkov drives Xcode and the iOS Simulator entirely through an MCP server and prompts — no clicking required — treating the toolchain as a scriptable interface instead of a GUI you have to operate by hand.

📍Level: Advanced

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

Trailing Commas Beyond Arrays In Swift 6.1

Sarun Wongpatcharapakorn covers how Swift 6.1 extends trailing-comma support past arrays to parameter lists, tuples, and generics — a small change that quietly makes every future code review and diff cleaner.

📍Level: Beginner

Beta Preview: LazyState

Point-Free previews LazyState, a library that picks up where WWDC's new @State macro left off, letting SwiftUI view state be initialized lazily and dynamically from data the parent view passes in.

📍Level: Advanced

Coding 👨‍💻

Why Swift Is Introducing A Warning For Weak Captures Within Nested Closures

John Sundell explains a new Swift compiler warning that catches a specific, easy-to-miss closure-capture mistake — and why "just add [weak self]" turns out not to be automatically enough once closures start nesting.

📍Level: Intermediate

Building A Reusable HTTP Client In Swift With async/await

Mohammad Azam builds a typed, testable networking layer from scratch on async/await — a solid reference the next time you're tempted to reach for a third-party networking library instead.

📍Level: Intermediate

Dynamically Setting Accessibility Custom Content Pairs In SwiftUI

Bas Broek shows how to attach and dynamically update multiple accessibility custom content entries on a view, so VoiceOver users get more than one flattened description of what's on screen.

📍Level: Intermediate

Apple 🍏

Surprise And Shine

Apple announced a September 9, 2026 event, widely expected to headline the iPhone 18 Pro lineup. Nothing developer-facing has shipped yet, but it's the date to have on your radar.

Update: New Domain For Sign In With Apple

Apple reversed a planned domain change for Sign in with Apple and iCloud+ Hide My Email after developer and user pushback — the current domain stays in place.

AI & Tooling 🤖

Getting Into Flow With AI Coding

Natasha makes the case that AI-assisted coding can deepen flow state rather than break it — if you stay actively involved: breaking work into small commits, and doing the planning and reviewing yourself instead of handing that over too.

📍Level: Intermediate

Claude Code Rules, Hooks And Skills, And How I Set Mine Up

Roland Leth breaks down Claude Code's three configuration layers — rules, skills, and hooks — and how they differ: preferences you state versus procedures you define versus safeguards that get enforced whether the AI "remembers" them or not.

📍Level: Intermediate

Design🎨

Building An Accessible Calendar Chart With Swift Charts

Matthaus Woolard builds a calendar-style chart with Swift Charts that also works with VoiceOver — treating accessibility as part of the chart's design from the start rather than a pass added at the end.

📍Level: Intermediate

Tutorials 📒

Uploading To TestFlight From The Command Line

Kyle Browning walks through scripting a TestFlight upload without opening Xcode — a useful building block for anyone trying to get release day off a human's clipboard and onto CI.

📍Level: Intermediate

Fix Sluggish SwiftUI Previews Instantly With Static Mock Data

Sagar Unagar shows a quick technique for keeping Xcode previews fast: swap live or expensive data sources for static mocks so iterating on a view doesn't mean waiting on a network call every time.

📍Level: Beginner

Community🤝

SE-0541: Flexible Swift/C Interoperability For Packages

The Swift Evolution community accepted SE-0541, giving Swift packages more flexible ways to interoperate with C code — a small but real ecosystem win for anyone bridging C libraries into Swift.

📍Level: Advanced

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Instead of Sunday, we’re publishing “Devs for Devs” on Monday.

This week, I’m happy to have Vinicius Serpa Pansan, an iOS developer with 4 years of experience building apps with a focus on performance and user experience. Based in São Paulo, Brazil, he works across the Apple ecosystem with technologies including Swift, SwiftUI, UIKit, and AppKit.

He shares his experience with AI-assisted app creation. Let’s check how to check, verify and adapt the AI-assisted code.

P.S. You can check out Vinicius’s work on LinkedIn, and Git.

A few months ago I started building Fio, a voice-first journaling app for iOS. The core idea is simple: speaking is faster than typing, so instead of asking someone to type out their day, you just talk, and the app transcribes and saves it. No decision required at the moment of capture, no folder to choose, no structure to commit to. Just speak, and it’s there.

I built it entirely in SwiftUI, and from day one, Claude Code and Codex were part of the actual development process, not a tool I reached for occasionally, but something I used in nearly every session.

My first instinct, like most people’s, was to use AI the obvious way: describe what I wanted, get a working implementation, accept it, move to the next screen. It’s the fastest path from idea to shipped feature, and for a while, it felt like exactly the right call. Screens came together quickly. Features that would have taken me a full evening to hand-write were done in twenty minutes.

Then, a few weeks in, I noticed something that bothered me more than it should have. I’d finish a session having built something that worked, and if you’d asked me to explain why it was built that particular way, instead of some other reasonable way, I sometimes couldn’t answer with confidence. I knew what the code did. I didn’t always know why it was the right shape for the problem.

That gap is easy to ignore when everything is working. It stops being easy to ignore the moment you have to defend a decision, in a code review, in an interview, or just to your future self six months later trying to remember why you did something a certain way.

This is the story of how I closed that gap, and the four-step loop I ended up building around it.

The Problem with Just Accepting the Output

The default AI workflow most developers fall into is straightforward: describe a problem, get a suggestion, skim it, it looks reasonable, accept it, move to the next task. It’s fast, and it feels productive, because things keep getting built. Velocity is visible. Understanding isn’t, so it’s easy to quietly deprioritize.

The moment this stopped being abstract for me was a decision that actually mattered for Fio: how to handle voice transcription. The app’s entire premise rests on a privacy promise, you speak, it’s transcribed, and nothing leaves the device unless you explicitly choose to back it up to your own iCloud. No audio ever touches a server. That’s not a minor implementation detail, it’s the reason the app exists in the shape it does.

If I had approached that the way I approached the first dozen smaller features, describe “add voice transcription,” accept the first working version, I likely would have ended up with something that technically transcribed audio just fine, but quietly assumed a server round-trip somewhere in the pipeline, because that’s the default shape most transcription examples and tutorials reach for online. It would have worked. It would have also violated the one promise the entire app is built around, and I might not have caught it until much later, possibly after the architecture around it was already hard to unwind.

Nothing about that outcome would have been the AI’s fault, to be clear. I was the one who hadn’t specified the constraint, hadn’t asked why a particular approach was chosen over another, hadn’t treated the output as something to interrogate rather than something to accept. The tool did exactly what I asked. I just hadn’t asked precisely enough, because I wasn’t in the habit of asking at all.

That’s the moment I stopped treating AI output as a finished answer and started treating it as a first draft that owed me an explanation

Here’s the difference in practice. The version I almost shipped would have looked something like this:

The version that actually matches Fio’s privacy promise sets one property explicitly:

One line. But it’s the line that turns “probably private” into “actually private,” and it’s exactly the kind of detail that’s easy to skip when you’re evaluating from a neutral position instead of comparing against something you wrote yourself first.

The Loop I Built Instead

I didn’t design this all at once. It came together step by step, each addition responding to a specific way the “just accept it” habit had already failed me.

Step 1: Write Your Own Approach Before Asking for One

Before I ask Claude Code or Codex to implement anything non-trivial, I write, in plain language, how I think it should work. Not code. A paragraph, sometimes just a few sentences. What matters isn’t the polish, it’s that I commit to an opinion before I see someone else’s, even an AI’s.

This sounds like a small thing, but it changes the psychology of the whole exchange. When you ask first and see the answer second, you’re evaluating from a neutral position, and neutral positions default to “looks fine” far more often than they should. When you write your own approach first, you have something to compare against, and comparison is a completely different cognitive act than approval. You’re no longer asking “does this look right?” You’re asking “where does this differ from what I expected, and why?”

More than once, my written approach turned out to be missing something the AI’s version accounted for, and I learned from the gap. Just as often, my approach was actually right, and the AI’s first suggestion took a shortcut I didn’t want, which I only caught because I had something concrete to compare it to.

Step 2: Let It Implement or Push Back, Not Replace

Once there’s a direction, the AI’s role is to build within it, and to flag problems it can see that I can’t, not to substitute its own direction for mine by default. This is a subtle distinction, but it changes how I write prompts. Instead of “build a sync mechanism for offline notes,” I’ll say something closer to “here’s how I want to structure the sync mechanism, tell me what breaks.”

That framing invites pushback instead of discouraging it. And when the pushback comes, it’s usually specific and useful, because it’s responding to a concrete proposal rather than generating one from scratch.

Step 3: Ask “Why This, Not the Alternative” on Every Non-Trivial Call

This is the step that actually catches the cases like the transcription example, the ones that are quietly wrong by default, not obviously wrong. If I can’t explain, in my own words, why a piece of implementation exists the way it does, I don’t move forward, regardless of whether the code compiles and the tests pass.

Sometimes the answer the AI gives is genuinely good, something I hadn’t considered, and I learn from it directly. Sometimes asking the question reveals that I framed the original request incorrectly, and the more useful fix is upstream of the code entirely. Either way, I come out of the exchange knowing something I didn’t know when I asked.

Step 4: Close Every Session by Summarizing What You Learned

Not what got built. What got understood? At the end of a session, I ask for a short summary of the concepts we touched, framed as though I had to explain them to someone else afterward, a teammate, an interviewer, my future self debugging this in six months.

This is the habit that turns a series of coding sessions into something that compounds instead of something that just accumulates. It’s also, practically speaking, what makes a project like this defensible later. When you can explain not just what a piece of code does but why it exists in that shape, you’re not reciting an AI’s explanation from memory, you’re demonstrating that the understanding is actually yours.

What Changed

Fio still isn’t public, so I’m not going to pretend this loop is the reason the app is good. What I can say with confidence is narrower and, I think, more useful: I know exactly why every non-trivial decision in it was made. That wasn’t true a few weeks earlier, when I was moving faster and understanding less, and it’s a different thing entirely from knowing that the code works.

That distinction matters more than it might seem to at first. Code that works is a snapshot. Understanding why it works, and why the alternative wasn’t chosen, is what lets you extend it, debug it under pressure, or explain it convincingly to someone else, none of which “it works” guarantees on its own.

I think this is the trade worth naming clearly, because it’s easy to miss in the current wave of AI-assisted development: speed was never actually the constraint holding most developers back. Understanding was, and it’s always been the harder, slower thing to build, which is exactly why it was the first thing to get cut whenever a faster path appeared. AI is, among other things, a very fast path. It removed a real excuse people used to have for skipping the “why”, there simply wasn’t time, someone had to just ship the thing. That excuse is mostly gone now. What’s left is a choice, made consciously or not, every time you accept a suggestion: build the loop that forces understanding, or don’t, and get code that works until, one day, it doesn’t, and you’re left debugging something you never actually understood in the first place.

The question worth asking isn’t “am I using AI?” anymore. At this point, most of us are, and the answer says less than it used to. The more useful question is narrower: after this session, do I know more than I did before it started, or am I just further along?

If you’re building something with AI as an active part of your process and want to compare notes on what’s working and what isn’t, feel free to reach out. I’m always happy to talk through it.

Ship day gets the screenshots, the release notes, and the celebratory post. Day two gets the bug reports.

This week’s reads are about that much longer stretch of software life: a 14-year-old app replacing its database, an open-source maintainer asking others to take ownership, a developer measuring what iOS background scheduling actually does in the wild, and an engineering lead making decisions before certainty arrives.

Hit reply and tell us: what’s the oldest piece of software you’re still responsible for keeping alive?

Shipping Is the Easy Part. Sustaining It Is the Job.

with Divya Ravi — Technical Editor, iOS engineer

Ship day gets all the ceremony. The build goes green, App Review says yes, and for a few hours the project feels finished.

Then somebody finds the edge case.

Maybe it is an old device you no longer own. Maybe it is data created six versions ago. Maybe it is not even your bug, but it is happening inside your app, so the distinction is not especially useful to the person staring at a broken screen.

That is the part of shipping we rarely celebrate: the years after the release, when the job becomes less about adding something new and more about keeping a promise you already made.

Daniel Saidi’s Wally is a good example. The app is 14 years old, and version 7 replaces Realm with SwiftData. Saidi describes a much cleaner architecture, less storage code, better integration with modern Apple frameworks, and private iCloud sync. It is tempting to summarize that as a straightforward modernization. It probably did not feel straightforward while changing the foundation of an app that has been accumulating users and data since 2012.

There is a point in every long-lived codebase when leaving the old system alone stops being the conservative choice. The workaround has a workaround. A dependency no longer fits the direction of the platform. The code still runs, but every new feature pays rent to an architectural decision made years ago. Replacing it is risky. Keeping it is risky too.

Matt Massicotte’s post sits nearby, although the debt is human rather than technical. He lists the open-source projects he can no longer maintain properly and asks people to take them over. I appreciated how direct the post is. Open source has plenty of launch energy and very little succession planning. We talk about adoption, stars, and contributors; we talk much less about what happens when the person whose name is on the repository no longer has the time to be its unpaid support team.

Asking for maintainers is not abandoning a project. Done early enough, it may be the most responsible maintenance decision available.

Irving Popovetsky’s post on iOS background tasks is the kind of article that only gets written after the happy path has stopped being useful. He instrumented BGTaskScheduler on his own device and watched what happened over time: refreshes arrived hours later than requested, resubmitting could accidentally push a pending task further into the future, and background launches became less frequent when the app went unopened.

The useful part is not a magic configuration that makes iOS behave like cron—there isn’t one. It is the record of all the small decisions required to make an unreliable system reliable enough: keeping refresh work short, handling expiration races, anchoring the next request to the last run, and being honest with users about what the operating system controls. This is maintenance in its purest form. The API call is easy; learning how it behaves after weeks of real use is the job.

And sometimes the maintenance problem is outside your repository. Jeff Johnson’s latest App Store post looks at suspicious gaps between ratings and written reviews, along with developers submitting apps at remarkable volume. You can improve your architecture, tests, and release process and still depend on a distribution system whose failures you cannot patch.

So I kept coming back to Mohammad Faani’s decision framework, especially his 70% rule: when one option looks roughly 70% right, choose it and adjust as you learn. That is useful advice for leads, but it is also a fair description of maintenance work. Most choices arrive with incomplete information. Wait for certainty and the backlog continues making decisions for you.

Working on SDKs has changed what I count as a successful release. A launch can be exciting, but the work that builds trust happens afterward: integrations continue working, old assumptions are tested against new platform behavior, and users do not need to know how much changed underneath them. “Nothing broke” is not much of a headline. It is still an outcome worth being proud of.

There is no tidy lesson here. Sometimes the right call is a migration. Sometimes it is one more compatibility fix. Sometimes it is admitting that a project needs a new maintainer. The hard part is noticing when the decision has changed—and making it before neglect makes it for you.

Hit reply and tell me: what are you still sustaining years after you shipped it, and would you make the same choices again?

Related reading on this week's theme 📚

Wally 7

Daniel Saidi releases version 7 of Wally, the wallet app he first built in 2012. The biggest change is underneath: Realm is gone, SwiftData is in, and the new storage layer removes a lot of code while adding private iCloud sync.

📍Level: Intermediate

Looking for Maintainers!

Matt Massicotte has more open-source projects than he can properly support, so he names them and asks for new maintainers. A candid post about ownership, handoffs, and the part of open source that begins after people depend on your work.

📍Level: Beginner

Running iOS Background Tasks Reliably, Part 1

Irving Popovetsky instrumented BGTaskScheduler on a real device and documented what actually affects background execution: task expiration, accidental rescheduling, energy budgets, force-quitting, and how foreground usage changes the system’s willingness to wake an app. A valuable field report on building around behavior iOS deliberately does not guarantee.

📍Level: Advanced

A Framework to Make Decisions Faster as a Lead Software Engineer

Mohammad Faani offers a practical framework for decisions that cannot wait for perfect information: separate reversible choices from irreversible ones, timebox the research, write down the uncertainty, and use the 70% rule when it is time to commit.

📍Level: Intermediate

More Incredible Tales of App Store Curation

Jeff Johnson continues documenting App Store curation problems, including suspicious rating patterns and developers shipping apps at astonishing volume. A reminder that keeping an app healthy also means living with systems you do not control.

📍Level: Intermediate

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

What Is a Swift Package Registry?

Dave Verwer explains the difference between SwiftPM, a package index, and a package registry—and why verified, immutable source archives can be faster and safer than fetching every dependency through Git.

📍Level: Intermediate

Coding 👨‍💻

Protecting SwiftUI Views With Authentication

A reusable RequiresAuthentication container for gating SwiftUI screens behind login, including inline and sheet-based flows, dismissal handling, and a view-modifier alternative. One important caveat is included too: hiding a screen does not replace server-side authorization.

📍Level: Intermediate

Empty States in SwiftUI with ContentUnavailableView

Kyle Browning walks through the ContentUnavailableView initializers and builds a reusable approach for search results, errors, offline screens, and other empty states.

📍Level: Intermediate

The Curious Case of the Missing SwiftUI Clicks

Buttons inside a bidirectional ScrollView stop responding after a few taps. Switching to vertical-only scrolling fixes the problem, although the reason remains unexplained. One to remember for the next impossible-looking SwiftUI bug.

📍Level: Intermediate

Preventing Transitive Swift Imports with Bazel

Swift permits a module to import dependencies it never declared directly. Adin Ćebić shows how the rules_swift layering check makes those accidental imports fail at build time, before they become part of the architecture.

📍Level: Advanced

iOS 27: StateReporter

Anton Gubarenko explores StateReporting, a new iOS 27 framework that attaches app-state context to MetricKit and Instruments. Instead of seeing only that a hang occurred, you can see what the app was doing when it happened.

📍Level: Intermediate

NSTextTable in Swift

iOS 27 brings NSTextTable, NSTextTableBlock, and related TextKit APIs to UIKit, making real tables possible inside NSAttributedString. It is meant for rich text—documents, invoices, reports—not as a replacement for UITableView.

📍Level: Intermediate

Apple 🍏

Changes for Apps in the European Union

Apple announced new EU business terms taking effect October 1. The update replaces the per-install Core Technology Fee with a 5% commission on digital transactions in apps distributed outside the App Store, revises other commission rates, expands alternative-distribution eligibility, and adds child-safety rules for alternative payments.

Embedded Swift Improvements Coming in Swift 6.4

Swift.org previews broader language support for Embedded Swift, including generalized existential types, untyped throws, and metatypes, plus floating-point parsing and error handling for concurrent operations on constrained targets.

AI & Tooling 🤖

Apple Foundation Models: Hybrid AI with Dynamic Profiles

Peter Friese builds a router that keeps smaller prompts on Apple’s on-device model and sends larger ones to Gemini. Dynamic Profiles hold the model choice, token-budget check, and model-specific instructions so the call site stays clean.

📍Level: Advanced

Translation Sub-Agents Go Brrrrrrrr

Amy Delves shares a localization workflow built around LocalizedStringResource, a strings catalog for each view, detailed translator comments, and Xcode 27’s translation skill. It is a useful example of shaping a codebase so both people and coding agents have the context they need.

📍Level: Intermediate

AI Wanted to Give Up. The Human Didn’t.

Fatbobman reflects on Linus Torvalds’s “debug session from hell”: 24 debugging patches and 18 kernel boots to find a one-line fix. AI helped with the repetitive work, but human judgment supplied the persistence. A timely reminder that faster tools do not remove the hardest part of debugging—knowing when the evidence still does not add up..

📍Level: Intermediate

Tutorials 📒

Presenting Alerts and Confirmation Dialogs from Identifiable Data in SwiftUI

Natascha Fadeeva demonstrates the new iOS 27 item-based APIs for presenting alerts and confirmation dialogs. Binding presentation directly to an optional Identifiable value removes the separate Boolean state—and the synchronization bugs that can come with it.

📍Level: Intermediate

Video🎥

AI-Assisted TDD in Practice (Swift + AI)

Quality Coding demonstrates how test-driven development can put useful boundaries around AI-generated Swift code. The tests define the expected behavior, while the coding assistant works toward small, verifiable changes instead of producing an entire implementation at once.

📍Level: Intermediate

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Another Sunday, another “Devs for Devs” issue!

Meet Faiq Khan , an experienced iOS engineer with a strong background in building and shipping mobile products.

Today, he answers a simple question many indie devs face: what should an indie dev keep in mind while developing?

With his years of hands-on development experience and practical knowledge from working across different projects and teams, he shares his tips on how to keep moving forward.

P.S. You can check out and follow Faiq’s work on LinkedIn and website.

A Strategy for Indie Developers

As indie developers, we lack the safeguarding structure that full-sized product teams enjoy. We don’t have a dedicated PM, a scrum master, or the formal structure of a sprint or squad environment, systems designed to handle heavy planning, detailed estimation, and peer discussion.

You are often completely on your own making those decisions.

While traditional agile processes can work, as indie devs we need to relentlessly streamline how much energy we assign to planning overhead in order to deliver features in a reasonable time.

It’s easy to get caught up thinking about the distant product we want to build:

The big vision.

The polished UI.

The features we haven’t even started yet.

The version that exists somewhere months down the road.

Having that long-term vision is important. It gives you direction and something to work towards.

But there’s a danger in staring at the destination for too long: you can lose sight of what actually needs to happen today.

I’ve found it much more useful to think in two layers:

Long Eye: Where am I ultimately trying to take this product?

Short Eye: What specifically needs to happen today to move me one step closer?

And that short-term vision should get really short.

Not “build the new creation system this week.”

Instead:

“Today, get the item selection working.”

Tomorrow might be:

“Connect the selected item to the inventory system.”

Small, achievable steps.

There’s another benefit to working this way: small steps make it harder to fall down rabbit holes.

We’ve all been there. You start working on one feature, notice something that could be improved, start refactoring it, discover another problem, research a new approach… and suddenly three hours have disappeared and you’re nowhere near what you originally set out to do.

Daily Goals

A clearly defined daily goal gives you something to anchor yourself to.

You can still explore. You can still experiment. But you always have a destination for the day.

For me, a good daily goal should be (MASS):

Meaningful: it should move the product forward, even if only slightly.
Achievable: something I genuinely have time to complete.

Simple: clear enough that I don’t spend half the day deciding what to do.

Small: scoped to fit within the day.

And there’s one task I always want to finish the day with:

Review tomorrow’s agenda.

Before closing the laptop, decide what tomorrow’s small win looks like.

That way, when you sit down the next morning, you’re not asking:

“Where do I start?”

You already know.

The Long Eye tells you where you’re going.

The Short Eye tells you what to do next.

Keep the steps small, stay out of the rabbit holes, and keep moving forward.

Think big. Plan small. Ship every day.

This week’s articles share a common thread: frameworks can change significantly beneath APIs that look exactly the same.

SwiftUI’s compiler performance is improving, @State has a new underlying implementation, and developers are still debating whether the framework’s long-standing limitations are acceptable. Together, these pieces show why understanding the mechanism—not just the API—often leads to faster debugging and better engineering decisions.

Have you ever had to investigate a SwiftUI or UIKit behavior that the documentation couldn’t explain? Hit reply—I’d love to hear what you found.

Under SwiftUI's Hood, Nothing Is As Simple As It Looks

with Divya Ravi — Technical Editor, iOS engineer

Seven years after its introduction, SwiftUI still asks developers to trust a considerable amount of hidden machinery. This week’s reading made a strong case for looking beneath that abstraction.

Start with ContentBuilder. Apple introduced it at WWDC26 as a way to improve SwiftUI type-checking performance. But as Fatbobman explains, the improvement does not come from adding another builder type. It comes from restructuring the shared builder APIs used by containers such as Group and ForEach.

By relying on TupleContent and deferred conditional conformance, SwiftUI gives the type checker less work to perform. The code developers write remains largely unchanged, while the compiler does substantially less work behind the scenes.

That distinction matters. When build performance improves without an obvious source change, it is easy to treat it as compiler magic. Understanding the implementation gives us something more useful: a clearer mental model for why certain view structures are expensive and why newer APIs may compile faster.

A similar change is happening with @State.

Stewart Lynch found that in Xcode 27, @State is implemented as a macro rather than a property wrapper. The syntax remains familiar, but the initialization behavior changes in an important way.

Previously, the initializer expression could be evaluated during every view recreation, even when SwiftUI ultimately preserved the existing state value. With the macro implementation, that expression is evaluated lazily.

For a simple integer or Boolean, the difference is unlikely to matter. For state initialized through a database lookup, file operation, or expensive computation, it can eliminate work that developers may not have realized was happening.

These two changes approach the same problem from different directions. ContentBuilder improves compiler behavior beneath a stable API, while the new @State implementation changes the underlying mechanism without changing how the declaration looks. Both improvements are nearly invisible unless someone profiles the behavior, examines the generated code, or asks why the result changed.

That brings us to Yakov Manshin’s “SwiftUI After 7 Years: A Story of Mediocrity,” a deliberately sharp retrospective that generated more than 300 comments on Hacker News.

His central argument is difficult to dismiss completely: after seven years, “it is still a young framework” becomes a less convincing explanation for persistent problems. Focus management, drag-and-drop, platform inconsistencies, and difficult edge cases have survived several release cycles.

I do not agree with every conclusion in the article, but the larger tension is real. SwiftUI’s internals continue to improve, while some visible limitations remain stubbornly familiar.

Those are separate measures of maturity. Compiler performance can improve dramatically while developers still struggle with basic interactions. A framework can gain powerful new APIs without resolving gaps in older ones. When we say SwiftUI has come a long way, it is worth being precise about which part of SwiftUI we mean.

Chang-Jui Lin’s article on building an EPUB reader with CoreText offers a practical counterpoint. Instead of adapting a WebView or relying on a higher-level text component, Lin built directly on CoreText to support reflowable content, fixed layouts, media overlays, and bidirectional text.

It is a much lower level of abstraction—and a much larger engineering commitment. But it also provides the control required for a problem that higher-level frameworks do not solve cleanly.

That is not an argument for rebuilding every framework primitive. Most abstractions are valuable precisely because they prevent us from owning that complexity. But when an abstraction becomes the constraint, understanding the layer below it can reveal options that are otherwise easy to miss.

The broader lesson from this week is not that SwiftUI is good or bad. It is that no framework should remain a complete black box.

The engineers who diagnose difficult problems fastest are often the ones willing to inspect the generated code, profile the rebuild, trace the macro expansion, or move down the stack when the current abstraction stops being useful.

Frameworks will continue to improve while retaining frustrating gaps—sometimes within the same release. The durable skill is learning how to investigate what the framework is actually doing. That understanding makes debugging faster, design decisions clearer, and point-release surprises far less surprising.

What is the last SwiftUI, UIKit, or Swift behavior you had to reverse-engineer because the documentation did not explain enough?

Related reading on this week's theme 📚

ContentBuilder Explained: The Secret Behind SwiftUI's Type-Checking Speedup

An investigation into how Apple improved SwiftUI type-checking performance through TupleContent, shared builder APIs, and deferred conditional conformance. A useful read if you want to understand what changed beneath the WWDC26 performance claims.

📍Level: Advanced

A Change of State

A focused demonstration of @State becoming a macro in Xcode 27. The new implementation lazily evaluates its initializer, avoiding unnecessary work when SwiftUI recreates a view.

📍Level: Intermediate

SwiftUI After 7 Years: A Story of Mediocrity

A critical assessment of SwiftUI’s maturity and the framework limitations that remain after seven years. You may not agree with every argument, but it is a useful prompt to reconsider which rough edges we have started treating as normal.

📍Level: Advanced

Adapting EPUB 3 Features to CoreText in Yuedu Reader

A detailed look at implementing EPUB 3 rendering directly with CoreText, including reflowable text, fixed layouts, media overlays, and bidirectional content. It shows both the control and the complexity involved in owning a native text-rendering pipeline.

📍Level: Advanced

The Curious Case of the missing SwiftUI Clicks

A real-time debugging log of SwiftUI buttons that quietly stop responding inside a horizontal ScrollView — fixed, but still without a clear answer for why. A fitting closer for this week's theme: sometimes going under the hood just leaves you with a better mystery.

📍Level: Intermediate

SwiftUI Lies: Your Animation Breaks Because One View Is Actually Multiple Layers

A first-person debugging story showing why a button’s label and background can animate independently — and how ZStack, drawingGroup, compositingGroup, and geometryGroup each solve (or half-solve) the problem for different reasons. A concrete companion to this week’s “nothing is as simple as it looks” theme.

📍Level: Intermediate

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

IP and DNS Leaks in WebKit Affecting Proxy Browsers and Apple iCloud Private Relay

Researchers document a WebKit issue that can expose a user’s real IP address and DNS queries while using proxy-based browsers or iCloud Private Relay. Important context for teams making privacy guarantees around WebKit-based experiences.

📍Level: Intermediate

Coding 👨‍💻

How to stream SSE with URLSession in Swift

A practical implementation of Server-Sent Events using URLSession.bytes(for:), along with a small test server. Particularly useful for apps consuming AI responses or other incrementally delivered data.

📍Level: Intermediate

Type-safe JSON and JSONB in StructuredQueries

StructuredQueries 0.35 introduces schema-checked support for JSON and JSONB data in SQLite. The article shows how to retain type safety while working with semi-structured local data.

📍Level: Advanced

Using Top Functions Mode in Instruments to Quickly Find the Slowest Code

A concise guide to the Top Functions view in Xcode 26.4’s profiling instruments. Sorting by self-weight and inspecting flame graphs can make it much easier to identify where execution time is actually being spent.

📍Level: Intermediate

Installing simulator runtimes from the command line

Command-line steps for installing simulator runtimes when Xcode 27 beta remains stuck on “fetching download information.” A useful workaround to keep nearby when the graphical installer fails.

📍Level: Intermediate

Sendable and @Sendable closures explained with code examples

A clear explanation of Sendable types and @Sendable closures, with examples showing how values move safely across concurrency boundaries. A solid reference when working through Swift 6 strict-concurrency warnings.

📍Level: Intermediate

Taking control of toolbar items in SwiftUI

Explores SwiftUI toolbar placement, customization, and platform-specific behavior. Helpful for interfaces where the default toolbar layout does not provide enough control or consistency.

📍Level: Intermediate

Apple 🍏

Get ready for new creative assets on the App Store

Apple previews new creative and marketing asset options for App Store product pages. Worth reviewing before planning your next product-page update or launch campaign.

TestFlight Update

The latest TestFlight release notes, covering recent changes to Apple’s beta-distribution workflow. A quick check before your next external-testing cycle may save some surprises.

AI & Tooling 🤖

Using Cursor in Xcode 27

A hands-on guide to connecting Cursor to Xcode 27 through Agent Client Protocol support. It offers an early look at how external coding agents can participate directly in an Xcode-based workflow.

📍Level: Intermediate

Build a Local Codex Token Usage Ledger Without Replay Errors

A practical fix for tracking token usage across Codex/Claude coding-agent sessions without hitting replay errors — useful if AI agents are part of your build pipeline, even outside the Swift/iOS-specific tooling this newsletter usually covers.

📍Level: Intermediate

Tutorials 📒

Recording VoiceOver on iOS & macOS

A practical guide to capturing VoiceOver audio for accessibility testing, bug reports, and demos. iOS supports the workflow through screen recording, while macOS requires a virtual-audio device.

📍Level: Intermediate

Community🤝

SwiftUI should become Open-Source

Makes the case that open-sourcing SwiftUI could help developers diagnose and address long-standing issues such as keyboard focus and drag-and-drop. Even if the proposal feels unlikely, the argument raises useful questions about framework transparency and community participation.

📍Level: Intermediate

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

This week, our guest author is Noam Efergan, a Senior Mobile Engineer at Yazio specializing in iOS development.

A self-taught developer based in the UK, he’s also a technical writer with a particular interest in CI/CD, automation, and modern mobile development practices.

Beyond his engineering work, Noam is a core member of the SwiftLeeds team and an active contributor to the iOS community, sharing his experience through articles, conference talks, and open discussions about mobile engineering.

Let’s see how a coding task can lead to a marketing video matching the latest updates.

P.S. You can check out Noam’s work on LinkedIn, X, and website.

Treating Marketing Assets Like Build Artifacts

Every time I made a meaningful change to Dee’s interface, I created a second task for myself: remake the marketing.

A label moved, a timer changed, or a new state appeared. Suddenly an App Store screenshot was stale, a clip no longer matched the product, or a translated screen had to be recorded again. Recreating the right state by hand was often slower than the UI change itself. Timers kept moving, animations settled at different moments, and sample data was never quite identical.

That is a familiar indie developer problem. The person building the product is also producing the screenshots, launch posts, and promo videos. Repeating fragile setup work is a poor use of that person’s time.

I eventually stopped treating marketing assets as files I created manually. I started treating them as build artifacts that should be reproducible from the real app.

Start with an Exact SwiftUI State

Dee is a Muay Thai training app with time-based workout screens. That makes manual capture especially awkward. By the time I navigate to the correct round, dismiss the right controls, and start recording, the timer has already changed.

The solution begins inside the app. In debug builds, a launch argument selects a named marketing state. Each state creates the same typed models used by the product, but with controlled input. A frozen clock stops the timer from drifting while XCTest waits for the interface.

#if DEBUG
enum MarketingScreenshotSeed {
    static let launchArgument = “-AppStoreScreenshotMode”

    enum Mode: String, CaseIterable, Sendable {
        case roundTimer = “round-timer”
        case restNext = “rest-next”
        case liveActivity = “live-activity”
    }

    static func makeClock() -> TestClock {
        TestClock(now: Date(timeIntervalSince1970: 1_800_000_000))
    }
}
#endif

The important part is not the particular launch argument. It is the boundary. Marketing fixtures control dependencies and data, but they do not replace the production view with a separate mock screen. If I change the actual workout layout, the next capture contains that change.

Keeping the fixtures debug-only also prevents this tooling from becoming a hidden route through the release app.

Let XCUITest Operate the Camera

Once the app can launch directly into a stable state, XCUITest becomes a reliable camera operator. The test starts the requested mode and locale, waits for the real screen, and stores the screenshot as a named attachment.

private func captureMarketingLocale(_ locale: String) {
    for (name, mode) in marketingScreens {
        let app = launchWorkout(locale: locale, mode: mode)
        settle(seconds: 1.5)

        let attachment = XCTAttachment(screenshot: app.screenshot())
        attachment.name = “\(locale)_\(name)”
        attachment.lifetime = .keepAlways
        add(attachment)

        app.terminate()
    }
}

I currently run the capture flow across six locales. Locale is just another launch input, so translated screens follow the same path as English instead of becoming a separate manual checklist.

Animations introduced another source of flakiness. A view can be accessible before the simulator has produced a complete frame. For the more animated screens, the test samples screenshots until it receives the same PNG twice. If the compositor never settles, the test fails rather than quietly exporting a broken image.

That failure is useful. When a UI change invalidates a fixture or makes a screen unstable, I find out during capture. I do not discover it weeks later while assembling launch material from an old folder.

Move from XCTest to Remotion

The XCTest attachments are extracted from the result bundle and copied into a small marketing workspace. From there, Remotion turns the real app captures into code-driven vertical video.

<AbsoluteFill>
  <TransitionSeries>
    <TransitionSeries.Sequence durationInFrames={120}>
      <FastHookScene screenshotPath={roundScreenshotPath} />
    </TransitionSeries.Sequence>
    <TransitionSeries.Transition
      presentation={slide({direction: “from-right”})}
      timing={springTiming({durationInFrames: 15})}
    />
    <TransitionSeries.Sequence durationInFrames={150}>
      <FastProofScene
        nextScreenshotPath={nextScreenshotPath}
        summaryScreenshotPath={summaryScreenshotPath}
      />
    </TransitionSeries.Sequence>
  </TransitionSeries>

  {deeCueAudioPath ? (
    <Sequence from={105} durationInFrames={135}>
      <Audio src=/__u/thosewhoswift.substack.com/%7BstaticFile(deeCueAudioPath)%7D />
    </Sequence>
  ) : null}
  <TimedCaptions captions={captions} />
</AbsoluteFill>

The composition controls timing, transitions, captions, framing, and audio. The current example renders at 1080 by 1920, 30 frames per second, and 12 seconds. It uses Dee’s captured screens, and the composition can include a cue copied from the app’s shipped resources rather than recreating the interface or sound for the advertisement.

I also added a capture manifest and hashes around the process. The manifest binds the exact screenshots, audio, and composition properties used by a render. Preflight checks dimensions, captions, asset provenance, and whether inputs changed after capture. Human review remains the final step.

This is more machinery than a single promo clip needs. It becomes valuable because the output is recurring. One source capture can support App Store screenshots, social video, carousels, and localized variants without pretending that a design mock is the shipping product.

What was Worth Automating

Coding agents helped me move faster through repetitive plumbing, test cases, and review. They were useful for tracing asset paths and checking consistency across the Swift and TypeScript sides. They did not decide what the product should claim, which screen represented it honestly, or whether the final creative was ready to publish. Those decisions stayed with me.

The pipeline still has a maintenance cost. Fixtures must evolve with the app. UI tests need care around animations and simulator behaviour. Remotion adds another toolchain. If I needed one screenshot for one launch, I would take it manually.

I would consider this approach when an app has dynamic screens, several locales, frequent UI changes, or an ongoing need for product content. Start with one painful state, not a complete marketing platform. Add a launch argument, freeze its dependencies, capture it in a UI test, and only automate the next stage when repetition justifies it.

The larger lesson for me is that testability has uses beyond tests. When an app can reproduce an exact state on demand, it becomes easier to debug, demonstrate, localize, and market. The best part of this workflow is not that it produces a video. It is that the video remains connected to the product that users will actually open.

Swift concurrency stopped being the scary new thing a while ago — it’s just how we write Swift now. But “we adopted it” and “we understand it” are different claims, and this week’s picks live in the gap between them. The theme: concurrency that’s grown past the tutorials and into the parts of real apps where the edges actually are.

Wrestling with an isolation error that makes no sense? Reply — those are the best ones to dig into together.

The Delegate Is Dead. Long Live the Actor.

with Divya Ravi — Technical Editor, iOS engineer

Every Apple framework of a certain age carries the fingerprints of the era it was born in. Open CoreBluetooth, or CoreLocation, or any of the old guard, and you’re not just reading an API — you’re reading 2011. The delegate pattern everywhere. State machines you assemble by hand across six callbacks that fire in an order the compiler knows nothing about. A “did” method for every possible thing that could happen, and a strong-reference dance you have to get exactly right or the whole thing quietly deallocates out from under you.

For a decade, that was just the cost of doing business on Apple platforms. We learned it, we internalized it, and we mostly stopped noticing how strange it was. You want to read one value off a Bluetooth sensor? Sixty lines, seven delegate methods, and a comment somewhere that says // now what? for the disconnect case nobody fully handled.

What’s happening in Swift right now is the slow, deliberate dismantling of that world — and I don’t think we talk about it plainly enough. Structured concurrency didn’t just give us a nicer way to write async code. It changed what the shape of correct code looks like. The delegate era scattered your logic across callbacks because callbacks were the only tool for “tell me when this happens later.” Async/await collapsed that back into something you can read top to bottom: wait for the radio, find the device, connect, stream the readings. The program finally looks like the sentence you’d use to describe it.

But here’s the part I actually want to make the case for, because it’s subtler than “async is nicer.” The real shift isn’t syntax. It’s who enforces correctness. In the delegate world, thread-safety was a promise you made to yourself in a comment — “these callbacks arrive on this queue, so be careful.” Nobody checked. You just had to be right, every time, forever, including the time six months from now when a tired version of you touches that file at 4pm on a Friday. Swift 6’s isolation model takes that promise and hands it to the compiler. The actor doesn’t ask you to be careful about which context your state is touched from. It makes touching it from the wrong context not compile.

That is a genuinely different relationship with your own code. And it’s why the isolation errors everyone complains about are, I’d argue, mostly a good thing wearing an annoying costume. When the compiler rejects your code with some knotty message about a non-Sendable type crossing an actor boundary, it is usually not being pedantic. It’s telling you about a data race that, in the old world, would have shipped — and surfaced three weeks later as a one-in-ten-thousand crash you could never reproduce. The friction moved earlier. That’s the whole trade. You pay at compile time instead of paying at 2am when the pager goes off.

The catch — and there’s always a catch — is that the model is subtle exactly where it matters most. Protocols and global actors interact in ways that surprise even people who’ve been doing this for years. The difference between isolating a protocol, a conformance, and a requirement is real, and getting it wrong produces errors that feel arbitrary until the mental model clicks. That’s the actual work of this era: not memorizing which keyword goes where, but building an intuition for what the compiler is protecting you from, so the errors read as help instead of harassment.

So if you’ve been treating Swift concurrency as a box you check — “yes, we migrated, yes, it compiles” — I’d gently push on that. The migration is the easy part. The understanding is the part that pays off, because it’s the difference between fighting the compiler and letting it do the thing it’s uniquely good at: proving, before your code ever runs, that an entire category of bug simply cannot happen.

The delegate taught us to be careful. The actor lets us stop having to be. That’s not a small upgrade. That’s the ground moving.

What concurrency concept finally clicked for you — and what’s still fighting you? Hit reply. The best answers make next week’s issue.

Related reading on this week's theme 📚

Concurrency past the tutorials — where the real edges are.

Bluetooth Without the Delegate Dance

Kyle Browning rebuilds CoreBluetooth for the Swift 6.2 era — writing the same heart-rate feature three ways (raw delegates, a 2021 wrapper, and a modern actor-based design) to show exactly how much the language moved. The payoff: tying an actor's isolation directly to CoreBluetooth's delivery queue via custom executors, so events arrive already isolated. A masterclass.

📍Level: Advanced

An Even Closer Look at Protocols and Global Actors

Matt Massicotte on the genuinely subtle interaction between protocols and global actors — the difference between isolating a protocol, a conformance, and a requirement, and why getting it wrong produces errors that feel arbitrary until the model clicks.

📍Level: Advanced

Swift 6.2 Concurrency in Practice: Default to MainActor, Escape on Purpose

Blake Crosley on the mental-model flip in Swift 6.2 — default your module to the main actor, then leave it on purpose in named places. The same data-race guarantee, far fewer false-positive errors, drawn from shipping it across a real app family.

📍Level: Intermediate

Building Testable SwiftData Apps

Mohammad Azam on structuring SwiftData so it's actually testable — keeping persistence at arm's length so your logic runs in tests without a live store fighting you at every step.

📍Level: Intermediate

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

What's New in Swift: July 2026 Edition

The official Swift.org digest rounds up the month across the project — releases, evolution proposals, community talks, and the news that Swift now runs in a broader range of IDEs including Cursor, VSCodium, Kiro, and Antigravity via the Open VSX Registry.

📍Level: Beginner

Coding 👨‍💻

Managing Focus in SwiftUI with FocusState

Natascha Fadeeva on driving focus properly in SwiftUI — FocusState, programmatic focus changes, and the keyboard-management details that make forms feel right.

📍Level: Intermediate

SwiftUI Document APIs in the 2027 Releases: Everything You Need to Know

Sagar Unagar on the new Document protocol — snapshot-based updates, efficient disk access, and how it layers on top of the existing FileDocument world without breaking it.

📍Level: Advanced

Using SwiftUI's ContentBuilder with Non-View Types

Artem Novichkov digs into ContentBuilder — the unified builder replacing per-container overloads — and how to use it with non-view types, plus what it means for compile times.

📍Level: Advanced

iOS 27: Working with the Media Intelligence Framework

Anton Gubarenko digs into iOS 27’s new Media Intelligence framework — what it exposes, what it’s actually good for, and where it fits alongside the existing media APIs.

📍Level: Intermediate

Apple 🍏

Hello, Developer: August 2026

Apple's monthly developer digest for August — a guided tour of the biggest WWDC26 updates, a walkthrough of building App Store assets for iOS 27, and a profile of the team behind the hit game "Is This Seat Taken?"

Design 🎨

Concentric Buttons with OS 27's SwiftUI APIs

Alexander Weiss on the new concentric-shape APIs in OS 27 — building nested, concentric button shapes that stay aligned the way the new design language expects.

📍Level: Intermediate

Adaptive SwiftUI Toolbars in iOS 27

Natalia Panferova on the new adaptive toolbar behavior in iOS 27 — how toolbars reflow across size classes and what you get for free versus what you still configure.

📍Level: Intermediate

AI & Tooling 🤖

Using AI Without Losing Your Critical Thinking

Bruno Rocha on staying sharp while leaning on AI tools — a thoughtful, non-hype take on where agents genuinely help and where offloading judgment quietly costs you.

📍Level: Beginner

How to Use Git Worktree — and How AI Agents Use It

Mohammad Faani on git worktrees — the underused feature that lets you check out multiple branches at once, and why it's suddenly relevant as AI agents work across branches in parallel.

📍Level: Intermediate

Video 🎥

Previewing SF Symbols with Apple's Own Renderer

Amy Worrall wires up Apple's own SF Symbols renderer to preview symbols exactly as the system draws them — a neat bit of tooling for anyone who's been squinting at approximations.

📍Level: Advanced

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Not on Wednesday as usual, from now on we’ll see each other twice a week. Welcome to our new newsletter segment, “Devs for Devs”

We used to run a whole separate newsletter for this called “Indie App Devs” Now, every Sunday, we’ll feature a new segment from world-class, well-known devs here.

We’re starting with Natalia Panferova. I’m sure she doesn’t need to be introduced to you. She’s a software engineer, author, and former member of Apple’s core SwiftUI team, where she helped design and build SwiftUI APIs.

She has worked with startups and large companies across Europe and New Zealand, building web and mobile applications.

And without further ado, let’s jump into today’s topic and prepare our apps for iOS 27.

P.S. You can check out Natalia’s work on LinkedIn, X, and her website.

Since WWDC, I’ve been spending a lot of time exploring the changes coming in iOS 27 and working through what they mean for the apps I maintain, from rebuilding them with Xcode 27 and testing layouts at different sizes to reviewing SwiftUI changes that may affect existing code.

There are plenty of new APIs to explore, and it’s always tempting to start adding them straight away. But for an existing app, I think it’s more useful to begin by checking how well it works with the new SDK and system behavior. Much of this preparation isn’t about adopting new APIs at all. It’s about making sure existing layouts work when the app is resized, reviewing the visual changes that come from rebuilding with Xcode 27, and addressing new compiler errors and warnings in existing SwiftUI code.

The amount of work will be different for every app, but these are the main areas I’d recommend reviewing.

Supporting Resizable iPhone Apps

One of the most significant changes in iOS 27 is that iPhone apps can now appear at more flexible sizes. This makes it increasingly difficult to assume that an iPhone app will always run in a narrow portrait window or at one of a small set of familiar screen dimensions.

Until recently, our walking app Strolly only supported portrait orientation on iPhone. It makes heavy use of non-modal sheets placed over a map, allowing users to adjust their route preferences while continuing to interact with the content underneath. When we added landscape support in preparation for iOS 27, we found that the system sheet didn’t preserve its non-modal presentation after rotation. It became a full-screen sheet and covered most of the map.

We ended up building an adaptive panel that appears along the bottom in a narrow layout and moves to the trailing edge when enough width becomes available. The layout decision is based on the actual scene width rather than the device type or horizontal size class. This lets the same presentation adapt to iPhone rotation, iPad multitasking, and window resizing.

Not every app will need a custom presentation, but it’s worth checking for similar assumptions throughout the interface. Fixed frames, hard-coded screen dimensions, and layouts that switch only on device idiom can all become problematic when the available space changes.

Xcode 27 includes resize handles in SwiftUI previews and a resizable iOS simulator, which make it easier to test a range of widths without relying only on predefined devices. I’d pay particular attention to toolbars, sheets, overlays, forms, keyboards, and any screen that places several controls side by side.

It’s also important to check that state remains stable while the available size changes. Controls shouldn’t disappear or become difficult to reach, and resizing shouldn’t unexpectedly reset navigation, scroll position, selections, or data owned by the view hierarchy.

Reviewing the Liquid Glass Appearance

Apps built with Xcode 27 automatically receive the latest refinements to the Liquid Glass design. Many of these changes come through standard SwiftUI and UIKit components, so rebuilding the app and inspecting the result should come before adding custom glass effects.

Navigation bars, tab bars, sheets, menus, toolbars, and standard controls may all look slightly different. Custom interfaces can also produce unexpected results when they place translucent controls over photographs, maps, gradients, or similarly colored content.

I’d test these screens with accessibility settings such as Increased Contrast and Reduce Transparency. Users have more control over the appearance of Liquid Glass in iOS 27, so the interface should remain clear across those variations rather than depending on one specific level of transparency.

Toolbars need some extra attention now that apps can appear at more sizes. Xcode 27 adds SwiftUI APIs for controlling which toolbar items remain visible and which move into the overflow menu. We can assign a visibility priority to important groups, deliberately place less frequently used actions in a ToolbarOverflowMenu, and use the topBarPinnedTrailing placement for an action that should always remain available.

Before adopting these APIs, I’d resize the existing toolbar and see what the system does by default. Standard behavior may already be sufficient. Where it’s not, the new controls let us express which actions are most important without replacing the system toolbar with a custom implementation.

Building the Existing App with Xcode 27

I like to begin a new SDK migration by building the existing project before introducing any new features. This keeps compiler errors and warnings caused by the new SDK separate from issues introduced while adopting new APIs.

Building with Xcode 27 brings a few SwiftUI changes worth checking. One of the most notable is that @State is now a macro rather than a property wrapper. This fixes a long-standing performance issue when an @Observable class is used as the default value of a state property. The initial expression is now evaluated lazily, so the observable model is created only when SwiftUI sets up the state storage rather than every time the view value is recreated.

We should still avoid assigning an observable model to @State inside a view initializer. This creates a new model whenever the initializer runs, even though SwiftUI preserves only the first value in its state storage. If the model depends on changing input from the parent, it can also retain stale data because later assignments are ignored.

Custom environment values are another area to check. Xcode 27 now warns when an @Entry declaration creates a new class instance directly in its default expression. Every fallback environment lookup would otherwise return a different reference, which can make SwiftUI treat the value as changed and reevaluate dependent views unnecessarily.

Some existing view expressions can produce new ambiguity errors because SwiftUI’s result builders are now unified under ContentBuilder. For example, expressions passed directly to overloaded APIs such as overlay and background may need to use their trailing-closure variants so the compiler can select the intended overload.

Adopting New SwiftUI APIs

Once the app builds and works correctly, we can start looking for places where the new APIs solve an existing problem or let us remove custom code.

Swipe actions are no longer limited to rows inside a List. In iOS 27, applying swipeActionsContainer() to a ScrollView enables coordinated swipe actions for rows in a LazyVStack, LazyVGrid, or custom layout.

SwiftUI also has new native reordering APIs for stacks, grids, and other containers. We apply reorderable() to the dynamic content and reorderContainer(for:) to the enclosing container. SwiftUI manages the drag preview, insertion placeholder, and animation, while the app receives a ReorderDifference to apply to its model.

AsyncImage has gained new initializers that accept a URLRequest, giving us control over request headers, cache policy, and timeout without requiring a separate image-loading implementation. A new asyncImageURLSession() modifier can provide a custom session to asynchronous images in part of the view hierarchy.

These are all useful improvements, but an app doesn’t need to adopt them simply because they are new. I’d start with areas where the current implementation is limiting the interface, requires significant custom coordination, or has been difficult to maintain.

If the app continues supporting older versions of iOS, new APIs will also need an availability strategy. In some cases, the new behavior can be an enhancement on iOS 27 while the existing implementation remains as the fallback. In others, it may be better to wait until the deployment target can move forward rather than maintain two complicated code paths.

Testing Before the Public Release

An app prepared for iOS 27 still needs to work correctly on every version it supports. I’d test the main flows on both iOS 27 and the oldest supported system, paying particular attention to code guarded by availability checks.

Accessibility and localization can expose layout issues that don’t appear with default settings. I’d check the main screens with large Dynamic Type sizes, VoiceOver, Increased Contrast, Reduce Motion, and longer localized strings. These tests become especially useful alongside resizing because the most difficult layouts often combine a narrow width with larger content.

For performance-sensitive apps, Instruments 27 adds Run Comparisons for measuring changes between profiling sessions and expands the Swift executors instrument for investigating work running on the main actor and other executors. iOS 27 also introduces a new Swift-first MetricKit API. It continues to deliver app-health metrics and crash and hang diagnostics, while adding memory exception diagnostics and the ability to break metrics down by app-defined states.

Finally, I’d avoid leaving all of this work until the last beta. APIs and behavior can still change throughout the beta period, but testing early gives us more time to report issues through Feedback Assistant and adjust the app without rushing just before the public release.

SwiftUI Books with 20% off! 📚

New SDK releases are exciting, but they also remind me how important it is to understand the behavior behind the APIs we use. Many of the issues Xcode 27 now helps us identify are related to the same fundamental topics we deal with every year: view identity, state ownership, data dependencies, layout, and performance.

I cover these foundations in SwiftUI Fundamentals, which explains SwiftUI’s core principles and underlying mechanisms in depth. My newer book, The SwiftUI Way, builds on that foundation with practical guidance for structuring production apps, managing data flow, minimizing unnecessary view updates, and avoiding subtle anti-patterns as projects grow.

Both books include free lifetime updates. I recently released a substantial update to “The SwiftUI Way” with expanded guidance on data flow, view performance, stable custom bindings, environment values, and the changes to @State in Xcode 27.

Readers of this newsletter can use the coupon code ThoseWhoSwift" to get 20% off any of my books or book bundles until the end of August. You can find all the available options on the Nil Coalescing books website.

iOS 27 shipped, and now the real work starts — not adopting the shiny new features, but finding where they rub against the app you’ve already built. Liquid Glass is the most visible example: stunning in the keynote, strange in a UIKit view that predates it by a decade. But it’s the same story across the cycle — the gap between what demos cleanly and what survives contact with a real, aging codebase. This week is about that gap, and the field notes people are writing as they hit it.

Hit an iOS 27 surprise in your own app? Reply and tell me — I’m collecting the good war stories.

When the Glass Meets the Girder

with Divya Ravi — Technical Editor, iOS engineer

There’s a particular moment in every major design transition that nobody puts in the keynote. It’s the moment you build your project against the new SDK, launch the app you’ve shipped for years, and watch something you didn’t touch look subtly, unmistakably wrong. A button with the wrong corner. A bar that doesn’t blur where it used to. A control that was crisp yesterday and is now floating in a way you never asked for. Welcome to Liquid Glass in production.

I want to talk about that moment honestly, because the discourse around a new design language tends to split into two unhelpful camps. One says it’s gorgeous and you should adopt it everywhere immediately. The other says it’s a regression and you should fight it. Both miss the actual engineering reality, which is more interesting and more useful: a system-wide design language is not a coat of paint you apply. It’s a set of assumptions the framework now makes about your views — and the friction you feel is the distance between those new assumptions and the ones your codebase was built on.

Here’s the thing about Liquid Glass specifically. It’s a material, and materials are contextual by nature. A glass button assumes it sits on top of something worth seeing through. A minimizing bar assumes there’s content behind it that benefits from the effect. These are reasonable assumptions — until they meet a ten-year-old UIKit view hierarchy that was architected when every surface was opaque and every layer was flat. The framework does its best to adapt your old views to the new material, and most of the time it succeeds. The pitfalls live in the cases where it can’t, and those cases are exactly the ones a keynote demo will never show you, because keynote demos are built fresh, in the new world, with none of the accumulated assumptions of a real app.

This is why “just adopt it” is bad advice and “just fight it” is worse. The right posture is the one experienced engineers take toward any system-level change: understand what the framework now assumes, audit where your app violates those assumptions, and decide — deliberately, view by view — where to adapt and where to opt out. Liquid Glass gives you compatibility escape hatches for a reason. They’re not admissions of failure. They’re the framework acknowledging that your app has history, and history has weight.

The deeper lesson here isn’t about glass at all. It’s about what a design language actually is, underneath the marketing. It’s a contract about how surfaces relate to each other — depth, translucency, hierarchy, motion. When Apple changes that contract, every view you own is silently re-signed under the new terms, whether you read them or not. The apps that transition well aren’t the ones that adopt fastest or resist hardest. They’re the ones that treat the new contract as something to actually read — to understand where their existing UI agrees with it, where it conflicts, and where a five-minute opt-out saves a week of chasing a visual bug that was never a bug, just a disagreement about assumptions.

And Liquid Glass is only the most visible instance of a pattern that runs through this whole release. The same gap shows up everywhere real apps meet iOS 27: in the rendering model, in the architecture decisions that determine how easily you adapt, in the long-standing rough edges the framework quietly smoothed while you weren’t looking. The friction isn’t a bug in the release. It’s the tax every mature codebase pays when the platform moves — and the apps that pay it cheaply are the ones built to bend.

So if you’re staring at a control that looks wrong this week and you didn’t change it, you’re not losing your mind. The framework changed the terms. Go read them — the field guides are already being written, and the good ones map the pitfalls before you fall in. That’s the whole job this cycle: not adopting blindly, not resisting reflexively, but understanding precisely where the new platform meets the girder of everything you already built.

Related reading on this week's theme 📚

iOS 27 meets real apps — the friction, the fixes, and the field notes. Liquid Glass leads, but the theme runs deeper: rendering, architecture, and the rough edges the framework quietly smoothed.

Liquid Glass: A Field Guide to UIKit Compatibility Pitfalls

Fatbobman documents the issues appearing when Liquid Glass meets existing UIKit code, including UIBarButtonItem, UITabBarController, WKWebView, and UIStepper, with practical workarounds for each.

A strong field guide for teams updating mature UIKit apps.

📍Level: Advanced

Changing the Shape of Glass Buttons in SwiftUI

Livsy Code explores how Liquid Glass interacts with custom SwiftUI button shapes—and how to keep control of the corners when the defaults don’t fit your design.

📍Level: Intermediate

AsyncImage Finally Gets Caching in SwiftUI

Sagar Unagar examines the new caching behavior in AsyncImage and what it means for network usage, repeated image loads, and scrolling performance.

📍Level: Intermediate

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

Swift Protocols and the Main Actor

John Sundell on how actor isolation actually works with protocols — one of those foundational topics that quietly trips up even experienced developers as concurrency tightens.

📍Level: Advanced

Stop Using @unchecked Sendable

Soumya Mahunt makes the case against reaching for @unchecked Sendable as an escape hatch — what it really costs you, and the safer patterns that get you the same result.

📍Level: Advanced

Introducing ListKit: An Open-Source Library for SwiftUI Lists

Daniel Saidi open-sources ListKit — reusable view components and extensions for the list problems everyone re-solves from scratch, from sectioning to selection to reordering.

📍Level: Intermediate

Coding 👨‍💻

Demystifying Thread Hopping with Swift 6.2 Approachable Concurrency

Nikita Vasilev breaks down what actually happens when your code hops threads under Swift 6.2's approachable concurrency — and how to reason about it instead of guessing.

📍Level: Intermediate

New in SQLiteData: Sectioned Queries

Point-Free adds sectioned queries to SQLiteData — a clean way to drive sectioned SwiftUI lists straight from your database without hand-rolling the grouping.

📍Level: Intermediate

Apple 🍏

Hello Developer: July 2026

Apple's monthly developer digest rounds up the latest across the 27 platform releases — new documentation, sample code, and release notes, plus design resources and WWDC26 follow-ups worth a scan.

Design 🎨

Keeping Canvas Interactions Responsive with Frame Reprojection

Matthaus Woolard on maintaining responsive canvas interactions under the new rendering model using frame reprojection — a look under the hood of how modern SwiftUI stays smooth under load.

📍Level: Advanced

AI & Tooling 🤖

The iOS Testing Strategy Agent Skill

Artem Mirzabekian shares an agent skill built around a practical iOS testing strategy.
It’s a useful example of turning team conventions—what to test, how to structure tests, and which edge cases matter—into repeatable instructions an AI coding agent can follow.

📍Level: Intermediate

A Sol's Work: Shipping with GPT-5.6 Sol

Rudrank Riyam gives a coding agent a real engineering task, step away fro several hours, and the checks whether the final report matches what actually happened.
An honest account of where long-running agent work succeeds- and where human verification is still essential.

📍Level: Intermediate

Tutorials 📒

Building a Custom In-App Keyboard in SwiftUI

Lee young-jun needed an in-app numeric keyboard and discovered SwiftUI's TextField gives you no clean hook for it — so he went spelunking through the UIKit view hierarchy to find the underlying UITextField and swap its inputView. A genuinely instructive walk through the messy reality of bridging SwiftUI and UIKit, dead ends included, ending with a sharp note on why banking and OTP apps ship custom keyboards in the first place.

📍Level: Advanced

Shipping a SwiftData App with iCloud Sync

Thorsten Stark walks through taking a SwiftData app from local persistence to multi-device CloudKit sync, including model constraints, container setup, and duplicate- record problems caused by concurrent device updates.

📍Level: Intermediate

Video 🎥

SwiftUI Image Caching Explained: Faster Lists and Better Performance

Stewart Lynch explains image caching in SwiftUI end to end — why uncached liimage loading hurts scrolling performance, how a caching layer helps, and how to build one clearly.

📍Level: Intermediate

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Last week the iOS 27 beta landed and everyone braced for what breaks. This week is the other side of that coin — the quiet, genuinely useful APIs Apple slipped into iOS 27 that make code you already write simpler. The stuff that never gets a keynote slide, but shows up in your codebase for years.

Got a favorite iOS 27 API nobody’s talking about? Hit reply — I’m collecting them.

The AI Agent for Your RevenueCat Data

Meet Rico! 👋

RevenueCat’s embedded AI app growth advisor for subscription apps. Ask questions about churn, trials, pricing, paywalls, or retention and get answers using your app’s real subscription data directly inside RevenueCat and Slack.

Built to help iOS developers make smarter monetization decisions faster.

Try Rico today!

The Quiet Half of iOS 27

with Divya Ravi — Technical Editor, iOS engineer, creator of FoundationModelsKit

Every WWDC has two halves. There’s the loud half — the keynote feature, the framework everyone live-tweets, the thing that lands on every “what’s new in iOS 27” listicle by Tuesday afternoon. And then there’s the quiet half: the small API refinements that never trend, never get a session to themselves, and turn out to matter far more to your day-to-day code than the headline act ever will.

I want to make the case for the quiet half — because this year it’s unusually good, and because the quiet changes are the ones that actually change how you write things.

Here’s the pattern I keep noticing in iOS 27. For years, a whole category of ordinary UI work lived in an awkward middle ground: not hard exactly, but not supported either. Swipe actions only worked inside List. Reordering only worked inside List. Adaptive panels meant hand-rolling a detent system and hoping it behaved in landscape. Toolbar customization meant quietly fighting the framework’s defaults. You could do all of it — you just did it by working around the framework instead of with it. Every iOS codebase of a certain age has a folder full of these workarounds, and everyone who’s touched one knows the specific dread of opening it.

What iOS 27 quietly does is close a lot of those gaps at once. Swipe actions work outside List now. Reordering has real APIs instead of a custom drop-delegate dance. Size classes gave way to a more honest model of available space — which suddenly matters, now that iPhone apps resize. None of these got a dramatic reveal. All of them delete code you currently maintain.

And that’s the real point, the one I’d underline twice. The loud features add capability — new things your app can do. The quiet features remove liability — workarounds you no longer have to own. Those two are not equally valuable, and we consistently act like they are. A new capability is something you adopt when you have the time and the reason. A removed workaround is tech debt that stops being your problem the moment you migrate — no adoption required, no feature to design, just deletion. And deletion compounds. Every custom reordering implementation you delete is code you no longer test, no longer debug, no longer explain to the engineer who inherits that file in eighteen months.

There’s a reason this half gets ignored, and it isn’t laziness. It’s that the quiet changes don’t announce themselves. Nobody writes a breathless thread titled “swipe actions now work in a ScrollView.” It doesn’t demo well. It doesn’t screenshot. But six months from now, the teams that went looking for these changes will have measurably simpler codebases than the teams that only adopted the headline features — not because they’re better engineers, but because they read past the first screen of the release notes.

So here’s my actual advice for this cycle, and it’s almost aggressively practical: before you build anything custom in iOS 27, check whether Apple already built it. The odds this year are genuinely good that they did. The framework spent this release catching up to a pile of things we’ve been hand-rolling for half a decade, and the catch-up is sitting in the quiet half, waiting for someone to notice.

Read the release notes to the end. That’s the whole tip. The loud half will find you on its own — it always does. The quiet half you have to go looking for, and this year, it more than pays for the trip.

Related reading on this week's theme 📚

Building Adaptive Non-Modal Panels in SwiftUI

Matthaus Woolard builds a detent-based, non-modal sheet that adapts from a bottom panel in portrait to an edge-aligned one in landscape — exactly the kind of thing you used to hand-roll and pray over.

📍Level: Advanced

Taking Control of Toolbar Items in SwiftUI

Majid Jabrayilov on iOS 27's new toolbar APIs — finer control over appearance now that the design language splits content and controls into separate layers.

📍Level: Intermediate

Making a SwiftUI Sheet Automatically Size to Fit Its Content

Daniel Saidi on getting sheets to size to their content instead of defaulting to half the screen — a small, satisfying win over a default everyone has fought at some point.

📍Level: Intermediate

iOS 27: UIBarMinimization

Anton Gubarenko on iOS 27’s new bar-minimization behavior — how to control the way bars collapse and expand, and where it fits in a modern multi-window layout.

📍Level: Intermediate

WWDC26: Reordering Items in SwiftUI Lists and Grids

Gabriel Theodoropoulos walks through the new reorderable and reorderContainer APIs — native drag-to-reorder that finally works beyond List.

📍Level: Intermediate

From Size Class to Available Space

Fatbobman on why iOS 27 moves past size classes toward a more honest model of available space — and why that matters now that iPhone apps resize.

📍Level: Advanced

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

Understanding Code Signing and Provisioning in iOS

Natascha Fadeeva demystifies the whole signing chain — certificates, provisioning profiles, entitlements — as a practical mental model instead of a black box you fight at build time.

📍Level: Intermediate

Keeping SwiftData Behind a Boundary

Natascha Fadeeva on wrapping SwiftData behind a protocol boundary so your app isn't married to the framework — cleaner tests, easier migration, fewer surprises down the line.

📍Level: Intermediate

Swipe Actions Outside of List in SwiftUI

Majid Jabrayilov on one of iOS 27’s most overdue additions: swipeActions now works in a ScrollView and custom layouts, not just List.

📍Level: Intermediate

Coding 👨‍💻

Test iOS Apps in Different Time Zones

Antoine van der Lee on catching an entire class of date bugs before your users do — how to actually run your app under a different time zone on a physical device.

📍Level: Intermediate

Apple 🍏

New Business Terms for Link-Out Purchases

Apps that communicate or promote offers for digital goods outside the App Store will be subject to new terms — an initial acquisition fee, a store services fee, and, for the EU External Purchase Link Entitlement, the Core Technology Commission.

On-Demand Resources Are Deprecated in iOS 27

Apple's App Store Connect docs now list On-Demand Resources (and the NSBundleResourceRequest API) as deprecated across iOS 27, iPadOS 27, tvOS 27, and watchOS 27, with support to be removed in a future release. Apple recommends migrating to Background Assets.

Design 🎨

Blend Modes in SwiftUI

Natalia Panferova walks every SwiftUI blend mode through focused visuals and real use cases — and shows how to control exactly which views participate in each operation.

📍Level: Intermediate

AI & Tooling 🤖

User Diagnostics Reports: Solving Bugs Faster with AI Agents

Antoine van der Lee on turning real user diagnostic reports into fixes — feeding crash context to an AI agent and getting back a reviewed pull request instead of a raw stack trace.

📍Level: Intermediate

Tutorials 📒

Bridging Gemini Video with Foundation Models and CustomSegment

Rudrank Riyam routes video through a LanguageModelSession to Gemini — Apple's on-device model takes images but not video, so he bridges the gap with a custom Transcript.CustomSegment and a LanguageModelExecutor, verifying each layer along the way.

📍Level: Advanced

Video 🎥

iOS 27 SwiftUI Updates in Action

A hands-on tour of this cycle's SwiftUI changes in a real project — reorderable views, swipe actions outside List, and the new navigation and presentation APIs, shown in code.

📍Level: Intermediate

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

The iOS 27 public beta shipped on July 13 — which means the conversation just shifted from “what did Apple announce” to “what happens when I actually run this.” This issue is about that gap.

If you’ve installed the beta and hit something surprising, hit reply — I’m collecting real-world beta friction for a future issue.

The Public Beta Isn’t a Preview. It’s a Deadline.

with Divya Ravi — Technical Editor, iOS engineer, creator of FoundationModelsKit

Every year the public beta gets framed as a gift: try the new features early, play with Siri, see what’s coming. That framing is comfortable, and for most users it’s correct. For developers, it’s a trap — because the public beta isn’t the moment you preview iOS 27. It’s the moment the clock on your existing app starts ticking out loud.

Here’s the mental model shift I’d push this cycle: a beta is not a demo of the future. It’s a dry run of a migration you have already been assigned, whether you’ve accepted the ticket or not.

Why “it still works on my device” is the most dangerous sentence in July.

The trap with betas is that your app usually does still launch. You install iOS 27, open your app, tap around, and nothing obviously breaks. That’s the false negative that costs teams their September. Because the things that break in a major OS transition rarely break at runtime on day one — they break at the boundaries: at build time when you move to the new SDK, at submission time when a new requirement gets enforced, and at the edges of APIs whose behavior shifted by a few degrees rather than flipping outright.

Consider the shape of this year’s mandates. Building against the iOS 27 SDK now enforces the UIScene lifecycle — an app that hasn’t migrated doesn’t degrade gracefully, it fails to launch. The Liquid Glass opt-out that teams leaned on for a year to buy time is now simply ignored. These aren’t features you opt into. They’re floors you fall through if you weren’t ready. And critically: none of them show up if you only test by installing the beta on a phone and tapping around. They show up when you rebuild.

The real work is boundary testing, not feature testing.

The instinct in beta season is to test the new stuff — the shiny APIs, the headline features. That’s backwards. The new stuff isn’t shipping in your app until you write it. What’s shipping in your app in September is everything you already wrote, recompiled against a new SDK, running on an OS whose assumptions moved. So the highest-value beta work is regression work: rebuild against the new SDK today, and watch what your existing code does at the three boundaries that actually matter —

Build boundary: does the project compile against the iOS 27 SDK, and do the new SDK-enforced requirements (scene lifecycle, launch storyboard, design compatibility) pass? This is where “won’t launch” bugs live, and it’s a compile-and-run-once check, not a feature you have to exercise.

Behavioral boundary: do the APIs you already depend on still behave identically? Major-version transitions are where a method that returned one thing quietly starts returning another under specific conditions. These are the expensive bugs, because your code is “correct” and the ground moved.

Submission boundary: will App Store Connect accept the build? Some requirements aren’t enforced at runtime at all — they’re enforced at upload, in September, when you have no runway left.

Why this is really an architecture question in disguise.

If migrating to a new SDK is a scramble every single year, that’s not an Apple problem — it’s a signal about your codebase. The teams that move through a beta cycle in an afternoon are the ones whose apps were built so the OS is a dependency they can swap, not a foundation poured into every layer. Clean scene management, a UI layer that doesn’t assume a specific design system, submission requirements encoded in CI rather than in someone’s memory — these are the things that turn “OS migration” from a summer-eating project into a checklist.

The public beta is the cheapest, lowest-stakes environment you will ever get to find out which kind of codebase you actually have. Use it as the dry run it is — not the preview it’s dressed up as. The teams treating July as playtime are the same teams that will be firefighting in September. The ones treating it as a deadline will ship the day iOS 27 goes GA and never think about it again.

Rebuild against the SDK this week. Not because the new features demand it — because your existing app already does.

Agree, disagree, already knee-deep in a scene-lifecycle migration? Hit reply — I read every one.

New here? Subscribe free to get “Under the Hood” and the week’s best iOS picks every issue.

Related reading on this week's theme 📚

iOS 27 SDK: 3 Major Requirements That Might Break Your App

Makwan Barzan on the mandatory UIScene lifecycle, the ignored Liquid Glass opt-out, and the enforced launch screen.

Read more.📍Level: Intermediate

Foundation Models Is Now a Hybrid Platform — and Picking the Tier Is the New Design Decision

Wesley Matlock on routing one LanguageModelSession across on-device, Private Cloud, or frontier.

Read more.📍Level: Advanced

Continuation vs CheckedContinuation vs UnsafeContinuation

The three ways to bridge callbacks into async/await, and exactly what each trades away.

Read more.📍Level: Advanced

SwiftUI Animation Techniques: The iOS 27 Update

Nathan Fennel on layer shaders, the Timeline API, and chaining multi-step motion.

Read more.📍Level: Intermediate

Copywriting with Agents and…Apple Designers?

Jordan Morgan on using AI agents for the craft around the app, not just the code.

Read more.📍Level: Beginner

SwiftUI Network Reachability with NWPathMonitor and Observation

Stewart Lynch's clean, modern replacement for the old Reachability class.

Watch here.📍Level: Intermediate

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

Swift 6.3.4 development is open for non-Darwin platforms

The merge window is open now, closing July 24, with release targeted for the end of July — worth tracking if you ship Swift on Linux or Windows.

Read more.📍Level: Intermediate

The Hidden Cost of Unstable SwiftUI Environment Defaults

Natalia Panferova flags a real footgun: class-typed @Entry defaults get reallocated on every access, so SwiftUI sees a "new" value each time and re-evaluates views that shouldn't update. The fix is a one-line move to stable storage.

Read more.📍Level: Advanced

Coding 👨‍💻

Swift Actors Explained with Real Examples

Rahul breaks actors down from first principles — how they protect shared mutable state by serializing access, why that eliminates data races by design, and how to reach for them instead of locks and dispatch queues.

Read more.📍Level: Intermediate

Apple 🍏

Apple expands App Store capabilities to help developers grow and reach new users

Covers the age-rating/Time Allowances change, Creative Assets, Asset Library, Personalized Collections — the big developer-facing App Store update.

Read more.📍Level: Beginner

Xcode 27 Release Notes

The technical rundown of what's new and changed in the iOS 27 SDK — AppKit, SwiftUI, StoreKit, Metal, and more.

Read more.📍Level: Intermediate

Latest Developer News & Updates

Apple's running feed of App Store Connect, TestFlight, and submission changes — TestFlight now accepts Xcode 27 beta builds, and IAPs can be submitted standalone. — this one's a feed not a permalink, but it's the honest home for "the latest submission changes"

Read more.📍Level: Beginner

Design 🎨

Taming Row Height and Spacing Jumps in SwiftUI List

Fatbobman digs into why List won't smoothly interpolate a row whose height changes dynamically, then builds a pure-SwiftUI fix using Animatable, a custom Layout, LayoutValueKey, and state decoupling.

Read more.📍Level: Advanced

AI & Tooling 🤖

Rendering SwiftUI Previews with Xcode's MCP Server

Xcode's MCP bridge grew from 20 tools to 47 in the Xcode 27 beta. Amy Worrall skips the agent entirely and drives RenderPreview directly over JSON-RPC, turning Xcode into a rendering service for a SwiftUI preview gallery.

Read more.📍Level: Advanced

Tutorials 📒

Apple Foundation Models in iOS 27: The Complete Builder Guide

A thorough guide to on-device LLM inference — how Core AI, Foundation Models, and your app logic layer together, plus the larger model, on-device fine-tuning, expanded context, and full tool calling.

Read more.📍Level: Intermediate

Video 🎥

What's New in SwiftUI for iOS 27

A walkthrough of the new SwiftUI APIs landing this cycle — lazy @State, faster compiles, reorderable(), swipe actions beyond List, and the new Document protocol.

Read more.📍Level: Intermediate

Community 🤝

SwiftCon Returns to Berlin This October

SwiftCon is back as part of nextapp devCon (Oct 7–9) — six mobile-dev conferences under one roof, spanning Swift, Android, Flutter, React Native, AI, and XR. Worth a look if you're planning fall conference travel.

Read more.📍

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

We have a new team member! 🙋‍♀️

Divya Ravi, Senior iOS Engineer at Unity and creator of FoundationModelsKit, is joining Those Who Swift as a new newsletter editor.

If you’d like to get to know Divya, check out her LinkedIn and X.

Anton isn’t going anywhere!

He’s now the editor of our new website - which brings me to the second big news. 🥳

We now have a blog with unique, quality content.

New content, collaborations, partnerships, special deals, and more coming soon. Stay tuned! 😎🤘

Own Your web2app Funnel and Get Paid in Days

web2wave lets subscription apps sell on the web first: users complete a quiz flow, pay, then download the app with an active subscription. The sale closes before install, so you don’t pay 15-30% app store fees on it.

• Get paid in 1-2 days instead of 30+, for much faster cash flow.

• Build the full funnel with the no-code editor, or in a minute with Wavy AI or the web2wave MCP.

• Ship A/B tests and cancellation flows without waiting on app releases.

• Keep full web-side tracking and UTM attribution, even post-ATT.

Payment coverage in web2app: direct integrations with Paddle, Stripe, Solidgate, FastSpring, Zotlo, Unlimit, Xsolla, PayPal, Billerix, and 100+ more via Primer.

Free to use until you launch paid traffic.

Try web2wave free

Post-WWDC26: The 3 On-Device AI Patterns That Will Actually Ship This Year

with Divya Ravi — Technical Editor & iOS engineer, creator of FoundationModelsKit

Every June, WWDC produces the same split-screen reaction: a keynote full of features that sound revolutionary, followed by a developer community quietly asking which of them will actually be usable in a shipping app before next June. This year is no different. Between Siri AI, Private Cloud Compute, and a redesigned Foundation Models framework, there’s a lot to sort through — and most of the coverage so far has just listed announcements rather than telling you what to actually build against.

So here are the three patterns from WWDC26 I think are worth architecting around this cycle — not because they’re the flashiest, but because they’re the ones you can ship on, today, without waiting for a keynote demo to become real.

1. Model portability is no longer a side project — it’s a protocol.

Apple’s new LanguageModel protocol means your app’s AI logic doesn’t have to be married to Apple’s on-device model anymore. Swap in Claude, swap in Gemini, or fall back to on-device — all through the same session interface, with your tool calls and context management untouched. In practice, this turns a decision that used to require re-architecting your AI layer into a Swift Package Manager dependency change.

Why it matters: most teams have been quietly hedging against being locked into Apple’s model quality, especially for anything requiring nuanced reasoning. This protocol makes that hedge free. If your app currently has model logic tangled into your view layer or business logic, this is the year that tech debt gets expensive — everyone else’s app is about to be able to swap providers in an afternoon, and yours won’t be if the session boundary isn’t clean.

2. Bring-your-own-model finally has a real home: Core AI.

Core AI is Apple’s new answer to teams who don’t want to use Apple’s model at all — a full on-device deployment framework with a Python conversion pipeline and a Swift runtime, tuned to run across CPU, GPU, and Neural Engine without a server dependency. This has existed in rougher form via Core ML for years, but Core AI is the first version that feels like a first-class platform citizen rather than a workaround.

Why it matters: if you’ve been holding off on shipping a proprietary or fine-tuned model because the on-device tooling felt like a science project, that excuse is gone. The teams who move now — while most of the ecosystem is still only using Apple’s default model — get a real differentiation window before “on-device AI” becomes table stakes and looks identical across every app in a category.

“None of these patterns are really about AI capability — they’re about architecture. The apps that struggle won’t fail because the AI is bad. They’ll fail because the plumbing underneath was never built to be swapped, extended, or exposed in the first place.”

3. App discovery is moving into the OS, not your app’s UI.

Between the Spotlight semantic index, App Intents schemas, and the new View Annotations API, Apple is making a clear bet: the primary way people invoke your app’s functionality is about to be Siri asking on their behalf, not someone tapping your icon. Annotate your views, expose your actions through App Intents, and your content becomes something the system can reason about and act on — conversationally, without you building any of that interface yourself.

Why it matters: this is the one pattern that’s easy to underestimate because it doesn’t produce a flashy demo. But it’s the one most likely to quietly redefine what “distribution” means for an app over the next two years. Ignore it and you’re opting out of an entire invocation surface your competitors will be inside of.

The thread connecting all three

Model portability rewards apps with clean session boundaries. Core AI rewards apps that already separate inference from UI. App Intents rewards apps that expose actions as first-class objects instead of burying them in view controllers. None of this is really about AI capability — it’s about whether your architecture was ready for it.

If you’re planning your roadmap around this WWDC cycle, the highest-leverage work isn’t picking which shiny feature to bolt on first. It’s making sure your architecture can say yes to any of the three.

Agree, disagree, or think I’m missing a pattern? Just hit reply — I read every one.

Apple 🍏

Foundation Models in iOS 27: Tool-Calling Control

Blake Crosley digs into the new ToolCallingMode API and Apple’s built-in OCR and barcode tools — the kind of detail that matters once you’re past the keynote demo and into shipping.

• The new ToolCallingMode structure lets you control how aggressively the model calls tools mid-generation, and the framework can auto-switch modes to bound activity within a single request.

• OCRTool and BarcodeReaderTool run entirely on-device, in your app’s own sandbox — Apple maintaining the recognition code changes who owns it, not where it runs.

Read more.📍Level: Advanced

Apple’s WWDC26 AI Story Is About Control, Not Just Models

Jon Brown’s read on the keynote pairs directly with this issue’s essay — if you only click one link this week, make it this one.

• Argues Apple Intelligence has less to work with when an app’s data model is vague or its actions aren’t cleanly represented — architecture first, AI second.

• Makes the case that App Intents should be treated as core app structure from day one, not a Siri checkbox bolted on near ship.

Read more.📍Level: Intermediate

WWDC 2026 Developer Tools: Xcode 27, Swift, Foundation Models

A blunt, opinionated take — and one I don’t think is right, which is exactly why it’s worth reading.

• Argues App Intents adoption is now effectively mandatory, since apps without it become invisible to Siri as an entry point.

• I’d push back on “mandatory” for anything outside the productivity/utility category — but the underlying pressure is real and worth planning around either way.

Read more.📍Level: Intermediate

Tutorials 📒

Getting Started with Apple’s Foundation Models

Artem Novichkov builds a HealthKit-powered health coaching feature using a custom Tool — the most practical, code-first entry point in this issue.

• Walks through defining a custom Tool that pulls live blood pressure data from HealthKit into a LanguageModelSession.

• Good starting point if you haven’t touched Foundation Models yet — minimal boilerplate to get a working tool-calling session running.

Read more.📍Level: Beginner

Introducing FoundationModelsKit: Production Patterns for Foundation Models on iOS

Full disclosure: this one’s mine — including it because it’s directly on-theme for this issue, not just because I wrote it. At WWDC26, Apple made a bold move: Foundation Models now ship with iOS, on-device, with no download or external dependency.

• Walks through production patterns for actually shipping with Foundation Models, not just prototyping with it.

• If you want the deeper technical background behind this issue’s essay, this is where it comes from.

Read more.📍Level: Intermediate

Coding 👨‍💻

SwiftUI Best Practices, straight from Apple’s Xcode 27 Agent Skill

Antoine van der Lee dissects the actual Markdown reference files Apple bundled into Xcode 27’s SwiftUI agent skill — and it’s basically a written confirmation of this issue’s whole thesis.

• The skill’s reference files split cleanly by concern — structure, data flow, environment, modifiers — all built around one idea: a view is SwiftUI’s unit of invalidation, and most performance problems come from invalidating more than you need to.

• Worth reading even if you don’t use agents — it’s effectively Apple’s own internal SwiftUI style guide, now public.

Read more.📍Level: Intermediate

Swift Bits: My Top Xcode CI Environment Variables

Anton digs into Apple’s environment variable reference for Xcode Cloud — unglamorous, but exactly the kind of thing that saves you an afternoon of debugging why CI behaves differently from your local machine.

• Covers the popular variables for detecting which workflow, build action, and app target is running — the context most custom ci_scripts builds actually need.

• A good reminder that hardcoded CI scripts age badly; context-aware ones survive team and project changes.

Read more.📍Level: Intermediate

Design 🎨

5 biggest Liquid Glass changes in iOS 27 and macOS 27

A clear rundown of how Apple is walking back a year of Liquid Glass complaints — legibility, corner-radius consistency, and icon clarity all got real fixes this cycle.

• Apple’s HI design director confirmed most of these improvements apply automatically to apps already using the Liquid Glass framework, with minimal developer work required.

• macOS 27 finally standardizes corner radius across apps — a small detail, but one that’s been a visible inconsistency since Liquid Glass launched.

Read more.📍Level: Beginner

Other cool stuff 🧰

How I use FlowDeck to let my AI agent build and run my apps

Donny Wals on folding an agentic coding tool into his existing workflow — a good counterweight to the rest of this issue, since it’s about AI helping you build, not AI features inside what you ship.

• Started using FlowDeck after the tool’s builder reached out following a post Donny made about managing AI agent context windows.

• The interesting part isn’t the tool itself — it’s the workflow shift of agents opening PRs against real crash reports while you’re away from the keyboard.

Read more.📍Level: Intermediate

Video 🎥

Build intelligent Siri experiences with App Schemas

Straight from Apple’s own WWDC26 session — Dan Niemeyer walks through exactly how Siri understands and acts on your app’s content, which pairs directly with pattern 3 in this issue’s essay.

• Covers how App Entities model your existing content (a calendar event, a mail message, a photo) so the system can reason about it without you rebuilding your data model.

• Demonstrates real cross-app actions, like Siri sending someone’s latest report by name — worth watching before you scope your own App Intents work this cycle.

Watch here.📍Level: Intermediate

Thanks for reading!

Got a pick worth featuring? 📬 Use the submission form and share with more than 15,000 developers.

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Fable 5 is back! At least for a little while. 🤞

Anthropic has extended its availability until July 12, giving developers a few more weeks to work with the model before the next planned change.

The announcement turned out to be more controversial than expected. When access to Fable 5 was initially reduced, many users were automatically moved back to Claude 4.8. While still a capable model, plenty of developers noticed the difference. Longer reasoning, more consistent code generation, and overall responsiveness were among the areas where Fable 5 had earned its reputation. Going back felt less like a version update and more like losing a favorite development tool.

This situation also highlights an interesting challenge of cloud AI. Unlike traditional software, where you decide when to upgrade or downgrade, modern AI services can change underneath your workflow. The same prompt may produce different results depending on the currently available model, making consistency another variable developers have to consider.

Whether Fable 5 stays longer or not, one thing is clear: developers quickly adapt to better tools, and going backwards is never an easy sell.

Are you using Fable 5 in your daily workflow, or has another model become your primary coding assistant?

Swift Around the Web 🌐

AI Agent Skills For iOS Development

Artem Mirzabekian gives a clean mental model for something a lot of teams are still treating as vague tooling folklore.

• The article separates repository rules, Claude project memory, and reusable skills into distinct jobs
• The practical value is in making agents less guessy: small instruction files for always-on rules, skills for repeatable workflows, and CI for anything that must be enforced

Read more.📍Level: Intermediate

What’s New In Swift: June 2026 Edition

Swift’s June digest feels more substantial than usual because WWDC26 gave it a lot to work with, from language changes to ecosystem moves and major open-source announcements.

• The biggest updates include Swift 6.4 previews, Swift in parts of Apple’s kernel, an open-sourced QUIC transport layer, and new Foundation Models utilities
• It also works well as a community snapshot, pulling in Swift Package Index joining Apple, the new Networking workgroup, notable package releases, and a few evolution proposals worth tracking

Read more.📍Level: Intermediate

Coding 👨‍💻

Defer In Swift Explained With Code Examples

Antoine van der Lee revisits defer through a modern Swift lens, which makes the article more useful than a basic keyword refresher.

• It covers both the classic cleanup use case and the newer Swift 6.4 ability to await inside defer when the surrounding context is async
• One of the clearest points is why Task { ... } is not a real replacement here: unstructured cleanup can outlive the function, while async defer preserves the guarantee that cleanup finishes before scope exit

Read more.📍Level: Intermediate

Understanding Sendable In Swift

Natascha Fadeeva explains Sendable from the angle that matters most in real code: what happens when values cross tasks, actors, and other concurrency boundaries.

• Sendable marks types that are safe to pass across concurrency boundaries, and Swift 6 treats violations much more strictly than Swift 5’s default mode
• The article is strongest where it gets practical about classes: immutable final classes can conform, mutable shared state usually belongs in an actor, and @unchecked Sendable should be treated as a manual safety promise, not a warning silencer

Read more.📍Level: Intermediate

Design 🎨

ConcentricRectangle And ContainerRelativeShape

Ralf Ebert’s note is short, but it clears up a visual detail that is easy to miss when trying the new shape APIs.

• ConcentricRectangle and ContainerRelativeShape both adapt to outer rounded container shapes, but they do not behave the same once positioning shifts
• The key distinction is practical: ConcentricRectangle is more tied to actual corner geometry, while ContainerRelativeShape stays more uniform as a general container-aware shape

Read more.📍Level: Intermediate

Other cool stuff 🧰

iOS27: CADisplayLink for UIWindowScene

Article explains a small beta API change to make a bigger point about how display-driven work should be modeled in modern UIKit.

• The article clearly separates Timer from CADisplayLink: one is interval-based, the other is tied to frame boundaries and visual smoothness
• The new part in iOS 27 is scene ownership, where display-synchronized work can be attached to a specific UIWindowScene instead of feeling like a loose global loop

Read more.📍Level: Intermediate

Custom Bindings In SwiftUI: Closures Vs Subscripts

Natalia Panferova takes a very specific SwiftUI pattern and turns it into a useful performance lesson about how bindings are represented.

• Binding(get:set:) is flexible, but recreating closure-based bindings in body can trigger extra row updates when unrelated state changes
• A subscript-based binding gives SwiftUI a more stable projection to track, so child views only reevaluate when the relevant state actually changes

Read more.📍Level: Advanced

AI 🤖

Claude Cowork On Web And Mobile

Anthropic is expanding Claude Cowork beyond desktop, which changes the product from a laptop-bound agent into something that can follow work across devices.

• Cowork is rolling out to web and mobile first for Max users, with more plans to follow over the next several weeks
• The bigger shift is background continuity: sessions, files, and approvals can now move between desktop, phone, and web while Claude keeps working even when no device is online

Read more.📍Level: Intermediate

Tutorials 📒

SwiftUI .crossFade Navigation Transition In iOS 27

Sagar Unagar highlights a small SwiftUI addition that will probably get used a lot more than its size suggests.

• .crossFade gives SwiftUI a built-in fade transition with almost no setup
• It fits screens like settings, forms, editors, and login flows better than zoom-style transitions

Read more.📍Level: Intermediate

Video 🎥

Modern iOS Performance Myths: Episode 1

Artem Mirzabekian and Bogdan Poplauschi use the first Swift Academy episode to push performance discussions away from vague “fast or slow” claims and toward how apps actually feel in production.

• A technically fast app can still feel slow if feedback arrives late, state updates wake too much UI, or performance only looks good on modern devices
• The episode also cuts through common myths around SwiftUI, UIKit, averages, and concurrency, with one clear message: measure real user experience, not just pretty local metrics

Watch here.📍Level: Intermediate

Reordering SwiftData In List And Grid

Stewart Lynch walks through two different reordering paths for SwiftData-backed content, starting with the built-in List move flow and then building full drag-and-drop behavior for a grid.

• The list version is simple: use onMove, update sortOrder, and save back through modelContext
• The grid version is the more useful part: keep a local display array for drag state, reorder it with a custom drop delegate, then persist the final order only when the drop completes

Watch here.📍Level: Intermediate

Books 📚

The iOS Core Engineering Series — Volume 1

Anubhav Giri positions this as a fundamentals-first iOS engineering resource built around two topics that trip up a lot of developers once apps get real.

• Volume 1 focuses on memory and concurrency
• From the page snippet, it looks aimed at system-level foundations rather than framework tips

Get here.📍

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

This week, Apple announced price increases across most of its hardware lineup, including MacBooks, iPads, HomePods, and Apple TV. The notable exception is the iPhone. According to the company, soaring memory and storage chip prices, driven largely by AI data center demand, have reached a point where Apple can no longer absorb the additional costs. Even Apple, with one of the strongest supply chains in the industry, isn’t immune to the global memory shortage.

This has another consequence for developers. Running open-source LLMs locally is becoming increasingly attractive as cloud services tighten token limits and subscription models. But local AI needs RAM, and lots of it. Machines with 64 GB, 96 GB, or 128 GB of unified memory are now significantly more expensive, with many high-memory Mac configurations selling at substantial premiums, even on the secondary market and major retailers. The cost of moving away from cloud AI is rising alongside the cost of staying with it.

We’re entering an interesting phase where AI isn’t limited by model quality anymore. Instead, it’s becoming constrained by infrastructure, memory availability, and cost. Choosing between cloud-hosted models and running them locally is no longer just a technical decision. It’s increasingly a financial one.

If hardware prices continue to rise, would you rather invest in a powerful local machine for open-source LLMs or continue relying on cloud AI subscriptions?

Swift Around the Web 🌐

Reordering Beyond List - SwiftUI iOS 27

Sagar Unagar highlights one of the most overdue SwiftUI upgrades in iOS 27: drag-to-reorder is no longer trapped inside List.

• reorderable() and reorderContainer(for:) bring native reordering to stacks, grids, and custom Layout types
• SwiftUI reports a ReorderDifference, while your app stays responsible for applying and persisting the move

Read more.📍Level: Intermediate

A Custom Pull-to-Refresh In SwiftUI

Artem Mirzabekian treats pull-to-refresh as a state machine problem, which is what makes this custom approach feel more deliberate than most one-off gesture hacks.

• The component exposes the full refresh lifecycle, from pull progress to finishing animation
• It is built for cases where .refreshable is not enough, like branded indicators, custom thresholds, and tighter layout control

Read more.📍Level: Advanced

Coding 👨‍💻

Understanding Privacy Manifests In iOS

Natascha Fadeeva lays out privacy manifests as a practical Xcode task, not just another compliance checkbox.

• A PrivacyInfo.xcprivacy file declares collected data, tracking use, and required reason API access for your app or SDK.
• The article is especially useful around third-party SDKs and required reason APIs like UserDefaults, file timestamps, disk space, boot time, and active keyboard access.

Read more.📍Level: Intermediate

Design 🎨

Where Should Loading State Live In SwiftUI?

Mohammad Azam uses a simple products example to make a larger architectural point about where state duplication starts to creep in.

• He argues for keeping loading state in the view while the store stays the single source of truth for data
• The article is really about tradeoffs: some solutions can work, but they can also duplicate state and make updates like add or refresh feel more awkward

Read more.📍Level: Intermediate

Other cool stuff 🧰

SwiftUI Is One Graph, Over 40+ Years of Engineering

Mihaela Mihaljević Jakić’s post is less a SwiftUI tutorial and more an attempt to strip the framework down to its engine room.

• The central claim is that SwiftUI behaves like a single demand-driven graph, not a view tree that gets broadly diffed and rebuilt.
• It gets more interesting when the article connects that graph to the older stack beneath it — Core Animation, Core Graphics, Core Text, and Core Image — and argues that SwiftUI only really makes sense once you see the deeper machinery it sits on top of.

Read more.📍Level: Advanced

Proposing Task-Local Test Traits For Swift Testing

Point-Free’s proposal is small on the surface, but it targets a very real annoyance in test setup for task-local values.

• It would add a built-in .taskLocal trait, so tests could bind task locals without writing a custom trait for each one.
• The bigger benefit is less boilerplate and less need for separate test-support modules just to make task locals usable in Swift Testing.

Read more.📍Level: Advanced

AI 🤖

Previewing GPT-5.6 Sol: A Next-Generation Model

OpenAI is introducing a new three-tier GPT-5.6 family, with Sol as the flagship model, Terra as the balanced middle tier, and Luna as the faster lower-cost option.

• Sol adds new max reasoning and an ultra mode that uses subagents for more complex work.
• The preview is limited at first, with OpenAI emphasizing stronger safeguards, better coding performance, and broader availability in the coming weeks.

Read more.📍Level: Advanced

Introducing Claude Sonnet 5

Anthropic is positioning Claude Sonnet 5 as its most agentic Sonnet yet, aiming to bring Opus-like follow-through and tool use to a cheaper tier.

• It narrows the gap with Opus 4.8 on reasoning, coding, tool use, and knowledge work, while launching as the default model for Free and Pro plans.
• Pricing starts at $2 input / $10 output per million tokens through August 31, 2026, then moves to $3 / $15, with Anthropic also saying Sonnet 5 is safer than 4.6 overall and weaker than Opus models on dangerous cyber tasks.

Read more.📍Level: Beginner

Claude Science, An AI Workbench For Scientists, Is Now Available

Anthropic is pushing deeper into scientific workflows with a product that feels less like a chatbot and more like a research environment.

• Claude Science brings literature analysis, code, figures, manuscripts, and compute management into one workflow for scientists.
• It launches in beta on macOS and Linux for Pro, Max, Team, and Enterprise users, with a strong focus on biology and biomedical research.

Read more.📍Level: Intermediate

Tutorials 📒

Using Cursor In Xcode 27

Pol Piella shows that Xcode 27’s agent support is open enough to bring Cursor into the workflow, not just Apple’s built-in or officially listed assistants.

• The setup is surprisingly direct: install Cursor’s CLI, point Xcode at the agent executable, and run it with the acpargument.
• The bigger story is Xcode 27 itself: ACP support means custom agents can now sit inside Xcode’s intelligence flow alongside first-party options.

Read more.📍Level: Intermediate

Video 🎥

What’s New In SwiftUI For iOS 27?

Paul Hudson’s walkthrough makes it clear this is another unusually strong SwiftUI year, with improvements that range from under-the-hood compiler wins to features developers will feel immediately in app architecture and UI polish.

• The biggest changes are surprisingly quiet ones: @State is now a macro, View became a content builder, and both shifts aim to cut wasted work and reduce those infamous type-checking errors
• The visible additions are broad and practical — reordering outside List, swipe actions in custom layouts, prominent tabs, AsyncImage caching, crossfade navigation, smarter toolbars, and new APIs that hint at a more resizable future for iPhone apps

Watch here.📍Level: Intermediate

Books 📚

Mohammad Azam’s SwiftData Architecture is focused on the part most SwiftData content skips: how to build production apps, not toy samples.

It covers architecture, debugging, migrations, CloudKit, and performance.

Get 20% off with code: THS2026

Buy here.📍

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

This week brought two interesting pieces of news that, at first glance, seem unrelated. One is about trust and identity in the AI era. The other is about trust and community in the Swift ecosystem.

Anthropic has started rolling out identity verification for certain Claude users. Depending on the situation, users may be asked to provide a government-issued ID and a selfie through a third-party verification provider called Persona. Anthropic states that the data is used for safety, abuse prevention, and regulatory compliance, and that verification images are stored by Persona rather than directly by Anthropic. The company also says this information is not used for model training.

The timing is interesting. Over the last year we’ve seen multiple discussions around privacy, data leaks, account verification, and surveillance concerns across various platforms. As AI tools become more powerful and gain access to more capabilities, providers are naturally moving toward stronger identity controls. Whether users will accept that trade-off is another question entirely. Some developers are already looking at alternative models and providers that require fewer verification steps and collect less personal information.

On the Swift side, there was much more cheerful news. Swift Package Index is joining Apple. For years, SPI has been one of the most valuable community resources for discovering packages, evaluating maintenance quality, and helping developers make better dependency decisions. What started as a community project by Dave Verwer and Sven Schmidt has become such an important part of the ecosystem that Apple decided to bring it under its umbrella.

This is a great example of how community efforts can grow into essential infrastructure. Documentation, open-source libraries, newsletters, podcasts, and package indexes are all created by people who care enough to invest their time before anyone else sees the value. Apple recognizing that contribution is a positive signal for the entire Swift community.

As AI services move toward stricter identity checks and ecosystem platforms become more centralized, where do you draw the line between convenience and privacy? Would you consider switching to another LLM if it required fewer verification steps?

Swift Around the Web 🌐

UIPortalView: From Live Mirroring to Liquid Glass-Style Effects

Artem Mirzabekian uses _UIPortalView as a way to peek behind some of iOS’s most interesting visual tricks, especially where live mirroring starts to feel more like composition than ordinary view rendering.

• The article shows why portals are different from snapshots: the source stays alive, updates in real time, and can be projected into overlays, lenses, reflections, or warped slices
• Just as important, it keeps the line clear between research and production: _UIPortalView is a fascinating private API to study, but not something to ship in an App Store build

Read more.📍Level: Intermediate

Swift 6.4: What’s New In Concurrency

Antoine van der Lee’s overview is useful because it focuses on the small Swift 6.4 concurrency changes that are easy to miss, but likely to show up quickly in real code.

• The biggest additions include async defer, cancellation shields, async Result, typed throwing Task initializers, and warnings for ignored throwing tasks
• He also flags two changes that matter beyond pure concurrency syntax: weak let for cleaner Sendable code, and ~Sendablefor making intentionally non-sendable public types explicit

Read more.📍Level: Intermediate

Coding 👨‍💻

Actors In Swift: The Problem They Solve And How It Works

Omar Elsayed breaks actors down from first principles, which makes this feel more like a mental model repair than just another concurrency explainer.

• It clarifies what actors actually protect, how cross-actor access works, and why await is required even for synchronous actor methods across isolation boundaries
• The most valuable section is reentrancy: actor calls are safe from data races, but state can still change across suspension points, and that is where the confusing bugs begin

Read more.📍Level: Advanced

SwiftUI’s New Item Based Presentations In iOS 27

Sagar Unagar highlights one of those SwiftUI changes that looks small, but quietly fixes a long-standing state smell.

• Alerts and confirmation dialogs can now be driven directly from optional item state
• That means no extra Boolean flags, fewer impossible states, and cleaner presentation logic

Read more.📍Level: Intermediate

Apple 🍏

Updated Apple Developer Program License Agreement Now Available

Apple has revised Attachment 12 of the Apple Developer Program License Agreement to spell out terms for iOS apps in Brazil.

• The update covers alternative distribution, alternative payments, out-of-app offers, and the Core Technology Commission.
• Developers need to sign in and accept the new terms, while translated versions will appear on the Apple Developer website within a month.

Read more.📍

Changes To iOS In Brazil

Apple is opening up iOS in Brazil under a new agreement with CADE, and the change is much bigger than a policy footnote.

• Starting with iOS 26.5, developers in Brazil can use alternative app marketplaces and external payment options for digital goods and services.
• Apple is pairing that with new safeguards like iOS notarization, marketplace authorization, and child-safety requirements, and developers must accept updated program terms by July 6, 2026

Read more.📍

Design 🎨

WWDC26: SwiftUI Group Lab 2nd - Q&A

Article turns another dense SwiftUI lab into something you can actually come back to after WWDC.

• It covers practical SwiftUI topics like navigation, layout, geometry, identity, overlays, and UIKit interop.
• The big win is readability: grouped answers and time codes make the session much easier to revisit.

Read more.📍Level: Advanced

Liquid Glass In SwiftUI: How To Modernize An iOS App Template

Beniamin Marcu frames Liquid Glass as a structural redesign problem, not a quick visual polish pass.

• Start with navigation, surfaces, and shared components before touching colors
• The article also pushes a careful rollout: design tokens, system components where they help, layered icons, and small reversible updates

Read more.📍Level: Advanced

Other cool stuff 🧰

Swift Package Index Joins Apple

Ted Kremenek, Dave Verwer, and Sven A. Schmidt announce that Swift Package Index is now part of Apple, with the goal of building a more robust package registry for the Swift ecosystem.

• Swift Package Index will keep operating as it does today, with no immediate changes for package consumers or authors.
• Apple’s backing is meant to push things further in areas like scale, package signing, identity, and long-term ecosystem reliability.

Read more.📍Level: Beginner

Swift Conditionals: if, switch, guard and Pattern Matching

Divyesh Vekariya’s article is aimed at fundamentals, but it does a good job showing where Swift’s conditionals stop being familiar syntax and start becoming expressive language tools.

• It walks from optional binding into Swift’s much more powerful switch, including ranges, tuples, value binding, and whereclauses.
• The other big theme is guard: not just as syntax, but as a way to flatten functions and make preconditions obvious.

Read more.📍Level: Beginner

Tutorials 📒

How To Use Ollama Models In Xcode 27

Amos Gyamfi shows how Xcode 27’s new Chat Provider path opens the door to both local and cloud-hosted Ollama models inside the coding assistant workflow.

• The setup is straightforward for local models: install Ollama, run a model, then point Xcode’s locally hosted provider
• The article also covers the hosted route, where Ollama Cloud models are added through Xcode’s internet-hosted provider using an API key and standard auth headers

Read more.📍Level: XXX

Video 🎥

Swift Macros Demystified: Build A Freestanding Expression Macro

Stewart Lynch takes one of Swift’s more intimidating features and makes it feel much more approachable by building a freestanding expression macro step by step.

• The video is focused on understanding, not just copying code
• It is a practical walk through of how macros expand and how to build one yourself

Watch here.📍Level: Intermediate

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

WWDC is calmly leaving us with a lot of new frameworks, reviews, and guides to explore. This year, however, felt different from previous conferences. There were no traditional one-on-one Labs, but plenty of group Labs. No dedicated app consultation appointments where you could discuss your product and ask for best practices tailored to your use case. The format is evolving, just like the industry itself.

Software development has changed dramatically over the last few years. Old habits, learning plans, and even tutorials become outdated faster than ever. Even the biggest companies are adapting to new realities. And it’s not only developers who face these changes. The tools we rely on have their own growing pains.

It was hard to find a developer community this week where Fable 5’s blocking policies weren’t discussed. From memes to deep technical analyses, everyone seemed to have an opinion on who might be affected and why. Combined with stricter token limits and changing subscription models across AI platforms, it raises an interesting question: will these restrictions accelerate the adoption of local open-source models?

Models like Qwen, Gemma, and others continue to improve, offering developers more control over privacy, costs, and availability. Running AI locally still requires hardware and setup, but the trade-off may become increasingly attractive as cloud services adjust pricing and usage policies.

One thing WWDC reminded us is that adaptation is part of our profession. Frameworks change, conferences change, AI tools change, and so do our workflows. The important part is staying curious and finding the right balance between shiny new technologies and practical everyday development.

Have you already tried a local LLM, and could you imagine it becoming part of your daily toolkit?

Swift Around the Web 🌐

(Some) Unanswered Swift Group Questions

Matt Massicotte picks up the Swift Group Lab questions that never made it onto the stage and gives them the kind of direct, experience-heavy answers many teams probably needed more than the live format allowed.

• Swift 6 defaults are powerful, but easy to misuse
• Matt’s answers are valuable because they show when defaults help and when nonisolated becomes necessary

Read more.📍Level: Advanced

WWDC26: Swift Group Lab – Q&A

Post turns a long live lab into something much easier to keep and reuse after WWDC.

• The Q&A covers real Swift pain points
• Grouped answers and time codes make it much easier to scan

Read more.📍Level: Advanced

Coding 👨‍💻

Async Cleanup In defer With Swift 6.4

Artem Mirzabekian highlights one of those language changes that looks small on paper but removes a very real annoyance from modern async code.

• defer can now contain await in Swift 6.4
• That makes async cleanup much cleaner around teardown, actor calls, and resource handling

Read more.📍Level: Intermediate

Testing Foundation Models: Code That Won’t Give The Same Answer Twice

Wesley Matlock tackles the testing problem almost everyone runs into with on-device AI: the feature works, the code is covered, but the model itself sits outside the test strategy because its output refuses to stay still.

• The framework uses contract checks, mocks, and rubric-based evals
• Test shape and behavior first, then score model quality over time

Read more.📍Level: Advanced

Apple 🍏

Deprecation Of The ImageCreator Class

Apple is drawing a hard line around ImageCreator: the API is being discontinued and will stop working on iOS 27, iPadOS 27, macOS 27, and visionOS 27.

• Beta builds still compile, but warn in Xcode and fail in TestFlight
• Before release, apps need to move to Image Playground or another image service

Read more.📍

New Domain For Sign In With Apple And iCloud+ Hide My Email

Apple is unifying relay email addresses under private.icloud.com later this summer, which means Sign in with Apple and Hide My Email will start generating new aliases on the same shared domain.

• Existing relay emails will keep working
• Developers should update allowlists and email validation rules for private.icloud.com

Read more.📍

Design 🎨

SwiftUI’s New .prominent Tab In iOS 27 Is Not A Floating Action Button

Sagar Unagar makes a sharp design point that a lot of teams will probably need to hear during the iOS 27 cycle.

• .prominent highlights a destination, not an action
• If it opens a flow or sheet, it probably is not the right fit

Read more.📍Level: Intermediate

Other cool stuff 🧰

Custom Scroll Layouts With Swipe Actions In SwiftUI On iOS 27

Natalia Panferova highlights one of those small WWDC additions that immediately removes a long-standing SwiftUI annoyance.

• swipeActions now works beyond List, including ScrollView layouts and custom Layout types
• onPresentationChanged helps track which row is currently open

Read more.📍Level: Intermediate

What’s New In SwiftData For iOS 27

Mohammad Azam roundup is a good reminder that SwiftData did not get one giant headline feature this year — it got a set of fixes that make everyday modeling and querying feel much less awkward.

• iOS 27 fills in several long-missing SwiftData gaps
• The update reduces enum workarounds, custom filtering, and schema friction

Read more.📍Level: Intermediate

WWDC26 Group Labs: The Real Story Isn’t Foundation Models. It’s Evaluation.

Divya Ravi’s piece pulls one idea out of multiple WWDC26 labs and makes it feel much bigger than any single framework announcement.

• OS-bundled models make evaluation a product requirement, not a nice-to-have
• Apple’s labs also exposed practical limits around context windows, routing, schemas, and prompt-injection risk

Read more.📍Level: Intermediate

AI 🤖

Statement On The US Government Directive To Suspend Access To Fable 5 And Mythos 5

Anthropic says it was ordered by the US government on June 12, 2026 to suspend Fable 5 and Mythos 5 for all users, including foreign nationals inside Anthropic, while leaving other Anthropic models unaffected.

• Anthropic says the directive was based on a narrow jailbreak, not broad dangerous capability
• The company is complying, but warns this standard could chill frontier model releases

Read more.📍Level: Beginner

Tutorials 📒

Using Claude With Apple Foundation Models

Artem Novichkov shows how quickly Anthropic’s package turns Claude into a drop-in remote model for Apple’s Foundation Models API, so the same LanguageModelSession, @Generable, and tool-calling patterns can work with either on-device or server-side models.

• It covers real product tradeoffs like auth, model switching, and context limits
• It also shows where this is heading: one API, swappable models, and richer tool use

Read more.📍Level: Advanced

Video 🎥

Build a Swift Terminal Developer Toolkit with TUIkit

Stewart Lynch uses Tuikit to build a real multi-panel terminal app in Swift, not just a toy demo.

• The app combines navigation, persisted state, Git status, and a release tracker inside one terminal UI
• It also shows the full path to something usable: third-party packages, build steps, and installing the tool so it can run anywhere

Watch here.📍Level: Intermediate

Books 📚

Packt Publishing Sale

Packt Publishing is running a huge sale across many of its books, including “AI Driven Swift Architecture” by Walid SASSI and Dave Poirier.

If modern AI development sometimes feels like sailing through unpredictable seas, this book can serve as a lighthouse. It combines practical guides with real-world examples to help you understand AI tools, improve your workflow, and build better Swift applications.

Buy here.📍

The Founder’s Playbook: Building An AI-Native Startup

Anthropic’s playbook reframes the startup journey around what small teams can do when AI is baked into the company from day one, not bolted on later.

• It breaks the journey into Idea, MVP, Launch, and Scale
• The big shift is from building everything yourself to orchestrating AI-assisted work

Read more.📍Level: Beginner

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

It’s easy to write a note this week because… you know why. It’s WWDC week!

Whether you’re attending in person or, like most of us, following online, this is one of the most exciting periods of the year for Apple developers. There’s also a touch of history to it. Many expect this to be Tim Cook’s last WWDC as Apple’s CEO, making the event even more memorable. Whatever the future holds, the technologies presented this week will shape our work for years to come.

To make the most of the conference, here are a few tips:

• Start with the Keynote and the Platforms State of the Union. The Keynote gives you the big picture, while the State of the Union dives into the technical details and often reveals features developers care about the most.

• Bookmark the sessions you’re most interested in and watch them at your own pace. A few years ago, Apple started releasing almost all videos on Day 1, so you no longer have to worry about booking a lab before seeing the related session.

• Don’t skip the Labs! They’re one of the best opportunities to ask Apple engineers direct questions in a more informal setting. Sometimes a five-minute conversation can save hours of debugging.

• Rewatching is absolutely encouraged. If a concept doesn’t click during the first viewing, don’t worry. WWDC content ages well, and you can always return to it weeks or even months later when you need it.

A comfortable pace is probably the best WWDC strategy. There’s no prize for watching every session in a single week, and a healthy sleep schedule will help more than another late-night video marathon.

The reward is worth it. Every year we discover new techniques and fresh approaches to code we use every day. This year is no exception. Even familiar concepts like task cancellation received thoughtful improvements, including new cleanup capabilities for concurrent tasks.

Enjoy the conference, take notes, ask questions, and remember: WWDC is not a sprint but a library you can keep returning to throughout the year.

What is the one announcement that would make your WWDC unforgettable?

Swift Around the Web 🌐

iOS 27: Notable UIKit Additions

Jordan Morgan rounds up this year’s UIKit changes with a clear pattern: most of the work is not flashy, but aimed at adaptable navigation, scene management, and tab or sidebar behavior in a more multi-window, resizable world.

Read more.📍Level: Intermediate

What Is New In SwiftUI After WWDC26

Majid Jabrayilov’s WWDC26 SwiftUI roundup feels refreshingly grounded: not a reinvention of the framework, but a steady removal of real production pain points around containers, navigation, toolbar control, and document workflows.

Read more.📍Level: Intermediate

SwiftUI’s State Is Now A Macro

Artem Mirzabekian explains that Apple has changed @State under the hood from a property-wrapper presentation to a macro-based one, without changing the way SwiftUI code is written day to day.

Read more.📍Level: Intermediate

Coding 👨‍💻

What’s New In Swift: May 2026 Edition

Dave Lester’s monthly Swift digest works best as a quick radar sweep rather than one big headline, pulling together meetup talks, WebAssembly progress, mentorship news, notable package releases, and a few Swift Evolution updates worth tracking.

Read more.📍Level: Intermediate

Announcing The Networking Workgroup

Swift’s Ecosystem Steering Group has created a new Networking workgroup to push the platform toward a more unified and interoperable networking stack, from low-level I/O and shared protocol implementations up to modern client and server APIs.

Read more.📍Level: Advanced

SwiftUI: Observable Macro Under The Hood

Nikita Vasilev unpacks @Observable by showing that it is not just nicer syntax, but a compile-time transformation that rewrites stored properties, injects an ObservationRegistrar, and tracks reads and writes at the key-path level.

Read more.📍Level: Advanced

Apple 🍏

Introducing Time Allowances

Apple is adding Time Allowances in iOS 27, iPadOS 27, and macOS 27 so parents can manage kids’ app time more flexibly across categories like Entertainment, Games, and Social Media. For developers, the part to watch is classification: social features will soon need to be declared in the age rating questionnaire, can trigger a 13+ minimum age rating, and become a required disclosure for new submissions and updates starting in September 2026.

Read more.📍Level: Intermediate

Updated Apple Developer Program License Agreement And App Review Guidelines Now Available

Apple has revised both the Apple Developer Program License Agreement and the App Review Guidelines to cover new frameworks, updated AI terms, kid and teen safety guidance, and a handful of policy clarifications across areas like Live Activities, accessibility-related content changes, and developer identity requirements. This one is worth skimming even if you usually ignore agreement updates, because the changes touch practical areas such as Foundation Models, Trust Insights, Suggested Actions, Customer Engagement APIs, App Store Connect disclosures for minors, and stricter wording around spam or phishing through Live Activities

Read more.📍Level: Intermediate

Update For Apps Distributed In Texas

Apple says new Apple Accounts in Texas will start falling under SB 2420 on June 4, 2026, which means age assurance, parent or guardian consent for minors under 18, and support for consent revocation now matter for downloads, in-app purchases, and significant app changes. For developers, this is less a policy footnote than an integration checklist: review the Declared Age Range API, PermissionKit’s Significant Change API, the new StoreKit age rating property, and the related App Store server notification flow.

Read more.📍Level: Intermediate

Apple Developer Centers Are Expanding To Berlin

Apple is opening its fifth Developer Center in Berlin later in 2026, giving developers across Europe closer access to in-person sessions, workshops, labs, and one-on-one appointments with Apple experts. The post reads less like a product announcement and more like an ecosystem investment, especially with multilingual support and hands-on consultation spaces built into the new center.

Read more.📍Level: Beginner

Design 🎨

SwiftUI Animation Timing

Natalia Panferova breaks SwiftUI animation timing into three layers — easing curves, spring animations, and fully custom timing — and explains them in a way that makes the presets feel much less like magic.

Read more.📍Level: Intermediate

Other cool stuff 🧰

What We Learned Hitting #1 on Product Hunt

Philip Sørensen, Co-founder & CEO of Brew, shares how they hit #1 on Product Hunt and what lessons they picked up along the way. Also what surprised him and the one thing he wishes someone had told him before launching.

Read more.📍Level: Intermediate

Styling Measurement Unit Fonts In SwiftUI

Natalia Panferova shows a neat way to style the value and unit of a formatted Measurement differently in SwiftUI by using AttributedString instead of treating the whole output as one uniform Text.

Read more.📍Level: Intermediate

AI 🤖

Claude Fable 5 and Claude Mythos 5

Anthropic is drawing a sharper line between broad access and frontier capability here, releasing Claude Fable 5 for general use while keeping the less-restricted Mythos 5 behind trusted-access programs for cyberdefense and life sciences.

Read more.📍Level: Beginner

Master Of Puppets: Foundation Models Tool Calling In Swift

Wesley Matlock shows how Apple’s on-device model can stop guessing and start asking your app for facts mid-generation by calling Swift tools inside a single respond flow. The article becomes much more than a framework tour once it reaches the real constraints: SwiftData isolation, Sendable boundaries, actor-owned stores, and the surprisingly important detail that tool results should come back as readable ground truth, not just raw structured blobs.

Read more.📍Level: Advanced

Tutorials 📒

SwiftUI Localization Guide — Change Language Without Restarting The App

Sagar Unagar shows how to make in-app language switching feel truly native in SwiftUI, with instant updates, persisted selection, and proper RTL support instead of sending users to Settings and forcing a relaunch.

Read more.📍Level: Intermediate

Video 🎥

WWDC26: Keynote

Apple’s WWDC26 keynote is the broadest possible reset, with the official chapter list pointing to four big beats: platform improvements, trust and safety, Apple Intelligence and Siri, and the usual sweep across the latest software releases. It is less of a deep technical session than a map of the year ahead, so its real value is in showing where Apple wants developer attention to go before the detailed platform talks begin.

Watch here.📍

WWDC26: Platforms State Of The Union

Apple’s companion session to the keynote is the developer-facing version of the week, framed around “the newest advancements on Apple platforms” rather than big public-facing announcements. In practice, this is usually the talk that matters more once the keynote ends, because it points developers toward the APIs, platform changes, and technical direction that will shape the rest of WWDC26.

Watch here.📍

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Anthropic has confidentially filed for an IPO that could bring the company to the public market as early as this fall. OpenAI is reportedly moving in the same direction. Looks like this year will become one of the biggest for AI-related IPOs and investments. The race is no longer just about models and benchmarks. It’s about infrastructure, profitability, market positioning, and who will shape the next generation of tools developers use daily.

And meanwhile, we are preparing for WWDC.

Apple has already released its intro video, mentioning Labs, popular sessions, and even music. Yes, WWDC has its own official Apple Music playlist, and surprisingly BTS made it there too. The conference keeps evolving from a purely technical event into a full ecosystem experience around development and creativity.

Last week’s poll showed fairly predictable but very realistic expectations from developers: a more stable Xcode with fewer crashes, smarter predictions that actually work as intended, and deeper UIKit adaptation of controls and features for SwiftUI. Many developers still feel that SwiftUI lacks parity in important areas, especially for complex production apps.

Hopefully next week will show whether these expectations are finally met.

And to demonstrate how inspiring WWDC can be, in collaboration with TheSwiftVlad we’re sharing a beautiful SF Symbols animation. Because honestly, wouldn’t it be great to see this level of polish and creativity presented directly during the conference itself?

What is the one WWDC announcement that would instantly make your daily development workflow better?

The AI Agent for Your RevenueCat Data

Meet Rico! 👋

RevenueCat's embedded AI app growth advisor for subscription apps. Ask questions about churn, trials, pricing, paywalls, or retention and get answers using your app's real subscription data directly inside RevenueCat and Slack.

Built to help iOS developers make smarter monetization decisions faster.

Try Rico today!

Swift Around the Web 🌐

Stateless Actors

Matt Massicotte explores a deceptively simple question: if actors exist to protect mutable state, does an actor with no state make any sense at all? His answer is more nuanced than a yes or no, showing that stateless actors can still be useful for off-main execution, custom executors, or protecting external state like the file system — but only when the trade-offs are clearly understood.

Read more.📍Level: Advanced

Task Names In Swift Concurrency

Artem Novichkov walks through Swift’s new task naming support and shows why it matters once concurrent work gets large enough to debug, profile, or inspect in Instruments. A nice detail in the article is that names are meant for diagnostics, not app logic, with clear examples across Task, detached tasks, task groups, SwiftUI’s .task, and the current limitation that async let children still cannot be named.

Read more.📍Level: Intermediate

Coding 👨‍💻

How Do You Build A Mutex That Works With Async/Await?

Omar Elsayed explores a subtle concurrency problem: actors do not guarantee mutual exclusion across suspension points, and Swift’s native Mutex cannot safely span await. The article gets especially interesting when it breaks down Matt Massicotte’s TaskGate approach, using continuations and a small internal lock to hand ownership from one waiting task to the next without blocking cooperative threads.

Read more.📍Level: Advanced

Registering For Push Notifications In SwiftUI

Natascha Fadeeva walks through the full push registration flow in SwiftUI, from requesting permission and checking the current authorization state to registering with APNs and handling the returned device token. A useful reminder here is that SwiftUI still relies on an app delegate for the APNs callbacks, so UIApplicationDelegateAdaptor remains part of the picture even in a modern app.

Read more.📍Level: Beginner

Apple 🍏

All Systems Glow

Apple is using this short post as another WWDC26 countdown marker, with the conference now just one week away and the full event staying online and free. This is more of a mood-setting signal than a product update, but it does mark the final stretch before the June 8, 2026 kickoff.

Read more.📍

Get Ready With The Latest Beta Releases

Apple has released new beta builds for iOS 26.6, iPadOS 26.6, macOS 26.6, tvOS 26.6, visionOS 26.6, and watchOS 26.6, alongside the recommendation to build and test with Xcode 26.5. It is the usual signal to start validation early, especially if your app depends on newer SDK behavior or platform-specific edge cases.

Read more.📍

Design 🎨

Building For Voice In, Visuals Out

Allen Pike argues that AI is moving toward a more natural interaction pattern where people speak and computers respond with interfaces, visuals, and structured output instead of long spoken replies. What makes the piece stand out is its focus on latency: voice feels magical only when it is fast enough to avoid awkward turn-taking, which is why voice-in and visuals-out may be the most practical near-term direction for real products.

Read more.📍Level: Intermediate

Other cool stuff 🧰

Marketing Apps as a Developer

Oleh Stasula, the founder of WinWinKit and Usage is coming back for the part 2. In the part 1 he shared a few personal tips on how he designs apps users love.

This is part 2 - about what to do once you’ve shipped, because shipping without marketing will keep your product invisible.

Read more.📍Level: Beginner

Reactive Frameworks Vs Async/Await Vs AsyncAlgorithms

Artem Mirzabekian looks at the shift in Swift’s center of gravity: reactive frameworks once gave iOS developers one clean model for asynchronous code, but async/await, actors, Observation, AsyncSequence, and AsyncAlgorithms now cover most of that ground with less conceptual weight.

Read more.📍Level: Advanced

Scaling iOS Application Development With Tuist

Michael Gerasymenko and Ashutosh Dubey show how Delivery Hero used Tuist to keep Xcode and Swift Package Manager in place while making a fast-growing modular codebase much easier to scale. The numbers make the story land: local clean builds dropped from 2.5 minutes to 0.5 minutes, incremental builds roughly halved, and CI build plus unit-test time improved by 2.5x — with the trade-off being migration effort, caching-related debugging limits, and the discipline needed to maintain project structure as code.

Read more.📍Level: Advanced

AI 🤖

Enter Sandman Mode: Three Months Inside Xcode 26.3’s Agentic Coding

Wesley Matlock treats Xcode 26.3’s agentic coding less like magic and more like a sharp new tool: excellent at grounded multi-file refactors, compiler-driven fix loops, and SwiftUI preview iteration, but still prone to losing the thread or inventing neat-looking abstractions that do not belong.

Read more.📍Level: Advanced

Tutorials 📒

Enabling Haptic Feedback With sensoryFeedback In SwiftUI

Gabriel Theodoropoulos shows how SwiftUI’s sensoryFeedback modifier makes haptics feel like a natural part of view code, with semantic styles like selection, success, error, start, and stop, plus custom impact variations when more control is needed. The article is especially helpful in the way it explains the trigger model: feedback is tied to changes in an Equatable value, not to the button tap itself, which is an easy detail to miss at first.

Read more.📍Level: Beginner

Video 🎥

Apple’s Hidden AI: Unlock Foundation Models on Your Mac with Apfel

Stewart Lynch turns Apple’s on-device models into something much more tangible by using Appfel from Terminal instead of starting with a full Xcode project. The video gets even more practical in the second half, where he installs it with Homebrew, tries prompt, chat, and server modes, then uses agentic coding to reshape an existing Appfel-based Mac utility into something that better fits his workflow.

Watch here.📍Level: Advanced

Modern iOS Security: Attacks, Defenses & AI

This Swift Academy episode turns iOS security into a very current discussion, mixing real production failures with a broader look at how AI is changing both attack speed and defense workflows. Conversation with Dave Poirier and Deya Elkhawaldeh is especially valuable because it stays practical: weak storage, unsafe assumptions about “secure by default” platforms, and shallow threat modeling are still common, while AI is rapidly lowering the barrier for reverse engineering and automated security review.

Watch here.📍Level: Advanced

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

WWDC is getting closer and closer, and this time it feels less like gentle notification sounds and more like a huge bell ringing about upcoming changes. AI Agent videos are already appearing outside the usual WWDC flow, leadership changes are making headlines, and many are even speculating that this could be one of the last conferences where Tim Cook still takes such a central role on stage.

Of course, Apple is presenting technologies that have been in development for years, not just between conference cycles. Whatever we see this June will continue shaping the ecosystem for many years ahead. That’s why this period always becomes the season of wishlists. Developers start sharing hopes for iOS, visionOS, tvOS, Swift, Xcode, and everything around them. Better multitasking, smarter Siri, more open frameworks, improved AI integrations, fewer restrictions, and more stability.

One topic that keeps surfacing again and again is SwiftUI. Despite all the progress, many developers still struggle with hidden behaviors, unpredictable rendering, navigation edge cases, and debugging complexity. Discussions around “SwiftUI should become open source” appear more frequently every year. Not because developers dislike the framework, but because they want to understand it better, contribute fixes faster, and build more predictable architectures on top of it. Swift itself became stronger after opening up to the community, and many wonder whether SwiftUI could benefit from the same path.

But expectations are tricky things. The lower they are, the easier it is to be surprised in a good way.

So instead of asking about cold expectations, let’s ask something different: what change would genuinely make your everyday development experience better?

Justas here… 🙋‍♂️

I would like to share something you might find valuable.

My friend Simonas and I launched a 100% FREE invoicing tool called - Invcly

Nothing super fancy, just a simple invoicing tool that allows you to send and track invoices. The main reason we built it is because I was tired of paying $20 a month for invoicing software, paying extra for features, for more saved clients, and other upsells. Companies always find ways to charge you more.

With Invcly, you can:

📌 Create and track invoices.
📌 Save clients.
📌 Create and save templates.
📌 Send recurring invoices (still in beta).
📌 Create different products.

And most importantly, it’s always FREE. No hidden fees or hard paywalls (you know what I’m talking about).

Feel free to use it, share it with friends, and most importantly, send me an email with any bugs or features you would like to see.

Enjoy, and let’s make invoicing simple and free! 🧾

Try Invcly!

Swift Around the Web 🌐

Swift Task Lifecycle Management - Structured vs Unstructured Concurrency

Sagar Unagar shows why concurrency structure in Swift is not just a style choice, but something that directly affects task lifetime, cancellation, error propagation, and UI consistency. His guidance is refreshingly clear: start with structured tools like async let, TaskGroup, and SwiftUI’s .task, and only move to unstructured Task or Task.detached when the work is genuinely independent.

Read more.📍Level: Advanced

UniqueBox, Ref, And MutableRef In Swift 6.4

Artem Mirzabekian explores how Swift 6.4 expands the language’s ownership vocabulary with UniqueBox, Ref, and MutableRef, giving developers more precise tools than class boxes or unsafe pointers for expressing heap ownership and scoped access. A useful way to read this addition is as a split between storage and access, which makes these types especially relevant for lower-level libraries, custom storage, interop layers, and performance-sensitive code.

Read more.📍Level: Advanced

Coding 👨‍💻

Making A SwiftUI Sheet Automatically Size To Fit Its Content

Daniel Saidi shows a neat workaround for one of SwiftUI’s missing sheet features: sizing a sheet to its actual content instead of forcing it into .medium, .large, or a guessed fixed height.

Read more.📍Level: Intermediate

Working With The Keychain In iOS

Natascha Fadeeva explains the Keychain through its core query model, showing how the same dictionary-based structure powers save, read, update, and delete operations for sensitive data like passwords and tokens.

Read more.📍Level: Intermediate

Refreshing And Animating Views Using TimelineView In SwiftUI

Natalia Panferova shows how TimelineView gives SwiftUI a clean way to reevaluate views on a schedule, which makes it especially useful for clocks, timed refreshes, and visuals that need to stay in sync with time. A helpful distinction in her article is that TimelineView belongs to the UI layer, while Timer is still the better fit for background work, data refreshes, or logic that should live outside the view.

Read more.📍Level: Intermediate

Apple 🍏

Upcoming Changes To Age Ratings In Australia And Vietnam

Apple is updating App Store age ratings in Australia and Vietnam on June 18, 2026, with Australia dropping the 15+ category and Vietnam introducing local age ratings aligned with national law. The key thing for developers is to revisit the App Store Connect age rating questionnaire now, since existing ratings may be recalculated automatically from the answers already on file.

Read more.📍

Design 🎨

Making Accessibility Accessible

Bas Broek lowers the barrier to accessibility work by focusing on practical tools like Voice Control labels, Hover Text, and the VoiceOver caption panel instead of starting with deep theory. The most useful takeaway is that accessibility becomes easier to improve when teams can quickly see what assistive technologies expose and spot where labels, traits, or element exposure break down.

Read more.📍Level: Intermediate

Other cool stuff 🧰

Modern Isn’t A Value. Fit Is.

Omar Elsayed argues that “modern” APIs like async/await, actors, or new architectures are not automatically better when they make the surrounding codebase harder to read and integrate with. The most useful takeaway is the boundary rule: modernize internals when it helps, but keep external APIs aligned with the system your team already speaks.

Read more.📍Level: Advanced

In Praise Of SwiftUI

SwiftUI’s biggest win may not be “UI in Swift” at all, but the reactive data flow that keeps complex interfaces in sync without so much manual plumbing. Sarah Reichelt makes a grounded case for treating it as the default choice for speed and maintainability, then reaching for AppKit or UIKit only when a real gap, bug, or performance limit shows up.

Read more.📍Level: Intermediate

SwiftUI Should Become Open-Source

Max Seelemann argues that SwiftUI still struggles with core platform behaviors like keyboard focus timing and macOS drag and drop, which makes Apple’s “best way to build an app” promise harder to defend. His bigger point is that open-sourcing SwiftUI could speed up fixes, reduce its dependence on OS release cycles, and give developers a way to help move the framework forward where Apple has been too slow.

Read more.📍Level: Intermediate

AI 🤖

Anthropic Co-Founder Chris Olah’s Remarks On Pope Leo XIV’s Encyclical “Magnifica Humanitas”

Chris Olah argues that AI should be examined not only by the labs building it, but also by outside critics willing to question its broader social and moral impact. He centers that case on three concerns in particular: global inequality, human flourishing, and how little we still understand about advanced models, while candidly noting that commercial and geopolitical pressure can push frontier labs away from acting responsibly.

Read more.📍

Tutorials 📒

Create And Style App Shortcuts In iOS Using AppShortcutsProvider

Shankar Madeshvaran walks through the full App Shortcuts flow, from AppIntent and AppShortcutsProvider setup to branded tiles with custom tint, solid backgrounds, gradients, and Light/Dark variants. Shortcut styling lives in Info.plist and asset catalogs, not Swift code, and the same branded look also carries into Spotlight results.

Read more.📍Level: Intermediate

Video 🎥

Decoupling SwiftData in SwiftUI: Is It Worth It?

Mohammad Azam uses a practical SwiftData and SQLite example to show how a protocol-based DataAccess layer can decouple persistence from SwiftUI views, while also exposing the real cost of that abstraction. This pattern gives flexibility and cleaner boundaries, but you lose SwiftData conveniences like automatic UI updates and can end up with more architectural weight than the app really needs.

Watch here.📍Level: XXX

One more Thing 🎮

W.W.D.C. 2026: The Pregame Quiz

Jordan Morgan turns pre-WWDC nerves into a smart trivia round built from the year’s Apple news, App Store policy updates, hardware launches, and community lore. It works as more than a quiz, really — a fun way to refresh the details developers are most likely to want in their heads before the keynote.

Play here.📍

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Hello! 👋

This week I partnered with Shannon Ash. She’s been writing CVs since COVID-19 hit, helping people position themselves better and land new jobs.

Six years later, her work is still producing real results.

Some results:

• 87% of her clients landed interviews within 2 weeks of applying.

• 70% reported a salary increase, up to 35%, while securing their new role.

• Some went from months, up to 4 months, of silence to multiple offers at once.

Here are few testimonials:

The clients she mainly works with are usually dealing with one of these problems:

• Ghosted - they’ve been applying for 2+ months with zero replies and no interviews.

• Pivoting their career - they’re in their late 30s or 40s with a decade of expertise, but don’t know how to translate their wins or skills into a new industry or niche.

• Aspiring to be a leader - they’re aiming for the C-Suite or a Senior Lead role, but their current CV still looks like a list of tasks, not a record of impact. The CV changes with seniority.

• Procrastinating daily - they’re unhappy where they are, but the mental weight of updating their CV is a lot. They keep putting it off and don’t have the time to even start.

Offer:

• Cover Letter and CV: a positioning statement letter, which is Shannon’s spin on a cover letter, plus a CV.

• Fully optimized LinkedIn profile to match the new narrative.

Price: 450€ 📌

Important - this offer has limited spots:

• June only 5 spots available.

• July only 5 spots available.

• August only 10 spots available.

Interested? - Just reply to this email or contact me at - thisweekinswift@gmail.com

Swift Around the Web 🌐

Deprecating Your Own Convenience API

Majid Jabrayilov shows a neat way to stop compatibility helpers from becoming permanent dead code using Swift availability annotations. The key idea: deprecate wrappers when the new minimum OS makes them unnecessary, then obsolete them later so the compiler forces cleanup.

Read more.📍Level: Intermediate

A Feature Flags System In Swift

Artem Mirzabekian shows how feature flags can grow from simple booleans into real app infrastructure while staying type-safe, thread-safe, and predictable. The most useful part is the full architecture: typed features, priority-based resolution, local overrides, SwiftUI environment injection, and a built-in toggle screen for QA and testing.

Read more.📍Level: Advanced

Coding 👨‍💻

Tracking App Store Purchases With Server Notifications

Mohammad Azam shows how App Store Server Notifications complete the StoreKit 2 story by letting your backend react to renewals, refunds, billing issues, expirations, and purchases outside the app. The most useful part is the payload breakdown: Apple sends nested signed JWTs, so the key is decoding signedPayload, then signedTransactionInfo and signedRenewalInfo, to extract transaction and renewal state cleanly.

Read more.📍Level: Intermediate

ContentUnavailableView In SwiftUI - Complete Guide With Examples

Sagar Unagar shows why ContentUnavailableView is more than a simple empty-state helper: it gives SwiftUI apps a consistent, accessible way to handle no-content, failed-load, and no-results screens without rebuilding the same UI each time. The most useful part is the practical range, from the built-in .search variant to custom actions and recovery flows, while keeping empty states restrained and platform-native.

Read more.📍Level: Intermediate

Apple 🍏

Coming Bright Up - WWDC26

Apple is teasing WWDC26 with a short preview, calling it a week of technology, creativity, and community that will be online and free. It is more of a save-the-date than a technical update, but confirms Apple is starting the WWDC ramp-up.

Read more.📍

Introducing The 2026 Apple Design Award Finalists

Apple has announced the 2026 Apple Design Award finalists, highlighting 36 apps and games for innovation, ingenuity, and technical achievement. It is a good shortlist to browse before WWDC, especially for a quick look at the product quality and design direction Apple is celebrating this year.

Read more.📍

Other cool stuff 🧰

Using Xcode MCP With Claude Code

Daniel Saidi shows how Xcode 26.3’s built-in MCP server gives Claude Code direct awareness of project structure, schemes, builds, and tests instead of treating Swift files as isolated text.

Read more.📍Level: Intermediate

Understanding Basic Animations In SwiftUI

Natascha Fadeeva explains the two core SwiftUI animation paths: animation(_:value:) for view-driven implicit animation and withAnimation for explicit state-driven changes. The most useful part is the decision guide, including when to use each approach and the iOS 17+ completion handler for follow-up work after an animation finishes.

Read more.📍Level: Beginner

AI 🤖

How Claude Code Works In Large Codebases: Best Practices And Where To Start

Anthropic says Claude Code works best in large codebases when teams invest in the harness around the model, especially CLAUDE.md files, hooks, skills, plugins, LSP integrations, MCP servers, and subagents. The most useful takeaway is practical: live agentic search avoids stale indexes, but results improve when the codebase gives Claude clear local context and path-specific expertise.

Read more.📍Level: Intermediate

Tutorials 📒

How To Recognize Text In Images With Vision In Swift

Khoa Pham shows how Apple’s newer Vision API makes text recognition cleaner by replacing callback-heavy VNRecognizeTextRequest flows with the async RecognizeTextRequest introduced in iOS 18 and macOS 15. The key takeaway: avoid fragile continuation wrappers around the older synchronous API, and use the new async request model when your deployment target allows it.

Read more.📍Level: Intermediate

Optimizing For VoiceOver And Voice Control

Bas Broek shows how an accessibility change that feels cleaner for VoiceOver can make Voice Control noticeably worse, especially when combined elements turn separate buttons into hidden actions. The key takeaway: improving one assistive technology can hurt another, so the better solution is sometimes the more balanced one, not the most “optimized” version.

Read more.📍Level: Advanced

Video 🎥

Understanding Swift Result Builders-The Power Behind ViewBuilder

Stewart Lynch starts with ViewBuilder in familiar SwiftUI containers, then builds custom result builders from scratch to show how declarative syntax works under the hood. The most useful part is the hands-on progression from simple string builders to conditional checklist generation with buildExpression, buildOptional, and buildEither.

Watch here.📍Level: Intermediate

Claude Code Just Dropped /Goal (Master It In 8 Minutes)

This walkthrough explains /goal as a hands-off Claude Code workflow, where one model does the work and a second agent checks whether the finish line has been met. The key takeaway: goal conditions should be specific and verifiable, with turn or time limits to avoid wasted tokens.

Watch here.📍Level: Beginner

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now