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.

Not a metaphorical checklist. A real one — a Confluence doc with 25 steps, every box ticked manually, every tool opened in sequence. GitHub to cut the branch. Tuist to bump the version. Jira to create the release, find every ticket in “ready to deploy” state, tag each one with the release version. App Store Connect to create the new version, write release notes in every supported language, configure the rollout settings, select the build, submit. Slack to ping testers, post in the deploy channel. Then wait for regression sign-off, then back to App Store Connect to push to production. Then merge the release branch, create the sync PR back to develop, update the Confluence doc title from “Deploying” to “Released.”

Best case: 1–2 hours if everything went smoothly and you had no interruptions. Average: 3 hours. Bad day: 5 hours.

And we rotated. Nobody owned releases permanently — that would be too cruel. So every couple of weeks, a different engineer drew the short straw.

This is not a unique problem. Most mobile teams I’ve talked to have some version of it. You’re context-switching between half a dozen tools, the App Store submission process has steps that can’t be skipped, and over time the checklist grows because the app grows and so does the complexity — there’s just more to do.

Engineer time is expensive, we need to save it. This was pure overhead — not a feature, not a bug fix, not a code review. Just ceremony.

What we set out to do

We didn’t set out to reinvent how we deploy mobile apps. The goal was modest: automate the checklist. Get as close to one-click as possible. Get this off our engineers’ plates.

We adopted Runway, a mobile release management platform. It replaces a lot! Runway cuts the release branch, bumps the version and raises the PR, calculates the diff between this release and the last one, auto-tags every Jira ticket with the release version, creates the Jira release page, generates the build, and handles App Store and Play Store submission. The steps that used to require a human navigating six tools in sequence now happen automatically.

The release engineer’s job went from running a 25-step checklist to: kick off the release, verify your tickets work, approve the build, submit. Runway handles the rest.

That alone was worth it.

Sponsored

Join One of the Top Consumer App Teams in San Francisco

Triumph builds two #1 App Store apps: Triumph Arcade, a casual skill gaming platform, and Rips, the best way to discover and buy trading cards. Hundreds of thousands of MAUs, a tiny mobile team of three, and some of the best engineers you'll ever work with. Salary: $200-400k

https://jobs.ashbyhq.com/triumph-arcade/a96e8422-6b1a-4bd9-b5ea-8073e5c26880?utm_source=mobile_engineer

The question we didn’t expect to ask

Once releasing was cheap, we started asking questions we hadn’t asked before.

The obvious one: why are we still releasing every two weeks?

If a release takes a few clicks instead of half a day, there’s no reason to batch changes. You can ship as things are ready. So we did. We moved to on-demand releases — ship when there’s something worth shipping, not on a calendar. Effectively, we got as close to continuous deployment as possible on mobile. Just like a good web or backend team would.

The less obvious question came next: why are we doing 7-day phased rollouts?

Phased rollout is standard practice on iOS — 7 days is the default. You ship to 1% of users, then slowly ramp up over the week, watching your crash rate and reviews as you go. The idea is that if something goes wrong, you pause the rollout before it reaches everyone. You fix it, submit a new version, and start over — back to day one, back to 1%. Then the new version rolls out over another 7 days.

We had been following this without question. It’s a dogma of the iOS community — a sacred cow. Everyone is scared of shipping a bug. OMG what if it crashes for someone! So you roll out slowly, keep your finger on the pause button, and feel safe.

But then we actually looked at our numbers, and they didn’t support the fear.

The phased rollout probably isn’t helping you as much as you think it does

Phased rollout protects you from client-side bugs — code you shipped that breaks something for users. For it to be worth the delay, two things need to be true:

1. You ship crappy code regularly — crashes, broken flows, bugs that make it through to production. If your defect rate is low, there’s nothing much to catch.

2. You have the monitoring tools to get an early warning signal in that first 1%, and the discipline to actually watch them and act. Without that, the rollout is just delay with no feedback loop.

For us, neither was really true.

Our crash rate from client-side changes is low — super low, something like 3.6x less than our web team’s. We’re a careful team, and our architecture — we use RIBs — gives us a structure that’s easy to reason about, easy to code review, and hard to break in ways that don’t surface during development. The QA gate before every release means engineers verify their own tickets before anything ships.

If RIBs is new to you: I’ve written about our full architecture at UpKeep and I’m also the primary iOS maintainer of the repo.

What actually goes wrong for our users mostly comes from the backend — API contract changes, service issues, things the mobile app has no control over and that a phased rollout does nothing to address. If the backend breaks something, it breaks it for 1% of users and 100% of users equally.

On top of that, phased rollout creates a queuing problem. Start a 7-day rollout on Monday. By Wednesday, there’s a fix ready to ship. Now you either wait out the rollout — so your fix doesn’t reach users for days — or you submit a new release and restart the clock from 1% again. Neither option is good.

So we stopped. We switched to releasing directly to 100% of users.

The only thing we can’t control is Apple’s review process, which normally takes less than a day. After that, users get the update immediately.

What actually makes this safe

This isn’t reckless. You have to have your shit together to deploy continuously.

For us, that comes from three things.

Architecture. RIBs gives us a structure that’s easy to develop in and easy to code review. Features are isolated. Changes are contained. The codebase is large, but it’s navigable. This keeps our client-side defect rate low.

If you want to understand why architecture is important, I’ve written about clean architecture and why it matters

Feature flags. Anything risky goes behind a flag. You can merge and deploy the code before the feature is visible to users. If something goes wrong after you flip the flag, you turn it off — no new release needed.

Ownership. Engineers test their own tickets before every release. Regression isn’t a separate team’s job — it’s yours. You know what you built. You verify it works.

This is part of a broader shift I’ve been thinking about — mobile engineers owning far more of the stack than they used to.

These three together mean that by the time a release ships, we’re genuinely confident in it. Not because we’re lucky, but because we built a process that we can trust.

What about when you do ship a bug?

You will eventually. Everyone does.

With on-demand deployment, a hotfix is just the next release. Same pipeline, same process. Fix it, merge it, kick off a release, ship it. Users get the fix quickly — often faster than they would have under a phased rollout cycle where you’d have to wait for the current rollout to complete before starting another.

No special hotfix process. No war room. Just another release.

This isn’t for everyone

Large teams need different tools. At companies like Uber, there’s a weekly release train. Your code either makes it through the CI queue before the cut or waits for next week. That structure exists because there are many engineers, many features, and the coordination overhead alone is significant. A release train makes that manageable.

If you’re at a company with dozens of engineers all committing to the same mobile app, a release train is reasonable. But most mobile teams aren’t that. Most mobile teams are small, working on a focused product, and operating with far more ceremony than needed.

If you ship clean code and your defect rate is low, you probably don’t need bi-weekly releases. You don’t need 7-day rollouts. You’re just slowing yourself down for no good reason — or out of fear.

Where to start

The tools are out there. Runway is what we use and it works well for us. You could also wire something similar yourself with GitHub Actions and the App Store Connect API — the automation isn’t magic, it’s scripting the steps you currently do by hand.

The harder part is the philosophy. Phased rollout feels safe. Frequent releases feel risky. That intuition is backwards if your team has good architecture and a low defect rate.

Start with the checklist. Automate the parts that don’t need a human. Once releasing is cheap, the rest of the questions answer themselves.

I was on the tail end of my paternity leave. I’m lucky enough to work for a company that gives generous time to bond with your baby. It’s been great, but also kind of exhausting. I need sleep, lol.

Now that I’m back, here’s what’s been happening with me — and the world. If you haven’t noticed, there’s been a bit of an AI wave in tech lately. You may have heard of it.

The book

My last posts were about the revised async/await chapter for The iOS Interview Guide 2nd edition:

The Mobile Engineer

[Book Update] Async Chapter Revision Based On Feedback + Chapter Conclusion

Thank you everyone who responded to my call for feedback on the async chapter of The iOS Interview Guide 2nd edition…

Read more

3 months ago · 4 likes · Alex Bush

The Mobile Engineer

[Book Update] Async Chapter is Done! Looking for Feedback.

I’m finally done with the Async chapter of The iOS Interview Guide! It took a while, been busy with work, took a detour, but now I’m back to working on the second edition reinvigorated…

Read more

4 months ago · 4 likes · 12 comments · Alex Bush

I incorporated a round of reader feedback and added four new sections covering legacy API bridging, actor reentrancy, debounced search, and a multi-paradigm network request comparison. Thank you to everyone who submitted feedback.

During the break I also made solid progress on the UIKit chapter — it’s essentially done, I just need to polish it up and post a feedback call the same way I did for the async chapter. That’s next on my list.

The book is still very much in progress. There’s a lot left to write, but I’m moving forward.

AI experiments on the side

Turns out paternity leave is great for late-night rabbit holes when the baby finally sleeps.

I spent a lot of that time playing with AI-augmented coding. Vibe coding, web development experiments, building out personal projects. The models have gotten dramatically better. The agentic stuff especially — it caught up fast. I have some stuff to share — thoughts, opinions, and current best practices. Will be posting about it, stay tuned.

I also went down a rabbit hole trying to run everything locally. I got OpenClaw running in a Docker container on an external drive — so it wouldn’t wreck my main machine — and connected it to locally running models via Ollama. It didn’t go well. Turns out an M1 MacBook Pro with 64GB of memory is not enough to do anything meaningful with local models. The models are just too big. Oh well. I did learn a lot about Docker, so there’s that.

What I came back to at work

This is where it gets interesting, and where I have a lot more to say in a dedicated article.

Short version: we went all in on AI-first development — not just engineering, but the whole organization. Every team got subscriptions to things like Claude and Cursor with very generous token budgets. I came back and dove right into this “token-galore” as I call it, and I really don’t want to go back to how I worked before.

My scope also changed. I’m now doing product work alongside engineering — customer research, data analysis, synthesizing feedback from users. Stuff I always wanted to do but never had the bandwidth for. AI makes it feasible. The scope of what a software engineer can actually build, own, and influence has gotten so much wider now than ever before. I already shared some of my thoughts on mobile devs being fullstack.

The Mobile Engineer

Mobile Engineers - You’re All Full Stack Now

Back in the day I started my dev career by making MVP apps for entrepreneurs and startups in Silicon Valley. They were mobile apps, Android and iOS. I started with Android but as I would build the apps for my clients they would keep asking to make the same thing on iOS. So, I picked up a few books on iOS dev and built them the iOS apps they wanted…

Read more

5 months ago · 16 likes · 3 comments · Alex Bush

This is similar. I want to have a proper write-up on this.

What’s coming

I have a backlog. Here’s what I want to get to — tell me what you want to read first.

KMP deep dive, part 2 — and then part 3 about RIBs

I already published an intro to KMP and how we use it to share business logic across iOS and Android. I want to go deeper — a part 2 on the implementation details of the KMP side, and then a part 3 on how the iOS architecture fits together with RIBs. The full picture, end to end.

Mobile Continues Deployment on Demand

Mobile teams have always been stuck behind App Store review cycles and phased rollouts. We decided to close that gap with web deployment as much as possible. Automated everything, adopted Runway, and now ship to 100% of users with basically a click. We’ve been working this way for several quarters new and it surprisignly works! I want to write it up in detail.

Mobile engineers owning the full stack

I’ve argued before that mobile engineers make great full-stack engineers. Now we’re living it. Our team owns everything end-to-end — from the app screen and mobile business logic to the API contract and the backend implementation with the database queries, the whole thing. AI makes this actually feasible. I want to expand on this with real examples.

RIBs + Swift concurrency

As a maintainer of Uber’s iOS RIBs repo, I’ve been slowly modernizing it for Swift concurrency. I have a working approach — main actor isolation, full backwards compatibility, and a clear path for Swift 6 — and I want to document it properly for anyone running RIBs in production.

What do you want to read first?

