IOS

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

Swift Academy Podcast, Episode 12, Season 2 Modern iOS Security: Attacks, Defenses & AI Dave Poirier and Deya Elkhawaldeh on iOS security as an engineering culture problem rather than a tooling one, and on what AI has already changed for the people attacking your app. May 31, 2026 🎧 Swift Academy Podcast · Episode 12, Season 2 · Mobile Security • Attacker Mindset • AI Watch the Episode Why This One Matters “Apple handles security for us” is, according to both guests, the single most expensive misconception in iOS development. The platform gives you good defaults. It does not give you a threat model. This is not a conversation about theoretical vulnerabilities or hacker theatre. It is about engineering culture, architecture, and the gap between what developers assume the OS protects and what it actually protects. The uncomfortable part is how small the mistakes are that open the largest attack surfaces. The second half looks at what AI has changed. Work that used to demand deep expertise can now be automated and scaled, which moves the floor for attackers rather than the ceiling. That reframes when security has to enter a project: not before shipping, but on day one. The Conversation How small mistakes become large surfaces The implementation errors that show up again and again in shipped iOS apps What developers assume the device protects, and where that assumption fails Why the responsibility sits with the engineering team, not with a security review at the end Thinking like the attacker How attackers actually choose targets, and why they start with the low-hanging fruit Where jailbreaking stands today, and whether it still deserves the attention it gets What defending an app realistically looks like in 2026 Why a defensive culture beats any individual tool What AI moved How AI-driven tooling accelerates offensive work, and what that does to the economics of an attack The same tooling on the defensive side, and where it genuinely helps How far to trust AI inside a development workflow that has security consequences Which security myths survive, and which best practices actually hold up About the Guests Dave Poirier & Deya Elkhawaldeh iOS security specialists • Runtime protection, application hardening, defensive security Dave Poirier and Deya Elkhawaldeh work on runtime protection, application hardening and defensive security techniques for Apple platforms. Dave is also the co-author, with Walid Sassi, of AI Driven Swift Architecture (Packt), and a recurring voice on the security thread that ran through the first season of this podcast. Key Takeaways The platform is not your threat model. Apple's defaults are good and they are not a substitute for deciding what you are protecting and from whom. Attackers start with the easy wins. Most breaches do not need a sophisticated exploit, they need one careless implementation detail. Culture beats tooling. A team that reasons about security during design will outperform one that buys a scanner and runs it at the end. AI raised the floor for attackers, not the ceiling. Work that once required an expert is now automated, so the volume of competent attacks goes up. Security belongs on day one. Retrofitting it after the architecture is set is where the cost explodes. Resources & Links 🎥 Episode 12, Watch on YouTube 🎧 The Season 1 security series with Dave Poirier 📘 AI Driven Swift Architecture, co-authored with Dave Poirier Listen & Subscribe If your team still treats security as something that happens after the feature is built, this is the episode to send them. 🎥 Watch on YouTube 🎧 Listen on Apple Podcasts ☕ Support the Podcast

Cloud APIs put a frontier model behind a single HTTPS call. That convenience is hard to beat, and for most production workloads it remains the right choice. But something has shifted over the last couple of years: the gap between “what a hosted model can do” and “what a model running on your laptop can do” has narrowed enough that local inference is no longer a curiosity. For developers, especially those of us building on Apple Silicon, it has become a serious option. ...

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

A walkthrough of Anthropic’s new Claude Agents (agent view) inside Claude Code on iOS: how to run a Clean Architecture refactor agent and a unit-testing agent in parallel on isolated Git worktrees, with the full lifecycle and synchronisation pitfalls.

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