Mobile development blogs, tutorials and resources inside!Latest Mobile Dev Insights: iOS, Android, Cross-PlatformAdvertise with Us|Sign Up to the NewsletterMobilePro #225: The Right Way to Modernize Legacy iOSHi ,Not every legacy codebase is asking to be rewritten.Every development team eventually inherits code that feels older than the tools they're using today. The instinct is often to ask whether it's time for a rewrite, but that's rarely the first question worth answering. More often, the challenge is figuring out which parts of the architecture are still doing their job—and which ones deserve to evolve.This week's article explores exactly that through the lens of a real iOS modernization project. Instead of treating AI as an architect making design decisions, it shows how coding agents become far more effective when they're given clear architectural boundaries. That's a timely perspective as Android Studio expands its AI capabilities, Apple prepares developers for iOS 27, and modern developer tools continue shifting from generating code to collaborating with the engineers who design it.TL;DRLegacy codebases don't always need rewrites—many can be modernized incrementally with the right architectural boundaries.Separating DTOs from domain models makes framework migrations safer and easier to manage.AI coding agents work best when architectural rules are explicit rather than implied.Agent Skills help encode project conventions, enabling repeatable and reliable AI-assisted refactoring.Compile-time dependency injection improves reliability by catching wiring issues before runtime.Modernization is ultimately about preserving good architecture while letting AI handle repetitive implementation work.This week’s news corneriOS 26.6 prepares iPhones for the transition to iOS 27: Apple is expected to release iOS 26.6 as the final major update before iOS 27, focusing primarily on bug fixes, performance improvements, and security updates rather than new user-facing features. For iPhone developers, this release is important for validating app stability on the mature iOS 26 platform and ensuring a smooth transition to iOS 27 later this year.Apple sues OpenAI over alleged trade secret theft in hardware race: Apple has filed a lawsuit accusing OpenAI and several former Apple employees of misappropriating confidential hardware trade secrets to accelerate OpenAI's consumer device ambitions. Apple alleges the information was used to support development of future AI hardware, while OpenAI denies any wrongdoing.Android Studio Quail 2 speeds up AI workflows with parallel agent tasks: Android Studio Quail 2 is now stable, introducing a redesigned AI Agent Mode that lets developers run multiple AI-assisted tasks simultaneously, eliminating the need to wait for one request to finish before starting another. The release also integrates LeakCanary directly into the Android Studio Profiler for faster memory leak detection and brings AI-powered crash analysis to App Quality Insights with one-click fix suggestions.iOS 27 Beta 4 refines Siri, Photos, and developer testing: Apple has released iOS 27 Beta 4, focusing on polishing the platform ahead of launch with refinements to Siri, Photos, AirPods controls, and the Liquid Glass interface rather than introducing major new features. Developers can also test new capabilities like ProRes Log 2 video support, per-network Connectivity Assist, and updated media APIs while validating app compatibility against the latest SDK changes.A glimpse of BuildWithAI newsletterBuilding with AI is quickly becoming part of every developer's workflow. Each week, Build with AI explores practical AI engineering, agentic development, LLMs, MCP, coding tools, and the techniques shaping modern software development. Here's a glimpse into a recent featured article:The Mental Model - Why loops aren’t just bigger promptsFor two years, the workflow was: you write a prompt, you read the output, you write the next prompt. The agent is a tool you hold, one turn at a time. That’s prompt engineering, and no matter how good the context or the harness around it gets, you’re still the one closing the loop.Loop engineering removes you from that position. You’re not writing better instructions —you’re building the system that decides what to prompt, when, and whether the result is good enough to move on. The agent still does the work. The loop decides whether to trust it.No hype. No fluff. Just the mental models and code that hold up in production.The five moves every loop makes:Discovery- how the loop finds work to do, instead of waiting for you to hand it a task.Handoff- how work gets assigned to an agent, with enough context to act without you in the room.Verification- checking the result before it’s accepted. This is the one teams get wrong (more below).Persistence- recording what’s done, so the next tick doesn’t repeat work or lose state.Scheduling- deciding when the loop runs again, and when it stops.The part that breaks most loopsVerification is usually built as the agent checking its own work. That fails predictably: an agent grading its own output tends to praise it, the same way a student grading their own exam finds fewer mistakes than a second reader would. The fix isn’t a better prompt for self-review — it’s a structurally separate evaluator: a different call, ideally a different model, whose only job is to be skeptical.This is also why the same loop can produce opposite results in different hands. Two teams can build an identical five-move structure and get completely different reliability, because the judgment sitting inside the verification step is where the real engineering is. Generation is nearly free now. Judgment is the scarce resource.Read more...Build production-grade apps with Claude CodeClaude Code can generate code fast, but this workshop shows developers how to make it work reliably inside a real codebase.On July 31, Luís Rodrigues and Gabriela de Queiroz will build live and show how to use CLAUDE.md, Skills, MCP workflows, scaffolds, and guardrails to create production-grade apps. You’ll follow the setup step by step and leave with patterns you can apply to your own projects.Reserve your seatModernizing Legacy iOS Architecture with AI as an Observer, Not an ArchitectMost legacy codebase conversations start in the wrong place. Teams jump straight to "should we rewrite this?" when the better question is usually "what here is actually still sound?" That's the premise behind a recent deep dive into modernizing a real-world iOS e-commerce codebase, one that's architecturally solid but built on choices that made sense years ago: RxSwift for async work, Swinject for dependency injection.Rather than treating those choices as mistakes, the project treats them as historically valid decisions worth evolving carefully. Along the way, AI tools like Claude Code get a specific, limited role: not decision-maker, not architect, but observer. When an AI agent struggles to reason about a codebase, that friction usually says more about the architecture than about the tool:Here's what that modernization process looked like in practice.Clean architecture as the foundation, not the rewrite targetThe project's Clean Architecture setup follows a familiar three-layer split: Presentation, Domain, and Data, with dependencies flowing inward toward the Domain layer. Nothing exotic. What makes it work well under refactoring pressure is a strict separation between DTOs and domain models.DTOs are shaped by whatever the backend API returns, built for transport and decoding, not for expressing business meaning. Domain models describe what the app actually cares about, independent of how any given endpoint happens to structure its response. Repositories sit at the boundary, translating one into the other so the Domain layer never has to know about networking or API-specific quirks.That separation is what makes the rest of the migration possible. When your business logic doesn't know or care whether data arrived via RxSwift or async/await, swapping the underlying async mechanism becomes a contained, lower-risk change instead of a system-wide rewrite.Teaching an AI Agent to refactor with boundariesRefactoring a legacy codebase is delicate work. Ask an AI coding agent to migrate from RxSwift to Swift Concurrency with no explicit boundaries, and it will make architecturally significant decisions on its own, not because it's overreaching, but because nobody told it not to.The fix here is Agent Skills: reusable, domain-specific instruction sets (defined in a `SKILL.md` file) that get loaded automatically when relevant, turning a general-purpose coding agent into one that understands *this* project's conventions. Instead of a one-off prompt, the Skill encodes the actual migration pattern, how a `DisposeBag`-managed subscription becomes a plain async function, how a `BehaviorRelay`-backed ViewModel becomes a stored property backed by Swift's `Observation` framework, and so on.The results were concrete. Claude Code, guided by the Skill, correctly stripped RxSwift usage out of ViewModels and networking code. But it also revealed a gap: the agent removed the code that used RxSwift without recognizing that the now-unused RxSwift dependency was still declared in `Package.swift`. That's not a knock on the tool, it's a signal that dependency graphs themselves need to be encoded as part of the architectural rules an agent follows, not left to inference. A second, narrower Skill focused specifically on cleaning up `Package.swift` closed that gap.The pattern worth remembering: AI agents are excellent at mechanical transformation once the rules are explicit, and noticeably weaker at inferring implicit architectural intent. Skills are how you make that intent explicit.Dependency injection: from runtime wiring to compile-time validationThe second major thread is a migration from Swinject to Factory for dependency injection, a shift that's less about swapping libraries and more about when your dependency graph gets validated.Swinject wires dependencies at runtime through a container: you register a type, and if you forget to register something it depends on, the app compiles fine and only breaks when that resolution actually happens. Factory flips this, dependencies are declared at compile time, so missing or mismatched wiring shows up as a build error instead of a runtime surprise.This shift also affects where composition logic lives. Swinject supported "Assembly" groupings, letting registration logic live close to the feature it configured. Factory has no direct equivalent, so composition naturally gravitates toward a single, centralized location, in this case, the app module. That's a reasonable trade-off for a project of this size, but it's worth knowing upfront if you're planning a similar move on a larger, more modular codebase: centralization that's fine at one scale can become a bottleneck at another.Modularization: Where SPM Ends and Tuist BeginsThe chapter's second half turns to modularization, a genuinely separate concern from Clean Architecture, but one that becomes unavoidable as teams and codebases scale.Swift Package Manager, now deeply integrated into Xcode, handles dependency management and moderate modularization well. But its core logic lives inside Xcode's closed-source layer, which creates real limits: SPM can't customize build settings the way a full Xcode project can, and teams pushing for finer build-performance control eventually hit a ceiling.That's the gap Tuist fills. It started as a project-generation tool (in the same space as XcodeGen) but has since expanded into shared build caching, both module-level caching integrated with its own generation workflow, and caching layered on top of Xcode's native build system. The two approaches aren't mutually exclusive, and which one makes sense depends on project size and team structure.The migration path from SPM to Tuist follows the same Skill-based approach used earlier: rather than deleting `Package.swift` and starting over, Tuist is introduced alongside the existing SPM setup, and the architectural rules embedded in the SPM configuration, typed dependency helpers, module boundaries, and so on, get carried forward explicitly into the Skill that drives the migration. Skip that step, and the agent has no way of knowing which structural decisions were intentional.The real takeawayStrip away the specific tools, RxSwift, Swinject, Factory, Tuist, and the throughline is this: AI-assisted refactoring works best when architectural intent is written down somewhere the agent can actually read it. Agent Skills are that mechanism. They turn tribal knowledge about a codebase's conventions into something explicit, shareable, and repeatable across future refactors, shifting AI from a reactive code transformer into a collaborator that operates within boundaries the team has actually defined.If you're sitting on a codebase with its own set of "decisions made years ago," the lesson isn't to rewrite it. It's to make the architecture's implicit rules explicit, then let the agent do the mechanical part.This article is based on AI Driven Swift Architecture published by Packt.📚 Go DeeperIf you’re looking to confidently embrace the next era of Apple development, AI Driven Swift Architecture by Walid SASSI and Dave Poirier offers an unfiltered journey into modern Swift development with Swift 6 concurrency, SwiftUI, and Clean Architecture at its core.🤖 Explore Apple’s new on-device foundation models for private, offline intelligence🛠️ Learn and implement the Model Context Protocol (MCP) into practice by building custom MCP servers in Swift🔀 Figure out a repeatable workflow for shipping future-ready iOS apps feature by feature, agent by agent, and test by testAI Driven Swift ArchitectureBuy now at $44.99📢 Important: MobilePro is Moving to SubstackWe’ll be moving MobilePro to Substack soon. From that point forward, all issues will come frompacktmobilepro@substack.com.To ensure uninterrupted delivery, please whitelist this address in your mail client. No other action is required.You’ll continue receiving the newsletter on the same weekly cadence, and on Substack you’ll also gain more granular control over your preferences if you wish to adjust them later.💭 Let’s TalkIf you inherited a legacy app today, would you rewrite it or modernize it piece by piece? Why?Reply and let us know.Advertise with usInterested in sponsoring this newsletter and reaching a highly engaged audience of tech professionals? Simply reply to this email and our team will get in touch with next steps.Cheers,Nithya Sadanandan and Runcil Rebello,Editors-in-Chief, MobilePro*{box-sizing:border-box}body{margin:0;padding:0}a[x-apple-data-detectors]{color:inherit!important;text-decoration:inherit!important}#MessageViewBody a{color:inherit;text-decoration:none}p{line-height:inherit}.desktop_hide,.desktop_hide table{mso-hide:all;display:none;max-height:0;overflow:hidden}.image_block img+div{display:none}sub,sup{font-size:75%;line-height:0}#converted-body .list_block ol,#converted-body .list_block ul,.body [class~=x_list_block] ol,.body [class~=x_list_block] ul,u+.body .list_block ol,u+.body .list_block ul{padding-left:20px} @media (max-width: 100%;display:block}.mobile_hide{min-height:0;max-height:0;max-width: 100%;display:none;overflow:hidden;font-size:0}.desktop_hide,.desktop_hide table{display:table!important;max-height:none!important}.social_block .social-table{display:inline-block!important}}
Read more