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

5 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.

I figured I would join the hype train and share mine as well. Here we go:

AI Code Gen Tools in Xcode

We all are waiting for something better than, not-so-useful, autocomplete that we’ve currently got in Xcode. Cursor, Intellij, and other similar IDEs are leaps and bounds ahead of Xcode, Apple needs to keep up here.

Personally, I really like Cursor’s approach with its powerful codebase indexing and coding rules that kick in based on file pattern match.

More SwiftUI integration into UIKit

This one has been a long time ask of mine - better integration of SwiftUI into UIKit. I still believe that currently the best way to build iOS apps is not to create a SwiftUI app but instead to have a UIKit based app where you extensively use SwiftUI. As of today the way you do it is by utilizing UIHostingController, that holds SwiftUI view, by either subclassing from it or embedding as a child view controller as a wrapper around SwiftUI view.

It works well enough, but what’s missing is something more lightweight than a view controller wrapper - a simple view holder that accepts a SwiftUI object to render.

What I’m thinking about is basically something like the UIHostingConfiguration that UITableView has but for a UIView.

This technically already exists for macOS with NSHostingView. So, my wish is for Apple to add this to iOS, something like “UIHostingView.”

Less Singletons and More Protocols in Apple Frameworks

It’s been a pet peeve of mine for many years now. Apple makes great OSes and frameworks for developers to use, but the way their APIs are implemented often is poor, lacking, and outright bad. Specifically the abundance of singletons and lack of interfaces (protocols), for things like UserDefaults, URLSession, FileManager, NotificationCenter, etc., makes it very inconvenient to work with them. You constantly would have to wrap around them with your own custom wrappers that have interfaces (protocols) to actually be able to properly inject and mock them.

And don’t even get me started on singletons… it’s just an anti-pattern to have those in the first place!

My wish is for Apple to be better architects of their frameworks’ public APIs and adhere more to SOLID principles.

Protected Keyword In Swift

This one also has been a long time pet peeve of mine - the lack of protected keyword/concept in Swift. In every other normal OOP language there is a concept of a protected method or property that indicates that it’s designated for subclasses only and is available to them to call or override. Protected methods or properties are not available publicly otherwise.

Kotlin has it. Java has it. Ruby has it. Typescript has it. C# has it. PHP has it. What is wrong with you Swift!?!?!?!?

I know I know what you’re going to say! “But Alex, it was explicitly decided for Swift not to have protected keyword”. Well, I don’t care, it was a bad choice and there is no excuse for it.

Over time all major general purpose languages, as they add features, coalless on the same set of features and become alike. It’s inevitable as there are only so many good ideas for features in a programming language and they constantly “borrow” and copy each other.

So Swift, get on with the times and add the darn protected keyword, will you!

Conclusion

These are some of the "wishes" on my list that come to mind. We'll see what Apple has in store for us this WWDC. I am not holding my breath for the additions I listed, but then again...

The main way you use and create AsyncStreams is via the Continuation API:

func generateNumbersWithContinuation() -> AsyncStream<Int> {
    AsyncStream { continuation in
        
        continuation.onTermination = { termination in
            // do the cleanup here
        }
        
        Task {
            for i in 1...5 {
                try await Task.sleep(nanoseconds: 500_000_000)
                continuation.yield(i)
            }
            continuation.finish()
        }
    }
}

// run it with
Task {
    for await number in generateNumbersWithContinuation() {
        print(number)
    }
}

Here, we create an AsyncStream that emits new values over time asynchronously and calls finish when it’s done. We also set up the onTermination callback block to do the cleanup of any underlying resources that were producing the values asynchronously to be emitted from the stream.

Conceptually, pretty much literally, this is an RxSwift Observable:

private let disposeBag = DisposeBag()


func generateNumbersWithObservable() -> Observable<Int> {
        return Observable.create { observer in
            
            for i in 1...5 {
                Thread.sleep(forTimeInterval: 0.5)
                observer.onNext(i)
            }
            observer.onCompleted()
            
            return Disposables.create {
                // do the cleanup here
            }
        }
        .subscribe(on: ConcurrentDispatchQueueScheduler(qos: .userInitiated))
}

// run it with
generateNumbersWithObservable().subscribe(onNext: { number in
        print(number)
}).disposed(by: disposeBag)

Here, we do literally the same thing, we have an Observable that emits values over time asynchronously and calls onCompleted when it’s done. We set up a cleanup block with Disposables.create to do the cleanup of any underlying resources that were producing the values asynchronously to be emitted from the observable.