Reply to this email, leave a comment, or vote in the poll below. I read everything.

And if none of this sounds interesting to you — tell me that too. I can take it :)

Happy coding!

I’ve added several major sections based on your input:

• Continuations for bridging legacy APIs - How to wrap old completion handler code into async/await using withCheckedContinuation. This was a big omission since basically every real codebase needs to bridge between old and new async patterns.

• Actor reentrancy solutions - Added the pattern for fixing reentrancy bugs. Shows how concurrent callers can await the same task instead of creating race conditions.

• Debounced search with Task cancellation - Practical example of search bar implementation showing how to store task handles, cancel them on new input, and use Task.sleep for debouncing. Includes both async/await and RxSwift versions since that’s what you’ll actually encounter in production code.

• Network request comparison across all paradigms - This was the biggest addition. Same user profile fetch implemented four ways: completion handlers, async/await, Combine, and RxSwift. All using a unified APIClient with proper Swift 6 concurrency compliance. Interviewers love asking this type of question because it shows you understand the trade-offs between approaches, not just the latest Apple marketing.

And here’s how the chapter concludes - my take on async work in iOS:

Async work on iOS has evolved from manual threads to GCD to reactive frameworks to Swift Concurrency. Each approach solved real problems for its time.

Here’s what the industry expects: Swift Concurrency is the default for new code. If you’re interviewing or joining teams building new features, expect async/await, actors, and structured concurrency everywhere. You need to know it cold. That said, production codebases have years of existing code - you’ll maintain GCD dispatches, RxSwift chains, Combine publishers. Real work means bridging all these paradigms.

Here’s my actual opinion though: Rx (whether RxSwift, RxJS, or RxJava) is a superior model for asynchronous code. It handles simple cases just as well as async/await, but gives you real power for complex reactive flows. More importantly, learning Rx once translates across every platform and language - your RxSwift knowledge works in RxJS, RxJava, RxKotlin. That portability matters.

Apple’s attempt to eliminate concurrency bugs through Swift Concurrency sounds great on paper, but the infuriatingly strict compiler constraints often do more harm than good. That’s not elegant - that’s fighting the compiler to do reasonable things.

If you have solid architecture, most concurrency problems disappear. When your application state, domain models, and UI layer are clearly separated, when you avoid global state and singletons, race conditions become rare. The bugs Swift Concurrency tries to prevent at compile time just don’t happen in well-architected apps.

So my message to mobile engineers: don’t obsess over using the most recent stuff just because Apple said so. Focus on getting your architecture right. Avoid singletons and global state. Once you have clean separation of concerns, the async code becomes easy regardless of which tool you pick.

Know Swift Concurrency because you’ll be asked about it in interviews. Understand GCD and reactive patterns for maintenance work. But don’t treat any of these as religion - they’re tools. Pick what fits your problem and your architecture.

The comparison patterns in the chapter - especially the network request implementations across all four paradigms - show how the same problem gets solved differently. Use them as templates when evaluating which approach fits your specific situation.

This chapter is the new addition to the book, not a refactoring of an existing chapter. That’s also partially why it took me a while to finish it. It covers all things async: Threads, Swift Concurrency, MainActor, Actors, AsyncStream, GCD, NSOperation, RxSwift, Combine, etc.

The goal is to give the reader a broad overview of options to execute asynchronous work on iOS so that they know what to pick best for the job and problem at hand.

Any type of feedback is welcome, from tiny typos to critique of the whole chapter structure.

Let me know if you want to get the draft by emailing me, commenting, or DMing on Substack.

I hit a wall pretty quickly. The apps I built could only do so much without a backend. My clients kept asking for more features that required a backend for my mobile apps, so I picked up the books again, this time on Ruby on Rails, and started to build backends and APIs for my mobile apps. On occasion I’d even have to build a dashboard or two in javascript (and dart) or a landing page for those projects so I’d even dabble in frontend a little bit (just enough to know I hate it).

Eventually, I specialized in iOS because building all of those things and being the jack of all trades spread me too thin and burned me out. I liked iOS development the most. This, in a nutshell, is the story of how I became an iOS specialist. But it is also a story of how I became a versatile generalist who doesn’t care what platform or language to work with (unless it’s javascript, ick) and builds things full-stack or with a full-stack mindset.

Years went by and two things that I observed struck me:

First, it seems like almost no one in the mobile community builds full-stack and/or touches or even understands backend development. Second, as far as I can tell, the mobile devs, on average, are better devs because they pay more attention to details and grow up within a constrained environment.

Let me expand on both of these points.

Mobile Devs Are Rarely Fullstack

It is common in the JS/TS world to be fullstack. You build the backend, you build the frontend for it. Often, if it’s JS/TS, even the same language is used in both. It is pretty normal and sometimes expected for devs to build entire features top to bottom maybe with an exception of design.

Now, you could argue that it is a good thing or bad thing whichever way and you probably would be right. Devs not specializing and having enough knowledge about each side is a bad thing. But at the same time, the same devs holistically solving a problem for the user and not making disjointed implementations by pointing fingers to the other side is a good thing as well.

But somehow mobile devs have avoided this over the years. They just sit in their own silo and make not just the mobile side without the backend, but get this, ONLY one platform at a time!? 😱

It’s probably, mostly or partially, due to the fact that the language, like in JS/TS case, is not shared between mobile and backend. But that said, I’ve seen plenty of Rails devs who are also perfectly comfortable making JS frontend stuff all in one go. I suspect that the difference is that mobile development has enough complexity for one engineer to dive deeply for their entire career. But, nowadays, the same thing can be said about both frontend and backend development I suppose.

And I think the lack of good and “fun” backend frameworks like Ruby on Rails written in Objective-C/Swift or Java/Kotlin is not helping either. Although, these days Kotlin,Ktor and Spring Boot are helping in that department.

Mobile Devs Are Best Suited To Be Fullstack

I would argue that mobile devs are the best suited to be fullstack engineers. Consistently I find that mobile devs have a higher attention to detail, polish, architecture, and design patterns than their frontend and backend counterparts. In general, they care more and want to do more.

I suspect that this is due to the constrained environment that we “grew up in.” Mobile development is a very challenging and constraining environment to be coding in. Yes, it’s not some low level middleware device optimization code, but since day one mobile devs have to think about memory constraints, network bandwidth, CPU utilization, battery, etc., where their frontend web JS dev counterparts are completely clueless about these things.

Heck, the intermittent internet connection alone forces mobile devs to pay attention and always ask—“what is the loading state for this feature?” and “what is the error/empty state if the internet connection is down for this feature?” and so on. These are the things that frontend devs, and a lot of backend devs, usually don’t have to worry about much (even though they should!).

Another big constraint that mobile devs have to work with is the screen real estate itself. It is much more forgiving to be working in a desktop-sized environment where there is a lot of room for design and feature arrangement and where you, perhaps, could display “all the things” at the same time in one single screen. Then you don’t have to worry about navigation and routing and relationship between your screens as much.

On mobile you simply can’t fit all that stuff on your screen at the same time so you have to be careful about how you arrange screens, how you navigate, how you present data, etc. Yea, yea, I know, you could say—“Alex, this is the designers’ problem” but in reality it’s the devs who need to take care of it and the ones who need to implement it dealing with the underlying code complexity. Non-mobile devs simply lack the appreciation (and skill/knowledge) for it.

I think all of these make mobile devs perfectly suited to not only “sweat the details” on mobile but also give the same care and attention to the backend (or maybe even frontend) implementations. Mobile devs are missing out and holding themselves back by not venturing outside of their mobile world into a wider fullstack development lane.

I believe (and have observed first hand) that mobile devs can shine building features end-to-end, starting with the mobile client side and then crafting the perfect backend API and implementation for them on the backend side. They would be keenly attuned to the challenges and demands of mobile such as backend API versioning that often (ahem, always) gets overlooked by the backend and frontend engineers (where the former don’t want to deal with the complexity and the latter don’t even understand the issue).

AI Can Help You Expand Your Scope

So, why am I bringing it up now?

AI gives us mobile devs a golden opportunity to move up and down the stack with ease. AI augmented development has been nothing short of magic for me lately. It’s enabled me to move between codebases, mobile, backend, frontend, whatever with even more ease now and utilize LLMs as a helper, aide, automation, and a crutch (haha) to fill in the gaps of my specialized knowledge, in addition to helping aid my overall high-level system understanding of the problem I’m trying to solve and of the code I’m working in.

Are you building a new mobile screen/feature? Great, you got the iOS or Android implementation done, now use the AI to help you craft specific, bespoke, highly optimized, VERSIONED, API endpoint/s for this feature. Hand it off to your backend counterparts and demand they build it this way, the right way, so that your mobile app works the best it can.

Better yet, just pull out Cursor (or your other favorite IDE/LLM) and start building out a PR with the implementation of that endpoint you want. Don’t know certain intricacies of backend development? Trust me, it is not as hard as some of the hardest stuff you had to deal with on mobile. Have LLMs help you. Open up a PR and ask your backend folks to review it, see what they say.

Or build the whole thing yourself end-to-end and integrate it all in one go. You know the constraints of mobile, you know what the API should look like, you know how to consume it, you know what needs to be done. Go for it!

Conclusion

AI opens up a golden opportunity for every mobile engineer to be “unshackled” and build things full stack.

Go for it, see how far you can get!

I firmly believe that you’ll be able to pick up all the intricacies of backend and frontend development much faster than the frontend and backend engineers can figure out how to build mobile apps properly!

One of them is how deinit behaves with the new strict Swift Concurrency.

Apparently, if you have a @MainActor annotated type, its deinit will be assumed to execute in a nonisolated context even though the type is @MainActor. Supposedly, this is because the object can get deallocated (its last retain count reference released) on any thread, not only the one it’s isolated for (the main in this case).

This becomes an issue if you have any type of cleanup logic in your deinit where you need to free up the resources your object is holding on to or to call any cleanup logic such as closing streams, open connections, subscriptions, etc. The compiler now will yell at you and tell you that you can’t be calling methods on self in deinit. Even if you wrap self in a weak self and run the methods via a Task { @MainActor in } wrapper, it still would not work because by the time it hops to the threads main thread, your weak self reference is going to be nil.

Now, to me this was a huge surprise and a big pain for two reasons:

1. In my application codebases, I never ever ever used deinit as a logical cleanup. It just doesn’t make sense and is very error-prone to let the Swift language/framework control the flow of application logic. An explicit cleanup at the appropriate time/lifecycle is always much better.

2. Now I am forced to deal with this issue because I need to modernize the RIBs codebase and make it compatible with the new strict Swift concurrency.

The way deinits are used under the hood of RIBs is for data cleanup and lifecycle propagation (such as letting all the children RIBs know that the parent is detached/deallocated so that they do their own cleanup) and for internal RIBs reference counting to keep track of memory leaks.

I’m exploring different solutions. I can’t use isolated deinit because I need to support older iOS/Swift versions, but most likely I’ll end up refactoring away from deinit entirely and have explicit cleanup methods when RIBs are detached. That way I can keep the same isolation context and have no restrictions on method access and be guaranteed that my object is still in memory.

Conclusion

The more I dig into Swift Concurrency and the new strict rules, the more I get annoyed with it. I understand the desire and the good intentions behind it—let’s help developers with concurrency thread hopping so that they don’t call things on the wrong thread (such as UI updates on a non-main thread) and don’t have as many race conditions and other subtle concurrency problems.

But the approach Apple took with Swift seems to me too rigid and prescriptive. Better education of the Swift community on better design patterns and architectures that avoid these threading issues would’ve sufficed. Now, instead, we all are struggling with compiler issues caused by strict concurrency rules because we want to help a few devs to write better code.

What’s interesting is that, quite often, not only the backend engineers designing the APIs do not fully understand the constraints and best practices for mobile, but even mobile engineers themselves don’t know what a good backend API for mobile should look like.

