Understand the small iOS app experiment

Outcome

You will understand the business and delivery system behind a small iOS app, define what AI may assist with, and create a sixty-day experiment that can end in continue, narrow, reprice, pause, or stop.

A small app completes one mobile job

A small app is not a reduced version of a large startup. It helps a recognizable person complete one useful outcome in a context where an iPhone or iPad is a natural tool. It earns a place on the device through speed, reliability, privacy, accessibility, and a reason to return.

The minimum business system connects:

a repeated user situation;
evidence that the existing workaround is costly or unreliable;
one complete mobile workflow;
a testable product promise;
code and data a developer can understand and maintain;
accurate privacy and App Store disclosures;
a monetization model proportional to continuing value;
support, correction, update, and closure paths.

Generating a screen with AI proves none of these. The experiment succeeds only when representative users can complete the promised job safely and the developer can operate the product after release.

The running example

This Playbook follows ScopeSnap, a fictional offline-first iPhone utility for independent consultants. During a client conversation, the user records a change request, compares it with an agreed project baseline, labels the request as a possible defect, included revision, assumption issue, or new scope, and exports a neutral decision note.

ScopeSnap does not interpret contracts, provide legal advice, contact clients, or decide whether extra payment is owed. Its first version stores records locally on the device. It requests no contacts, microphone, photos, location, tracking, account, or cloud access. The app can export a user-reviewed text summary through the system share sheet.

AI assists the founder with research synthesis, SwiftUI scaffolding, test ideas, debugging explanations, and review checklists. AI is not embedded in the app. This separates AI-assisted development from an AI product and avoids transmitting sensitive client notes to a model.

Separate three hypotheses

Problem hypothesis: independent consultants experience enough uncertainty around change requests to use a dedicated mobile record.

Product hypothesis: a fast offline capture, comparison, and export workflow is better than notes, memory, or a generic project tool for this moment.

Business hypothesis: enough users value the complete workflow to justify a one-time paid unlock or another honest price after testing.

Test these in order. Working code cannot validate the problem. Positive interviews cannot validate usability. Downloads cannot validate willingness to pay or retention.

Define a complete vertical slice

The first release supports one path:

create a project baseline;
record a request in the client's words;
compare it with the baseline using guided questions;
select a provisional category and confidence;
add impact and missing information;
review a neutral decision note;
export through the system share sheet;
reopen, edit, archive, or delete the record.

The app needs empty, validation, success, edit, delete, export-cancel, and storage-failure states. A happy-path demo without these states is not a usable slice.

Define what AI may do

AI can accelerate bounded work when the developer supplies context and verifies the result:

explain an unfamiliar framework or compiler error;
propose a small type or view structure;
draft code from explicit acceptance criteria;
generate edge cases and test names;
compare an implementation with Apple documentation;
review a diff for force unwraps, broad permissions, logging, or missing states;
help write release notes from a verified change list.

AI must not receive production credentials, signing assets, private user data, unpublished client material, full subscriber exports, or secrets. It must not make final decisions about privacy, security, accessibility, payments, legal compliance, or App Store policy.

Every generated change remains untrusted until the developer reads the diff, understands the behavior, runs tests, and observes it on a representative device.

Keep the architecture intentionally small

ScopeSnap uses SwiftUI, a modest local persistence layer, plain value types for decision logic, and the system share sheet. It does not begin with authentication, a backend, synchronization, push notifications, advertising SDKs, analytics SDKs, or third-party AI.

This is not anti-growth. It reduces failure surface while the problem and workflow are unproven. A backend can be added only when a validated user need cannot be served safely on-device.

Choose evidence at six levels

Problem evidence: interviews and observed workarounds show a repeated situation.

Usability evidence: representative testers complete the core task without coaching.

Technical evidence: tests and device observation show reliable storage, export, recovery, and purchase behavior.

