AI-Assisted iOS App Deployment

Useful Materials: Apple’s product page guide

Welcome back. In the last lesson, we created a verified app facts file, landing page copy, and a privacy and support draft. In this lesson, we’re going to reuse those facts to prepare the App Store listing for Tokens Dashboard version 1.0. We’re still not going to open App Store Connect, but we are preparing a review copy package that someone can use there later.

That boundary is going to let us focus on the part where AI is genuinely helpful: drafting options, tightening language, checking field limits, connecting claims to evidence, and challenging the final package.

The danger is that App Store fields are short, public, and very tempting to fill with whatever sounds most impressive. We’re going to choose accurate over flashy. I promise accurate can still sound good, and we don’t have to make it sad or boring at all. By the end, you will have reviewed App Store copy, a screenshot plan based on real app screens, and a readiness checklist for the first release.

Let’s take one look again at app-facts.md. And here, remember that we had release information, audience purpose, our verified features, information around data and privacy, support and contact information, limitations and non-goals, screenshot inventory, and a little bit more.

We also had a sample set of information for our landing page draft: the goal and audience, the hero heading and support copy, primary call to action, feature sections, et cetera. Now, before prompting, we want to verify the current requirements from Apple. Now, at the time of this recording, for example, the exercise is going to use a 30-character maximum for the app name and subtitle, 170 characters for promotional text, 4,000 characters for the description, and 100 bytes for the keyword field. Notice that keyword uses bytes, not simply visible characters. For plain ASCII terms, those often line up, but they are not universally the same thing. Screenshots have their own device and file requirements. We will prepare the story and captions here, but we will check Apple’s live specifications again before producing final submission assets.

The metadata fields also have different jobs. The subtitle is a short summary. Promotional text carries the current marketing message. The description explains the app’s features and value. Keywords provide relevant discovery terms. The support and marketing URLs give people somewhere useful to go.

Giving each field one job helps us avoid repeating the same sentence five different ways. And because this is version 1.0, what’s new remains not applicable.

I’ve gone ahead and searched for Apple’s Creating Your Product Page website, and you can see here how it has tremendously useful information around how your App Store page is going to look and be structured, and certain limitations, like the one we were talking about just before. The app name can be up to 30 characters long. We also have an icon. Subtitle, which can be up to 30 characters long as well. App preview, screenshots, description. We have promotional text with a limit of up to 170 characters. We have keywords limited to 100 characters total. In-app purchase information, what’s new, and more.

I’m going to go ahead and close this, and I’ll close our landing page copy file and app facts. I also want to locate this module’s AI deployment resources folder and go ahead and open the lesson two prompts file. I’ll go ahead and do so in VS Code.

Now, I’m going to go ahead and copy the first prompt, same as we have before. And notice how it needs to reference a couple of files. And instead of pasting the contents here, I’m just going to ask ChatGPT to find those for me. I’ll switch back to ChatGPT, and in the same chat that we were in in the previous lesson, I’ll just ask it to work on the next prompt and to find the files referenced in our folder.

Now, this lesson’s prompt asks for several options: character and byte counts, fact ID references, and a separate screenshot plan. We want options because the first response is not automatically the best one. We also tell ChatGPT that the app name is fixed and what’s new is not applicable.

If your AI tool also reports token usage, maybe the prompt name, the model, or the token counts, you can, as we did in the previous lesson, ask it to do so and to give you those numbers for you. Again, remember, these are just references, but not a universal specific price estimate.

Great, let’s take a look at the files. Now, the response is giving us a couple of options for subtitle, promotional text, description, et cetera. So let’s take a look.

Now, before I choose anything, what I will want to do is compare the options against three questions that I’ll ask myself. Is it accurate? Is it clear? And does it sound like this app? Text that’s maybe longer, more dramatic, or packed with buzzwords does not necessarily have to win by default. Shocking, I know. But this is why we’re using AI to help us, not to make decisions for us without our input or review. Here we have a couple of subtitle options, for example. Review team AI patterns or team-level AI usage review. We have promotional text options. We also have recommended plain text descriptions, information for the keyword, supported URL recommendations, marketing URL recommendations, and more, as well as some open questions for us to review.

