SwiftUI

Swift Academy Podcast · Series A mock-interview series with Artem Mirzabekian, Lead iOS Engineer. Real mobile system design problems, solved out loud the way a senior interview actually runs, with the roles swapping between episodes. Two episodes published. 🎧 Swift Academy Podcast · Series · 2 episodes · Requirements • APIs • Domain • Architecture “Most system design conversations stop at the box diagram. The interesting part starts after: what happens when the cursor is stale, the receipt URL has expired, and the user is on a train with no signal.” The premise of this series What This Series Is Mobile system design is usually taught as a whiteboard ritual, or reduced to an argument about architectural acronyms. This series does the opposite. Each episode takes one realistic feature and designs it properly, out loud, with the trade-offs left visible instead of tidied away. Episode 1 tackles an e-commerce home page; episode 2, broken down below, tackles the transaction history of a banking app. The feature is deliberately unglamorous and deliberately hard. A transaction list looks trivial until you hold it to production standards: thousands of records, a server that keeps changing beneath you, a search field, filters, receipts behind expiring URLs, and a security team with a firm opinion about what may be written to disk. Every decision in it has a cost, and the point of the series is to name that cost rather than hide it. Inside Episode 2: Designing a Transaction History Paging Through a List That Will Not Sit Still Offset pagination breaks the moment records are inserted while the user scrolls: rows repeat, rows vanish, and nobody notices until it reaches production. Cursor-based pagination is the answer, and the design work is in the details around it. Why offset paging is unsafe against a mutating dataset, and what the user actually sees when it fails Cursor design: opaque tokens, stability guarantees, and what to do when the server invalidates one mid-scroll Prefetch thresholds, in-flight request de-duplication, and cancelling work the user has scrolled past Where the cursor lives, and why it does not belong in the view Search and Filter Without Fighting the Pagination Search and filters are where a clean pagination design usually falls apart, because each one produces a different result set with its own cursor and its own lifecycle. Server-side versus client-side filtering, and the point where the dataset makes the choice for you Debouncing, cancellation, and keeping the visible list coherent while a query is in flight Composing filters, date ranges, categories, amounts, without a combinatorial explosion of endpoints Resetting or preserving scroll position when the query changes States and Freshness “Loading, loaded, error” is not a state model, it is a placeholder for one. Real screens are simultaneously stale, refreshing, partially loaded, and partially failed. Modelling loading, empty, partial, stale, refreshing and failed as a type the compiler can check Distinguishing an empty list from a list that has not loaded, the single most common bug in this feature Freshness policy: what to show immediately from cache, what to revalidate, and what to block on Error recovery that does not discard the data the user is already reading The Offline Versus Security Debate This is the part of the series with no clean answer, which is exactly why it is worth recording. Offline access argues for caching transactions on device. The security posture of a banking app argues against writing financial history to disk at all. The real threat model: device theft, backups, jailbreak, shared devices, and what each one actually exposes What a partial answer looks like, caching metadata but not amounts, or encrypting with a key held in the Secure Enclave Cache lifetime tied to session lifetime, and what must be destroyed at logout Why this decision belongs to the product and the security team, and what the architecture must do to keep it reversible Expiring Receipt URLs Receipts are served behind short-lived signed URLs. That single constraint reaches surprisingly far into the design. Why a signed URL must never be persisted, and what to persist instead Fetching the URL lazily at the moment of use, and handling expiry between tap and load Retry and re-signing flows that do not strand the user on a broken screen What this implies for share sheets, deep links, and anything that outlives the session SwiftUI, UIKit, and the Layers Underneath The UI framework is the least interesting decision on this list, and the one people argue about most. We treat it as an implementation detail and spend the time on the layering that survives either choice. Where SwiftUI is a clear win for this screen, and where UIKit still holds an advantage on large lists Interoperating deliberately rather than accidentally, and keeping the boundary in one place ViewModel, Presenter, Service, UseCase: what each layer owns, and the concrete test you apply to decide where a piece of logic belongs Keeping the pagination, freshness and caching policy testable without a running UI What This Series Deliberately Avoids No MVVM versus VIPER debate. It is a distraction from system design. We talk about responsibilities and boundaries; name the resulting pattern whatever your team already calls it. No whiteboard theatre. Every decision is tied to a failure mode you can actually observe in a shipped app. No single right answer. Where the trade-off is genuine, it is left as a trade-off, with the cost of each side stated plainly. About the Guest Artem Mirzabekian Lead iOS Engineer at Sovcombank • 10+ years scaling mobile platforms Artem leads iOS engineering at Sovcombank, where transaction history is not a hypothetical exercise but a screen used by millions of customers under real regulatory and security constraints. His work spans iOS architecture, Swift, SwiftUI, system design and technical leadership, with a decade of experience scaling mobile platforms and the teams that build them. Watch the Series Episode 1, Designing an E-Commerce Home Page The opening episode takes one of the most common mobile engineering scenarios and runs it as a real interview: clarifying requirements, defining the APIs and data models, and arriving at an architecture that scales. Artem published a companion repository with a working implementation of the ideas discussed, typed backend-driven sections, defensive DTO mapping, cache-first loading, visibility-based analytics, optimistic add-to-cart, and an image pipeline with downsampling and request de-duplication. 🎥 Watch episode 1 · 95 min 📦 Companion repository Episode 2, Designing a Banking Transactions Screen The second episode swaps the roles: this time Walid is the candidate and Artem the interviewer. It is the session the breakdown below is drawn from, working through the transaction history of a mobile banking application from requirements to architecture. 🎥 Watch episode 2 🎬 Full playlist on YouTube 🎧 Follow on Apple Podcasts Go Deeper: AI-Driven Swift Architecture The layering this series relies on, use cases, services, and the boundaries that keep a feature testable, is the subject of the book. If the sessions leave you wanting the full treatment of Clean Architecture, TDD and modular Swift on production codebases, that is where to continue. 📘 Read about the book

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

