From StretchTap to an AI Skills Workflow: From Idea to Apple Submission

With StretchTap, I experimented with developing an Apple Watch application using Codex, all the way to submission to Apple. My involvement focused mainly on the product’s features and the decisions needed for distribution. The agent handled the technical execution, from the Swift project to preparing App Store Connect.

I then used this experience to build a reusable skills workflow: idea validation, development, quality auditing, publication, and maintenance, coordinated by an orchestrator.

The workflow evolved gradually. StretchTap was the practical experiment that revealed which tasks to automate, which checks were missing, and which decisions needed to remain with me.

The starting point: stop restarting a timer

During a stretching session, a conventional timer requires attention after every interval. I wanted an application that would let me choose a duration once and then repeat the cycles automatically.

StretchTap’s scope was deliberately small:

• 20, 30, 45, or 60-second intervals;
• one-tap start;
• automatic repetition;
• haptic feedback at the beginning of each new cycle;
• a countdown and cycle counter;
• an immediate stop control.

The application runs independently on Apple Watch, without accounts, a server, advertising, analytics, or third-party dependencies. It was prepared in French, English, German, Italian, and Spanish.

These choices simplified the architecture and privacy questions. They still left a challenge specific to the watch: the timer needed to remain useful when the screen turned off.

First, check the actual environment

Before development, I asked Codex to inspect the Mac: Xcode installation and configuration, command-line tools, Swift, Git, the watchOS SDK, simulators, and signing capabilities.

This step may seem secondary, but it helps distinguish a project problem from an environment problem.

The agent could then use several ways to act:

Tool or interface	Use in the project
Build tools	Swift checks and build preparation
Xcode and Organizer	Configuration, signing, archiving, validation, and upload
Simulator	Interface and user-flow checks, screenshots
Controlled browser	Apple services and App Store Connect configuration
Git and GitHub	Preserving the source and synchronizing changes

Some operations encountered restrictions on CoreSimulator access from the execution environment. Work then continued through Xcode. This distinction was later incorporated into the workflow: identify the available execution channel and verify the outcome before declaring a task complete.

A small application with several technical concerns

The application was developed in Swift and SwiftUI. The project separates the entry point, interface, and timer logic into files such as StretchTapApp.swift, ContentView.swift, and IntervalTimer.swift.

This separation makes it possible to change the timer’s behavior without putting all the logic inside the screen.

The work also covered:

• compatibility with the targeted watchOS versions;
• localized resources;
• the icon and its asset catalog;
• application identifiers;
• signing settings;
• the Xcode scheme used for archiving;
• the structure of the distribution package.

The minimum deployment target was lowered to watchOS 9 during the project. The archive scheme was also corrected to produce the distribution container with the Watch application embedded.

These details explain why “the code compiles” is an intermediate milestone. The deliverable also needs to be correctly assembled and signed for distribution.

The timer exposed a defect after the first upload

One of the most useful lessons concerned execution when the screen turns off.

The implementation used a watchOS extended runtime session, with a physical-therapy configuration, and included a stop at the system limit for that session.

However, a first build had already been uploaded to Apple before a configuration defect was identified: the required mode was missing from the final configuration file.

The agent corrected it, checked that the timer started and transitioned automatically to the second cycle, and prepared build 2.

The lesson is specific: a setting present in the project, or expected by the code, can still be absent from the built result. Checks therefore need to cover the final package and its behavior.

This experience informed the checks added to the workflow later: identify the exact build, inspect its contents, and avoid reusing evidence from an earlier build after a change.

Signing, archiving, and build identity

Preparing distribution required an Apple Distribution certificate and provisioning profiles matching the project’s identifiers.

The agent used Xcode and Apple’s interfaces to prepare signing, create the archive, and validate it before uploading to App Store Connect.

The process distinguishes several states:

1. The project compiles.
2. A signed Release archive exists.
3. The archive passes Apple validation.
4. The build is uploaded and processed in App Store Connect.
5. The build is selected for submission.
6. Apple reviews the application.
7. The application may become publicly available.

These states were formalized in the skills. A successful upload does not establish approval or publication.

The consolidated workflow also calls for a release identity to be passed between stages: version, build number, identifiers, source commit, signing team, and the archive’s SHA-256 fingerprint.

The purpose is to verify that the audited package is the one being prepared for publication.

Publication work extends well beyond Xcode

The agent prepared descriptions, subtitles, keywords, and promotional text in all five languages. Two Apple Watch screenshots were produced: the interval-selection screen and the running timer.

The support and privacy website was published on GitHub Pages in a separate repository:

StretchTap          → private application source
stretchtap-support  → public support and privacy website

This separation makes the pages accessible without exposing the application source.

The privacy declaration was prepared after inspecting the code: no accounts, network access, tracking, advertising, or third-party SDKs. The public text and App Store listing needed to remain consistent with these characteristics.