Congratulations Apple, you reinvented the wheel! Ghmm… but I digress.

This is not unexpected since the concept of reactive streams is very good, so it’s natural for Apple to steal/get inspired by it.

…but where Apple didn’t go far enough is to make async/await functions mimic, and be similarly implemented to, RxSwift Singles.

Conceptually, async operations, regardless of what language and framework you use to implement them, are blocks of code/work, jobs that need to be executed asynchronously, that have the main block of work/setup plus a cleanup part to wind down if the operation was cancelled or finished.

When we look at the AsyncStream and Observable examples above (albeit, very simplified), we see that in action - there is a main chunk of code for the main action and then there is a cleanup block to wind down the operations.

The difference from async/await is that it assumes that there will be multiple results produced. With async/await, typically, there is one result produced at the end of the operation (or no result but you can mimic it with Void with both AsyncStream and Observable).

func generateANumbersWithAsyncAwait() async -> Int {
    try? await Task.sleep(nanoseconds: 500_000_000)
    return Int.random(in: 1...5)
}

// run it with
Task {
    let result = await generateANumbersWithAsyncAwait()
    print(result)
}

Above is an example of an async/await function. It has the main block of code to perform the work, but where is the cleanup to wind down the operation? It’s not there. The only thing you can do is to check on a procedural flag with Task.isCancelled or Task.checkCancellation(). The problem with it is that most of the time developers will simply forget to do it.

Now, if only Apple would implement async/await functions similarly to AsyncStream so that they have an onTermination callback to implement the cleanup…. Oh wait, if they did that they would essentially reimplement/reinvent the Single from RxSwift!!!

Singles in RxSwift are Observables made for one purpose, to produce one value asynchronously. Since they are observables in nature they have the same traits such as Disposables.create callback block to properly cleanup after the operation is done or cancelled:

private let disposeBag = DisposeBag()

func generateNumbersWithSingle() -> Single<Int> {
        return Single.create { observer in
            
            Thread.sleep(forTimeInterval: 0.5)
            observer(.success(Int.random(in: 1...5)))
            
            return Disposables.create {
                // do the cleanup here
            }
        }
        .subscribe(on: ConcurrentDispatchQueueScheduler(qos: .userInitiated))
}

// run with
generateNumbersWithSingle().subscribe(onSuccess: { number in
            print(number)
}).disposed(by: disposeBag)

Here, just like with Observable or AsyncStream, you have an explicit dedicated block for cleanup of the asynchronous operation.

If only async/await was like that! (sigh…) but unfortunately it remains the “AsyncStream that never was”... Apple should’ve just stole/reimplemented the Rx Single…

Over the years I’ve been exploring and experimenting with different async solutions on iOS. Things like Threads, Grand Central Dispatch (GCD), NSOperations and NSOperationQueues, Futures, Promises, etc. Ultimately, I came to the conclusion that the best way to solve asynchronicity on iOS is by using ReactiveX streams and observables to model it.

But more recently, with the introduction of Swift 5.5 in 2021, Swift Concurrency promised to solve the asynchronicity problem by providing async/await, actors, and other features.

By the time it came out, I was all in on Rx, but also learned that it’s not a silver bullet for every problem and that it shouldn’t be used everywhere in every layer of your application. To achieve the best results for the effort you put in and to reduce the number of potential errors you should NOT use Rx Observables and Streams in the UI layer of your application. Everywhere else it’s fair game - business logic, networking layer, service layer, etc.

So effectively, the asynchronicity problem was solved for me. Rx has a steep learning curve but if you apply it and use it with discipline you won’t have any problems.

And then comes async/await that’s claimed to be the best at asynchronicity. Well, I examined it more thoroughly as I conducted my research on the Async chapter of The iOS Interview Guide 2.0 and it has its pros and cons, but still Rx would solve all of these problems even before for me. This is how it stacks up:

• async functions to model asynchronous operations - already had that with Single and Observable in Rx

• Sequential execution with await and parallel execution of async operations with async let - yep, already had that with higher order functions such as flatMap, concat, zip, combineLatest, merge, etc.

• State management with actor - yea, had that, with Subject, BehaviorRelay, etc. There are more advanced compile time controls and safety that comes with Swift Concurrency though, more on that later.

• Error handling with do/try/catch/async throw - we had that with onError callback, catchError, retry, etc. That said, error handling might be a bit easier in some scenarios with Swift Concurrency vs RxSwift

• Operation cancellation and cleanup with Task/isCancelled - RxSwift has a more robust clean way of doing it with subscribe, Disposable, and DisposeBag. More on that later.

