AI-Assisted Feature Development for iOS

Welcome back. In the last lesson, we took a fuzzy feature idea and turned it into a feature brief. That brief gave us the audience, the problem, the scope for version one, the non-goals, and a few open questions.

In this lesson, we are going to turn that brief into an iOS development plan. Still no implementation, I know. The restraint is impressive. We are showing a lot of patience, and I’ll give you and me a lot of credit. However, somewhere, our project manager is shedding a single, maybe more, tears of joy.

Now, the goal in this lesson is to end with a draft development plan file that is specific enough for a developer or an AI coding agent to implement later. We will define the proposed Swift types, the files we expect to add or change, the data flow, the insight rules, edge cases, accessibility requirements, and acceptance criteria. This is where the feature starts to feel real. But we are still keeping it safely in planning mode.

Now, let’s review the feature that we created in lesson one. The key decisions should already be there. This feature brief is for team leads, engineering managers, and project leads. The feature stays team level. It does not expose individual developer names in insight cards. It does not call an LLM inside the app, and it does not claim that AI caused delivery improvements. These constraints are not decoration. They are guardrails. When we ask AI to make a development plan, these guardrails help keep the response from drifting into a bigger, messier feature.

Now, before we ask for a plan, let’s actually remind ourselves what the app already looks like. The app, as you can see here, is intentionally small. It has models and mock stores that we have some Swift files for, view models that prepare and display data, and some SwiftUI views that show the dashboard screens. The summary screen uses navigation destinations to drill into existing chart views like we showed before. Here we’re taking a look at cost by model or tokens versus outcomes.

Now, this gives us a pretty natural place for our feature to live, a new summary row that opens a new detail screen with the AI usage insights. We don’t need new app architecture, big refactors, or new navigational paradigms. We also don’t need a backend. We don’t need a tab bar. We need a focused plan that fits the app we already have.

Now, we are ready for the first planning prompt: Prompt 1: Draft the iOS Development Plan. The prompt gives the AI our feature brief, the app architecture context, and the planning constraints. Again, this prompt is intentionally specific. You can find it in the prompts file in the student resources for this lesson. Now, if we ask for a plan for this feature and provide no boundaries, well, we should not be surprised when the answer that the AI agent gives us wanders off into the woods. This is why, as you can see here, our prompts are descriptive, constrained, and even have structures or specific outputs that we may want to use.

Back in your AI tool, in my case, ChatGPT, let’s go ahead and copy prompt one from this lesson’s prompt files and paste it. Now, before I do that, I’m just going to rename this chat into Development Plan. Feature Development Plan, actually. Perfect. Just so that it retains some context and gives me an idea of what I’m working with in this chat for the Tokens Dashboard project. I’ll switch to VS Code where I have the prompt that we want to begin with, and I’ll switch back to ChatGPT and say, “Let’s continue.” Now with the development plan prompts.

Now, this first response is not the final plan. It’s really a draft for us to have a back and forth with the AI tool so that we refine things to our liking. I want to look for a few specific things in this scenario. Did the AI tool keep the feature small? Did it avoid runtime AI calls? Did it avoid individual-level coaching? Did it define concrete Swift types? Did it include edge cases and acceptance criteria? If the answer to any of these is that it’s missing or not what we expected, it doesn’t mean that things failed and that this plan is a complete failure and we have to start from scratch. That’s the whole reason we are reviewing the plan before implementation, and it’s normal to sometimes iterate until you have a result that you’re happy with. Now, if your plan starts contradicting your brief, pause and fix things before going any further.

We now have a draft plan, but before we wrap up this lesson, because that’s not all we need, let’s maybe have it do a targeted review. Now, this is not a full adversarial review. That’s something that we’re going to do in lesson three. For now, we want to check whether the API surface, edge cases, accessibility notes, and acceptance criteria are ready for that deeper review. I’ll switch back to VS Code to copy prompt two: Prompt 2: Review API Surface and Edge Cases, and then switch back to ChatGPT and continue.

Fantastic. Don’t forget to check out the results. And this is another spot where you should not blindly accept everything. Look for practical additions. Maybe the AI catches a missing empty state. Maybe it points out vague acceptance criteria. Maybe it asks whether the workflow pattern insight is too sensitive. Those are useful findings. But if it tries to expand the feature into a bigger system, maybe add additional UI elements, just rein it back in and tell it to keep the plan small.

