AI-Assisted iOS App Deployment

Welcome. In this module, we are taking a finished iOS app and getting its launch content ready. We’re not signing the app, uploading a build, or clicking around in App Store Connect. This module is about preparing the material that needs to be accurate before any of that happens.

We will create a landing page and privacy materials, prepare an App Store copy package, and then use a fictional launch feedback dataset to practice turning feedback into useful next actions.

And through all three lessons, AI is going to help us draft, compare, organize, and review. It is not going to decide what the app does.

That distinction matters because AI is very good at making missing information sound finished. Give it a vague app description, and it may cheerfully invent live syncing, smart recommendations, secure cloud storage, and possibly a tiny digital concierge wearing a hat. Lovely, but also not our app.

So before we write a single line of launch copy, we are going to build a verified app facts file. By the end of this lesson, you will have the source of truth file, reviewed landing page copy, and a privacy and support draft with unresolved questions clearly marked.

We’re going to be using the Token Dashboards application that we’ve built throughout the course and that is ready for its first public release. We know that we have a summary screen that’s going to give engineering managers and team leads some information and a quick view of AI usage and delivery metrics.

Now, another important fact is that this course version uses local sample data. The application is not connecting to any live production systems or pulling live tokens and usage data from any AI tool provider. These details are not tiny technical footnotes. They change what we are allowed to say on the landing page, in the privacy draft, and later in the App Store description.

Now, one of the things that I want to do is collect some evidence and information from the project. I’ll go ahead and open my Xcode project. And we can see that we have some files for assets, colors, the views, the models, et cetera. And while an AI tool can help us inspect the code and context in what it does, sometimes it cannot tell us every organizational practice, for example. It may not have information about our analytics provider or our analytics backend or any backend systems we may be connected to. It may also not have company-specific or business-specific information.

So our files can only help distinguish between what the code is doing or rendering on screen versus what our business needs or what we may want to convey to users in the App Store page. To capture some of these lessons, one of the things that we have created and provided for you is a sample file with app facts.

In the student materials, you should have AI deployment resources, and you have an app facts template file that we can go ahead and take a look at. And this is a template that we can use before asking AI to write any landing page, privacy support, or App Store content, and we’re going to be feeding this to the prompt that we write and copy from this lesson’s prompts.

Now, the slight template is intentionally blank. It gives us categories, stable IDs, and a place to record evidence, but it does not contain any launch answers. Every fact receives one of four statuses: verified in the app or code, verified by an owner, unknown, or not applicable. The IDs matter because we will ask AI to reference them beside important claims. If a landing page section says the app generates insights locally, we should be able to trace that claim back to something like feat-03 or priv-03.

Our AI deployment resources folder also contains an app facts file that has some content already in it. So let’s go ahead and take a look at it. I’ll do so in VS Code. Notice how we have different sections for release information, audience and purpose, verified features, data privacy, and so on.

With this, we are ready to prompt. Now, instead of saying, “Hey, AI tool, write a landing page for my dashboard,” we can give it some structured facts, evidence, limitations, and rules for any unknown information. And again, this workflow is not tied to a specific AI provider or tool. So you can attach the markdown files if your tool supports that or paste the contents directly as part of the prompt that I’ll show you in a second.

Your output will not match mine word for word, and that’s totally fine. We care about the process and whether what we’re doing is helping us achieve our end goal. If your tool also reports token usage, you can record the prompt name, model, input tokens, and output tokens as well as the total by asking it to do so before you begin. Now, those numbers vary by tool and model, so they’re useful observations, but not a universal or specific cost estimation tool.

I’ll go ahead and close the app facts file and locate lesson one’s prompts and open it in VS Code as well for me to copy. I’ll copy the first prompt, and notice how, as I was mentioning before, this app fact section expects us to paste the contents of app_facts.md or to point or attach it as part of the chat. So I will just ask ChatGPT, the tool that I’ll be using, to locate it within my projects folder.

Now, I’ve already started a new session in ChatGPT with Tokens Dashboard as a new project that I created, and it’s pointing to my module eight folder, which contains the Tokens Dashboard Xcode project, as well as the AI deployment resources. What I’m going to do now is ask ChatGPT and inform it that we’ll be doing some prompts and that for this particular one, I wanted to use the app facts file from my folder’s AI deployment resources.

Perfect. Let’s take a look at both drafts, starting with the landing page copy. So here we see that we have a page-one audience, we have hero heading and supporting copy. And notice how it references back to our app facts file. We also have some supporting copy, primary call to action, et cetera.

Same as in other modules, you always want to check what the AI tool outputs, tweak it, review it, and iterate on it until what you have is what you expect and what you need, and so that it’s also factually correct.

Let’s now take a look at the privacy and support draft. You may have some sections like information that requires owner or legal review, which is very important, and you may also see the same in the landing page or copy as far as open questions go for you to review.

Next, I want to show you a file called launch content review checklist, also available in the materials within the AI deployment resources folder. I’ll go ahead and open it in VS Code. Now, this checklist is our human pass. I can trace the local deterministic insights claim to feat-03, for example. I can also see that the support URL is still unresolved or maybe that the package is not ready to publish.

This is an important habit. Incomplete information should inherently look incomplete, and this checklist is going to be useful for you after the AI drafts the landing page, privacy, and support materials, so you can go through the list of elements and make sure that you have everything that you need.

Now, what we want to do is, back in ChatGPT, ask it for a second opinion. You may want to use a fresh chat so the reviewer judges the files instead of defending its original draft. Alternatively, you can remain here and ask it to do so. Now, this reviewer is going to get approved facts and both drafts. It doesn’t necessarily have to get the original conversation, depending on whether you start a new chat or not. I’m going to stick to a new conversation, and I’m going to go ahead and open the lesson prompts for this lesson file, and I’ll copy prompt two.

I also want to make sure that I have some of the files here, and if not, I can always go back and ask it to create those. In this case, it’s placed those files, the landing page copy, and the privacy and support draft in the root folder while my app facts is in AI deployment resources. So I will simply ask it to find those files in the module eight folder.

This audit should separate must-fix problems, items that need an owner, optional improvements, and supported claims worth keeping.

Now, we still don’t want to accept everything that it finds automatically or everything that it suggests. If the AI review, for example, correctly flags a claim about live data, we may want to remove it. If it asks us to invent a support URL so the page feels complete, we can reject that suggestion and leave the question open. If it recommends clearer wording without changing the meaning, that may be a useful optional improvement.

Here’s where I will reply with the findings that I accept, reject, or want revised, or the ones that I want left open. I don’t necessarily need another prepared prompt for that because I’m working with the live data that it has just responded with. But I can keep short, clear responses, and that should suffice.

So now, if we switch back to our folder, you should end up with the final three files: your landing page copy, privacy and support draft, and if we go into AI deployment resources, your app facts file. After you’ve iterated with the AI tool around its findings and polished things, you have these three connected artifacts.

And AI has helped us create and challenge the drafts, but also every publishable claim has to belong to a human owner or can be referenced against our checklist that we reviewed. And that’s all for this lesson.

You’ve created a verified app facts inventory before asking AI to write launch copy. You separated facts from unknowns, drafted landing page and privacy materials, and removed claims that the finished app could not support.

The big takeaway here is pretty simple. You give AI some verified context and then make it prove where the claims came from. In the next lesson, we will reuse this same source of truth file to prepare the App Store listing. Same app, same facts, but much tighter little text boxes. It’s going to be quite a lot of fun. I’ll see you in that lesson. Bye for now.