AI-Assisted Feature Development for iOS

Hello and welcome. In this module, we are going to plan a new feature for an existing iOS app with AI assistance, and I really do mean plan. We’re not going to jump straight into code just yet.

Now, for you, that may feel a little bit slower at first, especially if you’re super excited to just ask an AI tool to build the thing that you want, and I get it. I love seeing code appear quickly and automatically too. It feels like magic, and it’s super powerful. Who doesn’t like a bit of developer magic, really?

But if the plan is fuzzy, then the generated code usually gets fuzzy too. And then you get to enjoy the very fun activity of debugging a feature that nobody has properly defined. Yay! Such an awesome gift to start your new project.

So in this lesson, we are going to slow down just enough to shape the feature before asking anything to be implemented. We will use AI in three roles: a product lead, a designer, and an engineering manager. Each role will look at the same feature idea from a different angle. Then, we will make the actual decisions ourselves. By the end, you will have a feature brief that we can use in the next lesson to create a real iOS development plan.

Here, I have opened the starter project called Tokens Dashboard. Now, the starter project is a small SwiftUI application, and since this is the first time that you’re seeing it, let’s take a minute to walk through what is already here. Tokens Dashboard is also the sample app that we will use throughout the upcoming modules. So the work that we do here will carry forward throughout the rest of the course. It’s not a huge app, which is perfect for this module, but it has just enough structure to make feature planning interesting, but not so much that we spend the whole video just figuring out where files live.

Here on this first screen is our summary screen. It reads like a little dashboard brief. Each row gives you a short takeaway and then lets you drill into a chart.

The first row’s detail is for our cost by model. This shows how much model spend is attributed to each model in the mock data. There’s a donut chart, a total in the middle, and a ranked list below. For our feature, this screen matters because one possible insight is model concentration. If one model accounts for a large share of the total, that might be worth reviewing. Now, an important tiny caveat. That does not automatically mean anything is wrong. It just means the pattern is worth looking into.

If we go back, the next screen that we want to take a look at is tokens versus outcomes. This compares token usage with merged pull requests. It’s the kind of chart that can be really useful, but it is also the kind of chart that can be misread very quickly if we are not careful. Token volume alone is not a performance signal. It needs context, task complexity, quality, blocked work, review load, and a bunch of real-world details that the chart does not know about. That is one reason why our feature needs cautious language. We’re planning review signals, not performance judgments.

The final screen is our ticket to merge. This compares average days from ticket to merge for different AI usage cohorts. Again, useful signal, but not automatic proof. If one cohort is merging faster, that might be related to AI usage, or it might be task mix, team experience, review policy, or something else entirely. So one of the big planning constraints for this module is that we do not claim causation from this chart.

Now let’s peek at the code shape just enough to understand the app. Summary view owns the high-level navigation. There is a destination graph enum for the detail screens, and the summary rows navigate to those destinations. Summary view model builds the rows you see on the summary screen. Our models folder contains fixed mock data stores for model cost, developer outcomes, and ticket to merge samples. That is useful for us because our new feature can be planned around existing data. We do not need networking, authentication, persistence, or a backend for this module. So the app gives us a nice feature planning target, one new summary row, one new insight screen, and a small local rules layer that turns existing chart patterns into cautious team-level review prompts.

What we want to add is an interpretation layer, something that helps a team lead look at the charts and say, “Okay, what’s actually worth reviewing here?”

Here is a rough feature idea we are starting with. We are going to ask our AI tool “Add AI usage insights to the Tokens dashboard so a team lead can understand team-level AI usage patterns”. Now, that sounds useful, but it is also super vague. Dangerously vague, I would even say. What does understand mean? Who exactly is using this? Are we talking about individual developers? Are we judging performance? Is the app using AI at runtime? Are we just repeating the charts but in sentence form? Now, these are the kind of questions that we want answered before we just start jumping straight into the implementation.

Before we run the first prompt, a quick note about the prompts themselves. These prompts are longer than a casual chat message that you may be accustomed to, and that is intentional. For planning work, the AI needs context, what the app does, who the feature is for, what we already decided, and what we do not want it to do. A tiny prompt can be fine for a tiny question, but for feature planning, vague prompts usually create vague answers. So we are going to be a little more specific upfront and save ourselves cleanup later. This workflow is not tied to a specific AI tool.

