iOS Feature Implementation Using AI

Welcome to the third and final lesson of this module. In this lesson, you’ll use dedicated or specialized skills defined within Xcode to audit certain parts in your application.

Apple introduced those dedicated skills to help you improve your implementation of VoiceOver capabilities, of dynamic type, SwiftUI, UIKit, and many others. To invoke those skills, which they also have an autocomplete, start with a /, and from there, you can see all the commands you can use within an AI conversation. But skills, think of them as dedicated or custom commands created. They are basically markdown files explaining to the agent how to review something or how to execute a task through an extensive amount of information as part of the context of that operation. So let’s have a look on one of them.

I already have slash written, and then special. The available list, if it’s not visible properly, there’s swiftui-specialist, app-intents-specialist, accessibility-voiceover-specialist, accessibility-dynamic-type-specialist, accessibility-sufficient-contrast-specialist. When the feature was already implemented, because the UI was built with SwiftUI, it already invoked the SwiftUI Specialist. For this one, we want the Accessibility VoiceOver Specialist to review our implementation. So I use the autocomplete.

Review the implementation of the application and write the audit violations in a dedicated file, similar to how we approached this in the previous lesson.

  /accessibility-voiceover-specialist review the implementation of the application and write the audit violations in a dedicated file, similar to how we approached this in the previous lesson.

While this is running, I’ll start a new conversation. And for this one, I’ll use the dynamic type. Accessibility Dynamic Type Specialist. With the skill defined in the prompt, audit the implementation of this application, write all the violations you find in a document.

  /accessibility-dynamic-type-specialist Audit the implementation of this application, write all the violations you find in a document.

Now, I have two conversations running at the same time. Both of them are working on the same code base. They are not isolated. Only because they’re working against or writing a markdown file, each of them writing a separate file, I don’t have a risk where they conflict with each other or any possible collisions.

Both of the conversations finished and produced the file that I asked for. This is the first one, Dynamic-Type-Audit. Here are the contents of the file. Verdict: Failed. Thank you. And here is the second one, VoiceOver. Verdict: Failed. Hard truth, but it’s definitely valuable. Each of them contains the explanation of what needs to be changed, and it is quite comprehensive.

If you’re curious on how those skills are defined, you can find them a little deep. This is the path. It’s under Your User Folder, then Library, Developer, Xcode and CodingAssistant. They’re inside codex. Doesn’t matter even if you’re using Claude as your AI agent and then skills, __xcode. So full path of Your User Folder ▸ Library ▸ Developer ▸ Xcode ▸ CodingAssistant ▸ codex ▸ skills ▸ __xcode. Those are Apple’s skills. Feel free to open and have an idea on how they all work.

Let’s have a very quick look on one of the two that we used now. Here is the skill file that is describing how to run the audit, how the code can be understood to provide information of this audit and help you solve bugs that will increase the value and your accessibility support of your application tremendously.

In the next module, we will take all of those five audit files and use them to improve the quality of your application. While working with AI, you can find a bug, fix it immediately. But you might end up going into a rabbit hole of: “I find this fix, two minutes later, find another bug.” Sometimes it helps to have a proper review, just like how a quality control engineer, quality assurance or a tester takes your application, goes through a long round, finds as much information as possible, and gives you them to fix. If you start fixing things once, check for the next, fix it, check for the next, you’ll find yourself going through a long spiral, and you’ll be wasting a lot of time building the application and putting back it on the device, giving to the testing engineer, and so on and so forth.

Finding the right balance of efficiency is different from one project to another, from one person to another, and also based on your tooling. What’s important is you review those files for the audits to identify false positives. What is the AI agent hallucinating around? It might be something important to you, or it might be something that it says it’s important, but it’s pointless for you that it’s not worth the effort to fix. Take that decision, go through the audits yourself in your projects, and decide how to move forward. I hope you enjoyed this module. The next one, we will focus on testing using those audits.