In this article, I’ll outline my high-level approach and what I care about when designing backend APIs for mobile apps.

The Problem. Typical Approach. Abdication of Responsibility.

When I ask mobile developers what makes a good API, they typically give me vague answers like, “It should be JSON, it should be RESTful, and it should be optimized for mobile and scale well.” Sometimes I even hear “it all should be GraphQL!”

At the end of the day the tendency of mobile engineers is to just blindly accept the API that they are given or rely on the backend engineers to create something decent that would be convenient and effective for the mobile app to consume.

Mobile engineers should either advocate for and educate backend developers about effective mobile-first API design, or ideally, take the lead by designing the API contract themselves for the backend team to implement.

Mobile App Constraints

Mobile apps run on mobile devices (duh!). Despite advancements in chip design and battery life they are still much more limited than an application on the desktop that has persistent internet and power connection.

1. Connectivity: Networks are spotty, slow, and often intermittent (e.g., commuting in a subway).

2. Battery: Every network request and CPU cycle drains the battery.

3. Memory: Limited RAM (I mean relatively speaking nowadays) means working large data sets is still a challenge on mobile

4. System Optimization: because of all of these challenges there are system optimizations in place where the work/compute of your app can be paused and resumed or limited by the OS itself.

5. API Versioning is important: mobile apps do not update on users devices in a blink of an eye/page refresh like the web apps do so maintaining several versions behind of your API is prudent to keep older versions of the app still working.

Because of all of these constraints it usually leads to issues and degraded user experience if you reuse the same backend APIs that power, let’s say, your web/desktop application, and use them in your mobile application.

Typically reusing the API like this leads to mobile apps stitching several API requests of poorly optimized bloated JSON together to give something meaningful to the user like a complete feature or full screen of data for a given user experience.

Pragmatic JSON API Design for Mobile

There are several different approaches, architectures, design patterns, and conventions out there on how to organize and assemble your backend APIs. Here are some of the most common ones you would encounter:

REST vs GraphQL vs RPC

The debate around API design often revolves around what architectural style to pick for the API. Is it GraphQL that’s the best? Or REST? Or RPC? Or something else?

At the end of the day they have their own pros and cons. I am not going to dive deep into them here but here’s my brief take.

GraphQL. the best for public APIs. poor choice for internal API.

GraphQL - sounds good in theory but in practice a poor choice for API design for an internal API for your own mobile app consumption. The abundance of choice and permutations and configurability of the “queries” from the client side put the burden of API design on the client rather than where it belongs on the backend. This leaves backend with highly unpredictable and hard to optimize mess of requests/queries that is difficult to support and scale.

GraphQL is better reserved for situations where you don’t know the use case for your API upfront - aka for publicly facing APIs, because you don’t know how your users will be actually getting and sending the data to your backend and what is actually important to them, so yuo optimize for abundance of choice rather than on specific pre-determined/prescribed set of actions/choices/user flows.

RPC. problem domain specific but not standardized.

RPC is where the API organized around “remote procedure calls” (hence the name) and the idea behind it is that you make a call on the client side like it was “yet another method call for yet another procedure of your app” but under the hood, instead of executing it locally, it calls a “remote server” to do the compute and then it returns the result asynchronously. It’s a convoluted way of describing an API where it doesn’t have strict standardization and rules and has a much more free form arrangement/implementation where the endpoints you call mimic potential method calls if you were to call them locally rather than on the backend server.

The upside of this design pattern for API is that you could be very specific with the domain problem you’re solving and the API you’re serving for mobile but the downside is that there is no standard and it could lead to a bit of a chaos with widely different implementations even on the same backend API server. REST has a much better story on standardizing how the API endpoints look and behave.

REST. the golden standard. Solid overall choice.

REST is a fantastic standard and API design/architecture that nowadays is a golden standard and the golden foundational best practice for designing your own APIs. It encompases everything from the low level stuff like using HTTP status codes and verbs properly and extensively all the way to the high level prescription of organizing your endpoints around resources/entities in your system.

REST is probably the best choice if you don’t know what you’re optimizing for yet and just need to get started. It will carry you forward far, sometimes very far, but the downside is that you can’t always model everything around resources, especially when it comes to rich user experiences on mobile where one single screen might do a lot of stuff for the user. You will find yourself stitching multiple REST endpoint requests to multiple resources/endponits quite fast as you try to fulfill the data requirements for your mobile application screens.

Bespoke Backend APIs for Mobile User Experience (a little bit of RPC, a little bit of REST)

So what does “API optimized for mobile” even mean? Afterall we have all these choices (and more that I haven’t covered) to design our backend APIs consumed by mobile apps. Which one to go for?

At the end of the day I came to a conclusion that there is no one best option to go with and instead a highly optimized backend API for mobile should contain in itself the best parts of every approach.

Basically it boils down to - the API mobile app consumes needs to be bespoke and highly optimized for the user experience this API supports.

RPC style user experience endpoints

In practice this means that instead of RESTful collection of resources API style where the mobile app needs to make multiple requests and stitch data together on the client side to serve a screen or a feature you instead would create an RPC style API where each endpoint returns full set of data needed for a given screen or feature to work.

Highly optimized mobile endpoints like that would receive and return only the data needed for the mobile app to function, no more no less. They would not have any extra fields, properties, data, etc. “just in case” or because the endpoint is shared with other clients such a desktop web app. It wastes resource if you do it this way.

There would be no generic /users/235 or /posts/123 and /posts/123/comments endpoints. Instead you get one RPC style endpoint such as /postDetails/123 that returns combined, and only necessary, fields from all 3 of those endpoints to serve a post details screen in a mobile app that displays some post info + the comments + some of the author user info.

HTTP status codes and verbs

Highly optimized mobile endpoints, unlike simple RPC ones, utilize HTTP status codes and HTTP verbs heavily, just like REST endpoints do. The reason is because the convention is highly understood and predictable and conveys a lot of information about the request or response in a very short and concise manner. This makes the API instantly recognizable and predictable in its behavior. You can even get a lot of code generation/automation with popular networking libraries out there “for free” out of the box if you stick with these conventions.

API Versioning

Highly optimized mobile endpoints are heavily versioned. As mentioned above, mobile apps do not update all at once and there are always laggard users who update their applications late or refuse to do so. Highly optimized mobile endpoints need to be versioned to support those older versions of the app that are still in users hands despite the new hot latest app update that you pushed to the app store.

There are different ways and approaches to versioning backend APIs and it could be an entire article on its own to explore all of them. I’ll just leave it here by sharing what worked for me - version endpoint by endpoint and version frequently. Rely on passing IDs/UDIDs of your entities as much as possible instead of full object shapes, it helps with backwards compatibility of your domain models.

Conclusion

Even though we, as mobile engineers, might not care as much about backend API design, it is actually very important for us to be not only aware but advocate for more highly optimized mobile API endpoints to make our apps better, our user’s experience better, and our coding lives easier.

Go talk to your backend engineers about this. It’s 2025, there is no excuse to keep accepting the backend API you’re given stitching together 10 different endpoint responses on the client side to simply display a screen in your mobile application.

In my development career, I jumped around different languages and platforms. Everything from Objective-C on iOS (and later Swift), to Java on Android (and later Kotlin), to Ruby on Rails and lately Typescript/Node, and a bunch of things in between (Dart before Flutter days), and more.

I saw different pros and cons and strengths and weaknesses that each language, framework, pattern, or community exhibits. At the end of the day, I wasn’t able to find a community, pattern, convention, framework, or language that fully satisfies me and my sense of what is good code or bad.

What I ended up doing is picking “the good parts”—different bits and pieces, conventions, approaches, etc.—from each one of those different languages, frameworks, and communities and mixing them together in whatever language or platform I happen to use and write code for at the time. It actually turned out pretty well and at the end of the day is grounded in SOLID principles and Clean Code/Clean Architecture which are all language, framework, and community agnostic.

So given all that, it might not be surprising that I find some (if not a lot lol) parts of Swift and Swift community conventions odd or pointless or wrong. For example, the other day, I was reviewing some code in an iOS project that had to deal with connecting to a voice audio recording library. It was already implemented in our codebase and I had to take a look at its API to understand how to use it and at the current usage of it across the codebase.

My assumption was—well, there is probably some wrapper object around the library’s class/object that abstracts out starting, pausing, and stopping the recording. And I assumed there would be some sort of a delegation (via protocol, or callback closures, or a stream of data) happening upon recording start to “stream” the recorded data/voice/text as it happens. And sure enough it was; both of those assumptions were correct but the data streaming/delegate/callback part gave me a pause.

Here’s how the API looked like:

enum RecorderState {
    case idle
    case recording
    case stopped(finalText: String)
    case failed(error: Error)
    case receivedText(chunk: String)
}

protocol AudioRecorderDelegate: AnyObject {
    func audioRecorder(didChangeStateTo state: RecorderState)
}

protocol AudioRecorderProtocol {
    var delegate: AudioRecorderDelegate? { get set }
    var currentState: RecorderState { get }
    func start()
    func stop()
}

final class AudioRecorder: AudioRecorderProtocol {
    weak var delegate: AudioRecorderDelegate?
    
    private(set) var currentState: RecorderState = .idle
    
    func start() {
        self.currentState = .recording
        delegate?.audioRecorder(didChangeStateTo: currentState)
    }
    
    func stop() {
        let finalText = “Final transcribed text here”
        self.currentState = .stopped(finalText: finalText)
        delegate?.audioRecorder(didChangeStateTo: currentState)
    }
    
    // ... more business logic to update currentState and notify delegate about recording process
}

Everything is pretty straightforward, and the usage of it looks like this:

final class ViewModel: AudioRecorderDelegate {
    
    private var audioRecorder: AudioRecorderProtocol
    
    var onStateChanged: ((RecorderState) -> Void)?
    
    init(audioRecorder: AudioRecorderProtocol = AudioRecorder()) {
        self.audioRecorder = audioRecorder
        self.audioRecorder.delegate = self
    }
    
    func startRecording() {
        audioRecorder.start()
    }
    
    func stopRecording() {
        audioRecorder.stop()
    }
    
    func audioRecorder(didChangeStateTo state: RecorderState) {
        switch state {
        case .idle:
            // do stuff
            break
            
        case .recording:
            // do stuff
            break
            
        case .stopped(let finalText):
            // do stuff
            break
            
        case .failed(let error):
            // do stuff
            break
            
        case .receivedText(let chunk):
            // do stuff
            break
        }
    }
}

At first glance any Swift developer would say - “Alex, I see nothing wrong about this. There is an enum with all the states, this is very Swifty!” And yes, this seems to be the pattern that the Swift community fancies - to pass all the possible states/scenarios like this via a callback in one property and to declare an enum that lists all the possible cases. I acknowledge that there are good parts to this - for example, you get the compiler time safety when you add new states/cases to this enum. The compiler will warn you and make you explicitly handle all of them.

For any Swift developer this would be just it - the dogma says that this is good and this is how it should be.

But the problem is this approach makes your API less explicit and breeds the switch/case ifelsing across your codebase. The more new enums you add the more cases in the switch you’d need to have, especially if you pass that enum value around in different parts of your code.

And on top of it, the worst issue is that this makes your API readability much worse - it is very hard to say at a glance what it does, what kinds of callbacks would you receive if you are the delegate of this audio recorder. All you get is just this one method declaration: func audioRecorder(didChangeStateTo state: RecorderState) in AudioRecorderDelegate. You have to now hunt down for the enum RecorderState declaration (hopefully it’s in the same file, but likely it won’t be, because reasons lol) to actually understand what the API is. And imagine if you had several callback methods like this in AudioRecorderDelegate and each one of them had their own set of enums with their own 3-5 cases - you multiplied the problem of this “treasure hunt for the API declaration” tenfold!