• UI data binding with ObservableObject - Rx has it via Driver but as I mentioned above this is a mute point for me since I prefer not to have any data bindings and reactivity in my UI layer.

• Completely absent feature in Swift Concurrency - Scheduler. It’s a powerful feature of RxSwfit that allows you to control the execution context of observables with the async operation block’s or its callback. More on that below.

As you can already see from this short list - almost everything Swift Concurrency offers RxSwift provides plus more. Let’s take a look at those exceptions or specific things that need clarification.

State Management with Actor vs Subject/BehaviorReplay

Overall, there is nothing that you can do with Actor that you can’t do with RxSwift’s Subject using observeOn, subscribeOn, and serialize. But there is one clear advantage that Swift Concurrency has here - built-in compiler time checks for data isolation. Swift Concurrency also has Sendable and other tools for data isolation and thread safety.

In reality though, for over 15 years of me building iOS applications, I have never ever encountered a situation where data access over different threads was a problem. Usually, if you’d get to that point and start having issues with thread data access, race conditions, etc., it’s a symptom of a larger architectural problem rather than an “async problem to solve”.

Ask yourself - why do you have threading data access issues in the first place? Is there an improperly architected singleton in your app that everyone is trying to access and read/write data from/to? Most likely there is. You shouldn’t be using singletons in the first place, they are an antipattern. Just purge them and re-architect your data access and this will solve your problem, not an actor bandaid from Apple.

RxSwift wins here in my books because it gives you way more flexibility but I have to admit - it loses on the compile time checks, it’s better to have a compiler help you than not.

Error Handling in Swift Concurrency vs RxSwift

Here it might be closer to a tie. On one hand, RxSwift’s errors are thrown for the entire chain/stream in just one callback block at the tail end of the stream when you call it which makes it hard to debug. On the other hand, RxSwift has a lot of different catch and retry methods that could help you make the error behavior more sophisticated.

Swift Concurrency though has a more straightforward approach by using try/do/catch blocks. That’s a win for Swift Concurrency here.

Operation Cancellation and Cleanup

Swift Concurrency is just weird if not outright lazy here. After you call cancel() on a Task, which is similar to Disposable’s cancel() method, you are then supposed to constantly check Task.isCancelled or try Task.checkCancellation() to make sure your async operation doesn’t perform wasteful work after it was cancelled.

Ummmm… do what now? What is this primitive stateful procedure programming? Are we back in college, hacking together a god-user-object where all the state lives and we need to flip all sorts of states and flags on it to achieve everything in our codebase and ultimately drown in a sea of state related bugs?

This is just lazy and unprofessional on Apple’s part - this is not how modern software should be built. Most developers will forget to check the flag and won’t clean up resources causing subtle bugs and wasteful performance.

This is where RxSwift wins over Apple’s stuff hands down - every Observable has a dispose callback block that will be executed whenever the async operation is cancelled. This is where you would do proper cleanup of resources scoped to just your observable specifically. Nice, efficient, clean and tidy.

RxSwift’s Scheduler

This is another area where Rx wins hands down. The level of control and sophistication of it using Scheduler is untouched by Swift Concurrency - it doesn’t even have such a concept.

With the Scheduler, you can schedule operations to perform on the main thread, background thread, and schedule the call back when it emits values to perform on various threads as well. Even more, you can model the time itself in tests by using TestScheduler which allows you to run synchronous unit-tests that mock time ticks mimicking asynchronicity. Hands down a winner there!

Yes yes, I know what you’d say - “but Alex, you can use @MainActor and the await MainActor.run and other things like that!”. Yes, you can… but as I said above, they have nowhere near the sophistication you can achieve with the Scheduler.

Conclusion

At this point, I’m not ready to completely switch to Swift Concurrency and use async/await everywhere in my code, because RxSwift just provides so much more power and sophistication to solve async tasks. But at the same time, async/await has its merits too, for simpler linear operations such as network requests, for example. Plus, it has an easier learning curve than RxSwift.

RxSwift requires you to exercise discipline because it quickly can get out of control, but it gives you a lot of power. With Swift Concurrency you can be a bit more lax.

At the end of the day I use both, luckily RxSwift has several niceties and extensions to interoperate with Swift Concurrency and map async operations or streams to observables and singles and vice versa.

P.S. If you liked this content please share it, it helps spread the word about this substack! Also, I’m working on the 2nd edition of The iOS Interview Guide, topics like this will be covered in the Async Work chapter of the book. Subscribe if you want to hear more updates about my book’s progress.

Share