I’m choosing to use one here, which is going to be ChatGPT on the macOS desktop using the ChatGPT app, as you can see here that I’ve installed. But you can easily use Claude, Gemini, Cursor, or something else like LM Studio with local models. Anything that you prefer that can work with project context and markdown files. Obviously, the exact response will vary depending on the tool you use and even the models that you use. For example, in ChatGPT, we can choose from models like Astra, Terra, Luna, Sol, or others. This is normal, so don’t worry if your responses do not exactly match mine.

Another practical note. If your tool shows token usage, jot that down after each prompt. Token usage will vary by tool, model, and response length. So we will not use it for exact cost estimates. But it is still useful to understand roughly how much context your workflow is using.

Before we get started with writing our prompts to plan out our feature, I want to show you a few resources that are included in the student materials. You should have an AI Planning Resources folder, as well as the Tokens Dashboard starter project. Now, here I have some sample reference markdown files that you can use for things like a designer review, an engineering manager review, a product lead review, or even an adversarial plan review. We’re not going to be using these files or configuring them as custom agents or skills, so don’t worry about attaching them to any of the prompts we write. These are just for reference or for you to use in future projects.

Included as well are these lesson prompt markdown files. Let’s take a look at the lesson-1-prompts markdown file. You can take a look at these prompts that we can use to copy-paste into ChatGPT with more context and details, as opposed to just a shorter one or two-sentence chat that you may be used to. We will have a prompt to perform the product lead review, the designer review, as well as the engineering manager review. So please reference these files if you want to follow along and copy-paste the same prompts that I will be using.

With that, let’s go ahead and open up ChatGPT. And I’m going to go ahead and create a new project. And in this case, I want it to be a local project. The project name is going to be Tokens Dashboard. And I want to add a folder. So I’ll go on my desktop and select module three (You will find these folders in the materials for this module) so that I can have the AI Planning Resources folder, as well as Tokens Dashboard, the Xcode project. I’ll go ahead and click create.

Perfect. Now, I also want to switch models because Astra may be a little bit overkill and too much for what we need. So instead, I’m going to go ahead and switch to something like Terra, and I’ll use medium.

The last thing I want to do is to tell ChatGPT that if it’s able to, to keep track of the input, output, and total tokens used for each prompt, and to report that at the end of every response.

Excellent. Let’s go ahead and get started with the first prompt: Prompt 1: Product Lead Review. I’ll go ahead and copy prompt one and paste it into ChatGPT.

Let’s take a look at the results. Here, it’s giving us the product framing, the proposed version one scope, non-goals, any risks and weak assumptions, as well as any questions before implementation. Now, here is where you can begin talking back and forth with the AI tool. For example, answering any of the questions, rejecting anything that you may not agree with, adding things that it may be missing, or simply making adjustments before moving on to the next phase.

As an example, here in the proposed V1 scope, it says, “A single insight section containing three to five deterministic team-level cards based on the dashboard’s existing data.” Maybe I don’t want to do three to five cards. Maybe I specifically want one or three. I can mention that to ChatGPT to make that adjustment. Additionally, let’s say model mix, how the team’s model usage distribution changed over time. I may not want that, so I can tell ChatGPT to remove that line. Similarly to here, in the questions before implementation section, maybe I can answer some of these questions or tell ChatGPT, “Do not worry about that question in particular. It’s a non-issue,” or, “I will take care of it myself.”

Now, we started with a product lead review, and the goal is not to have AI decide a product for us. The goal is to make it challenge the idea before we get too attached to our first version. And this is one of my favorite uses of AI, not having it be like, “Please do my job for me,” but, “Please poke holes in this while I still have time to fix it.” Your response is obviously going to be different from mine, and that’s totally okay. What we’re looking for here is not a perfect answer, but rather for some useful pressure. In particular, I want to pay attention to anything about the audience, whether the feature is actually useful, any privacy concerns, and places where the app could accidentally sound like it is judging people.

Now, the AI hasn’t created any final files for us. We will do that at the end of this lesson. I am also going to be taking useful decisions from the review, rejecting anything that does not fit, and at the end, having AI help us write that into our brief file. If you’re using a file-aware coding assistant, you can ask it to make the edit right here, right now, but you still need to review and approve what it writes. ``

As an example, I want to have one of the questions before implementation answered. In particular, question number eight. It says, “Are there privacy or policy rules beyond hiding names, such as suppressing data for very small groups?” I’ll go ahead and answer that. And I’ll say for question eight, “There are no further concerns for privacy, only hide names and any sensitive information.”

Perfect. That gives us a clear product direction, who this feature is for, what problem it solves, and what we’re deliberately leaving out. In the next demo, we’ll review the feature from design and engineering perspectives, then bring all those decisions together in our feature brief. I’ll see you there.