Bottom line, even though the Swift community loves it, this approach breaks SOLID principles and makes your API implicit, indirect, and scattered.

A better approach is to stick to a more generic, tried and true, OOP/SOLID principles approach of sending messages and explicitly declaring your API as a set of dead simple callback methods:

protocol AudioRecorderDelegateV2: AnyObject {
    func audioRecorderDidBecomeIdle()
    func audioRecorderDidStartRecording()
    func audioRecorderDidStop(with finalText: String)
    func audioRecorderDidFail(with error: Error)
    func audioRecorderDidReceiveText(chunk: String)
}

protocol AudioRecorderV2Protocol {
    var delegate: AudioRecorderDelegateV2? { get set }
    func start()
    func stop()
}

final class AudioRecorderV2: AudioRecorderV2Protocol {
    weak var delegate: AudioRecorderDelegateV2?
    
    func start() {
        delegate?.audioRecorderDidStartRecording()
    }
    
    func stop() {
        let finalText = “Final transcribed text here”
        delegate?.audioRecorderDidStop(with: finalText)
    }
    
    // ... more business logic to notify delegate about recording process
}

And the consumption now looks like this:

final class ViewModelV2: AudioRecorderDelegateV2 {
    
    private var audioRecorder: AudioRecorderV2Protocol
    
    var onIdle: (() -> Void)?
    var onRecordingStarted: (() -> Void)?
    var onRecordingStopped: ((String) -> Void)?
    var onRecordingFailed: ((Error) -> Void)?
    var onTextReceived: ((String) -> Void)?
    
    init(audioRecorder: AudioRecorderV2Protocol = AudioRecorderV2()) {
        self.audioRecorder = audioRecorder
        self.audioRecorder.delegate = self
    }
    
    func startRecording() {
        audioRecorder.start()
    }
    
    func stopRecording() {
        audioRecorder.stop()
    }
    
    func audioRecorderDidBecomeIdle() {
        // do stuff
        onIdle?()
    }
    
    func audioRecorderDidStartRecording() {
        // do stuff
        onRecordingStarted?()
    }
    
    func audioRecorderDidStop(with finalText: String) {
        // do stuff
        onRecordingStopped?(finalText)
    }
    
    func audioRecorderDidFail(with error: Error) {
        // do stuff
        onRecordingFailed?(error)
    }
    
    func audioRecorderDidReceiveText(chunk: String) {
        // do stuff
        onTextReceived?(chunk)
    }
}

The AudioRecorderDelegateV2 declaration is very straightforward and tells you everything it does at the first glance:

protocol AudioRecorderDelegateV2: AnyObject {
    func audioRecorderDidBecomeIdle()
    func audioRecorderDidStartRecording()
    func audioRecorderDidStop(with finalText: String)
    func audioRecorderDidFail(with error: Error)
    func audioRecorderDidReceiveText(chunk: String)
}

There is no ambiguity, there is no hunting for other declarations, it’s just all there, explicit as simple messages to be sent from one object to another.

There is also still the same benefit of compiler time safety - if you add another method to the delegate declaration about a new event happening, everyone who adopts that protocol will get a compiler time warning and will have to implement it, just like with the enum case.

This instantly reduces the amount of ifelsing/switch-casing across your codebase and makes skimming and understanding your API dead simple. And, I’d argue, especially so when using LLMs nowadays. On top of it, it reduces the temptation to breed state and pass along the enum for other parts of the code to figure out what to do with each switch/case.

Conclusion

At the end of the day, the difference between the two approaches boils down to Enum State Machine approach vs Event Emitter approach.

The “Swifty Enum State” approach is a great tool for modeling objects whose internal state needs to be guaranteed (e.g., a Result type, or a single state machine within a component).

However, when designing an API that is purely meant to act as an Event Emitter—sending asynchronous messages about changes—the traditional, multi-callback approach remains the superior choice for maintainability, simplicity, and adherence to the Interface Segregation Principle. It is cleaner, more readable, and respects the fact that your consuming ViewModel is the true gatekeeper of your application’s state.

We should embrace the flexibility of well-designed interfaces, rather than defaulting to monolithic enum structures just because the Swift language makes switch statements easy.

Jacob’s done a great job fairly covering both KMP and Swift for Android implementations and showcasing their respective pros and cons! If you haven’t read his article go ahead and read it here. While you’re at it don’t forget to subscribe to Jacob’s substack!!!

Jacob’s Tech Tavern

Swift for Android vs. Kotlin Multiplatform

If you’ve been living under a rock for a year, I have shocking news about the election*, and great news about the future of Swift portability…

Read more

7 months ago · 12 likes · Jacob Bartlett

I thought I’d share my comments with the readers of The Mobile Engineer as well.

I mainly can comment on the Kotlin Multiplatform (KMP) side of things, as this is what we use at UpKeep and what I use in my personal projects. I’m still working on Part 2 and 3 of the architectural overview article that I published previously: Mobile Architecture at UpKeep, Part 1. They will cover more in depth the usage of KMP that we have in our iOS and Android apps.

On Platform-Specific Code and Decoupling

Jacob highlighted KMP’s expect/actual mechanism for injecting platform-specific code.

Kotlin Multiplatform has a very neat way of neatly injecting platform-specific code. First, you declare a provider file with an expect fun.

Now the actual fun begins. For each platform you’re implementing on, you set up the expect fun’s implementation: “actual fun”. Here, we can inject Ktor’s built-in HTTP client for Darwin platforms.

While neat, I lean toward a more decoupled approach using Dependency Injection (DI).

Instead of expect/actual, which keeps the platform-specific code declaration in the common module, we favor having the common KMP module depend on a simple interface. The platform-specific code (in the Android or iOS codebase) then implements that interface, and we inject that concrete object into the KMP class.

This approach offers a few key benefits:

1. Decoupling: It keeps the shared KMP code pure and agnostic, free from any platform-specific boilerplate required by expect/actual.

2. Clean Architecture: It adheres more closely to standard DI patterns, avoiding what some might view as “hacks or crutches” when platform capabilities are involved.

Modularization: The Single Umbrella Framework

Jacob pointed out a major pain point for KMP users: having to expose the shared logic as a single umbrella framework to the platform apps (well, iOS in particular).

Idiomatically, the KMP shared library is called “Common”. Or, sometimes, “Shared”. You can modularise the library as much as you like, but you will need to expose this to the platform apps as a single umbrella framework. This is pretty annoying for namespacing, but you stop noticing it pretty fast*.
https://blog.jacobstechtavern.com/i/177580473/calling-kotlin-from-ios

This is absolutely true, and it creates annoying namespacing challenges that you eventually just have to live with.

At UpKeep, we ran into this exact issue when setting up our KMP integration. The reason for this single module constraint usually boils down to how fundamental types (like String, Int, Array or the fundamental custom types you share) are handled. If you export multiple modules that all depend on these foundational types, the platform (specifically Swift/Obj-C) can see them as incompatible, distinct types across the different modules.

However, there is good news: the KMP team is working on solving this. There is a beta version of direct Swift export for KMP that appears to resolve this issue, which should allow us to export multiple, separate modules to Swift soon.

The SKIE Debate and Interoperability

The article mentioned SKIE (Swift Kotlin Interface Enhancer) as a way to smooth out rough edges around things like suspend functions and sealed classes, making them more idiomatic Swift.

When you’re running a long-term KMP project, you might want to use SKIE (Swift Kotlin Interface Enhancer). There’s a few rough edges around things like suspend functions, interfaces, and sealed classes which the library sands down into idiomatic Swift signatures.

We went back and forth on adopting SKIE, but ultimately, we decided against it. Instead of relying on an external tool to bridge the gap, we manage the interoperability ourselves. On the iOS side, we use simple wrapper classes around the KMP interfaces to convert them into familiar platform types like RxSwift Observables/Singles. This gives us more explicit control over the final developer experience.

Headless Logic and Testing

I loved Jacob’s idea of creating a little CLI app target to interact with and test the multi-platform module outside of the UI. This is a neat way to handle testing and interaction!

https://blog.jacobstechtavern.com/i/177580473/working-with-headless-libraries

I’ve long been an advocate for headless business logic (logic that runs without any UI dependency), even before the multiplatform movement. Now, it makes even more sense. Personally, I achieve similar benefits by running real staging API calls directly from my unit and integration tests instead of relying on a separate CLI.

Architectural Boundaries: ViewModels

A great question Jacob posed was: “Where do the view models go?”

This is the single most controversial point of debate when implementing a multiplatform solution. Where do we put the view models? “Shared business logic” unambiguously includes networking, caching, analytics, models, processing, queues, config, and most of your services. But view models (and, depending on your architecture, perhaps interactors, presenters, and navigators) could go either way. This is a double-edged sword.

https://blog.jacobstechtavern.com/i/177580473/where-do-the-view-models-go

In my view, View Models (VMs) are a platform-specific concept. If they are simply plain old objects used purely for managing UI state and exposing data from the shared layer (without containing business logic), they belong in the platform codebase (Android/iOS).

For sharing higher-level architecture components, like Interactors or Presenters, the debate continues. We don’t share these at UpKeep yet, but I’m actively considering porting some or all of a framework like RIBs to KMP for that exact reason. I hope to write an article about that process someday!

The Mental Overhead of IDE Context Switching

Haha, Jacob nailed naming the IDE context switching overhead with the title The big IDE fuckfest lol

I doubt “the big IDE crapfest” would sufficiently convey the overwhelming mental overhead that comes with bouncing between 2 instances of Android Studio (or IntelliJ) and 2 instances of Xcode, for 2 different implementations of the same project.

I understand that this is a huge pain for some developers but IMO - I don’t mind because I actually bounce between three IDEs on my mobile projects: Xcode (for iOS), Android Studio (for Android), and IntelliJ IDEA (for KMP/Kotlin code)! (oh and + Cursor these days for LLM code generation). While the overhead is real, the value gained from sharing the core logic often outweighs the annoyance. Plus, I personally appreciate the mental split - ok, I’m in Xcode, now I’m working on the iOS side, next I’m in IntelliJ IDEA, now I’m working on the shared business logic with no UI overhead, etc.

Team Structure: Core vs. Full-Stack

Finally, Jacob noted that some KMP shops use “core engineers” (business logic) vs. “design engineers” (UI) model, which requires careful API contract coordination.

At UpKeep, we’ve taken a different approach. We are a smaller team—three iOS and three Android engineers, six total—and we intentionally encourage a “full-stack” approach. We make iOS developers learn KMP/Kotlin and Android developers become familiar with Swift and iOS compilation issues. This ensures that every developer has a stake in the shared logic and can troubleshoot issues across all parts of the mobile stack.

Conclusion

Jacob did a great job covering and comparing Swift for Android and KMP. Currently, Swift for Android is clearly not ready for primetime, lacking the polish and tooling that KMP provides. But, it will be interesting to see how they stack up against each other in a few years. My personal preference remains KMP, as I find Kotlin to be a more “sane” and unsurprising (which is a good thing) language compared to Swift, so I will continue to use it for multi-platform development for the time being.

Before diving into my proposed POC (which is still a work in progress and might change!), I’ll give a quick overview of the RIBs architecture, its current state on iOS, and how it handles concurrency today.

RIBs Architecture

Overall, RIBs architecture allows you to model your application as a tree of business logic scopes, where each scope contains at least the 3 core things: Router, Interactor, and Builder. That’s where the acronym RIBs is coming from.

Each RIB scopes business logic and can have an optional view. Because of this, RIBs do not necessarily correlate with screens that your application has, but for a lot of them, that’s the case.

And a RIB has additional things that it utilizes based on the concrete needs and implementation of your application, like: Services, Managers, Storages, Streams, Use Cases, etc.

By its nature, RIBs architecture is business logic driven rather than UI driven. This is by design so that asynchronous background work and async reactive data streams in the business logic can be made the centerpiece of the application rather than fickle whims of UI/UX design changes.