I also chose a price of €1.99 and automatic release after approval. Commercial choices and regulatory declarations required my confirmation.

The agent performed the operations; I retained responsibility for the decisions and the information declared.

Apple’s response: demonstrate the application on a real watch

After submission, Apple requested additional information under Guideline 2.1 — Information Needed. The message referred to the developer account’s limited review history.

Apple requested a demonstration on a physical device, a description of the audience and problem being solved, usage instructions, information about external services, and any regional differences.

The demonstration scenario prepared for StretchTap was concrete:

• launch the application on a real Apple Watch;
• select 20 seconds;
• show the countdown;
• let the second cycle appear;
• stop the timer.

The agent prepared a structured response covering the requested points. The demonstration and physical observations still needed to be supplied.

The simulator can help verify screens and interactions. It cannot establish what the user feels on their wrist or replace observations on real hardware.

At this point in the story, StretchTap had been submitted to Apple and had received this request for additional information. Approval and public availability remain separate outcomes.

Turning the experience into skills

After this experience, I wanted to preserve the method for other applications.

Here, a skill is a set of reusable instructions, supplemented where needed by references, templates, and validation scripts. It guides Codex through a task; the available tools perform the operations.

Responsibilities were divided as follows:

Skill	Responsibility
apple-app-product-validator	Clarify and assess an idea, then prepare the brief
apple-app-child-idea-validator	Guide a child’s idea with adult approval
apple-app-builder	Develop, test, and produce the signed package
apple-app-quality-auditor	Inspect the package in a separate audit phase
app-store-publisher	Prepare App Store Connect and manage submission
apple-app-maintainer	Examine signals after publication
apple-app-lifecycle-orchestrator	Coordinate the stages and preserve state

Auditing is separated from development: the auditor does not change the code. A defect goes back to the Builder, and the corrected package must be checked again.

This separation of responsibilities does not, by itself, guarantee the absence of errors. It makes handoffs and the expected evidence more explicit.

Persistent state to resume the work

The orchestrator manages the main sequence:

Idea → Validation → Development → Audit → Publication → Maintenance
                         ↑         |
                         └── Fix ──┘

It defines a control dossier containing, among other files:

AppleAppWorkflow/
├── workflow-status.json
├── owner-profile.json
├── workflow-journal.md
└── decision-log.md

The status records the current stage and next action. The journal records transitions. The decision log makes it possible to reuse an authorization or preference already given within its scope.

This addresses a difficulty in the first journey: confirmations were sometimes repetitive. A decision should not need to be requested again simply because the work moves to another stage.

The workflow still preserves application-specific decisions, such as price, release method, and legal declarations.

The workflow’s own checks needed testing

Auditing the skills revealed weaknesses in the validators themselves.

Some checks trusted the declared fields in a dossier too much. Others blocked legitimate situations, such as recording verified information or beginning maintenance before its initial dossier had been completed.

The corrections strengthened several areas:

• the existence of files and consistency of their fingerprints;
• matching application, platform, build, and signing identity;
• distinguishing website audits from package audits;
• rejecting empty screenshot groups and missing mandatory evidence;
• handling metadata or price changes separately;
• resuming a project without inventing its history.

A later test campaign reported 116 passing tests, supplemented by simulated recovery and rejection scenarios.

These results concern the workflow contracts and validators. They do not certify StretchTap’s behavior on physical hardware and do not constitute Apple approval.

My role in the automation

My involvement focused mainly on the application’s features. The agent handled the technical work and tool interactions, but the conversation also included confirmations, commercial and regulatory decisions, and authentication steps.

I would therefore describe this experience as largely automated execution, guided by my product choices and bounded by human decision points.

StretchTap made it possible to reach a real submission and build a more explicit method from the difficulties encountered. The next validation is to use the consolidated chain from the beginning of another project, then observe its behavior through publication and updates.

An experiment with my family, too

I also added a skill to help my nine-year-old daughter define an application: apple-app-child-idea-validator.

The skill adapts the conversation by asking one or two short questions at a time. It helps the child explain who will use the application, its three main features, and the intended user flow, then restates the idea so the child can correct it.

Technically, it prepares two outputs: a summary accessible to the child and an analysis for the adult, including feasibility and privacy considerations. After an adult approves the scope, it produces a product-brief.md file that apple-app-builder can use to develop the application.

The sequence becomes: the child’s idea → an adult-approved brief → development → testing in Xcode Simulator.

My daughter was then able to test her application in the simulator and see how her choices translated into a usable interface. Hardware-specific behavior still needs to be checked on a real device.

This experience gives the workflow an educational dimension too: helping a child, accompanied by an adult, follow the path from an idea to a first application.

Continue with a related practical example: Customizing Dynamics 365 Business Central with Cursor: A New AI-Powered Approach ?.