Performance

Swift Academy Podcast, Episode 2, Season 3 Performance Is More Than Just Speed Part two with Artem Mirzabekian and Bogdan Poplauschi, going underneath the abstractions: Swift Concurrency migration, the cost of the tools we use daily, and why application launch is an architecture problem. August 23, 2026 🎧 Swift Academy Podcast · Episode 2, Season 3 • Part 2 of 2 · Concurrency • Abstraction • App Launch Watch the Episode The Hidden Cost of the Tools We Use Daily Part one challenged the myths. This one goes underneath them, into Swift Concurrency, abstractions, architecture, application launch, frameworks and dependencies. The connecting idea is that performance work rarely starts with performance. Migrating an existing codebase to Swift Concurrency tends to expose architectural weaknesses that were always there, and a dependency graph that grew quietly for two years turns into a launch time nobody can explain. What We Go Through Migrating an existing codebase to Swift Concurrency The migration is where most teams meet the model properly for the first time, and where the wrong mental model gets expensive. Migration pitfalls, and the mental models that cause them What async/await really means for execution, as opposed to what people assume Common Swift Concurrency anti-patterns that survive a migration The impact of @MainActor on CPU-heavy work When Task.detached becomes a problem rather than a solution Why blocking asynchronous work leads to deadlocks How adopting concurrency exposes architectural weaknesses that predate it Abstraction versus performance Abstraction makes code easier to read, test and maintain. It also hides what the application is actually doing, and at some point that stops being a good trade. Balancing clarity, maintainability, abstraction and performance rather than picking one Why understanding what sits underneath an abstraction is part of using it well Where protocols help the architecture and where they quietly cost something Application launch and the dependency graph Why a complex dependency graph slows down launch, and how that happens gradually The hidden cost of frameworks and of the tools used every day Treating launch time as an architectural property rather than a metric to optimise at the end About the Guests Artem Mirzabekian & Bogdan Poplauschi Lead iOS Engineer at Sovcombank • Staff Engineer, iOS Architecture & CI/CD Artem co-hosts the Mobile System Design Interview series. Bogdan appeared twice in Season 1, on taming legacy code and on refactoring in practice, and both reviewed AI Driven Swift Architecture. Key Takeaways A concurrency migration is an architecture review in disguise. The warnings you cannot silence are usually pointing at a real design problem. @MainActor is not a safety blanket. Putting CPU-heavy work behind it moves the cost onto the frame budget. Task.detached is rarely the answer. Reach for it deliberately, not to make a warning disappear. Abstractions have a price. Use them, but know what they are doing underneath before they become the bottleneck. Launch time is architectural. A dependency graph that grew unchecked cannot be optimised away at the end. Resources & Links 🎥 Season 3 Episode 2, Watch on YouTube 🎧 Part 1, Modern iOS Performance Myths 🧵 Swift Concurrency Explained with Matt Massicotte Listen & Subscribe If your team is midway through a Swift 6 migration and the warnings are multiplying, this pair of episodes is the one to share. 🎥 Watch on YouTube 🎧 Listen on Apple Podcasts ☕ Support the Podcast

Swift Academy Podcast, Episode 1, Season 3 Modern iOS Performance Myths Season 3 opens with a two-part conversation on performance, with Artem Mirzabekian and Bogdan Poplauschi. Part one is about the dogmas: what a fast app actually is, and why so many of them still feel slow. July 5, 2026 🎧 Swift Academy Podcast · Episode 1, Season 3 • Part 1 of 2 · Performance • SwiftUI • Concurrency Watch the Episode Fast Is Not the Same as Feeling Fast An application can be technically fast and still feel slow. That gap, between what a benchmark measures and what a user perceives, is where this episode spends most of its time. This is not a conversation about micro-optimisations or benchmark numbers. Artem and Bogdan have both spent years on high-performance iOS applications in production, and the discussion is about what actually happens under the hood once an app grows past the size where intuition still works. Several popular beliefs get challenged along the way, including a few that have hardened into dogma since SwiftUI arrived. The Myths We Take Apart Did SwiftUI simplify performance, or hide its cost? The framework removed a great deal of boilerplate. Whether it removed the underlying cost, or simply moved it somewhere harder to see, is the more interesting question. Which SwiftUI patterns turn dangerous once an application scales Is Environment quietly becoming the new Service Locator? When SwiftUI diffing stops being free and becomes a real bottleneck What actually consumes the 16.67 ms frame budget Is UIKit deprecated? Short answer in the episode, and it is not the one the discourse suggests. The longer answer is about where each framework still earns its place. Investigating what Instruments will not tell you How experienced engineers approach a performance problem the profiler does not immediately explain Concurrency versus parallelism, and why the confusion between the two produces bad fixes What a “performant” iOS app means in 2026, stated plainly About the Guests Artem Mirzabekian & Bogdan Poplauschi Lead iOS Engineer at Sovcombank • Staff Engineer, iOS Architecture & CI/CD Both are recognised in the Apple community for their technical depth and their years building high-performance iOS applications. Artem also co-hosts the Mobile System Design Interview series on this podcast; Bogdan appeared twice in Season 1 on refactoring and legacy code. Key Takeaways Perceived speed is the metric that matters. Users do not experience your benchmark, they experience the frame that arrived late. SwiftUI moved the cost, it did not remove it. The patterns that feel harmless in a small app are the ones that hurt at scale. Watch the 16.67 ms budget. Knowing what consumes it is more useful than any single optimisation technique. Concurrency is not parallelism. Confusing them leads to fixes that add complexity without adding speed. Instruments is a starting point, not an answer. The hard problems require a mental model of what the framework is doing beneath the abstraction. Resources & Links 🎥 Season 3 Episode 1, Watch on YouTube 🎧 Part 2, Performance is more than just speed 🧩 Mobile System Design Interview, with Artem Listen & Subscribe Part two goes underneath the abstractions, into Swift Concurrency migration, application launch and dependency graphs. 🎥 Watch on YouTube 🎧 Listen on Apple Podcasts ☕ Support the Podcast