
Issue 772
16th October 2026
Written by Konstantinos Nikoloutsos
Comment
Hello, iOS Dev Weekly readers 👋 It’s me Konsta.
I keep being surprised by how quickly AI is changing the way we work. This week, Anthropic shared why it replaced Git in its monorepo with Scion: source control was struggling to keep up with all the code being produced. They acknowledge earlier work like Google’s Piper, but seeing Git become the bottleneck still made me pause. I can understand familiar tools becoming less suited to the way a team now works. At the same time, duttish’s comment on Hacker News raises a fair question: how does review keep up with that pace when they still regularly find problems in Claude’s output?
On the mobile side, more stories about teams moving back to native have been catching my eye. Shopify’s move back to native caught my attention last month, and now I’ve come across Coinbase and ResortPass. A few examples don’t necessarily make a trend, but I’m interested to see where this goes.
There’s something else I can’t stop thinking about. Everyone seems excited to write new skills for agents, and the pile of AGENTS.md files, instructions, and documentation keeps growing. It brings to mind Uncle Bob’s warning that comments are future lies. I think these instructions can become future lies too. Each project’s codebase keeps evolving, and what made sense when we wrote a skill might no longer hold a few months later. So how do we get to a point where those instructions stay up to date automatically, with agents spotting what needs to change and proposing updates? Some of that context lives in the code, but some lives in conversations and meetings, where teams discuss where a project is heading and what problems they expect to face. My guess is that an agent would need to be able to listen to those discussions too, to understand when our intentions have changed. I haven’t figured out what that would look like yet, but the question keeps coming back to me.
Enjoy this week’s issue!
– Konstantinos
Sponsored Link
Learn AI-Assisted iOS Development with KodecoCurious about AI but don’t know where to start? Or unsure that it’s more than hype? Kodeco’s new program shows how AI helps at every stage of iOS development, from exploring legacy code through testing and review to the App Store, with you in charge throughout. Use code iosdevweekly for lifetime access at $340 (launch price $500) until 6 November. Find out more.
News
Meet Apple HomeView, a new way to enjoy entertainment and manage the homeApple released HomeView, and not everyone is convinced?. For developers, Apple’s updated design guidance is worth a look, Widgets now covers HomeView, and Live Activities includes advice for limited-width layouts.
Personally, I suspect Apple will invest heavily in making Siri stand out over the next few years, with devices like this becoming more ways to interact with it throughout the day. I am looking forward to seeing how that develops. BUT the million-dollar question for those of us in Europe is: when will we get the full Siri experience?
And if you’re reading this aloud, I hope I haven’t just activated Siri on your iPhone. 😅
Code
Swift Actor Reentrancy: Stop Duplicate Network RequestsActor reentrancy means that while an actor method is suspended at an await, other work can run on that actor and change its state before the method resumes. My old coworker Stavros, a staff iOS developer, recently told me that most developers he spoke to in his latest interviews weren’t aware of this problem. Give Mohit Agrawal’s article a read to understand how it happens, how it can lead to duplicate network requests, and how to prevent them.
Exploring _UILiquidLensView
Livsy Code explores _UILiquidLensView, the private UIKit view behind an interactive glass lens, looking at its resting and lifted states and how Telegram uses it. The sample menu makes those interactions easier to understand, and it’s worth a look for that alone. As the article makes clear, this is an experiment: private APIs don’t belong in production App Store code.
How I Architect SwiftUI Apps for Swift Concurrency – So the Compiler Stays Quiet
I suspect plenty of teams have reached the point where adding a single await feels like an invitation to a bunch of Sendable and actor-isolation diagnostics. It can be frustrating, especially in an existing codebase, but I’d much rather have the compiler catch a threading issue than discover it at runtime.
Karin Prater shares how she structures her SwiftUI apps to keep the compiler quiet. I recommend spending some time with her earlier articles and videos too. She has a lot of good material that helps these ideas fit together.
enumerated() Gives You an Offset, Not an Index. On a Slice Those Are Different Numbers.
Using the offset from enumerated() as an index feels like a future bug waiting for a small refactor: it works with an Array, then switching to an ArraySlice can expose the assumption. It reminds me of Juan Marin’s comment in issue 767, calling UIScreen.main.bounds “a bug waiting for a device” before discussing the iPhone Duo. It’s easy to rely on assumptions that hold until something changes. This article explains the difference and shows when to use the element directly, iterate over .indices, or pair indices and elements with zip.
Tools
BlueprintThis is the kind of tool I can imagine adding to a team’s CI/CD pipeline and having people notice straight away. Blueprint, by Mustafa Natur, turns your app icon into a blueprint-style version, with colours and badges and custom labels(thanks for that) that give testing builds and release candidates their own character. It makes them easier to tell apart and adds a little fun to the work.
It reminds me of the fastlane badge plugin, which adds a badge or overlay to your icon. What appeals to me here is the straightforward command-line workflow: install it, point it at an Icon Composer file or an app icon set, and generate a variant for your build configuration.
Article
AI-Friendly Frameworks: As Abstraction Moves Up, How Can Verification Keep Pace?How does an agent know that the SwiftUI screen it just built actually works as intended? That’s the question that stayed with me after reading Fatbobman’s article. He explores how frameworks can give agents useful feedback, with SwiftFairy and InnoDI as examples. I’d much rather give an agent a way to check its work than keep asking it, “Are you sure?”
Pragmatic Testing for Agents
This connects nicely with the question of quality in my introduction. An agent can write plenty of passing tests, but which bugs would they actually catch? Serg Dort shares how he trimmed his Swift app’s test suite by focusing on behaviour rather than tests that repeat the implementation. What caught my attention was that the agent also deleted a test that mattered. Checking coverage exposed the gap, and he shows how he repaired it. There’s a reusable skill included, but the reasoning behind it is the part I would spend time with.
And finally...
You can now say ‘hello’, Apple-style.