Swift Academy Podcast, Episode 11, Season 2 MLX Swift & On-Device AI Adrien Grondin, iOS developer at LM Studio and creator of Locally AI, on why Apple Silicon changes the economics of running language models locally, and where that stops being true. May 17, 2026 🎧 Swift Academy Podcast · Episode 11, Season 2 · MLX Swift • Local LLMs • Apple Silicon Watch the Episode Why This One Matters Most teams shipping AI features today send everything to a cloud API. That works until you look at the bill, the latency, or the privacy review. Meanwhile Apple has been quietly building the other path: a framework designed from the start for unified memory on Apple Silicon. Adrien Grondin is unusually well placed to talk about it. He works on LM Studio and built Locally AI, so he spends his days with models running on hardware people actually own. This conversation is about what that is really like once you leave the demo behind. Where MLX Fits Not Core ML, and not Foundation Models Three Apple-adjacent ways to run a model on device, three different jobs. The distinctions matter the moment you have to pick one. How MLX differs from Core ML, and why the difference is about who owns the training and conversion pipeline Where Apple Foundation Models stop and MLX starts Which model families MLX actually supports, Mistral, Qwen and Gemma among them Fine-tuning with MLX, and when it is worth the trouble The limits nobody puts in the demo The honest part of the episode. Running a model locally is a set of trade-offs, not a free win. Memory constraints on Apple Silicon, and what unified memory buys you GPU usage, battery consumption, and what sustained inference costs a phone Real latency on real devices, not on a plugged-in Mac Studio Device compatibility, and where the floor currently sits Building something with it The practical half: what it takes to put MLX behind a SwiftUI app today. Streaming responses and how inference behaves in a real UI Tool calling with MLX, and what that unlocks Pulling models from Hugging Face, and where quantization fits Why small language models may matter more than the frontier ones for shipping apps About the Guest Adrien Grondin iOS Developer at LM Studio • Creator of Locally AI Adrien moved from traditional iOS development into AI engineering, and now works on LM Studio while maintaining Locally AI. His view, argued in this episode, is that on-device AI is not a passing trend but the direction the Apple platform is heading, and that the developers who understand the constraints early will build the better products. Key Takeaways MLX is not a Core ML replacement. It is a different tool for a different job. Choose based on who owns the model pipeline, not on which is newer. Unified memory is the reason this works at all. Apple Silicon removes the copy between CPU and GPU memory, which is what makes local inference practical on a phone. Memory is the real ceiling, not compute. Model size and quantization decide what ships, long before performance does. Small language models deserve more attention. For most app features, a well-chosen SLM running locally beats a frontier model behind a network call. Test on device, early. Latency and battery behaviour on a real iPhone bear little relation to what you see on a Mac. Resources & Links 🎥 Episode 11, Watch on YouTube 💻 LM Studio 📦 MLX Swift on GitHub 📝 Running an on-device LLM with MLX Swift Listen & Subscribe If you are weighing on-device inference against a cloud API for your next feature, share this with whoever owns that decision. 🎥 Watch on YouTube 🎧 Listen on Apple Podcasts ☕ Support the Podcast

