Apple's Requirements for Web Apps in the App Store

Apple allows web-based iOS apps to be considered for App Store distribution, but a packaged website must meet the same review standards as other submissions. The main requirements concern useful functionality, reliable mobile behavior, privacy, payments, account access, and accurate store information. An app shell alone does not establish compliance, and a thin repackaging of a website can raise minimum-functionality concerns. Before creating a release build, evaluate the complete customer experience against Apple’s current guidelines, including rules that depend on your business model or storefront. Passing technical checks or obtaining a signed IPA does not guarantee App Store approval.

Minimum functionality requires more than a working URL

Apple’s App Review Guidelines are the primary reference, particularly section 4.2 on minimum functionality. Review the whole product rather than searching for a single feature that supposedly guarantees acceptance. A useful account-management tool and a container displaying promotional pages present very different experiences.

Prioritize a coherent mobile workflow: readable screens, predictable navigation, responsive controls, useful error states, and appropriate handling of external destinations. Notifications or a splash screen do not compensate for an otherwise incomplete product. Explain what users accomplish in the app, and avoid claiming that visual polish alone satisfies Apple’s requirements.

Privacy declarations must match the website and its services

A web-based app may load analytics, authentication, support widgets, advertising tools, and payment services from its website. Inventory those services before completing the store’s privacy answers. The fact that code runs on a web page does not make its collection irrelevant to the app experience.

Use Apple’s app privacy details guidance to work through data categories and purposes. Keep the privacy policy, permission explanations, and declarations consistent with actual behavior. Investigate whether tracking rules apply rather than assuming that all analytics requires tracking permission or that none of it does.

Payments depend on what customers buy

Distinguish digital content and functionality from physical goods and services consumed outside the app. Apple’s rules can also differ by category, storefront, and program eligibility. A checkout accepted on the public website is not automatically an acceptable in-app purchase flow.

Document each transaction: what is purchased, where it is consumed, how users discover the purchase option, and which storefronts are involved. Then compare that flow with the applicable payment provisions in the guidelines. Do not move checkout into an external browser as a presumed workaround. Resolve uncertain business-model questions before investing in submission assets.

Prepare a web-based iOS submission in six steps

1. Audit the complete mobile journey

Test account creation, sign-in, password resets, core tasks, purchases where applicable, and sign-out. Include slow networks, expired sessions, and server errors. Remove placeholders and links that lead users into unfinished desktop workflows. Reviewers need a functioning product, not a roadmap.

2. Address login and account deletion rules

Check whether your authentication design triggers Apple’s requirements for an equivalent login option, including Sign in with Apple where applicable. If the app supports account creation, assess the requirement to initiate account deletion within the app and any applicable exceptions. Hiding an account is not necessarily deletion.

3. Review permissions and bundled integrations

Request only capabilities you use and provide clear purpose descriptions where required. Understand any native components or third-party SDKs included in the build. Where applicable, investigate privacy manifests and required-reason API declarations rather than assuming the web app’s privacy policy covers every build-level obligation.

4. Create accurate listing materials

Prepare screenshots of the actual app, a truthful description, support details, privacy links, and the appropriate age-rating answers. Avoid implying capabilities that only exist in a browser or future release. Keep names and branding consistent across the app, store listing, and linked website.

5. Supply working reviewer access

Use Apple’s App Review preparation guidance when preparing notes and credentials. Provide access to relevant roles and explain non-obvious flows. If functionality depends on hardware, location, or an enterprise account, explain the dependency and provide an appropriate review method.

6. Test the actual release build

Check the signed app on supported devices, not just the website in Safari. Inspect safe areas, keyboard overlap, file uploads, external links, and navigation after authentication redirects. A reliable website can still behave differently in an embedded runtime. See the broader iOS conversion guide for the packaging context.

Pre-submission evidence checklist

• Record why the app provides a useful mobile experience beyond promotional content.
• Confirm current payment rules for each product and storefront.
• Reconcile privacy disclosures with website services and bundled code.
• Verify account deletion and applicable login requirements.
• Provide working review credentials and clear instructions.
• Check screenshots, support URLs, permission messages, and error states.
• Retest the release build after the final website deployment.

PwatoApp builds and the owner’s review responsibilities

PwatoApp creates Android APK/AAB and iOS IPA builds from an existing web app. The €49.99 one-time price includes unlimited Android and iOS builds with release signing; the dashboard is at /build. Building and signing are not compliance certification. The app owner remains responsible for developer enrollment, privacy declarations, payment compliance, submission information, and responding to review feedback.

FAQ

Will adding push notifications guarantee approval?

No. Review evaluates the overall app and its compliance. Adding one device feature does not cure inadequate functionality or an unsuitable business model.

Can the website change after review?

Web content can change, but that does not remove your obligations. Keep changes compliant and accurate, and submit a new app version when required. Do not use remote updates to conceal functionality from review or evade Apple’s rules.