Trust evidence: disclosures match code, permissions are minimal, accessibility tasks work, and serious defects receive correction.

Market evidence: the product page attracts suitable users and support questions match the promise.

Business evidence: a bounded paid test shows purchase, refund, support, and net proceeds behavior without depending on optimistic forecasts.

No single metric replaces the set. A five-star review from a friend does not validate demand. A successful App Review does not certify quality or legal compliance.

Budget the sixty-day experiment

Days 1–12: conduct interviews, inspect workarounds, define exclusions, and run a low-fidelity task test.

Days 13–22: prepare the project, architecture, repository, data model, acceptance tests, privacy map, and AI-use rules.

Days 23–40: build one vertical slice, then harden storage, export, errors, accessibility, and device behavior.

Days 41–50: run internal and external TestFlight testing, fix blockers, freeze the release candidate, and prepare truthful metadata.

Days 51–60: submit, release gradually when appropriate, support users, evaluate acquisition and utility, and make one operating decision.

The calendar is a cap, not a promise that review or discovery will follow a fixed schedule. Hold release when evidence, privacy, or quality is incomplete.

Model real costs

Include a compatible Mac, supported Xcode version, test device access, Apple Developer Program membership, design or accessibility help, domain and support page, paid tools, contractor review, tax or legal advice, and founder time. Apple currently lists its Developer Program at 99 USD per membership year in many regions, subject to local availability and terms.

Create a cash cap that the founder can lose without depending on future sales. Do not buy annual tools, a backend, or advertising before the core user path works.

Protect nonnegotiable boundaries

Exclude:

cloning a competitor's code, assets, listing, or distinctive interaction;
submitting generated code the developer cannot explain;
using private repositories or user data in an AI tool without authority;
requesting permissions “for future features”;
hiding data collection behind a generic privacy policy;
using external checkout to unlock digital app features contrary to applicable rules;
manipulating ratings, reviews, search ranking, or screenshots;
presenting a classification aid as legal advice;
forcing subscription onto a product without recurring value;
continuing to sell when a material defect cannot be supported.

Choose valid outcomes

At the end of the experiment, the founder may:

continue the same narrow free beta;
release a one-time paid unlock;
narrow the user or workflow;
change the artifact or platform;
add one evidence-backed capability;
pause to repair privacy, reliability, or support;
stop and remove or archive the app responsibly.

Returning to research is not failure. Rejecting a subscription for a static utility can be a stronger business decision than maximizing recurring revenue on paper.

Common failure modes

Beginning from an app idea. No repeated user situation is established.

Calling generated screens an MVP. The workflow cannot complete or recover.

Adding AI to the product by default. Sensitive data and cost expand without proof.

Treating App Review as QA. Apple review is not the developer's test program.

Choosing subscription first. Price is disconnected from recurring value.

Requesting broad permissions. Convenience creates privacy and review risk.

Measuring downloads only. Utility, retention, support, refunds, and cost disappear.

Deliverable

Write an iOS app experiment charter containing:

user, mobile situation, and repeated problem;
one complete outcome;
problem, product, and business hypotheses;
vertical-slice path and failure states;
allowed and prohibited AI assistance;
initial architecture and excluded infrastructure;
six evidence levels;
sixty-day phases;
budget, privacy, payment, and support boundaries;
continue, narrow, monetize, pause, or stop conditions.

Acceptance criteria

The charter passes when:

the app solves one mobile job rather than a category;
AI use has a verification owner;
the slice includes recovery and deletion;
no unnecessary backend or permission is assumed;
paid behavior waits for utility evidence;
costs and time have caps;
trust evidence is separate from store approval;
stopping protects testers and customers.

Next action

Save the charter as 01-ios-app-experiment-charter.md. The next lesson validates the problem through recent behavior, workarounds, and task tests before any production code is written.

Source notes

Apple requirements, fees, and regional terms can change. Verify the current agreement and documentation for the actual developer account and storefronts.