Swift Academy Podcast, Episode 10, Season 2 Beyond the Prompt: Foundation Models as an Architectural Layer in iOS Mohammad Azam on why Apple’s on-device LLM is less an AI feature and more a redefinition of where intelligence lives in your app, @Generable, @Guide, instructions, tools, and adapter-based fine-tuning, viewed through the lens of iOS layered architecture. May 3, 2026 🎧 Swift Academy Podcast · Episode 10, Season 2 · Foundation Models • On-Device LLM • iOS Architecture “Foundation Models is not a chat surface. It is a typed, on-device, structured capability you wire into your architecture, the way you wire in URLSession or SwiftData. Treat it like a chatbot and you will build bad apps. Treat it like a layer and you will build defensible ones.” Editorial framing of the conversation with Mohammad Azam Watch the Episode About This Episode Mohammad Azam has been writing iOS code since Objective-C 3.2 in 2010. Since then he has led mobile teams, shipped multiple App Store apps, taught iOS bootcamps, and, for the last several years, split his time between Swift and a Python/AI bootcamp. That dual perspective matters. When Apple introduced the Foundation Models framework, Azam was not reacting as someone discovering LLMs; he was reacting as someone who had already built CreateML pipelines, trained models in scikit-learn, and exported them through CoreML tools. The headline of this episode is not that Apple shipped an LLM. It is that Apple shipped an architectural primitive. Foundation Models is not a chat product; it is a typed, on-device, deterministic-ish capability that you wire into your app the way you wire in URLSession or SwiftData. This conversation reframes the framework from that altitude: where on-device intelligence belongs in a layered iOS architecture, why instructions outweigh prompts, how @Generable turns probabilistic text into typed Swift, and what adapter-based fine-tuning means for long-lived products. 📖 The themes of this episode are covered in depth in Chapter 6 of AI-Driven Swift Architecture, which is dedicated to designing production-grade integrations of Apple’s Foundation Models inside a Clean Architecture iOS codebase. An Architectural Deep-Dive into Apple’s Foundation Models Framework AI Is Not a Feature, It Is a Layer The most common failure mode in the current AI moment is the “Ask AI” button. Azam describes it bluntly: tools that used to work with a single click now demand a prompt. The friction is up, the affordance is down, and the user experience is worse. Forcing an LLM into a workflow that did not need one is a product mistake disguised as a technology investment. Foundation Models pushes back on that framing precisely because it is so cheap to invoke, no API key, no per-token cost, no network call. When the marginal cost approaches zero, the right question stops being “can we add AI?” and becomes where does intelligence belong in our architecture? That shift, from feature to layer, is the real paradigm change. The model becomes a service the domain layer can call when its rules genuinely benefit from inference, not a UI surface bolted onto the side of the app. Understanding Apple’s Foundation Models from a Developer Perspective For an iOS engineer with no LLM background, the framework is best described as a heavily structured subset of ChatGPT, running entirely on the Neural Engine, addressable through Swift. There is no inference server, no token billing, no conversation history leaving the device. The model is small, a few billion parameters at best, and ships with the OS. That single sentence contains the entire trade-off matrix: Privacy and offline come for free. Health data, journal entries, and personal contracts never leave the phone. Latency is dominated by the Neural Engine, not by network round-trips, which makes streaming UI viable for most prompts. The capability ceiling is real. The model has no knowledge of last week’s events, will not answer broad world-knowledge questions reliably, and is not competitive with frontier cloud LLMs for open-ended reasoning. Hardware gating is a constraint you must design around. Pre–iPhone 15 Pro devices will not run it at all, so any feature that depends on it needs an explicit non-AI fallback path. Azam’s expectation, which mirrors where the platform is clearly heading, is that the on-device model will eventually be paired with an Apple-hosted private inference tier, a hybrid where the device tries first and escalates only when needed. Architect today for that future: do not let “Foundation Models is here” become “Foundation Models is everywhere in our codebase.” Tools, Instructions, and Determinism: The Real Surface Area of the Framework The part of the framework that deserves the most architectural attention is the one developers tend to skip past: @Generable, @Guide, and instructions. Structured generation is the contract. A @Generable struct is not a convenience, it is the boundary between non-deterministic text generation and deterministic Swift code. The model is constrained to populate the schema; your app receives a typed value. @Guide tightens that contract per-property: a numeric range, a description, a constraint. Done well, the model becomes a function with a typed return value rather than a string firehose you have to parse. Instructions are system design, not prompts. Azam is emphatic on this point: instructions matter more than the prompt itself. The prompt is the request; the instructions define the agent, its role, its tone, its decision boundaries, when it should reach for tools, when it should refuse. In a layered architecture, instructions belong with the service that owns the capability, versioned alongside the schema. Treat them as configuration of a domain service, not as ad-hoc strings near the call site. Tools are controlled escape hatches. A tool is a Swift type the model can invoke, a weather lookup, a database query, an HTTP client. Conceptually it is the same idea as MCP, scoped to a single app: a typed interface that lets the model reach beyond its training data without losing the structured-output guarantee. The interesting design decision is not whether to expose a tool; it is how narrowly to scope it. Azam’s recipe-app example is instructive: a tool that fires only when rice is among the ingredients, deferring to a curated rice-dish API rather than the model’s general knowledge. That kind of fine-grained gating is where instruction quality and tool design meet. Integrating Foundation Models into iOS Layered Architecture The framework is well-behaved precisely because it does not push itself onto your architecture. It slots into the data and service layer like any other capability. Generables are DTOs. The model is a service. Your domain types remain the source of truth. The boundary that matters is persistence. A @Generable struct cannot wear @Model, it is not a SwiftData entity, and conflating the two is a category error. If a generated recipe needs to survive past the session, your service layer maps the generable into a SwiftData model and persists that. If the output is ephemeral, a one-shot summary, a transient suggestion, a view can consume the generable directly. The rule is the same as with any DTO/entity split: do not let an external schema bleed into your storage layer. This is also why the framework composes cleanly with existing apps. Adding Foundation Models to a Clean-ish architecture does not force a rewrite. It adds a new service implementation. The view models do not change shape; the domain does not learn about Apple Intelligence; the persistence layer keeps owning its types. If introducing the framework is invasive in your codebase, the framework is not the problem, your layering is. Models That Evolve: Adapter-Based Fine-Tuning The piece that gets less airtime than @Generable but matters more for long-lived products is adapters. Apple exposes an adapter-based fine-tuning path: you take the shipped foundation model and train a small delta on your own data, rental agreements, medical claim formats, your particular domain vocabulary. The base model stays Apple’s; the specialization is yours. The architectural implication is significant. Adapters give you a knob between “general-purpose model” and “model that understands my product,” without operating an inference cluster and without your data leaving the device. They also introduce a new kind of artifact in your release pipeline: an adapter is versioned, tested, and shipped alongside your binary. Teams that take Foundation Models seriously will end up with a model-evaluation workflow next to their unit tests, regression suites for generables, golden outputs for instruction changes, drift detection between adapter versions. That is a maturity step many iOS teams have not taken yet. Real-World Patterns from the Episode Strip the demos down to their architectural shape and a small set of reusable patterns emerges: Constrained recommendation. The Yummy recipe demo, Azam’s gardening app, both are the same pattern: user supplies a constrained input set, the model returns a @Generable list scoped by @Guide ranges, the view streams it. Use this whenever the answer space is open-ended but the shape of the answer is fixed. On-device summarization over private data. Health metrics, journal entries, transaction history. Cloud LLMs are non-starters here for compliance reasons; on-device LLMs are not. The pattern: summarize locally, persist the summary, surface in widgets or live activities. Structured matching against a user document. The resume vs. job description example. Two unstructured inputs, one structured diff out. This generalizes to contract review, code review, spec compliance, anywhere the value is in structured comparison rather than free-form prose. Tool-routed inference. The rice-recipe escape hatch. The model handles the general case; a tool handles the specific case where you have authoritative data. Use this whenever your product has curated content the model should not try to reinvent. Glanceable AI on wearables. Live Activities and widgets are a natural fit because Foundation Models’ latency is low and its outputs are short. A run summary, a hydration nudge, a weather-aware recommendation, all viable without ever lighting up the network. The common thread: every good use case has a clear input shape, a clear output schema, and a fallback for devices and contexts where the model cannot run. Vibe Coding, Domain Knowledge, and the Limits of LLM-Generated Architecture The conversation closes on a point that is easy to dismiss as a generic AI critique but is in fact an architectural observation. Azam ships several “vibe-coded” small apps and is candid that he could not point at any line in them and explain it. For single-purpose utilities and throwaway tools, that is acceptable. For anything that lives inside a meaningful domain, finance, healthcare, anything with regulatory weight, it is not. The reason is not that LLMs write bad functions. They write fine functions. The reason is that architecture is not a function-level concern. Where a calculation belongs, how a domain rule should be expressed, what should and should not be coupled, these are decisions that require understanding the business, and understanding the business is precisely what gets skipped when you outsource the code. Use LLMs as an accelerator for the parts you understand; do not let them become the reason you stopped understanding. Resources & Links 🌐 Mohammad Azam, Personal Website (azamsharp.com) 💼 Mohammad Azam, LinkedIn 🎥 Episode 10, Watch on YouTube About the Guest Mohammad Azam Senior iOS Engineer • Educator • Author Mohammad Azam has been working in the Apple ecosystem since 2010, starting with Objective-C and moving through every major shift in the platform since. He has led mobile teams at large organizations, taught iOS, web, and AI/ML bootcamps, and authored extensive course material on Udemy and his own platform on SwiftUI, UIKit, iOS architecture, and most recently Foundation Models. He is the developer behind My Veggie Garden, a gardening app on the App Store that uses Apple’s on-device LLM to recommend plantings based on location, weather, and USDA hardness zone, a concrete example of the architectural patterns discussed in this episode. His perspective on Foundation Models is informed by years of pre-LLM machine-learning work with CreateML, CoreML, scikit-learn, and Pandas, which gives his commentary on the framework an unusually grounded shape. Go Deeper, Chapter 6 of AI-Driven Swift Architecture If the framing of this episode resonates, treating Foundation Models as a typed capability inside a layered architecture rather than as a UI feature, the natural next step is Chapter 6 of AI-Driven Swift Architecture, which is dedicated entirely to Apple’s on-device LLM stack. The chapter takes the patterns discussed here and turns them into production-grade scaffolding: how to design @Generable schemas as service contracts, how to version and test instructions alongside the rest of your domain code, how to scope tool boundaries narrowly, where Foundation Models sits in a Clean Architecture module graph, and how to plan adapter-based fine-tuning as a first-class artifact in your release pipeline. It is the architectural reference companion to the conversation you just watched. The book itself (530 pages, published by Packt, foreword by Jon Reid) covers the broader picture: Swift 6 concurrency, Clean Architecture for iOS, AI-assisted development with Claude Code, MCP integration, and the engineering practices that make AI-augmented Swift codebases maintainable rather than brittle. 📖 Learn More, AI-Driven Swift Architecture 📚 Buy on Packt 🛒 Get It on Amazon Key Takeaways Foundation Models is an architectural layer, not a UI feature. Place it in your service tier, not your views. @Generable is the contract between probabilistic text and typed Swift. Design schemas as carefully as you would design API responses. Instructions outweigh prompts. Version them, test them, treat them as configuration of a service. Tools are how you keep the model from making things up about your domain. Scope them narrowly. Generables are DTOs, not entities. Map to SwiftData explicitly when you need persistence. Plan for hardware gating from day one. A feature that requires Foundation Models needs a non-AI alternate path. Adapters are how the model becomes yours. Treat them as shippable artifacts with their own evaluation pipeline. Do not add AI because it is available. Add it where the architecture genuinely benefits. The Real Shift The shift Apple is making with Foundation Models is quieter than the cloud-LLM narrative but more consequential for the people who build apps. Intelligence becomes a typed, local, composable capability, something you architect with, not something you bolt on. The teams that will get the most out of it are not the ones racing to ship a chat surface; they are the ones rethinking which parts of their domain logic could be expressed as a constrained generation, which workflows could be summarized on-device, where a tool boundary belongs. That is the right altitude for this conversation. Not how do I prompt it? but where does it live in my system? Foundation Models rewards architectural thinking and punishes experimentation-as-strategy. Treat it accordingly. Listen & Subscribe If this episode changed how you think about on-device AI and the place of Foundation Models in iOS architecture, share it with a colleague building in the Apple ecosystem, particularly anyone exploring SwiftUI, layered architecture, or the practical side of Apple Intelligence integration. Subscribe to the Swift Academy podcast for weekly deep-dives into iOS development, Swift engineering, and the craft of building software on Apple platforms. 🎥 Watch on YouTube 🎧 Listen on Apple Podcasts ☕ Support the Podcast

