Navigating Apple's Evolving Concurrency Models: A Comparative Exploration

As developers, we've all experienced the excitement—and sometimes frustration—of working in the Apple ecosystem. Apple's commitment to innovation often means we're introduced to new tools and paradigms, each promising to make our code safer, more performant and efficient, and maintainable. But with these advancements comes the challenge of adapting to change, especially when it comes to concurrency and asynchronicity.

In recent years, Apple has taken us on a journey from Operation Queues to Grand Central Dispatch (GCD), to Combine, and now to Swift Concurrency with async/await. Each iteration has brought new ways to think about and manage asynchronous tasks, but it has also required us to revisit and, in many cases, rewrite significant portions of our codebases.

To explore these changes and their implications, I created two versions of a simple app: one using Swift Concurrency and the other using RxSwift. You can check out these projects here:

• Dessertly (Swift Concurrency): https://github.com/scotteg/Dessertly
• Dessertly-RxSwift: https://github.com/scotteg/Dessertly-RxSwift

The Evolution of Concurrency in iOS

Since the early days of iOS, concurrency and asynchronous programming have evolved significantly:

• Delegate Pattern: One of the earliest strategies for managing asynchronous events in iOS. The delegate pattern relies on defining protocols and assigning delegate objects that respond to specific events, such as data being loaded or an operation completing.
• Operation Queues: Introduced as a robust system for handling tasks concurrently, NSOperation and NSOperationQueue allowed developers to manage dependencies, priorities, and cancellations among various tasks, making it easier to control the execution flow.
• Grand Central Dispatch (GCD): Debuting with iOS 4, GCD offered a higher-level API for efficiently managing concurrent tasks, leveraging multicore processing by allowing developers to dispatch tasks to different queues with ease.
• Completion Handlers: Widely used in early iOS development for managing asynchronous tasks, completion handlers were implemented using blocks. While blocks provided powerful capabilities, their syntax in Objective-C was notoriously complex, leading to resources like this to help developers understand and use them correctly. This complexity foreshadowed Swift’s more streamlined and intuitive approach to closures, which fully embraced modern programming paradigms.
• Reactive Programming (RxSwift, ReactiveSwift): The introduction of reactive programming libraries brought a paradigm shift, enabling developers to handle asynchronous events declaratively with observables and operators.
• Combine: Apple’s answer to reactive programming, introduced with iOS 13, brought a native reactive framework but ultimately fell short of reaching full parity with RxSwift before Apple shifted focus to Swift Concurrency.
• Swift Concurrency: The latest evolution, introduced with iOS 15, brought async/await and structured concurrency, simplifying asynchronous code by making it look more like synchronous code.

Performance, Maintainability, and Extensibility: The Showdown

Performance

• Swift Concurrency: As a native language feature, Swift Concurrency is optimized for Swift, offering lower overhead and better performance, especially in terms of thread management. It’s designed to handle many lightweight tasks efficiently, making it an attractive choice for performance-critical applications.
• RxSwift: While RxSwift is highly optimized for reactive programming, the need to manage observables and subscriptions can introduce overhead. However, in scenarios requiring high throughput, such as handling a large number of asynchronous events, RxSwift’s performance can shine.

Maintainability

• Swift Concurrency: The simplicity of async/await leads to more readable and maintainable code. Its integration with existing Swift error handling mechanisms makes it a natural fit for modern Swift codebases, reducing boilerplate and making code easier to understand.
• RxSwift: Although powerful, RxSwift introduces complexity due to its reactive nature. Long chains of operators can be difficult to debug and maintain, requiring developers to have a deep understanding of reactive programming concepts.

Extensibility

• Swift Concurrency: As the latest approach recommended by Apple, Swift Concurrency is likely to receive continued support and enhancements, making it a future-proof choice for new projects. Its seamless integration with Swift and other Apple frameworks makes it easier to extend applications with new features.
• RxSwift: RxSwift's strength lies in its composability and the rich ecosystem of libraries that support it. This makes it easier to extend functionality within the reactive paradigm, whether you're working on iOS or other platforms.