Another key concept is that there is a unidirectional data flow in RIBs. The data flows from the top parent RIBs down in a one-to-many broadcasting fashion, and data flowing up from children to parents goes via a one-to-one relationship. This allows for very effective state management that helps avoid data races and other data issues in the architecture.

Concurrency with RxSwift

The Role of Reactive Streams

To achieve concurrency and handle reactive data streams and asynchronous work in RIBs, RxSwift is traditionally used for its rich set of high-order functions, observables, subjects, and other reactive data stream implementations. RxSwift has the advantage of being a well-established and battle-tested reactive streams implementation standard that was ported, with minimal deviation, to every popular programming language.

Practically, when you work with RIBs, this doesn’t mean that you have to use RxSwift, but doing so will give you convenient helpers and integrations with RIB’s lifecycle to help you manage your observable streams and async work. You could, of course, roll out your own using Combine, Swift Concurrency’s async/await, or something else. You’d just have to manage your streams of data and async jobs yourself, making them work with the RIB’s lifecycle and ensuring they cancel when a RIB is detached.

Best Practice: Decoupling UI from Streams

Day to day, I found it to be the best practice in RIBs to have a clear separation and standard on how you use RxSwift in your applications: use streams/observables for async work everywhere in the business logic of the app but completely separate and keep it out of the UI view layer of the application.

In practical terms, this means:

• If you need to do a one-off async job (like a network request), have a service object produce a Single that wraps the request.

• The Interactor (the center of the business logic) injects the service, launches/subscribes to these streams, and binds them to its own lifecycle for data cleanup on detachment.

When it comes to updating the UI based on the data the streams/async jobs produce, instead of passing those streams down to the UI, you instead call methods on your RIB’s Presenter to present the received data. This way, you achieve a clean separation of concerns, avoid cluttering the view layer with Rx subscription logic, and decouple the async operation’s lifecycle from the UI’s lifecycle.

But I digress... I can be talking about this for hours and this warrants its own post (which I will write in the future), but this is overall how asynchronous work is implemented in RIBs.

The Problem

The problem today is two-fold:

1. No Native Swift Concurrency Helpers: There is currently no helper or integration to work with Swift Concurrency’s async/await directly with RIBs. If you want to call async functions from your Interactor or its dependencies, you’d have to manage wrapping them yourself into a Task and then managing its cancellation with the RIB’s lifecycle (e.g., wrapping the Task into an RxSingle or similar).

2. Swift 6.2 Strict Concurrency Violations: With the new Swift 6.2 strict concurrency rules enabled, several compiler warnings and errors related to actor isolation appear when using RIBs.

While both issues are fixable by adjusting your codebase and jumping through a lot of hoops to make the compiler happy, it’s not optimal. The amount of changes required for existing RIBs projects could be overwhelming and impractical.

The Solution

I outlined the POC of my solution in the PR I opened: https://github.com/uber/RIBs-iOS/pull/45. I’ll try to give it more context, detail, and a summary here.

Keep in mind this is still a proof of concept, and the proposed solution could dramatically change. There is a chance that I have a fundamental flaw or an irreconcilable issue with the way I’m thinking of implementing it, and I might have to redo the approach completely from scratch. But, as of today, I do have a working prototype and am looking for feedback on it!

Unfortunately, it is unlikely that breaking changes to existing codebases using RIBs can be avoided, but I think I was able to get them to a minimum.

Fundamentally, there are just two things that need to be done to satisfy the new Swift Concurrency strict rules:

1. UI/View Layer is MainActor Isolated: Everything that touches the UI/view layer (Presenter, ViewableRouter, ViewController, or parts of them) must be explicitly marked with @MainActor to indicate that they call methods to manipulate and re-render the UI on the main thread.

2. Business Logic is Nonisolated: Everything else is inherently asynchronous and needs to be marked as such with nonisolated (or other directives/protocols/keywords).

Along with those two changes, I added a couple of helper methods to the PresentableInteractor and the ViewableRouter to automate some of the boilerplate related to calling presenter methods or UI navigation methods on the main actor.

One thing that I haven’t added yet, but will likely add soon to this PR, is a convenience/automation/helper method/s to run async functions in the interactor and automatically create a wrapping Task and an Rx observable for it.

Looking for Feedback!

I’m looking for feedback on my PR. You don’t have to already work with RIBs or be an expert in Swift Concurrency, but I’d appreciate a second pair of eyes from someone who spent more time using Swift Concurrency than me. Perhaps I missed something critical there...

Also, how are the ergonomics of creating a new Swift 6.2 project and integrating this POC of the framework into it? How are the ergonomics and the experience updating an existing project using RIBs?

In the coming weeks, I’ll be testing all of that myself in new sample projects, in one of my personal projects, and in production at scale at work.

Original PR Submission

Here I’m posting the content of my POC PR submission that might add a bit more of a context and detail to the changes I made.

Swift Concurrency/Isolation Support

This is a draft PR to introduce Swift Concurrency Isolation support in RIBs. It is a functioning prototype but it needs thorough testing real codebases. I’ll be testing it in one of our production codebases and also in all of my personal projects. But, I’d appreciate volunteers to try this out and give us feedback. You can find sample usage of this change pointing to my fork that constitutes this PR here https://github.com/alexvbush/RIBsSample1

This change is related to https://github.com/uber/RIBs-iOS/issues/6 and https://github.com/uber/RIBs-iOS/issues/43

Overall, I’m still not able to make it work without breaking changes, but I believe I brought them down to a minimum.

This is still a WIP and I am open for feedback to make changes to this solution.

The Isolation and Threading Issues

Fundamentally, everything in RIBs can be async and run on different threads, and you as a developer need to manage concurrent access to the data in RIBs on your own. Historically it’s been done via streams RxSwift Observables, Subjects, etc. and in combination with the helper methods such as func disposeOnDeactivate(interactor: Interactor) -> Disposable it works pretty well out of the box. The only thing you’d really need to worry about was running your stream/observable observation callbacks on the main thread when you’d need to render the UI, aka call methods on your RIB’s presenter. This would normally be achieved by adding .observe(on: MainScheduler.instance) call onto observables so that their subscribe next callback block executes on the main thread. It works fine but requires developer discipline to remember to add.

The same applies to controlling multi-threaded access to data across your RIBs app - it is up to you how to implement it, but RxSwift that comes out of the box gives you a lot of tools and flexibility to do it.

With the new Swift Concurrency rules and compiler errors and warnings a lot of these things are either more explicit or attempted to be inferred and resolved at compile time.

If RIBs are used in projects with strict swift concurrency isolation enabled, then as it stands today one would experience a lot of compiler warnings about breaking isolation constraints and related issues such as these:

Ultimately the compiler is trying to be helpful by enforcing stricter concurrency but it doesn’t know/can’t infer the RIBs ways of ensuring safe concurrent access to data via streams and Rx observables. This leads to warnings and compiler issues that are either excessive or incorrect/not-needed in the context of RIBs.

Isolation Changes

In order to fix the compiler issues with the new strict swift concurrency we have to modify and explicitly state what kind of access each class or interface in RIBs should have.

Almost every class or protocol was marked as nonisolated and everything else that touches the UI aka the main thread was marked with @MainActor:

1. Presentable protocol and by extension Presenter class and its subclasses

2. LaunchRouting and its func launch(from window: UIWindow)

3. ViewControllable since its the one referring to UIViewController instances

Everything else, such as components, interactors, builders, routers, etc., was marked as nonisolated since it’s explicitly up to the developer to deal with concurrency there.

Overall those are all the fundamental the changes. But they have some implications and breaking changes.

What are the implications of all of these changes?

Well, this now means that calls to presenter methods, either directly or in callback blocks from Rx or async/await tasks, will result in the following error: Call to main actor-isolated instance method ‘presentStuff()’ in a synchronous nonisolated context.

This is a good thing and is what strict swift concurrency rules intend to help with. This will warn you if you are trying to call presenter methods from potentially not the main thread, this is forcing you to explicitly call them on the main thread which would reduce a lot of potential runtime errors.

The same type of warning occurs when we try to call methods on UIViewController instances while navigating the UI during viewable RIBs routing. Since router is nonisolated, and routing can actually be triggered from different threads, especially for headless routers, the only thing that really needs to be executed on the main thread is only the UI manipulation part which is the navigation between view controllers.

How should we call presenter methods now?

In the current incarnation (and keep in mind, I’m still exploring the solutions here) you have two options to properly call presenter methods on the main thread:

1. declare the presenter as nonisolated(unsafe) let presenter = self.presenter inline and then call your presenter methods wrapped in a Task { @MainActor in }.

2. use a new convenience method on PresentableInteractor that automates this for you.

Technically to make it work you could manually set up presenter inline as nonisolated(unsafe) local variable and then call it methods on it in Task { @MainActor in }. Since this would quickly become tedious, I added a helper method presentOnMainThread on PresentableInteractor that will do this for you. It can be called safely from an RxSwift observable callback or from a Task.

What should we do in routes now?

Same as with the presenter, routing now has to slightly adjust to explicitly call things on the main thread when necessary.

Just like with the presenter you can either do it manually:

Or you can use a new automation built into the ViewableRouter:

Other Implications

There are also other minor implications of these changes, such as Presentable interfaces having an associatedtype Listener and a nonisolated var listener: Listener? { get set } property declaration. The change is minor but breaking unfortunately, I am still exploring the ways to avoid this.

Feedback Needed!!!

This is an early work in progress exploration of how Swift Concurrency can work seamlessly with RIBs. There are a few more things that need to be done such as Task/async/await helper methods support that I’ll add a bit later.

In the meantime I am looking for feedback - please pull this PR or use the branch in my fork of this repo https://github.com/alexvbush/RIBs-iOS/tree/swift-concurrency-isolation and test out these changes in your own projects. Let me know what works and what doesn’t. There will be compiler issues and you’d have to tweak and migrate a few things but I hope it’s not too many. Let me know what you had to migrate and I’ll try to add helpful tutorial/readmes based on your input. And also checkout my sample project where I applied my fork’s branch to a sample RIBs app: https://github.com/alexvbush/RIBsSample1

Share The Mobile Engineer

This compiler warning (or compiler error, depending on how severe you set your settings) occurs when the framework is used in a Swift 6.2 project where the default concurrency isolation has changed. Essentially, now, if you do not explicitly specify otherwise, if your code is called from the main thread, from things like UIKit’s view controllers or from SwiftUI, you will get a bunch of warnings that you shouldn’t be doing so.

RIBs is a comprehensive architecture and framework and it addresses or touches all the high level aspects and layers of your application.

There are a lot of parts to it, but at the end of the day, things that need to be on the main thread are those that directly touch UI. Basically it’s the view layer composed of the view objects (UIViews, SwiftUI views, UIViewControllers, etc.) and presenters (ViewController in most cases or a standalone Presenter object implementing Presentable interface) + some aspects of Routing/Routers that touch the view for navigation (specifically ViewableRouter and not the Router).

Now, the theory is that we can just mark the things we need to be on the main thread with @MainActor and that’s it, where everything would just magically compile and give you appropriate compiler time warnings. But in reality, it is of course much more complicated and nuanced than that, especially with a framework that has high adoption and usage and is mission critical. To add Swift 6.2 concurrency isolation support, we want to make the minimum amount of changes and hopefully not introduce any breaking changes or compiler warnings (or a minimum amount of those) to the users of the framework as the migration could be a nightmare.

So, this is why I’ve been heads down figuring out how stricter Swift 6.2 compiler time rules for concurrency actually work in practice and what implications they have for RIBs framework and codebases that use it.

So far, marking things explicitly, where needed with nonisolated and @MainActor seems to be working… but I need to do more thorough testing. I’m in the beginning of my research so I don’t have all the answers yet but I’ll keep everyone posted on the findings.