Swift Academy Podcast, Episode 5, Season 2 iOS 26, SwiftUI & Accessibility A conversation with Natalia Panferova, former Apple SwiftUI engineer, author of three essential Swift books, and champion of accessible iOS experiences. 🎧 Swift Academy Podcast · Episode 5, Season 2 · iOS 26 • SwiftUI • Accessibility “Accessibility is not a feature you add at the end. It’s a design principle that shapes every decision you make as an iOS developer.” Natalia Panferova, Co-founder of Nil Coalescing Watch the Episode About This Episode Few people are better positioned to talk about the future of SwiftUI and iOS 26 than Natalia Panferova. A former member of Apple’s SwiftUI team, she brings rare insider perspective to the frameworks that millions of developers use every day. Today, she channels that expertise as co-founder of Nil Coalescing alongside Matthaus Woolard, a studio dedicated to world-class Swift education and tooling. In this episode of the Swift Academy podcast, we explore the sweeping changes arriving with iOS 26: the new Liquid Glass design language, the evolved SwiftUI APIs, and what these shifts mean for developers building apps today. We also take an honest, technical look at accessibility in iOS, a discipline Natalia considers fundamental, not optional. The conversation comes alive with a live walkthrough of Brève, her beautifully crafted app rebuilt for iOS 26, where she unpacks real SwiftUI code, shares practical tips, and demonstrates exactly how the new material system behaves in production. What We Cover 1. iOS 26 & Liquid Glass Design Apple’s most significant visual redesign in years arrives with iOS 26. The new Liquid Glass design system introduces a translucent, depth-aware material that redefines how surfaces, controls, and navigation elements feel across the entire platform. Natalia breaks down what it means for developers, not just visually, but architecturally. What Liquid Glass Material is and how it differs from previous visual systems How the new design language propagates through SwiftUI components automatically Where developers need to intervene and where the framework handles it for you The implications for custom UI components and existing app designs 2. SwiftUI in iOS 26: What’s New Every major iOS release brings SwiftUI closer to feature parity with UIKit, and iOS 26 is no exception. Natalia shares her perspective on the most impactful API additions, the subtle improvements that compound over time, and the areas where SwiftUI still asks developers to be creative. The most impactful new SwiftUI APIs in iOS 26 and when to reach for them How to adopt Liquid Glass in SwiftUI views without fighting the framework Animation and transition improvements that raise the quality bar for interactions Bridging old and new: strategies for incremental SwiftUI adoption in existing apps 3. Accessibility in iOS: A First-Class Concern For Natalia, accessibility in iOS is not a checkbox at the end of a sprint, it is a lens through which every design and engineering decision should be made. In this segment, she makes the case for accessibility as a professional standard and walks through the tools and APIs that make it achievable without compromise. Why accessibility-first thinking produces better UX for all users, not just some Key SwiftUI accessibility modifiers and what they actually do under the hood Common mistakes developers make and how to catch them early with Xcode’s Accessibility Inspector How iOS 26 improves the accessibility story for dynamic type, color contrast, and focus management 4. Live Demo, Inside the Brève App Theory meets practice in a live walkthrough of Brève, Natalia’s elegant reading and news app, fully adapted for iOS 26. She opens the code, walks through real SwiftUI implementations, and reveals the kind of decisions that separate polished apps from merely functional ones. How Brève adopts Liquid Glass to feel native from day one of iOS 26 Real SwiftUI layout techniques used in production, not simplified examples Accessibility implementation in Brève: labeled elements, semantic grouping, and VoiceOver flow Tips and tricks Natalia applies from her time on Apple’s own SwiftUI team Natalia’s Books Alongside building Brève and running Nil Coalescing, Natalia has authored three books that have become cornerstones of the Swift developer library. Each title is practical, deeply researched, and written with the clarity of someone who has worked on the frameworks from the inside. SwiftUI Fundamentals Updated for iOS 26 & Liquid Glass The definitive introduction to SwiftUI, now updated to cover the iOS 26 design system, Liquid Glass components, and the latest API additions. Whether you are building your first SwiftUI view or migrating a complex UIKit app, this book meets you where you are. Swift Gems Advanced Swift for experienced developers A collection of carefully curated techniques for developers who already know Swift and want to write it at a higher level. Each gem is self-contained, production-tested, and immediately applicable, exactly the kind of knowledge that takes years to accumulate on your own. Integrating SwiftUI into UIKit Apps Progressive adoption strategies The practical guide for teams with significant UIKit codebases who want to adopt SwiftUI without a full rewrite. Covers hosting controllers, bridging data flow, sharing state, and navigating the edges where the two frameworks meet. Explore all three books at books.nilcoalescing.com. About the Guest Natalia Panferova Co-founder, Nil Coalescing • Former Apple SwiftUI Engineer • Author Natalia Panferova is one of the most respected voices in the Swift and iOS development community. After working on Apple’s SwiftUI team, she co-founded Nil Coalescing with Matthaus Woolard, a studio producing high-quality educational content, tools, and apps for Swift developers. She is the author of SwiftUI Fundamentals, Swift Gems, and Integrating SwiftUI into UIKit Apps, and the developer behind Brève, a beautifully designed reading app built as a showcase for modern iOS development practices. 📚 Books, books.nilcoalescing.com ☕ Brève App, breve.coffee Key Takeaway iOS 26 is not just a visual refresh, it is a signal of where Apple wants the platform to go. The new Liquid Glass design system, the accessibility improvements, and the continued evolution of SwiftUI are all pointing in the same direction: a platform that rewards developers who invest in craft. Natalia’s career, her books, and the way she builds Brève are a masterclass in what that investment looks like in practice. Listen & Subscribe If you are building for iOS 26, working with SwiftUI, or thinking more seriously about accessibility in iOS, this episode is essential listening. Share it with a teammate, a design partner, or a developer who has been putting accessibility work off for one more sprint. Subscribe to the Swift Academy podcast for weekly conversations at the intersection of iOS development, software architecture, and engineering craft. 🎥 Watch on YouTube 🎧 Listen on Apple Podcasts ☕ Support the Podcast

