iOS Development in the Age of AI
Agentic coding is here. What does that mean for iOS development and the people behind it?
With Xcode 26.3 out, agentic coding is quickly becoming the norm; some even call it vibe coding, though I'm not a fan of that term. Another marketing-heavy word these days is AI. I don't think LLMs are intelligent, but that's a topic for another day. Now, you can type a few instructions, let the LLMs take care of the rest, and maybe relax with a cup of tea. But is it really that simple? In this first post, I want to look at where iOS development stands today. I'll start with a bit of history, talk about what it's like to be an iOS developer now, and see how LLMs can improve the workflow. What does all this mean for junior developers and anyone considering this career? And does it really mean we have to adapt if we don't intend to fall behind?
We're coming up on 20 years of the iPhone, and it's been almost as long since the iOS Developer role began; back then, it was called iPhone App Developer. I remember when the App Store launched with just a few hundred apps, and the SDK came out with iPhone OS 2.0. Apps like AOL Instant Messenger and Twitteriffic, and games like Super Monkey Ball and Tap Tap Revenge, were among the first. Nostalgia kicks in thinking about it. Back then, Mac developers made the jump to the iPhone SDK, bringing new energy to Objective-C. The next big milestone was the release of Swift in 2014, which simplified iOS app development and eliminated many of those [brackets]. Five years later, SwiftUI arrived, making building user interfaces much more approachable. Three years after that, ChatGPT launched in 2022 and quickly became one of the fastest-growing technologies on the internet. I believe this is now the biggest shift since the role began. Each of these milestones changed how we build apps, but none of them changed the fundamental expectation: that you understand what you're building and why. With all this powerful tooling at our disposal, let's explore iOS development today, what tools we use, and how I believe we should be using them.
Then and now, we use Xcode to build iOS apps. Xcode has improved significantly since its initial launch, and it now ships with built-in agent capabilities that would have felt reminiscent of science fiction a few years ago. We still expect to write testable, maintainable code using TDD and to choose the optimal architecture by considering the pros and cons of the application. Today, much of the code can be generated, but expertise is still expected and possibly more important than ever. We don't want black boxes shipped to production. It's important to know what we want from the final result before prompting the agent. A skill we should learn and master is composing prompts. The difference between a vague instruction and a properly organised one can be the difference between an hour of discussion and a working implementation on the first pass. While our goal is to speed up development and eliminate repetitive tasks with LLMs, we could easily waste time writing poor prompts, leading to longer interactions with an agent. One solution to avoid poor results is Agent Skill documents, which can yield far more desirable outcomes. For example, the recent release of the point-free AI skill docs makes adopting a more boilerplate-heavy framework easier than ever. Skill documents composed by the point-free team help adapt best practices when working with The Composable Architecture and other point-free frameworks. I expect to see more of this pattern going forward, with framework authors shipping AI skill docs alongside their libraries to ensure that generated code follows their intended conventions.
With LLMs, development can speed up, but only when prompts are carefully crafted. Planning is more important than ever. Before writing a single prompt, we want a detailed overview of the architecture, its moving parts, side effects, and state management strategy. All of these need to be considered before handing anything off to an agent. I've found that designing the dependency graph and identifying where side effects live before prompting leads to much better results than jumping straight in with something like "build me a login flow." After thorough planning, we can begin by having an agent handle the boilerplate, things like conforming to protocols, setting up networking layers, or scaffolding test files, while we focus our energy on the parts that require real decision-making.
Given that LLMs handle much of the writing, developers naturally spend more time reviewing code. What does this mean for the end product's quality? We are dealt great cards here, but how are we going to play them? By spending less time on the mechanical act of coding, we can invest more in UX, app performance, and long-term maintainability. We can run more thorough performance profiling in Instruments, spend time on accessibility, or refine animations that would have been deprioritised under tighter deadlines. At the end of the day, it depends on us and how we use AI. Just letting the agent do the work with minimal reviewing will lead to lower returns. I've seen generated code that looked perfectly clean on the surface but created subtle retain cycles, or used @StateObject where @ObservedObject was the correct choice. These issues only come up during careful review or runtime debugging. While quickly generating an app from scratch can work for prototypes and small projects, there are slim chances that this will translate well to production, especially when projects are owned by larger teams and many people are involved.
Once an agent has finished its work, how much polishing or adjustment does the developer still need to do? That depends on several elements: the language model used, whether Agent Skill documents were provided, and how well the prompt was written. When all of those areas are executed well and the setup is optimal, it can often be a matter of small, targeted changes to reach the desired end result. However, it also depends on the type of problem we are solving, the complexity level, and whether the model has already been trained on similar solutions. A well-established pattern like MVVM with Combine will typically yield cleaner results than a more specialised approach. In my experience with AVFoundation, anything involving FairPlay Streaming and DRM is an area where LLMs consistently fall short. The documentation is limited, much of the implementation relies on server-side key delivery logic that isn't well represented in public training data, and getting the AVContentKeySession flow right requires a level of domain knowledge that agents simply don't have yet. Learning where LLMs do well and where they fall short is something we should all be paying attention to.
We still need experts, and they are made, not born. Even though there are significantly fewer entry-level and junior positions now, experts are needed in every area of software development. How will future engineers who grow up with LLMs develop their expertise? Will they rely on agents to do the work and never build the mental models that come from struggling through problems? I believe we still need to encourage new Computer Science students and self-taught programmers to understand the fundamentals. By fundamentals, I mean the things an LLM cannot dependably teach through generated code alone: memory management and understanding ARC, concurrency and the details of Swift's actor model, architectural trade-offs and why you might choose one pattern over another, and the ability to debug problems that don't have a clear Stack Overflow answer. There's AI hype going around; some of it is legitimate, some is just pure science fiction. But the landscape is changing, there is no doubt about it. We are required to change while still developing true experts to prevent brain drain. If you are new to the industry and reading this, or even started coding when ChatGPT was released, I encourage you to learn those fundamentals, build a strong understanding of the topics, and form your own opinions. It cannot all be about speed and shipping software quickly. The developers who understand why something works will always be ahead of those who only know that it works.
It's still important for iOS developers to weigh the trade-offs and build a system that is right for the job by choosing the optimal architecture for the team and the app's scalability. Since writing code takes time, we are encouraged to use agents, provided we invest sufficient time in planning beforehand and reviewing the output afterwards. Manual optimisations are still necessary at the lower levels of development. Performance tuning, memory profiling, and platform-specific edge cases are areas where human assessment is still needed.
Getting the fundamentals right is important, but LLMs and agents can help us accelerate development and deliver production-ready apps faster than ever before. However, there is a real possibility we'll see fewer deep experts in the future as automation becomes the norm, and I think we should be honest about that risk. These days, it's important to think more like a product owner. That means stepping back from the code and asking whether the feature actually solves the user's problem, whether the architecture will hold up as the team scales, and whether we're building something maintainable or just something that compiles. The developers who do well in this new landscape will be the ones who ask the right questions, make sound architectural decisions, and take ownership of quality from planning through to release. The tools have changed, but the responsibility is still ours.