Issue 761

31^st July 2026

Written by Alex Ozun

Comment

Happy Friday!

If I had to summarise the common theme of this week’s issue, it would be “development at scale”. Apple platform development, not to mention Swift itself, has long since reached a level of maturity where the community is discussing the various challenges of building software at scale.

So I’m not surprised to see several great articles published recently that revolve around these challenges. Conveniently, as someone who is part of a large development team, I have a personal interest in these topics, so putting together this issue and providing the commentary felt effortless.

I hope you enjoy it 🫡

– Alex Ozun

News

Apple launches a new leasing program Apple Upgrade

This week, Apple announced Apple Upgrade, a new U.S. leasing programme for iPhone, iPad, Mac, and Apple Watch. My impression is that it’s a fairly standard leasing programme with multiple end-of-lease options, including a buyout that lets you keep the device for its original list price, effectively treating it as an interest-free loan.

But the more interesting part of the announcement was the controversy around the so-called ‘Restricted Mode’ discovered in the iOS 27 betas. It was initially suggested by 9To5Mac that Restricted Mode could be used to limit the capabilities of financed devices if you miss a payment. Apple then dismissed that assumption, stating that Restricted Mode won’t be used for this purpose, but without clarifying how it will actually be used. That leaves an uncomfortable question of how Restricted Mode will be used at launch, and what Apple (and other actors) might do with it in the future.

Code

Revisiting the JET iOS Modular Architecture in 2026

I still remember when Alberto first published the original article outlining Just Eat’s modular project architecture. It quickly became one of the most influential resources on modularisation, with many folks I’d discussed the topic with over the years directly citing it as inspiration for their own modularisation efforts. This makes me think that sharing this 7-years-later update is important for the community.

In the new article, Alberto describes an interesting challenge: a new module didn’t fit cleanly into any of the existing categories, leaving it in limbo between the Domain and Shared layers and prompting the team to reconsider their modularisation model from first principles. The final design they arrived at feels both convincing and natural.

Side note 💡: one small detail in the article that caught my attention was this: “The internal architecture of a module is unconstrained and teams may use MVVM, TCA, or anything else, provided they do so behind the facade.” Knowing that many teams, ours included, try to standardise their architectural patterns across the codebase, I felt compelled to reach out to Alberto to confirm that this is how it works in practice. Alberto confirmed that it is indeed common practice at Just Eat, and one the team is happy with, as it has saved them from unproductive architectural debates.

AI Broke Code Review. Here’s How to Rebuild It.

Whether or not you agree with Pawel that AI has indeed “broken” code review, it’s hard to argue that the existing social contracts around it are being heavily challenged by the sheer volume of AI-generated code. From whispers across the community, I know that almost every team is exploring some form of AI-powered code review to reduce the burden on human reviewers and let them focus on diffs that need their judgement most.

I like the article’s proposal (and the memes 🙂) to treat code review as a pipeline that starts before the pull request is opened. The pipeline acts as a “low-pass” filter, making sure that by the time the diff reaches human reviewers, all that’s left are the decisions a machine isn’t allowed to make. Easier said than done, and I can see how putting these systems in place would require significant upfront effort, but it seems like a worthwhile investment for teams.

The part I agree with most is the boundary it keeps around automation. Agents can apply safe mechanical fixes, but anything touching critical behaviour or public APIs still goes to a human. This feels like the right direction for code review when AI can generate code much faster than people can meaningfully review it.

Demystifying Thread Hopping with Swift 6.2 Approachable Concurrency

If I’ve learned anything about Approachable Concurrency it’s that there can never be too many articles explaining Approachable Concurrency. And this one from Nikita does the explaining part very well. I particularly like the side-by-side execution traces comparing how work is scheduled before and after enabling Approachable Concurrency, which makes the article useful as a quick reference. And as someone who hasn’t yet fully embraced Swift 6.2 and Approachable Concurrency, I find its conclusions reassuring.

Tools

The coolest use for the Vision Pro

Long-time indie developer Christian Selig, the creator of the legendary Apollo(RIP🪦) has a knack for finding practical uses for Apple’s platforms. This time, he built Prospector, an open-source Vision Pro tool that lets you load a 3D model and explore it at full scale. Christian used it to walk through the house he’s building before it exists. It’s a simple idea, but also one of the clearest examples I’ve seen of spatial computing solving a real problem.

And finally...