Ever wondered how to build intercative that feel natural and responsive? The kind where users can drag events and see real-timeupdates? SwiftUI’s combination of GeometryReader, alignementGuide, and gesture handling makes this suprisingly elegant. Let’s build from scratch and the understand the magic behind positioning elements on a timeline. The Challenge: Positioning Events in Time magine you need to visualize events that occur over time, think of a video timeline, project milestones, or async operations. The core challenge is: How do you position an element at a specific time on a timeline of unknown width? ...

SwiftUI’s declarative syntax often feels like magic. You can write natural-looking code with if statements, multiple view expressions, even loops, and somehow, it all just works. But how? The secret lies in ViewBuilder, one of Swift’s most powerful tools that transforms your declarative code into optimized SwiftUI types. Let’s dive into what makes this possible. The Foundation: Result Builders Before focusing on ViewBuilder itself, it’s important to understand what it’s built on: Swift’s Result Builder system (previously called Function Builders). ...

Remember when we first discovered @ViewBuilder in Part 1? That moment when everything clicked and you thought “wow, I can create my own SwiftUI-style components!” It was pretty exciting, wasn’t it? The declarative syntax, the composability, the way it all just… worked. Well, I hate to be the bearer of bad news, but today we’re going to talk about a pattern that might seem like the next logical step,but is actually a beautiful trap waiting to catch enthusiastic SwiftUI developers. ...

SwiftUI’s @ViewBuilder is a powerful attribute that enables us to create custom view components with a declarative and flexible syntax, just like native SwiftUI containers (VStack, HStack, etc.). In this article, we’ll explore: What is @ViewBuilder and why it matters How to create a custom view that accepts a @ViewBuilder closure What happens under the hood when SwiftUI processes a @ViewBuilder closure Practical use cases and benefits What is @ViewBuilder? @ViewBuilder is a special attribute that lets you write multiple views inside a closure, and SwiftUI will automatically combine them into a single view result. It acts like a function builder specialized for views. ...