For now, I’m just going to go ahead and ask ChatGPT to implement any suggestions or changes that it recommends and for any questions to just provide sensible defaults and recommendations. Now, once the AI tool returns with some of these suggestions, the last thing we’re going to do is to ask it to write out a draft development plan file with the contents of the plan that we’ve just created so that we’re starting to get from a high-level idea in the previous lesson to more specific details in the iOS world around how to actually develop the feature. So we fleshed out the feature, added some criteria, found any edge cases, designed it a little bit from an engineering, product, and design standpoint, and now we’re getting into the code level. Not yet writing code, but actually getting things in a state where we will be able to write code as efficiently and concretely as possible while getting the best results for our existing code base.

Excellent. Wait. I waited for almost six minutes, and, oh, it said it implemented the AI usage insights feature and changed some Swift files. Oh, no, why did it do that? And this is something that I wanted to show you. If we’re sometimes vague, AI tools do not understand what we mean. In this case, I was intentionally vague about, “Hey, implement any suggestions or fixes that you make here and add sensible default or recommendations.” ChatGPT, in particular, the 5.6 Terra model, understood that as go ahead and implement it in my iOS and Xcode project. But what I really wanted to say was, implement these changes and fixes into our plan and maybe even be explicit about don’t make any code changes. So I’m just going to do that to show you and so that we get an updated plan before moving on to the second prompt.

Now I’m asking ChatGPT to implement those changes, fixes, and to add any defaults it suggested or it recommends, but not in the Xcode project, to the plan itself. And for now, just to leave the code as it is. In my case, I can revert to the previous version of the code, but for your case, you will know how to specifically tell the tool not to make these mistakes. Notice how even here, it’s still making changes to the Xcode project, even though I said not the actual project or to make any code changes, to just update the plan and leave the code as is. You sometimes have to wrangle these tools into specific workflows so that they don’t end up doing things you may not have intended.

It’s come back with the results, and it says the implementation-ready plan is here, and it’s including deterministic defaults, some data flow edge cases, accessibility requirements, and that it’s been saved to development plan.md. In this case, ChatGPT has jumped ahead and created a markdown file, but I actually have one final prompt: Prompt 3: Finalize the Draft Development Plan that I want to copy and paste so that it can create the file with my needs and specification and guidance.

Before copying the final prompt, I’m going to ask ChatGPT to remove that file and tell it that I will provide the instructions on how to create one.

While it does that, I’ll switch to VS Code, and I’ll copy the final prompt to finalize the draft development plan. I’ll go ahead and copy that and have it ready. And I’ll just make sure that there are no extra markdown files here. So we just have our feature brief from the previous lesson. Perfect. I’ll go ahead and say to continue with the next prompt, and let’s wait for the results.

Perfect. Let’s take a look at that file. In the case of ChatGPT, it can open it inline for us here. So what have we created? Well, we now have a draft development plan with the feature summary, goals, non-goals, a proposed swift surface, file list, data flows, rules, edge cases, accessibility notes, acceptance criteria, and, if applicable, any open questions that we may still have. Now, this is much more useful than just asking an AI tool, “Hey, can you build me an insights usage screen that’s a row that then has details that maybe does this, this, and that?” Because the implementation may be totally what you expected, but chances are it will not be, or it cannot read your mind around exactly what you wanted to achieve. By going through this flow, we now have a more structured feature development plan that when you do ask the AI tool to do it for you and execute it and write the code, it will do it much closer to what you expect with little or no refinements needed, especially as models get smarter and smarter at doing this.

Now, the plan gives this something for the next developer or an AI coding session to work from. But just as importantly, it still marks the decisions that we have not yet resolved. In this lesson, you have turned a feature brief into a draft iOS development plan. You used AI to propose structure, but you kept the plan tied to the actual app. You also made sure the plan stayed small, deterministic, and responsible.

In the next lesson, we will do the uncomfortable but very useful thing. We will challenge this plan with an independent adversarial review. And yes, we are going to invite criticism on purpose. Very brave, but super professional. And it may be slightly tedious and painful, but it’s worth it because we don’t just want the AI tool to agree with us or to give us exactly what we need, but not do a review or trying to find gaps in our plan or in what we’re doing. So with that, I’ll see you in the next lesson. Bye for now.