Issue #2: Save All The Tokens You Can!
Everyone's trying to save on tokens, and the iOS community is shipping tools for it. Why AI belongs on your backend, not in your app. Plus Universal Links at scale, reliable uploads, and feature flags
Seems like everyone these days is trying to save on tokens lol.
I get it. This is pretty much how it went for me too. First I got excited about all the AI tools I could use. Then I started handing the AI more and more of the mundane tasks I didn’t want to do myself (if I ever have to sift through another log file by hand again, god no, just let my AI clanker do it for me). And it was great at first!
But then I ran out of tokens lol.
So I started paying a lot more attention to how I use it and how many tokens it burns. For me the solution has been writing as many scripts as I can for the AI to lean on, so it isn’t burning through tokens parsing JSON output and other stuff like that by hand. And that seems to be the theme across the iOS community right now too. Everyone is trying to cut down on token usage and building little tools to help you do it. Which is great. We need them.
There’s also a lot of enthusiasm right now about “let’s add AI and build harnesses into all the apps!” which is great, most of the time. But a lot of the implementations I see feel like dejavu from the Parse and Firebase days. Ship a subpar solution that’s mildly more convenient, then run with it as far as you can until you hit the breaking point, instead of building the thing properly with the right tool from the start.
Let’s get into it.
Mobile at Scale
One piece this issue, and it’s exactly the kind of hard-won production experience I wish more people wrote down.
Universal Links At Scale: The Challenges Nobody Talks About
Universal Links are one of those things that look easy in the tutorials and then blow up in production. Alberto De Bortoli (originally on the Just Eat Takeaway engineering blog) wrote up what it actually takes to run them at scale, and it’s a great read.
What I liked most is how methodical he is about validation. It’s not enough to validate your own apple-app-site-association file in CI. You also need a checker for the AASA file that Apple actually cached on its own CDN, because those two are not always the same thing. There’s nothing worse than shipping all your fixes to prod and then finding out your universal links still don’t work, because Apple’s CDN is serving a stale copy of your file on some caching delay you have no control over.
He also calls out a bunch of non-obvious gotchas. The one that got me was the pattern matching, where Apple’s matching doesn’t behave like the regular expressions you’d expect. There’s also good stuff on validating both your deep-linkable and non-deep-linkable URLs in CI, and the gotchas around encoding characters in your URLs.
Mobile devs are very often the ones who get pulled into the deeplink and universal link implementation, and at worst get blamed all the time when they don’t work. This is a good overview of the approach and the things to keep in mind as you build robust universal linking into your app.
AI-augmented development
Save all the tokens you can! let’s go!
AI-Powered Xcode Simulator Automation
Yes, this is a self-promotion piece from Antoine for RocketSim’s new CLI. It’s still worth a look, especially if you want an agent to do exploratory or UI testing for you.
The idea is to let your agent drive an already-running simulator (tap, type, scroll, read the screen) while keeping the token cost down. It leans on a compact, agent-friendly output format and a persistent connection to the RocketSim Mac app that holds simulator state between commands, so the agent isn’t re-paying for context on every step. It also gives the agent a better accessibility tree to read, which matters more than it sounds.
If you’ve seen FlowDeck and wondered how this compares, they actually sit at different layers. FlowDeck is the whole build-run-test loop (”never open Xcode”). RocketSim’s CLI deliberately doesn’t build or run anything. It’s the token-efficient interaction and inspection layer on top of a simulator you already have running. More complementary than competing.
Trust, Then Verify
This one scratches an itch I have right now. With AI I can produce a lot of UI code fast, but then it takes a long time to verify and validate that all of it actually works.
It’s a Claude Code skill for iOS that helps with exactly that. It does the same token-saving trick at the build step (piping xcodebuild through xcbeautify), but the part I really like is that it checks the SwiftUI accessibility tree first, before falling back to screenshots, which are slower and more expensive. That way the agent can do a first pass at checking its own work before handing it back to you.
I’m usually not a fan of adopting someone else’s skills for Claude or any other tool. But this one looks well put together and worth it, so I’m going to give it a try.
AgentKitten: Provider-Agnostic AI Agents in Swift
People are excited about this one mostly because “omg, it’s an agent framework written in Swift, for us iOS and Mac devs!”. I hate to burst the bubble, but this thing is built strictly for running the agent harness on the client, inside your iOS or Mac app, not on a server.
This feels like a bit of a dejavu that the mobile community had before. We tried to replace real backends with Firebase or Parse. We tried to push our syncing and business logic onto the client with Realm and Atlas Device Sync (and I wrote a whole told-you-so about how that went). That client-only shortcut always feels convenient, right up until it isn’t.
Same thing here. The moment you want to build something genuinely useful with AI in your app, the harness and the heavy logic belong on the backend, not boxed in by the data and compute you have on a phone. On-device models will keep getting better. But even then you’re tied down by the device.
So, cool project, but probably never going to be really useful or scalable.
Cupertino v1.0.0 “First Light”
This one I like a lot, because I’ve been having the exact problem it’s trying to address. The training data for Swift just isn’t as good as it is for the more common languages like typescript and javascript, so the LLMs I use will happily hallucinate Apple APIs that don’t exist.
Cupertino is a local MCP doc server that hands the model the actual Apple docs instead. Ask about Task and you get the real thing, not some made-up Mach kernel function. That would save me from a lot of made-up nonsense, and I’m going to test it on my own projects soon.
Swift
One quick Swift tip this issue, and it’s a good one.
Deprecating your own convenience API
Majid has a nice post on using @available on your own APIs, not just Apple’s. When you write a convenience wrapper to bridge some iOS 26 versus iOS 18 behavior, that wrapper turns into dead code the day you bump your minimum deployment target. The trick is to annotate it with the deprecated and obsoleted parameters of @available, so the compiler points you at every place you used it when that day comes.
I use @available myself but I never reached for its obsoleted parameter before. I really like the idea of having the compiler do that checking for me.
And it pairs nicely with how I work now. Once the compiler hands you the warnings or errors, you can point your AI at them and have it clean everything up deterministically, because it has the exact compiler output to work against.
Let’s keep our codebases clean of deprecated stuff.
Architecture & Design Patterns
Reliable Data Uploading on iOS
This is a good one. Jacob lays out a set of approaches for uploading data reliably and not dropping the ball on it, each one progressively more complex but more reliable than the last.
The last technique is especially dear to me right now, because I’m working on an app that needs to work offline. Once you have to deal with data changes people made while they were offline, the only thing that really works is a more sophisticated upload approach like that one (or even more involved than that).
A Feature Flags System in Swift
Feature flagging matters for any app that has at least some modicum of users and scale, to guard your feature releases, run experiments, ship major changes safely, and so on.
I’ve seen my fair share of feature flag systems over my career, and this one is on the more sophisticated side, more built-out than what we currently have at work. I’ll be reading it more thoroughly, and I’ll probably end up borrowing some of it for my own projects and at work.
From the Archive
This one ties straight back to the AgentKitten point above.
Breaking News: Realm is Deprecated. What now? Also, Told You So!
Back when MongoDB deprecated Atlas Device Sync and the Realm SDKs, I wrote about why leaning on a client-side sync product to stand in for a real backend was always going to end this way. Same thing worries me about on-device AI harnesses today. Worth a (re)read if you’re ever tempted to let a convenient client-side tool own logic that really belongs on your server.
That’s it for this issue. If you’ve got thoughts, comments, or an article or tool I should be looking at, let me know.