Cross-Platform Collaboration: A Key Advantage of RxSwift

One of the standout benefits of RxSwift is its role within the larger ReactiveX ecosystem. While Swift Concurrency offers a modern and efficient approach to handling asynchronous tasks, it remains largely unique to the Swift language. It does share some conceptual similarities with concurrency models in other languages, like JavaScript and C#, but it is still a distinct and Swift-centric solution.

In contrast, RxSwift is part of a broader ecosystem that includes RxKotlin, RxJS, and other ReactiveX implementations across different tech stacks. This shared foundation allows developers to work seamlessly across platforms, leveraging similar patterns and methodologies regardless of the language or framework.

For example, when I developed the Datadog app using RxSwift, I was able to collaborate more effectively with the Android team because they used RxKotlin. This alignment enabled us to better troubleshoot issues together and ensure feature parity across platforms. In multi-platform environments, this level of consistency is a significant advantage, as a common reactive paradigm simplifies both collaboration and problem-solving.

RxSwift: A Pillar of Stability Amid Change

One of the most compelling arguments for using RxSwift is its stability. While Apple has rapidly evolved its concurrency models, RxSwift has provided a consistent and reliable approach to managing asynchronous tasks. If you had chosen RxSwift years ago, you might have avoided the need for extensive refactoring that has accompanied each of Apple’s new concurrency paradigms.

My Journey with RxSwift and Combine

I was deeply involved in bringing RxSwift to the community, and I’ve always been an advocate for its reactive and declarative programming approach. When Apple introduced Combine, I was thrilled by the possibilities. The integration with the Apple ecosystem promised to bring reactive programming to the forefront of iOS development. However, my excitement was short-lived. Apple’s decision to shift focus from Combine to Swift Concurrency, without ever bringing Combine to full parity with RxSwift, was disappointing. This shift left many developers, including myself, who favored reactive programming, in a difficult position. We were excited about the promise of Combine, only to be left in a lurch as development seemed to stagnate.

Reflecting on a Missed Opportunity: RxDevCon

Another aspect of my journey with RxSwift was planning an RxDevCon conference. The goal was to bring the entire reactive community together, bridging the gaps across platforms and fostering deeper collaboration. There was strong interest from speakers and attendees alike, and I was excited about the potential impact this event could have on the adoption and growth of RxSwift in mobile development. Unfortunately, due to personal circumstances, I had to postpone the event, and it never materialized. I often wonder what difference it might have made in further solidifying RxSwift’s role in the mobile development ecosystem.

Swift 6 and the Road Ahead

With Swift 6 on the horizon, promising strict concurrency checking, the choice between adopting Apple’s latest tools and sticking with RxSwift becomes even more critical. Swift 6’s concurrency model, while powerful, will likely require substantial changes to existing codebases, particularly to address potential race conditions that the compiler may flag—even if they are unlikely to occur in production.

In an environment where Apple is continuously refining its tools, there’s something to be said for the stability and consistency offered by RxSwift. It allows developers to sidestep the frequent changes in Apple’s native concurrency strategies, providing a solid foundation that has stood the test of time.

Conclusion

Ultimately, the decision between Swift Concurrency and RxSwift depends on your project’s needs. If you prioritize stability and avoiding constant rewrites, RxSwift may still be the better option. But if you’re looking to harness the latest advancements and optimizations in Swift, embracing Swift Concurrency might be the way to go.

I invite you to explore the two versions of my project and consider how each approach might fit into your development strategy. Whether you’re adapting to Apple’s latest changes or sticking with a proven solution like RxSwift, understanding the trade-offs is key to making the right choice for your team and your codebase.

What do you think? Have you faced similar challenges? How have you navigated Apple’s concurrency models? Let me know in the comments or connect with me, and let’s talk!

#iOS #iOSDev #Swift #SwiftUI #RxSwift #SwiftConcurrency