[The Mobile Report] Issue #1: Two Kinds of Teams. AI Tools. Mobile Fullstack.
New newsletter format in addition to regular articles. Two kinds of teams and AI-augmented development. Push notifications and mobile fullstack development.
About this new format
I want to change things up a little bit with The Mobile Engineer and try out a periodical publication like this one, in addition to the occasional pieces I’ve been doing here. We’ll start with every two weeks for now to see if I can keep up with that cadence.
In each issue I’ll be sharing the latest stuff I’ve been reading (news, interesting things I run into, developments, etc.) from the mobile development world. Along with my opinion and take as a senior mobile engineer on each one of them.
I’ll be trying to keep some topics ongoing across issues, things like Mobile at Scale, Architecture & Design Patterns, and probably AI-augmented development (since it’s the new wave to ride and it’s genuinely useful). And I’ll also point back to my own archive at least once per issue so you have somewhere to dig deeper.
This doesn’t mean that my newsletter is going to turn into yet another article-review “weekly” newsletter, which there are plenty of out there. I will still post my regular articles with architecture and insights I find throughout my work building mobile apps. But what I’m trying to do here is just have something more regular that helps me digest what is going on in our fast-paced changing world, and hopefully is also useful to you guys.
I’m happy to hear feedback on this and how I can improve it to be more valuable to you, so let me know, email me, leave a comment, or DM me.
The Take
Two groups of teams are starting to emerge in software development these days, the ones that are embracing AI and the ones that aren’t.
It feels like we’ve been through this before.
Before the AI, mobile teams could be bucketed into two groups: those that put effort into the craft, care about architecture, design patterns, SOLID principles, CI/CD, etc. and keep their apps and codebases easy to change, and those not caring about any of that and following Apple dogma that MVCs and storyboards are great and that you should code one simple way no matter how complex or large your application and teams get.
The first group of teams moved evenly and steadily in the beginning, and continued to ship things steadily as their app and team grew over time.
The second group of teams, on the other hand, would ship fast at the MVP stage and maybe through a couple more iterations after that. But then they would slowly ground to a halt under the weight of bugs, tech debt, and an unwieldy codebase that nobody could touch anymore without breaking several other unrelated things along the way.
The same kind of divide is starting to happen now with AI.
The teams that are putting in the effort and building guardrails, changing their processes to adapt to this new tool, etc., are starting to move faster. And the ones that aren’t are starting to be left behind already.
Here’s the irony though.
The things that mattered for that first group of teams (clean architecture, solid design patterns, real CI/CD, etc.) are exactly the same things that let them move faster now with AI. Because the structure is already in place and AI just accelerates it from there.
Boilerplate is no longer a concern, architecture provides a clear structure and repeating patterns to work within. And devs can handle a lot more and ship faster than before without being afraid to break things along the way.
Meanwhile, the teams that skipped all that work are just vibe-coding with their agents, and they’re crashing and burning, just faster than before.
I am personally fully all in on AI-augmented development now. Lately I barely leave Claude Code and the terminal as I work on my iOS projects, and those projects keep expanding more and more into full-stack development encompassing the backend as well.
The biggest takeaway from my recent research into how other teams are doing this isn’t that you need more agents. It’s that your AI workflow is only as good as the codebase and context you give it.
With all that, there are still a couple of bottlenecks I keep hitting myself working with AI, such as cognitive overhead of context-switching across multiple agents working on different things in parallel, and the code review process being difficult given the amount and speed of code AI is now generating.
If you’ve cracked either of those, please let me know.
Let’s get into it.
Mobile at Scale
Two pieces this issue on the kind of testing infrastructure that pays off and compounds over time as your codebase grows.
Building Resilient Mobile Apps: A Layered Testing Strategy for Long-Term Stability
Gusto has a piece here where they walk through the test layers they have for their iOS app, with actual Swift code samples and all (protocol-based mocking for ViewModels, swift-snapshot-testing for visual regressions, URLSession stubbing for deterministic XCUITests, parallel execution on Bitrise, etc.).
What got me to actually click through and read it was the before/after numbers they shared. They brought down their test suite from 75 minutes to 39 minutes, and ended up with zero late-discovered release regressions after that.
I have difficulty with iOS UI tests myself, hands down. So I’m planning to sit down with this one and read it in depth and dissect.
Cross-workflow integration testing on iOS: a recipe for macOS + Docker pipelines
This one is technically a vendor marketing piece from Bitrise, but it’s still worth reading because there are a couple of interesting concepts in here that apply regardless of where your CI actually runs.
The first one is integration testing your mobile app against a real running backend, hosted in a parallel Linux workflow next to your macOS test workflow (on Bitrise or whatever CI of your choice), instead of just mocking the server in your tests.
The second one is the monorepo setup they mention, where you’d have backend, frontend, and mobile code all in one repo so that changes can be atomic across the stack.
I’ve been toying with both of those concepts at work and they’re a lot more interesting than they sound on the surface. So probably a separate article from me coming on this in the future.
AI-augmented development
This is The Take’s thesis in practice, with five pieces from people who are actually putting in the work to make AI accelerate their iOS development.
My agentic engineering workflow at an AI unicorn 🦄 ($ paywalled)
This is probably the most complete public account of agentic iOS engineering that I’ve come across so far.
The author Jacob Bartlett is a senior iOS engineer at Granola (a London startup that just hit unicorn status). He’s been averaging around 8 PRs a day in his role with roughly 99% of the code being AI-written at this point.
The article walks through how he gets to that point in his day-to-day. He talks about stacked diffs in Graphite that make AI code review workable, a 1-writer-plus-2-readers multi-agent pattern he uses, the verification chains he sets up that let Codex run overnight on flaky Bitrise CI loops, and detailed timelines for every step of his workflow.
He also goes into what he’s calling “knowledge debt contagion.” Which is the framing every team going all-in on AI needs right now, and that a lot of people don’t have a language for yet.
Both of the bottlenecks I called out in The Take get partially addressed in his article as well, so I’m planning to deep dive into this one and dissect it in detail myself.
How I use FlowDeck to let my AI agent build and run my apps
FlowDeck is a CLI that wraps Xcode’s build and run pipeline in a way that’s friendly to AI coding agents. Cleaner output, less noise for the agent to chew through (compared to raw xcodebuild output anyway). In this piece Donny Wals walks through his workflow letting his agent build, install, and run his apps end-to-end.
I’ve been using XcodeBuildMCP for the same kind of reason myself, barely leaving the terminal and Claude Code these days as I work on my iOS projects. But FlowDeck looks like a more complete package than what I’m currently using, so I want to try it out at some point soon.
Xcode Instruments Time Profiler: Improve performance with AI
I’m not going to lie, I’ve shied away from performance work in my own apps in the past because opening up Instruments and sifting through its data was always annoying and time-consuming for me.
But in this piece Antoine van der Lee shows how you can hand that whole boring part off to your AI. You feed it the profile data, let it find the hot spots, and propose changes to your code from there.
The piece also argues that you should expose your app as a CLI so the AI can verify its own output. And while I do see the value in that, I’d push back a little here. Because if your architecture cleanly separates business logic from UI then you’d already be able to test things easily, and the CLI part practically comes for free with that kind of setup anyway.
Good architecture has always made apps easier to test. And turns out it also makes them easier for AI to work with too.
Network Requests Optimization using Xcode’s Simulator & Agents
This piece is the same shape as the previous one, just applied to network performance instead. The idea is to capture runtime networking data from the Simulator, feed it to your agent along with the relevant code, and then ask the agent for optimization suggestions from there.
There’s a bit of self-promotion for Antoine’s own tools in there, but the underlying workflow itself is sound.
And again, you can see how a codebase with clear separation makes this kind of analysis productive. Because if your networking layer is buried in view controllers, your AI has nowhere to start. Whereas if duplicate calls or redundant fetches are sitting in one place, they’re easy to spot, either by you or by your agent.
Expanding Swift’s IDE Support
Swift now has first-class language support in Cursor, VSCodium, and other agentic IDEs through the Open VSX Registry. With auto-install for Cursor users right out of the box. And this is fantastic news for those of us who are trying to break out of the shackles of Xcode at some point.
The caveat though is that you’re not leaving Xcode entirely just yet, because simulators, Instruments, signing, and the whole build system all still live there. But for everyday editing and code-thinking work, the gap is closing fast.
From the Archive
Mobile Dev Interview In The Age of GenAI
If you’re prepping for an iOS interview right now or hiring for one yourself, this is the piece I’d point you to.
I wrote it back in late 2024 right after Gergely Orosz published his piece on how GenAI was reshaping tech hiring. And most of the points I argued in there have only gotten more true since then.
Cover letters are mostly noise now in this AI world. Resumes are low signal, so you might as well just use LinkedIn instead. And algorithmic puzzle interviews are finally dying off, which is honestly just good riddance in my books.
The signal that still survives all of this is take-home assignments combined with a pair programming session on the code the candidate submitted. You can see almost immediately who actually understands what they shipped, regardless of whether they used AI to write it.
Worth preparing for that loop, on either side of the table.
Architecture & Design Patterns
Two deep reads this issue on what’s actually happening underneath the surface when your code runs.
URLSession to Electrons: How Networking works on iOS ($ paywalled)
This is a good one. Jacob has been on a roll lately with these kinds of in-depth deep-dive articles. In this particular one you’ll get to learn a lot about how data sent from iOS apps (or really any other app in general for that matter) travels over the internet layers across the network.
Practical stuff to take away from this article for mobile engineers:
Batch Your Requests to Save Battery
The Why: The article notes that your cellular radio stays in a high-power state for a while after any burst of traffic. Frequent, small “drips” of network activity keep the radio awake constantly, which drains the battery.
The Approach: Batch your network requests. Instead of sending five separate analytical pings or minor data fetches back-to-back, combine them into a single endpoint request or queue them to fire together at strategic intervals.
Ask Your Backend Team About HTTP/3 (QUIC)
The Why: The article highlights QUIC as a newer transport protocol built on top of UDP that provides both speed and reliability. HTTP/3 utilizes QUIC to bypass the latency of TCP’s connection setup and avoid head-of-line blocking.
The Approach: Start a conversation with your backend/infrastructure team about enabling HTTP/3 on your servers. Once enabled server-side, recent iOS versions often handle the multiplexing improvements automatically, making your app feel significantly faster on flaky networks.
Unexpected Task suspension points in Swift Concurrency
In this article Antoine flags something that a lot of Swift devs tend to miss. The concurrency runtime can introduce suspension points beyond just your explicit await calls. And actor re-entrancy bugs can sneak into code that looks safe because of that.
That said though, I largely agree with the counter-point on this one. Because if you have proper actor isolation set up for your background work, then it’s mostly a non-issue for you anyway. And the same goes for if you happen to be on RxSwift or some other mature concurrency layer in your codebase.
And finally…
A ridiculously-lightweight push notification service
In this article an indie iOS dev walks through how to send push notifications by talking directly to APNs over HTTP/2. With just a handful of Swift code plus a 200-line Cloudflare Worker for the server-side bit of it.
No OneSignal, no Firebase Cloud Messaging, and none of the 23K+ lines of SDK code that come along with either of those options.
This is where I think mobile development is generally heading these days, toward less reliance on bloated third-party SDKs and more end-to-end ownership across the stack. Especially now that AI handles a lot of the parts of “going full stack” that used to slow us down for us (things like picking up new backend frameworks, writing all the boilerplate, navigating unfamiliar tooling, etc.).
The constraints we live with every day as mobile devs (memory, battery, intermittent connectivity, tiny screens, you name it) sharpen us in a way that frontend and backend engineers don’t always have to deal with. And with AI now removing the friction of crossing stack boundaries, that sharpness carries over surprisingly well.
I wrote more about this argument in a recent piece on why mobile engineers are best positioned to go full-stack in the AI-augmented world. And Pushy here is just one small good example of what I was talking about in there.
That’s it for this issue. Thanks for reading.