This is an excerpt from the upcoming 2nd edition of my book The iOS Interview Guide. If you’re interested to hear more book updates like this and to receive draft chapters as I write them feel free to subscribe to my substack, I’ll post all the updates here.

How does Thread class work in Swift?

\label{question:swift_threads}

This is a low-level question designed to gauge a candidate's understanding of the fundamental building blocks of concurrency on Apple's platforms. Even though direct thread management is rare in modern iOS development, knowing how it works provides important historical context for appreciating higher-level abstractions like Grand Central Dispatch (GCD) and Swift Concurrency.

Expected Answer: The Thread class is a low-level, object-oriented way to manage a single thread of execution directly. It's part of the Foundation framework and provides you with manual control over creating, starting, and managing a thread's lifecycle.

You can create a new Thread object by passing it a closure or a selector and a target to execute on a separate thread. Another option is to subclass the Thread class, override the main() method in it and put the code you wish to be executed on another thread there.

let thread1 = Thread {

print("This is running on a background thread.")

}

let thread2 = Thread(target: self, selector: #selector(doWork), object: nil)

thread1.start()

thread2.start()


final class MyThread: Thread {

override func main() {

print("Executing on a custom thread subclass.")

}

}

let myThread = MyThread()

myThread.start()

A Thread instance's lifecycle is managed manually with the following methods:

• start(): begins the execution of the thread.

• cancel(): signals to the thread that it should exit. This is a cooperative mechanism (just like in Swift Concurrency); the code running on the thread must periodically check the isCancelled property and handle termination gracefully.

• sleep(for:): Pauses the current thread for a specified time interval.

These days Thread is considered a legacy, low-level, solution that is most likely not what you want to go for in iOS application development. Instead, you should use more modern solutions that are built on top of the low-level Threads such as Grand Central Dispatch (GCD) and Swift Concurrency. Both of these solutions help you interact with Threads at a higher level of abstraction, where the system will manage the actual threads your work is executed on, rather than you having to manage it yourself manually. These solutions help you avoid many problems you’d encounter working with threads directly, such as:

• Data Races: Thread has no built-in protection for shared mutable state. You are entirely responsible for implementing synchronization mechanisms like locks (NSLock) or mutexes, which are difficult to use correctly and can lead to data races or deadlocks. Swift's actors solve this at the language level, providing compile-time safety.

• Thread Explosion: Creating too many threads can overwhelm the system, leading to excessive memory consumption and context-switching overhead, which harms performance. GCD and Swift Concurrency manage a limited pool of worker threads much more efficiently.

• Lifecycle Management: Manually managing the lifecycle of each thread is complex. Forgetting to terminate a thread or handle its cancellation can lead to resource leaks. Structured concurrency provides clear, scoped lifetimes for tasks, which automatically handle cleanup and cancellation propagation.

Red Flags:

• Advocating for the use of Thread for new application-level features.

• Failing to identify the significant risks associated with manual thread management (, such as data races and deadlocks).

• Not being aware of modern alternatives like GCD and, more importantly, Swift Concurrency with async/await and actors.

Help me make this chapter better.

What did I miss? Anything to add to make it more clear or helpful?

Your feedback directly helps shape this book into a more practical resource for the entire iOS community. Drop a comment or send me an email.

The iOS version bump is many versions behind the latest iOS release to help with backwards compatibility but it is necessary to have decent base support for SwiftUI and async/await.

The RxSwift update is also part of this effort, so that extensions and mappers between Observables and async/await can be used out of the box from the Rx library instead of being rebuilt within RIBs.

I also moved all of the iOS issues from the original RIBs repo into the new one. I will start replying and addressing them as soon as I can. Let me know if I missed anything or if you have any questions!

This is an excerpt from the upcoming 2nd edition of my book The iOS Interview Guide. If you’re interested to hear more book updates like this and to receive draft chapters as I write them feel free to subscribe to my substack, I’ll post all the updates here.

What is Actor and Sendable in Swift?

This question will come up as part of discussion around asynchronicity on iOS and as conversation goes deeper into the topic of Swift Concurrency. In Swift Concurrency, async/await is the means of defining and executing async work, while actor is the means of protecting data from race conditions and other async data access/read problems. As an iOS engineer you need to know how to work with actors (and their advantages, limitations, etc.) and you need to know how their features compare to other solutions such as GCD, RxSwift, or alternatives in other languages such as Coroutines in Kotlin.

Expected Answer: Swift Concurrency introduced a new type called actor. It behaves and acts much like class type. It’s a reference type, but its main purpose is to protect access to its mutable state from concurrent access by different threads. This helps protect data access to the actor's state and helps prevent data races by enforcing static checks at compile time. This process is called actor isolation.

Actor isolation is a “barrier”, so to speak, of access to actor’s properties data. Essentially, in order to access data on an actor externally, read its properties or write to them or call methods that mutate its state, you have to use the await keyword and access them asynchronously. Internally, the system will queue up access to data and mutations, processing them one at a time. This serializes access, preventing race conditions and ensuring data synchronization. This isolation is enforced at compile time giving developers an early warning.

Internal data access in actors can happen in a “normal” synchronous way and doesn’t require an await call.

Sendable

To maintain isolation, any data passed into an actor's methods or returned from them must be safe to share across threads. Types that are safe to share have to conform to the Sendable protocol. Marking something as Sendable, you guarantee to the compiler that it’s safe to transfer that value across threads.

Sendable protocol is akin to Codable in a sense that in order to have a type conform to it, every property of that type needs to conform to Sendable as well. Primitive types conform to it by default, and structs and enums as well, as long as all of their properties are other primitives or types conforming to Sendable. You can also make normal class types conform to Sendable, but you’ll have to manually manage access and mutability of their own properties using locks or other thread-safe mechanisms.

By default, everything is isolated in an actor. If you want to explicitly opt-out of the default isolation for a property or a function, you’d need to mark it with the non-isolated keyword. You would opt-out these functions or properties in an actor that are not mutating any state - since they don't mutate any state, they can be accessed safely synchronously and do not need to be put on an asynchronous queue with await.

Actor Reentrancy

One important thing to remember about actors is the actor's reentrancy behavior. When one message is sent to an actor object and is awaited on, it doesn’t mean that the actor becomes exclusively locked and will only execute other messages after the first request is fully processed. Instead, while one await call is suspended, another message can be processed by the actor and potentially finish sooner than the first one. This solves the problem of deadlocks that could otherwise occur where one actor waits on the execution to finish from another actor, and the other, in turn, waits on the execution of the first one to finish, therefore causing a never-ending deadlock.

The implication of this, though, is that you can never be sure if the state of the actor hasn’t changed between before and after you call an await method on it. You will have to check the data after suspension finishes to make sure it’s still in the correct state.

Prior Solutions

Prior to actors, using GCD (Grand Central Dispatch), we had to create a private serial dispatch queue to achieve a synchronization lock that allowed only one operation at a time to access data.

With RxSwift you’d use something like BehaviorSubject with SerialDispatchQueueScheduler with a similar setup as GCD - SerialDispatchQueueScheduler will ensure that there is a synchronization lock as long as you perform your operations on that scheduler.

Either GCD or RxSwift solutions required developer’s discipline to implement accurately, with Swift Concurrency’s actors the compiler aids in identifying isolation violation and potential race conditions it could lead to.

In other languages like Kotlin, you’d use Mutex and/or StateFlow, but there is no direct compile time safe equivalent to actors.

Red Flags:

• Stating actors are always single-threaded or non-reentrant: This is a major misunderstanding. While an actor processes messages serially, it is reentrant. An interviewer might ask a follow-up question specifically designed to test for this misunderstanding.

• Believing nonisolated moves code off the actor: Misconception that annotating a method with nonisolated will automatically run it on a background thread. nonisolated simply removes actor isolation; it doesn't dictate the execution context. The method will run on the caller's context.

• Saying Sendable for classes is easy: If the candidate suggests that making any mutable class Sendable is straightforward, it indicates a lack of understanding of the complexities of thread-safe mutable shared state and the implications of @unchecked Sendable.

• Confusing async with concurrency: While async functions enable concurrency, they don't inherently run on a background thread. They only mark potential suspension points. The actual thread hopping for background work is handled by the runtime or by explicitly offloading work (e.g., to an actor or another Task).

• Inability to explain why actors are safer than GCD/RxSwift for state: A strong answer shouldn't just list alternatives but articulate how actors offer a compiler-enforced safety mechanism that manual GCD queues or RxSwift schedulers do not for state isolation.

Help me make this chapter better.

What did I miss? Anything to add to make it more clear or helpful?

Your feedback directly helps shape this book into a more practical resource for the entire iOS community. Drop a comment or send me an email.

RIBs is a cross-platform architecture Uber came up with to power their mobile apps back in 2016.

I had the pleasure of learning about and working with this architecture during my time at Uber. I was sold on its modular and composable nature, clear separation of layers, and deep Clean Architecture roots.

Since then, it’s been my favorite architecture for mobile apps and I’ve used it for many years in personal and work projects applying it to codebases big and small.

Lately, I volunteered to help with maintaining the repo and I am now the official primary maintainer!

What is RIBs?

RIBs is an acronym that gives the name to the smallest logical piece of this architecture, a RIB, a group of 3 classes: Router, Interactor, Builder.

In RIBs architecture, your entire app consists of a tree structure of RIBs where each RIB represents a business scope of your app and can have zero or many children.

As the user interacts with the app and business logic demands, some RIBs will be instantiated and routed to and added to the RIBs tree, and some will be routed away from, deallocated, and detached from the RIBs tree.

This approach makes it very easy to break down your app into business scopes with single responsibility and logic completely isolated from each other. This way, a team can work on a subset of RIBs within a larger application and have their own “sandbox” in them and change whatever it wants without risking breaking other RIBs across the app.

The uniqueness of this architecture is two-fold:

1. it’s a complete end-to-end solution that not only has an architecture and a set of guidelines but also a framework to enforce structure (unlike other architectures such as MVVM, MV*, VIPER, etc. which are all essentially just sets of loose guidelines).

2. RIBs is business logic driven, not view/UI-driven. Pretty much every other mobile architecture is view-driven where the architecture itself and the application cannot exist without a view and the view is the very first and smallest component of the architecture. In RIBs, each RIB can exist by itself (aka be headless) without a view or can optionally have a view. UI updates and anything else in the view layer is driven by the business logic in the RIB rather than the other way around. It is a very subtle but profound difference that makes this architecture much more flexible and superior to any other client side architecture out there.

That said, of course, most of the RIBs will have an associated view that they will manipulate:

There is much more that I can say about this wonderful architecture but I’ll do it in followup posts in the future. If you want to learn more about it, here’s a list of other resources that might help:

• RIBs. The Best iOS Architecture.

• https://insideiosdev.com/episodes/alex-on-ubers-rib-architecture-2d362fd3

• https://www.uber.com/blog/new-rider-app-architecture

• RIBs - Uber's new mobile architecture that scales to hundreds of engineers by Tuomas Artman

• [Uber Mobility] Architecture Rewrite - Tuomas Artman

• [Uber Mobility] Deep Scope Hierarchies - Tony Cosentini

• [Uber Mobility] RIB (Router Interactor Builder) - Yi Wang

• [Uber Mobility] Plugins - Brian Attwell

A few years back, I started to make a video course about it, so if you’re interested you can check it out here, it’s free!

What are the plans for RIBs?

Since RIBs is a cross platform architecture at its core, it originally was implemented and published with Android and iOS combined together, all in one repo. Since there have been more developments happening in the Android implementation version iOS lately, Uber decided to split them out and give the iOS implementation its own github repo.

There are lots of outstanding issues and questions about the iOS framework in the original repo. I’ll start slowly moving those to the new repo and will try to help resolve them and answer questions as best as I can.

There is some modernization that needs to happen to the framework:

1. Add SwiftUI support

2. Add Swift Concurrency (async/await) support

While RIBs technically can support both out of the box, SwiftUI with UIHostingController, and async/await by wrapping it into a RxSwift Single or Observable, it would be nice to have helpers and convenience methods around it built-into the framework itself to make the integration smoother.

For anyone who’s transitioning and migrating existing codebases to RIBs, it would be nice to have some convenient APIs to provide that functionality for legacy code integration. I have encountered these issues myself in integrating RIBs into existing codebases - there needs to be some sort of support of attaching RIBs outside of RIBs tree hierarchy, to something like a legacy UIViewController. However, it’s not applicable to anyone, who, like Uber, starts from scratch and builds their entire application with RIBs from the getgo. For anyone who’s transitioning and migrating existing codebase to RIBs it is much more practical to start with leaf RIBs rather than the root and work your way up the tree. It is also technically achievable today with the current framework but you’d need to know the internal mechanics of how a RIB is attached to a RIBs tree and then replicate the same actions adding one to a view controller.

As I have other commitments like my ongoing work on my book, there is no timeline on these improvements, but I’ll try to add them as soon as I can and will post on substack about the progress.

Conclusion

I encourage everyone to try this fantastic architecture. It truly has been the biggest unlock for me for scalable application development!

At UpKeep we have a small mobile team that supports a rich feature set of our CMMS application. We have native mobile apps for iOS and Android and the main users are technicians in the field performing maintenance work on assets in various facilities such as factories, warehouses, etc.

Both apps are native apps that utilize native platform capabilities. As the feature set of both apps grew over the years, it became increasingly difficult to avoid subtle (or not so subtle) discrepancies between the two native app implementations. Sometimes some bugs will creep in on one platform or the other or one platform would use slightly different data fetching or permission logic. All of these add up to a degraded user experience and an added cost of “synchronization” between two platforms, either at the development stage (where devs from both platforms need to be in sync) or at the later bug fixing stage (where Android and iOS devs would need to dig through the discrepancies and figure out which platform actually behaves correctly and which one does not). Ultimately, we always had to write the implementation twice in Kotlin and Swift (since the two apps have the same features and are supposed to behave the same way).

All of that led us to exploring cross platform and multiplatform solutions and we zeroed in on Kotlin Multiplatform (KMP) as our technology choice.

In this article we’ll cover:

• Advantages of adopting KMP as a code-sharing technology over other options

• A high-level overview of the architecture of UpKeep’s mobile apps and the KMP integration

• Our team’s learnings and path forward

This is part 1 of a two-part series covering UpKeep’s mobile app architecture. This article will focus on the Kotlin Multiplatform side. In part 2 we’ll cover iOS application architecture in more detail.

Why KMP?

What is KMP?

KMP is a technology that allows Kotlin code to be shared and run as native code on various platforms such as iOS, Android, web, desktop, etc. KMP allows developers to write common business logic once and share it across different platforms while keeping the platform-specific code in separate modules.

What are the benefits?

Here’s an excerpt from our internal documentation that we circulated in the mobile team to get buy-in prior to embarking on adopting KMP in our codebases.

KMP provides several benefits:

Code Reusability (Unified Codebase): With KMP, you can write your business logic in a single codebase and share it across different platforms like Android, iOS, web, and desktop. This eliminates the need to duplicate efforts for each platform.

Maintenance: Maintaining one set of business logic is easier and less error-prone than maintaining multiple versions for different platforms. Bug fixes and updates can be made in one place and immediately benefit all platforms.

Consistent Behavior: Shared business logic ensures that the core functionality of your app behaves the same way on all platforms. This consistency improves the user experience as users get the same features and behavior regardless of the device they use.

Consistent Testing: Automated tests can be written once for the shared code, ensuring that all platforms meet the same quality standards. This reduces the risk of platform-specific bugs and discrepancies.

Reduced Development Time: Developing features and fixes once and deploying them across multiple platforms speeds up the development process. This allows developers to focus more on platform-specific enhancements and user experience rather than replicating business logic.

Resource Utilization: Teams can be more flexible and efficient. Instead of having separate teams for each platform working on the same feature, a single team can develop the shared logic while smaller platform-specific teams integrate and enhance it.

Maintaining Platform Independence & Flexibility: While KMP promotes sharing code, it also allows for platform-specific code where necessary. This flexibility ensures that you can optimize and customize the user experience for each platform.

Separation of Concerns: Platform-specific code can handle unique platform capabilities, UI components, and performance optimizations, while the shared code focuses on the business logic.

General Architectural Forcing Function: In general, using KMP forces developers to think through the business logic as a separate concept, clearly separated from the rest of the code, which in turn makes architecture much more robust and flexible.

What was the approach to roll it out?

Since most of the team was pretty new to KMP, we decided to take it slow and first build out a demo application as a proof-of-concept (POC) of how KMP works and its benefits. Later on, after the team was happy with the results and talked through the POC codebase extensively, we integrated KMP into our main Android and iOS codebases.

Since KMP is flexible and can be used adhoc we first refactored an existing feature with KMP and rolled it out behind a feature flag. This way, there was no surprises on the expected behavior, we could clearly validate before and after impact (there would be no change which is good in this case), and we had total control over it at runtime and could shut down the KMP refactored code path at any point in time if it was not working properly.

After a successful first attempt, we now use KMP for every new feature we develop in our mobile applications.

Mobile Architecture At UpKeep

How much code to share?

The introduction of KMP forced us to clearly articulate and define architectural boundaries in our mobile apps. The first discussion and decision that we made was how much code we should share between platforms.

These days, KMP offers a full end-to-end stack for code sharing that includes all the networking/service layer, storage layer, business logic, and UI code sharing. With KMP, you can choose to share as much or as little code as you want.

We decided to leverage the native UI on each platform to provide the best possible user experience. Therefore, we settled on sharing only the business logic code between iOS and Android for now. There is an asterisk to it though, which I’ll get into more later on.

What is Business Logic?

In a typical client side application there are two types of business logic:

1. The business logic of orchestrating network requests and database queries based on user input and general serialization, data mapping and processing, etc.

2. Management of business scopes (and screens), navigational behavior, and overall application state (screen hierarchy) as the user navigates across the app

It doesn’t matter what kind of architecture (or lack thereof) your app has, the business logic of your app will always encompass those two overall areas, regardless of whether it’s expressed explicitly or implicitly in the code.

The first group of business logic can be depicted like this:

(Authentication Business Logic Flow is in green)

Here, we are covering all the logic needed to make the “machinery” of the app work. After receiving user input to, for example, the login, the app needs to process and validate the input, form a proper network request to fulfill the backend API contract and issue the request. After that, the app needs to process the response, validate that it meets the contract expectations, serialize it, map it to domain models, and then, perhaps in case of a login, persist some of the response, such as session token, to disk.

All of these things are the “plumbing” but also the business logic every app has. These are not UI-related concerns.

The second group of business logic can be depicted like this:

(note grey is currently inactive application scopes/state)

This is where we manage the overall application state, what screens go first and second as the user interacts with the app, where the user should be navigated to after login or tapping on a feature tab/item, etc.

It also controls when the complex business flows (such as the authentication business logic flow above) should be triggered based on user input or other events.

Note, when I say “application state,” I mean the state that needs to support the above logic, not all the UI state of what strings and images to display in a given screen (we’re talking overall application flow here).

This typically ends up being represented as a tree of business scopes or a tree of screens the application has. Everything starts with a root and then business logic decisions are made such as to route to a login screen if the user token is not present. Later, the business logic here decides to route to the main screen upon user login or other types of navigation. Or, after the user inputs some data in the UI, a use case is executed to actually perform a request on the user's behalf. All that decision making on where to route/navigate the user based on the overall application state and when to trigger more complicated login (such as use cases for submitting and retrieving data) is what’s encompassed in this second group of business logic.

What part of business logic to share?

Now, as we established what those business logic groups are, we had a hard decision to make - where to draw the line on sharing the code and the business logic. We ended up picking the first group to share for the following reasons:

1. It’s a more clear-cut slice of mostly “functional” behavior with virtually no side effects (except occasional database persistence) that we can extract into use cases that are shared between two platforms. There would be no deviation or platform specific code or logic here except, perhaps, for the low-level specific details of data persistence and networking. But both of those concerns are fairly well established, abstracted out, and solved with current popular open source KMP libraries.

2. It would be ideal to share the second business logic group as well, but given that we have legacy code in our codebase with established and divergent from each other implementations between iOS and Android (iOS has some MVVMs but also a lot of RIBs, and Android is mainly on MVVM design pattern). We decided to not push it yet and not share the second group of business logic between our mobile apps yet. It will require more abstractions and more unification in the architecture of both apps to support this kind of code sharing. We are aiming for it at some point, though.

KMP Module Architecture: Clean Architecture

So, what does the architecture look like for the shared code inside of KMP?

After establishing what slice of the business logic to share, we quickly narrowed down on using Clean Architecture for it - our shared codebase would be a collection of high level business Use Cases that can be used in and shared between our mobile apps.

Here’s an example list of use cases we have:

• UpdateNotesUseCase

• UploadPhotoUseCase

• GetChecklistsAndTasksUseCase

• DeleteAllPhotosUseCase

• DeleteSignatureUseCase

• UpdateTaskValueUseCase

• GetWorkOrderActiveTimerUseCase

• GetWorkOrderTemplateDetailsUseCase

• GetWorkOrderTemplateListUseCase

LoginUseCase Example

This is how our Authentication flow would work and look like for Login Screen:

Here we have an Interactor or a ViewModel start execution of a LoginUseCase to login the user. The LoginUseCase contains all the orchestration business logic.

The LoginUseCase in turn asks AuthenticationRepository to perform whatever necessary low level logic to actually authenticate and log in the user.

The AuthenticationRepository first has AuthenticationService make a network request to authenticate the user with the backend API and to receive a session token from it.

Next the AuthenticationService uses a low level APIClient object to perform an actual HTTP request against the backend API to get the token.

After executing the HTTP request the API client serializes the response from JSON to Kotlin data class objects and returns it back to the AuthenticationService.

AuthenticationService passes the result back to AuthenticationRepository.

Then AuthenticationRepository maps the backend response to domain model objects that the rest of the app can work with. After that the repository asks SessionStorage to store the session token.

SessionStorage maps the domain models to DTO and uses DatabaseClient to store those DTOs in the actual database on device.

DatabaseClient is the one that performs low level queries to actually insert data in table/s.

After database insertion is successful, SessionStorage responds back to the AuthenticationRepository with success and AuthenticationRepository passes the authenticated token to the use case.

The LoginUseCase finally responds back to the Interactor/ViewModel about successful login so that the UI can navigate to the main user screen.

This roughly translates to the following responsibilities for each type of object:

• Use Cases are responsible for business logic orchestration - i.e. what repositories to use to retrieve or send data and business logic decision making on when to call them, user permissions, validation, etc.

• Repositories are responsible for data retrieval and sending. They abstract out how the data is received or stored - i.e. most of the time data is only sent or received via the backend API but sometimes it needs to be retrieved or stored in the local database, this what’s abstracted out by repositories, the use cases never need to know from where they got the data provided by repository.

• Services are responsible for concrete network requests to concrete endpoints. They serialize data for sending to backend API and after receiving.

• APIClients are responsible for actual mechanics of executing HTTP (or GraphQL or Socket) requests. It’s the low level object that uses URLSession or similar for actual network request sending.

• Storages are responsible for storing data to disk, a database, file storage, keyvalue, doesn’t matter. Just like services for API requests, storages serialize and map data sent and received to and from the database (or other means of storage).

• DatabaseClients are just like the APIClients - they are basically a wrapper around Core Data or SQL or UserDefaults or FileManager or similar that perform the actual low level data storing or retrieval function.

This is a somewhat simpler example where the use case doesn’t need to coordinate between different repositories to retrieve data but nevertheless it depicts the overall architecture of our use cases and their dependencies well.

I also omitted a bunch of helper objects that we have, in particular, the mapper objects from one layer onto another. It was a debatable subject on whether we need to have them as separate objects or if we are better off including mapping into each object such as repository, service, etc.

Modularization & Code Organization

I’ll cover modularization in detail in the next article of this series but briefly here - we modularize the shared KMP codebase by feature (i.e. Work Orders feature, Authentication feature, etc.) and by layers (database layer, networking layer, etc.)

We decided to keep shared KMP code in a standalone git repository from the iOS and Android codebases. The iOS and Android codebase import shared code as a native library.

From the developer experience point of view the shared KMP code is fetched and included in your main iOS or Android codebase as a git submodule folder so that you can change the code as you work on features full stack - both iOS/Android and KMP side at the same time.

KMP Shared Code Public API & Dependency Injection

We technically expose all of the KMP classes, including the low level ones, to the iOS and Android apps because we decided to leave dependency injection and assembly solutions to each respective application.

But the intended usage of the shared code is for iOS and Android Interactors or ViewModels to call only Use Cases from KMP and never the other objects (besides using the domain model input/output).

Architecture in iOS & Android Apps

I will cover the architecture of the iOS app (and perhaps the Android app as well) in the second part of this series. But I’ll briefly explain here how we use shared KMP use cases from the application code.

As you saw from previous diagrams the second group of business logic objects calls into Use Cases provided by the KMP code to perform useful work for the user. From the perspective of the iOS and Android apps everything is abstracted out for them. The only thing they need to do is to call the right use case at the right time and present things to the UI or route to another accordingly for the user.

Now, that is still a lot of business and UI logic that is inside of the iOS and Android apps and is not shared between them.

As mentioned before, the architectures of the iOS and the Android apps differ from each other. The iOS architecture is RIBs (Router Interactor Builder) and the Android architecture is MVVM.

On iOS Interactors are the orchestrators of business logic, they decide what needs to be presented on the screen, what use case needs to be executed and when, what next screen to route to, etc.

On Android ViewModels play a similar role but it’s not as well defined - VMs call use cases but other types of orchestration, presentation decisions, and routing happens in the view later.

We’re considering eventually moving the Android app to RIBs as well but this is in the distant future as we’re focusing on getting more things migrated to KMP across both codebases.

Learnings So Far & Path Forward

This is the third quarter for us using KMP. So far the feedback and experience have been positive. We’re able to share anywhere between 10% and 25% of the code for new features between two platforms, which is definitely a win for engineering and business. Along with it, we have better consistency and no discrepancies in how we send, retrieve, and massage data between Android and iOS where we use KMP.

Collaboration between iOS and Android engineers is at an all-time high because they now are literally working on the same codebase (at least part of it) together.

Another upside of this is that we have a brand new clean codebase with no baggage in it where we could start building things from scratch taking with us all the previous learnings on how to do and not to do things from both the iOS and the Android codebase. We have a clean and clearly defined architecture with single responsibility defined and outlined for each layer and object type.

The downside, of course, just like with any heavy architecture such as Clean Architecture, is the boilerplate - the sheer amount of files and classes needed to implement a feature is high. But because of clearly defined boundaries and responsibilities, it has not been an issue. Also, these days a lot of boilerplate code generation can be automated with LLM codegen. Since the code is so clearly defined and doesn’t have variability in each implementation, LLMs are highly useful and don’t get confused too often.

Moving forward, we’ll be adopting more and more KMP code throughout the codebases. As the rest of the architecture converges more and more between two platforms (with Android moving to RIBs) we might start considering moving the second group of business logic to the KMP side to share as well.

The last thing we will ever consider, and likely will never do, is to share UI with KMP between two platforms. UI sharing solutions such as React Native or others never work well and have too many limitations (and the same goes for KMP’s Compose Multiplatform), so it’s unlikely for us to go this direction. But even if we don’t share the UI but share 80% of the rest of the code, it will be a tremendous achievement!

To give you a refresher, semantic versioning in software is a set of rules that dictates how software version numbers are assigned and incremented. There are 3 numbers in each semantic version: Major, Minor, Patch. This approach to versioning helps manage dependencies by having a strict set of rules on what each number means and when they can be incremented. Short version is this:

1. The Major version number can and should only increase when backwards-incompatible or breaking changes are made to the software

2. The Minor version number can and should only increase when backwards-compatible, additive new changes are made. This shouldn't contain breaking changes.

3. The Patch version number can and should only increase when backwards-compatible, non-breaking bug fixes are made

Simple and sweet, I've been using it for ages. All libraries in SPM, Cocoapods, or Carthage we use in iOS (or in any other software ecosystem for that matter) follow semantic versioning and have version numbers such as 1.2.5 or 2.0.0, etc., following the X.Y.Z format. The first number is the major, the second is the minor, and the last one is the patch.

Now, here's my dilemma with the library I'm maintaining: what do you do when the change you're introducing is a bump of the dependency version of the dependencies of the library itself?

Say my library A depends on library B 6.1.0 and library C 5.2.1., and now I need to have it depend on library B 7.0.0 and library C 6.0.0. I really need to bump the versions of my dependencies because I'm going to utilize new features from them in my library soon.

Should it be a patch change? No, that doesn't sound right - I'm not fixing any bugs after all!

Should it be a minor change? Nah, I'm not adding any new functionality here… at least not yet. I need those new features from my dependencies first to do so.

Should it be a major change? I don’t think so. I am not breaking any backwards compatibility here since my public API is not changing, nor is the internal behavior of my library.

Hm… a dilemma…

After thinking about it a bit, I started to analyze what the consequences would be for the consumers of my library if I bumped the version numbers of library B and C, which my own library depends on.

Well, it turns out that the users of my library are also highly likely to be using my library plus libraries B and C (which mine depends on) in their own project as well.
This means that if I bump the version number of my library’s dependencies it will have a downstream effect on the consumers of my library forcing them to also bump the version of library B and C that they depend on. This is because now the old versions of those libraries, 6.1.0 and 5.2.1 in our example, won’t be compatible with my library’s dependencies. A dependency tree is a tree after all.

So, I conclude that even though it’s seemingly not a major destructive change, the change in versions of the dependencies of my own library constitutes a major change to the consumer of my library after all because it has downstream forceful/destructive effects.

Which means I have to bump the major version number of my library!

Conclusion

This is not pretty obvious at the first glance what semantic versioning number you should be bumping in case when you update dependencies of your own library that others depend on. It was a bit of a head scratcher but as a rule of thumb - as a library maintainer you shouldn’t be destructive to your users, or at least you need to communicate it via versions. It turns out, your own dependencies are important to consider as they could be used by consumers of your library downstream as well as by your library.

Since Swift 5.5, we’ve had actors that were designed to prevent data races. Actors ensure that only one piece of code (and only one thread at a time) can access its internal mutable state at any given time. This provides a safe and isolated context for async work execution.

However, working with actors, isolations, and the varying contexts of thread/queue execution (whether implicit or explicit) sometimes became very complex and challenging to manage.

In Swift 6.2, Apple changed this, attempting to simplify things by making everything in your app single-threaded by default. Simply put, now, everything runs on the @MainActor implicitly by default if you have the SWIFT_DEFAULT_ACTOR_ISOLATION build setting flag turned on. For brand new projects starting with Xcode 26, it’s going to be the default.

What this really means is the return to “old” behavior where your code implicitly, by default, runs on the main thread unless you specify otherwise.

There are basically three ways to run your async code off of the main thread in a background thread:

1. Use an actor

2. Use @concurrent function.

3. Use Task/Task.detached

Actors’ purpose is to hold a “safe” state that can be altered and accessed over multiple async operations from different threads, and @concurrent’s purpose is to run a one-off async job (for a stateless computation) on a background thread off of the main thread.

Conclusion

This new default threading behavior is a welcome change to the previously confusing, convoluted implementation of asynchronicity that Apple created in Swift. I’m glad they are listening this year and are making sensible changes for a change.

IMO, this is the implementation that they should’ve aimed for from the get-go as they introduced structured concurrency. It’s a more natural mental model and a safer assumption for every developer to think that, by default, everything is executed on the main thread. After all, this is how every other client-side platform works, and that’s how it was prior to Swift Concurrency.

As for my own projects… I’m still sticking with RxSwift :)

