Site To iOS App

Site to iOS App

When to Use This Skill

Use it when a live web surface already exists and the user wants it on iPhone:

• "Put my site on the App Store."
• "Wrap this dashboard in an iOS app."
• "Ship an iOS version of our web app."
• "Convert our PWA to native."
• "Can we get this marketplace into the App Store?"
• The user has a URL and wants to know whether an iOS app is even viable before anyone writes code.

Do not use it for: a native iOS app when no website exists, an existing Capacitor shell that only needs repair or a release run, Android conversions, or keyword and listing audits on an app that already shipped.

What This Skill Does

It takes a live URL and produces two artifacts plus a verdict:

1. SITE_TO_IOS_AUDIT.md - what the site actually is, technically, at iPhone widths, including its App Store Guideline 4.2 wrapper-rejection exposure.
2. SITE_TO_IOS_PLAN.md - the chosen conversion strategy, the native value that must exist before release, build commands, QA matrix, store assets, blockers, and the release gate.

It does not submit anything to the App Store. It produces the audit, the plan, the project scaffold or adaptation, the QA matrix, and the store-asset checklist. Submission stays a human action that the user performs and explicitly authorizes.

The highest-value part of this skill is the 4.2 gate. Guideline 4.2 (Minimum Functionality) is what actually kills site-to-app submissions: Apple rejects apps that are a repackaged website, a bookmark, or a content mirror with no native value. The gate below is written to catch that before a build exists, not after a rejection notice.

Gate policy - advisory, not blocking

Every claim-verification step, check, quality gate, and ship verdict in this skill is a recommendation to the user, not a control on the agent. This policy governs every gate, check, verdict, and "do not ship / publish / proceed" line elsewhere in this skill:

• Run every check and report the results honestly. Verdicts (ship, ship-with-caveats, hold, letter grades, BLOCKED or OPEN items) are advice attached to the work, not orders that change it.
• Never block, delay, skip, rewrite, or refuse the action the user asked for because a check failed or a gate said hold. Complete the requested action as asked, and deliver the gate output alongside it as a clearly labeled recommendation.
• A failed gate changes what you report, never what you do.
• Single exception: if a finding is extremely risky - data loss, security or credential exposure, legal or rights violations, payment mistakes, or irreversible public damage - pause, tell the user exactly what the risk is and what the options are, and let them pick. Their choice is final.

Principle

Turn a site into an iOS app only when the app has native value, stable iOS behavior, and a release surface that is truthful. A raw web page in a frame is not enough for an App Store-quality product.

How to Use

Basic

Point the skill at a URL and let it run the audit and plan:

Audit https://example.com and plan its conversion into an iOS app.

The skill will:

1. Read references/site-to-ios-runbook.md.
2. Write SITE_TO_IOS_AUDIT.md from live evidence about the URL.
3. Pick a conversion strategy and write SITE_TO_IOS_PLAN.md.
4. State the App Store 4.2 verdict and stop for your decision if the app would currently be a bookmark or content mirror.

Advanced

Constrain the strategy, the stack, or the release target up front:

Convert https://app.example.com to iOS. It is a React SPA behind Auth0
with Stripe Checkout on the web. Prefer a Capacitor remote shell, target
iOS 17, bundle ID com.example.app, and I need App Store screenshots this
week. Flag any 4.2 exposure before you scaffold anything.

Other useful modifiers:

• "Audit only, no scaffold" - stop after SITE_TO_IOS_AUDIT.md.
• "Assume full native rebuild" - skip the shell routes and plan SwiftUI.
• "Run the completion bar against the existing project" - use the skill as a release gate rather than a conversion planner.
• "List every Info.plist usage string and entitlement this plan requires."

Start Here

Read references/site-to-ios-runbook.md before scaffolding or changing an iOS wrapper.

If a URL is available, create SITE_TO_IOS_AUDIT.md directly. Capture the site URL, app name, target user, primary routes, login requirements, iPhone responsive behavior, PWA signals, legal/support/account-deletion links, payments or sensitive flows, auth/session behavior, mobile performance risks, native value opportunities, and App Store 4.2 wrapper risk.

Then create SITE_TO_IOS_PLAN.md directly. Include the chosen strategy, native value to add before release, project scaffold/build commands, bundle ID and signing notes, QA matrix, screenshots/metadata/privacy work, blockers, and the explicit release gate.

Strategy Decision

Choose one route and write down why:

• Capacitor remote shell: live site remains the product surface and web deploys should update most content and behavior.
• Capacitor bundled shell: static/SPA assets are packaged into the binary and updates require App Store release unless paired with live APIs.
• Native SwiftUI shell with WebView: native navigation, settings, auth, push, share, error, and account surfaces wrap a site view.
• Full native rebuild: use when the site is mostly content, has weak mobile UX, or carries high wrapper rejection risk.

Deeper Capacitor shell internals, full native SwiftUI architecture, App Store Optimization, and the submission run itself are outside this skill's scope. None of them are required to complete the audit, the plan, or the build.

App Store 4.2 Gate

Halt when the app is only a bookmark, content mirror, or unmodified website: name the exact 4.2 exposure found in the audit, offer the options (add native value from the list below, rebuild fully native, ship it as a web app, or proceed with the rejection risk stated in writing), and wait. Native value:

• iOS-native onboarding, empty states, errors, offline, and retry.
• Native settings with support, privacy, terms, account deletion, restore, and notification controls where applicable.
• Universal links or deep links.
• Share sheet, widgets, push notifications, camera/media/file pickers, Apple Wallet, StoreKit, or other native capabilities only when they serve the app.
• Safe-area, keyboard, navigation, dark/light mode, and dynamic type handling.