Let’s then take a look at the App Store screenshot plan. It has some sections like screenshot goal, ordered screenshot sequence, caption options, and more.

We want to turn the screenshot inventory from lesson one into an App Store story, really, and the first screenshot should communicate the overall product quickly. Then, we can show the insights experience and the supporting charts. Now, AI or ChatGPT in my case, may suggest the order and captions, but the images have to come from the real app. We’re not generating a prettier imaginary interface or some fake image of what we want people to think our app is and then hoping nobody notices, whether it’s the App Store review team or users themselves.

Now, notice that the captions provided describe actual screens. They don’t cover the interface with claims that the image cannot support. Final graphic design can add a restrained frame or background layer, but the app screen remains real and readable.

Let’s take a look at some other information in this file. And one of the things that we may also want to do with a quick search is to catch some surprises or potential trouble for us. For example, if the response says real-time team analytics, we may want to remove it because the current release uses local sample data. Or if it says something like AI-powered recommendations in one of the screenshots or the copy package, then we can clarify that the insight cards come from deterministic local rules. Again, if it generates some incorrect or inaccurate what’s new notes, even though we asked it not to, we can reject them.

Now, this is not a minor style preference. It is the wrong field for this release because it is version 1.0 and we don’t have a what’s new section. So again, these are some of the things to look out for and to review as you review the elements that you’ve been provided with. In our case, the copy package and a screenshot plan.

Now we want to review things put together for us independently, and the fresh reviewer is going to get the approved facts, copy package, screenshot plan, and current exercise limits. It doesn’t get the original drafting conversation. So we wanted to check the artifacts, not explain why its earlier choices were great and how it didn’t make any mistakes.

For reference, I’ve added the result of the prompt that we’re just about to paste in the AI deployment resources in the file app store listings review. I’ll go ahead and open it in VS Code. And you can notice how we have this file for App Store listing review, and it says use this independent review after drafting. Feel free to use this for your prompts as a reference, but the prompt that we’re just about to copy includes that. So I’ll go ahead and open the lesson two prompts file and copy the prompt.

I’ll then switch back to ChatGPT, close the markdown file that I was previewing, and again, just to get an impartial, accurate review of our artifacts, I’ll go ahead and start a new chat. Now, what I will tell it in my prompt is that the prompt contains some files for reference, and I want ChatGPT to find those in the folder for this project.

The response gives us the review findings and a draft readiness status. We can review things that it returns, like must-fix findings or items that require our confirmation. It also suggests some optional improvements, maybe supported content worth keeping, and the final draft readiness status. Again, remember, the process is to read through these, iterate, and have a back-and-forth with the AI tool until things are polished and ready as you need them. In my case, I would reply with findings that I accept, reject, maybe want revised, or just want to left open or don’t care about. Maybe one short response is enough, or maybe a couple of back and forths.

In this case, for this video, I will just ask ChatGPT to suggest any sensible defaults and to choose things for me.

Excellent. Let’s take a look at our release readiness checklist once again, and you can see how it has marked some items as completed or ready, and some open, like the public support URL or marketing URL not being ready. This is exactly what we wanted, and the final checklist shows what the files actually prove. First release and accuracy checks can pass while unresolved support or marketing or other URLs remain unchecked. For this exercise, the honest final status is ready with open questions.

We now have an App Store content package that is tied back to the finished application. The copy has clear field roles, counts to verify, and fact references. The screenshot plan uses real screens and safe sample information. The readiness checklist shows what passes and what still needs a human owner. We have not submitted anything to App Store Connect, and we have not pretended that an unresolved URL is magically ready or faked one. That is very successful preparation on our behalf.

In this lesson, you converted verified app facts into App Store-specific copy and a screenshot sequence. You compared multiple AI-generated options, checked that claims and field limits, and correctly treated what’s new as not applicable to a first release. The most important takeaway is that every public field should describe the app you actually built, not the app an AI tool wishes you had built or thinks you built.

In the next lesson, we will jump forward to the first weeks after launch and use a fictional supplied dataset to analyze user feedback, bug reports, feature requests, and potentially confusing review messages or support messages. Now, we made the promises, but next, we get to find out what our fictional users thought of them. Wish us luck, and I’ll see you in the next episode. Bye for now.