New Design. Liquid Glass.

The new design, in my opinion, looks nice and clean, despite the jokes on Twitter comparing it to Windows Vista's 2006 design.

I think the most important thing here about the new design is unification of it across all Apple platforms and making it even more divergent from Android. This will make it even harder to build cross platform applications with tech such as React Native because mobile platforms will diverge more and more incentivising developers to build native iOS applications more and more.

New sheets and menu presentations are nice. We’ll see how easy or difficult they are to customize.

The new tabBarBottomAccessory looks very nice too. Will be handy for time tracking applications. Hopefully it’s highly customizable and flexible in its presentation.

It seems like Xcode 26 is going to be the only release of Xcode where developers will be able to opt-out of the new Liquid Glass UI. Effectively it gives us about a year + some to migrate to the new design.

Icon Composer

This is great! I know it’s a small thing but having a nice little app that helps you create app icons with different variations is such a big help trying to publish your own app. Especially if you’re on a budget haha.

I’ll definitely be using it for my own projects.

Apple Intelligence

There is so much to cover about Apple Intelligence just from the Platform State of The Union video let alone from the other Apple Intelligence specific videos that I don’t think I’m going to do it justice. But here are some of the highlights/thoughts of mine:

Apple's approach to implementing its Foundation Models appears to be very well-thought-out. The way to use LLMs in your code is just by importing it like yet another framework in your app. And it runs on the user's device!

