Do it yourself
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main pageHow Kiro specs and steering work
Kiro, the spec-driven agentic IDE from AWS (also available as a CLI and on the web), works in two layers. Specs live in .kiro/specs/<spec-name>/ and consist of three files: requirements.md with user stories and acceptance criteria in EARS notation ("WHEN [condition] THE SYSTEM SHALL [behavior]"), design.md with architecture, sequence diagrams, error handling and testing strategy, and tasks.md, a list of discrete, trackable implementation tasks. Bug fixes use a Bugfix spec with bugfix.md instead of requirements. You can run tasks one at a time or all at once; then Kiro builds a dependency graph and runs independent tasks in parallel "waves".
Steering files give Kiro lasting knowledge about the project. They live in .kiro/steering/ (or globally in ~/.kiro/steering/; workspace rules win on conflict). Kiro can generate product.md, tech.md and structure.md for you, and it also reads AGENTS.md. Each steering file chooses an inclusion mode in its frontmatter: always, fileMatch, manual or auto (steering documentation).
For store readiness this split is exactly right. Steering carries the permanent facts (the app runs in a WebView, these rules always apply); the spec carries the one-time project of getting the app through review. The spec files are plain Markdown, so they also work as a brief for Claude Code or Codex if you switch agents later; the AI coding agents overview compares the options.
Steering file: .kiro/steering/native-app.md
The frontmatter must be the first thing in the file. #[[file:...]] pulls another file into the context; drop that line if you have no review notes yet. For rules that only matter while editing the native projects, create a second file with inclusion: fileMatch and a fileMatchPattern for ios/** and android/**.
markdown
---
inclusion: always
---
# Native app context (WebViewGold)
This web app is published as iOS and Android apps built with WebViewGold.
The apps load https://app.example.com in a WKWebView (iOS) / Android WebView,
so every deploy is live in both apps without a store update.
- Detect the app with isNativeApp(): navigator.userAgent contains "WebViewGoldApp"
(set via useragent_iphone / useragent_ipad in Config.swift, USER_AGENT in Config.java).
- Native features are URL schemes handled by the wrapper. Use only schemes listed in
https://www.webviewgold.com/llms-full.txt and always keep a browser fallback.
- No window.open popups for sign-in or payment inside the app.
- Store rules: Apple 4.2 (more than a website), 4.8 (Sign in with Apple next to other
social logins), 5.1.1 (privacy policy, in-app account deletion), 3.1.1 (digital
goods use in-app purchase on iOS). Google Play: account deletion + Data safety.
- Never edit signing, provisioning, keystores or the purchase code in ios/ or android/.
#[[file:docs/store-review-notes.md]]requirements.md: native app readiness
Create a Feature spec with the Requirements-First workflow (Kiro pane, the + button under Specs, or choose Spec in chat) and replace the generated file with this, adapted to your routes. Then run Analyze Requirements to find gaps and contradictions before the design starts.
markdown
# Requirements: Native app readiness
## Introduction
Prepare the web app for publication as iOS and Android apps built with WebViewGold,
so that it can pass App Store and Google Play review on the first submission.
## Requirement 1: Mobile layout
**User story:** As a phone user, I want every screen to fit and respond to touch.
1. WHEN any route renders at a viewport width of 320 px THE SYSTEM SHALL show no horizontal scrolling.
2. WHEN a fixed header or tab bar renders THE SYSTEM SHALL pad it with env(safe-area-inset-top) or env(safe-area-inset-bottom).
3. WHEN an interactive element renders THE SYSTEM SHALL give it a touch target of at least 44 x 44 px.
## Requirement 2: Account deletion
**User story:** As a user, I want to delete my account inside the app.
1. WHEN a signed-in user opens Settings THE SYSTEM SHALL show a Delete account action.
2. WHEN the user confirms deletion THE SYSTEM SHALL delete their data and auth record server-side, sign them out and show a confirmation.
3. WHEN anyone opens /delete-account THE SYSTEM SHALL explain how to delete an account in the app and by email.
## Requirement 3: Sign-in
**User story:** As a user, I want to sign in the way I prefer without leaving the app.
1. WHEN the sign-in screen offers Google or another third-party login THE SYSTEM SHALL offer Sign in with Apple as an equivalent option.
2. WHEN sign-in runs inside the native app THE SYSTEM SHALL complete without opening a popup window.
## Requirement 4: Legal pages
**User story:** As a reviewer, I want to find the privacy policy and terms quickly.
1. WHEN /privacy or /terms is requested directly THE SYSTEM SHALL return the page with HTTP 200.
2. WHEN the user opens Settings THE SYSTEM SHALL link to both pages.
## Requirement 5: Resilience
**User story:** As a user on a weak connection, I never want to see a blank screen.
1. WHEN a data request fails THE SYSTEM SHALL show an error message with a retry action.
2. WHEN a list has no items THE SYSTEM SHALL show an empty state.
## Requirement 6: App-only presentation
**User story:** As an app user, I do not want to be told to download the app I am using.
1. WHEN the user agent contains WebViewGoldApp THE SYSTEM SHALL hide download-our-app banners, builder badges and links to store listings.
2. WHEN the user agent does not contain WebViewGoldApp THE SYSTEM SHALL keep the website unchanged.
## Requirement 7: Native value
**User story:** As a returning user, I want to be notified about things that matter to me.
1. WHEN a signed-in user finishes onboarding in the iOS app THE SYSTEM SHALL offer an Enable notifications button that calls registerpush://.
2. WHEN the app exposes a push subscription ID (onesignalplayerid) THE SYSTEM SHALL store it on the user profile.
## Requirement 8: Secrets
**User story:** As the owner, I want no secret key to reach a device.
1. WHEN the production bundle is built THE SYSTEM SHALL contain only publishable keys.
My iOS WebView is finally approved. Thanks!!
Prompt to generate the design and tasks
Use it after you have reviewed requirements.md. It forces Kiro to ground the design in your real code and to keep tasks small enough to review.
Paste into Kiro chat with the spec open
Read .kiro/steering/ and AGENTS.md, then the requirements of the native-app-readiness spec. Inspect the codebase before writing anything: base every design decision on the routes, auth providers, database and hosting this project actually uses, and list anything a requirement assumes that you could not find. Design: describe the isNativeApp() utility and where it is used, where the account deletion logic runs on the server and how it authenticates the caller, how the push subscription ID reaches the user profile, the shared loading/empty/error component, and how Sign in with Apple fits the existing auth setup. Add a sequence diagram for account deletion. Nothing in the design may move a secret key into client code. Tasks: one task per reviewable change, each referencing its requirement numbers and ending with a manual test step at 375 px width. Make the first task a report-only payment inventory (where digital goods or subscriptions are sold), with no code changes. Do not create tasks that touch signing, provisioning, keystores or the bundle identifier in ios/ or android/. Stop after design.md and wait for my review before writing tasks.md.
Running the spec without losing control
A spec is only as good as the review gates you keep.
Write steering first
Generate the foundation files (product, tech, structure), then add the native-app steering file above. Without it, Kiro designs for a desktop browser.
Create the spec and review requirements
Use a Feature spec with the Requirements-First workflow, not Quick Spec: Quick Spec writes requirements, design and tasks in one pass without approval gates. Comment on exact passages with Markdown Review and run Analyze Requirements.
Review the design like a reviewer would
Check three things: deletion happens on the server and removes the auth user, no popup appears in any sign-in path inside the app, and no secret key moves to the client. Everything else is taste.
Run the first tasks one by one
A good task reads like
- [ ] 4. Add server-side account deletion (Requirements 2.2). Run individually until the layout and auth tasks are merged; parallel waves that edit the same components produce conflicts you then review twice.Deploy and test inside the app
Deploy the web app, then open it in a WebViewGold test build. Requirements 3.2, 6 and 7 can only be verified there.
Configure WebViewGold
Set the URL, the user agent token and the push switches in Config.swift and Config.java. Kiro can edit them if the fileMatch steering file tells it to change values only; signing stays yours.
From spec requirement to store rule
| Requirement | Apple | Google Play |
|---|---|---|
| 1. Mobile layout | 4.0 Design | Broken functionality |
| 2. Account deletion | 5.1.1(v) | Account deletion requirement |
| 3. Sign-in | 4.8 Login services | Not required on Android |
| 4. Legal pages | 5.1.1 Privacy | User Data policy, privacy policy link |
| 5. Resilience | 2.1 App completeness | Broken functionality |
| 6 and 7. App-only UI and native value | 4.2 Minimum functionality | Minimum functionality / webview spam |
Pitfalls
- Requirements written from the prompt instead of the code. Kiro will happily specify a /settings route you do not have. Ask it to list what it could not find.
- Using Quick Spec for this project. Speed is not the bottleneck here; the review gates are the point.
- "Run all tasks" on a fresh spec. Waves run independent tasks concurrently, but "independent" is judged from the task list, not from which files will really change.
- Spec drift. When you change your mind (for example, Google sign-in via redirect instead of popup), update requirements.md first, then let Kiro update design and tasks.
- Acceptance criteria treated as proof. Kiro can check code; it cannot see how an Apple reviewer experiences your app. Test the build on a phone.
- Payments silently "fixed". Keep the payment inventory report-only until you have read the Stripe vs in-app purchase guide.
Checklist before you submit
- Every task in tasks.md is checked off or deliberately removed, and requirements.md still describes what was built.
- The /delete-account URL is entered in the Play Console; the privacy policy URL in both consoles.
- Sign in with Apple and account deletion were tested inside a real build, not only in the browser.
- Supabase or Firebase backends pass the Supabase checklist or the Firebase checklist.
- The free readiness check passes for your production URL.
Frequently asked questions
Where do Kiro spec files live, and should I commit them?
In .kiro/specs/ with one folder per spec, containing requirements.md, design.md and tasks.md. Commit them; they document why the app behaves the way reviewers saw it and help the next agent or developer.
Does this work in the Kiro CLI or only in the IDE?
Specs and task execution are available in the IDE, the CLI and on the web. Analyze Requirements is listed for the IDE and CLI, and property-based correctness testing for the IDE only, so do the requirements review in one of those.
What is EARS notation?
The Easy Approach to Requirements Syntax. Each criterion names a trigger and an expected behavior (WHEN something happens THE SYSTEM SHALL do something), which makes it testable and easy for an agent to turn into code and checks.
Does Kiro read AGENTS.md?
Yes. Kiro reads AGENTS.md in the workspace root, in subdirectories and in the global steering folder. Those files are always included and do not support inclusion modes, so keep them short and put conditional rules into steering files.
Should the spec cover the WebViewGold Xcode and Android projects too?
Keep the spec about the web app. The native side is a handful of configuration values, not a feature; a short checklist and one reviewed edit of Config.swift and Config.java are enough.
Three ways to get your app into the stores
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
Cloud Builder
$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demoFull Service
$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered by
Winter Sale prices valid until December 31, 2026.