I especially liked the choice between a single response result from the model vs a stream.

@Generatable is also a very clever and great way of annotating and structuring the output you want to receive from LLM. I wonder what the accuracy and hallucinations would be??

Tool calling is also done via interfaces (protocols)! Finally someone at Apple thought through API design and did it well!

Because Foundation Models runs on device it can be available offline which is a distinct feature from Android.

VisualIntelligence and Intents integration via deep linking seems interesting too but I need to look into it more closely to figure out how it actually works. (I believe Intents is not a new API but integrating it with LLM things seems to be a great addition)

Xcode

Many new great things are coming to Xcode. ChatGPT and other LLM codegen models are finally coming to Xcode. I think this is the only wish that came true from my WWDC wishlist this year :)

The UI seems nice at the first glance but what I couldn’t see is the approve/reject style of UI to accept or reject the changes that LLM makes in your codebase. Kind of like what Cursor does. The new Xcode UI reminds me more of V0 or Figma Make more than Cursor or Intellij.

Another new nice addition is #Playground directive to test code inline. It will be very handy to try things out quickly.

Also, it looks like developers will be able to add their own custom models to be used in Xcode which is great (I personally don’t think chatgpt’s models are the best for coding anymore, go google!)

Swift

And the last one that caught my interest was all Swift changes. Unfortunately it doesn't seem like I’ve got my protected keyword wish haha.

• InlineArray - meh, great but it doesn’t seem like it would be very useful since iOS devices are so powerful these days you rarely need this level of optimization

• Span type - meh, probably is very useful for low level development and interop with C but I don’t think many app developers will be working with it day to day

• Interop of Java and Javascript seems to be very interesting! I’ll be digging into it later.

• It still puzzles me why Apple keeps introducing more improvements to race condition catching with things like the @concurrent. Concurrency issues are a solved problem if you architect your code properly. Just don’t use Singletons :)

Conclusion

These were just some of my first impressions, thoughts, and musings on what I saw in the Platform State of The Union video of WWDC 2025.

What piqued your interest? Leave a comment. And let’s see what Apple has in store for us tomorrow.