Publish Website App to App Store and Google Play

To publish a website app to the App Store and Google Play, create developer accounts you own, prepare signed builds, complete accurate listings and privacy declarations, test the full mobile journey, then submit each app for review. Apple charges $99 per membership year; Google Play lists a one-time $25 registration fee. Neither store guarantees approval.

Apple and Google use separate systems. Prepare the product and brand information once, then complete each store’s platform-specific steps.

SiteTo.App handles the build half of this process. You enter a public, mobile-friendly website, add your app name, icon, launch screen and menus, and preview the app on your phone for free. A one-time build fee ($29 Android, $79 iOS, $99 both) gets you iOS and Android builds ready for you to submit, and the steps below are yours.

Fees checked October 12, 2026: Apple membership and Google Play registration. SiteTo.App uploads iOS builds to the customer’s TestFlight account and supplies Android APK or AAB downloads; the customer submits both listings.

Before you create the store listings

Make sure the website is ready to behave like the core of an app:

• It uses HTTPS on every screen
• Layouts work at phone widths without zooming
• Navigation, login, checkout, and forms work with touch
• All links and support pages are live
• Loading, empty, error, and offline states are understandable
• The privacy policy accurately describes the app and website
• Users can find account and data controls

Apple’s review guidance says submissions should be final, with functional URLs and no placeholder content. Google similarly expects the listing to describe what the app actually delivers. If you are packaging a Wix site, the Wix mobile app guide compares Wix’s own options with a site-based build, and the platform checklist covers booking, member, and checkout journeys.

Step 1: Create accounts owned by the right entity

Apple

Join the Apple Developer Program as an individual or organization. Apple currently lists membership at $99 per year. An organization must verify its legal identity and generally needs a D-U-N-S Number.

If customers should see a company name as the seller, enroll the company rather than a contractor. Apple requires certain regulated services to be submitted by the legal entity that provides them.

Read Apple's current membership requirements.

Google Play

Create a Play Console developer account, choose the appropriate personal or organization account type, pay the applicable registration fee, and complete identity verification. Google currently lists a one-time $25 fee for full distribution in its published access terms.

New personal accounts have a testing requirement before production access. Personal Play Console accounts created after November 13, 2023 must run a closed test with at least 12 testers who stay opted in for 14 consecutive days before they can apply for production access. Organization accounts are exempt. Recruit a few more than 12 testers so a dropout does not reset the clock, and check the dashboard rather than assuming an app can move directly to a public release.

Step 2: Reserve the app identity

Choose an app name, bundle ID for iOS, and package name for Android. Package identifiers are technical, permanent identities such as com.yourcompany.yourapp; changing the visible app name later does not change them.

Use a name you have the right to use. Search both stores and relevant trademark databases for conflicts. Prepare a high-resolution square icon without transparent areas where a store disallows them.

Step 3: Produce signed builds

An iOS app is archived and uploaded through Apple’s toolchain to App Store Connect. Android uses a signed Android App Bundle for Google Play. Both stores enforce minimum build requirements: since April 28, 2026, App Store Connect rejects uploads that are not built with Xcode 26 and the iOS 26 SDK, and Google Play now requires new apps and updates to target Android 16 (API level 36). A no-code converter or managed service can produce these artifacts, while a source-code template requires you to build them.

SiteTo.App provides an APK or AAB for Android; the Android APK/AAB guide explains which one to use. For iOS, it uploads the signed build to TestFlight in your App Store Connect account; you then prepare and submit the App Store listing.

Keep signing credentials and account access under business control. Losing keys or allowing a former contractor to own the only administrator account can make future updates difficult.

Step 4: Add useful mobile features

This is especially important for website-based iOS apps. Apple’s minimum-functionality rule says an app should include features, content, and interface value beyond a repackaged website.

Useful additions may include:

• Native navigation tailored to mobile tasks
• Push notifications users explicitly choose
• Deep links into relevant content
• Native share, upload, camera, or download behavior
• Saved content or selected offline access
• Clear splash, loading, error, and no-connection screens

Do not add features only to check a box. Reviewers and users both benefit when native behavior supports the app’s actual purpose.

Step 5: Create accurate store assets

Prepare the app name, short and long descriptions, keywords where supported, category, icon, phone screenshots, contact details, support URL, and privacy-policy URL.

Screenshots must show the real app. Avoid unverified superlatives, fake awards, invented testimonials, or features that are not in the submitted build. Use the first screenshots to explain the core job in plain language.

For a website-to-app product, a strong sequence might show:

1. The primary home or discovery screen
2. The key transaction or member experience
3. Mobile navigation
4. A useful native feature such as notifications or saved content
5. Account or support controls

Step 6: Complete privacy and content declarations

Both stores ask what data the app collects, how it is used, whether it is linked to identity, and whether third parties receive it. Audit the website, analytics, authentication, payment services, notifications, advertising, and any embedded tools.

The answers must describe the whole app experience, not only the native shell. If the website collects an email address or loads an analytics SDK inside the app, consider it in the disclosure.

You may also need to answer questions about age rating, ads, content rights, encryption, financial features, health information, location, or children’s access.

Step 7: Test before review

iOS testing

Use TestFlight to install the release candidate. Test on more than one screen size if possible. Verify sign-in, Apple-required account behavior, external payment flows where permitted, permissions, push notifications, links, and deletion controls.

Android testing

Use Play Console’s internal or closed testing tracks. Internal testing is the quickest way to share a build with your own team. If your personal account was created after November 13, 2023, the closed test described in Step 1 must run for 14 consecutive days with at least 12 opted-in testers before you can apply for production.

On both platforms, test slow connectivity, a fresh install, an expired login, denied permissions, the system back gesture, file selection, and any path that opens another app or browser.

Step 8: Give reviewers complete access

If the app requires login, supply an active demo account and instructions. Keep that account working throughout review. Explain non-obvious features, special hardware needs, regional restrictions, and where reviewers can find native functionality.

Google specifically advises developers to provide valid credentials for restricted content. A reviewer who cannot get past login cannot verify the app.

Step 9: Submit each app

App Store submission

In App Store Connect, select the uploaded build, finish required metadata and compliance questions, add review notes, and submit the version. Monitor messages in App Store Connect and respond precisely if Apple asks for information.

Google Play submission

In Play Console, complete the app content and store-listing tasks, upload the app bundle to the correct track, add release notes, resolve policy warnings, and roll out the release. Google Play uses Android App Bundles to create optimized packages for devices.

Google’s release documentation is the source of truth for current console steps.

Common reasons website apps are rejected

The app feels like a thin website wrapper

Improve native navigation and app-specific utility. Make sure the core tasks work well on iOS, not simply a desktop page inside a frame.

Reviewers cannot sign in

Supply working credentials, disable expiring one-time codes for the review account when safe, and explain the login steps.

The listing is misleading

Remove screenshots or claims that do not match the build. Describe limitations clearly.

Privacy answers are incomplete

Audit web trackers and third-party services, not just native code. Make the privacy policy public and specific.

Links, purchases, or uploads break inside the app

Test every external handoff and return path on a real device. Decide intentionally which links remain in-app and which open the browser.

Required account controls are missing

If users can create an account, review current deletion and data-control requirements for both stores and expose the needed path clearly.

What happens after approval?

Choose whether to release immediately, manually, or in stages when the platform supports it. Watch crashes, failed web requests, login errors, user reviews, and support tickets. Keep store descriptions and privacy disclosures current when the product changes.

Website content can update without a new app build, but native configuration, SDK, permission, signing, or policy changes may still require a new release. Expect at least one store-driven rebuild a year as Apple and Google raise their minimum SDK targets, and confirm in advance who will produce it.

Common questions

Can I publish a website app in my own store accounts?

Yes. Use the Apple Developer and Play Console accounts owned by the person or business that should control the listings. SiteTo.App uploads the iOS build to TestFlight in your App Store Connect account and gives you an Android APK or AAB download. You complete the listings and submit them for review yourself.

Does SiteTo.App submit apps to Apple and Google for me?

No. SiteTo.App prepares builds, but the customer owns the store accounts, fills in metadata and privacy answers, and submits. For iOS, the build reaches TestFlight in your own App Store Connect account. For Google Play, use the downloaded AAB. Both stores decide whether the submitted app meets their current requirements.

How much are the developer account fees?

$99 per membership year is Apple’s listed Developer Program price, and US$25 is Google Play’s listed one-time registration fee. Both are separate from the SiteTo.App build price and are paid to the stores. Check the official linked pages when you enroll; account verification or testing can also affect your launch schedule.

Should I upload an AAB to Google Play?

Yes. An AAB is the Android App Bundle used for a Google Play submission. SiteTo.App also offers an APK download for Android distribution or testing needs. Keep the package identity and signing details under your control, then test the AAB-derived release through Play Console before asking for production access.

Does a successful build guarantee app-store approval?

No. A build is only one part of a complete submission. Apple and Google review the app, listing, privacy disclosures, account setup, and working experience. Provide reviewer credentials when login is required, verify every important mobile flow, and respond to review messages with specific fixes. A thin website wrapper can still be rejected.

Publishing checklist

• Developer accounts are owned by the correct person or company
• The website is responsive, secure, and production-ready
• The app makes key mobile tasks easier
• Both signed builds install and run on real devices
• Store names, descriptions, icons, and screenshots are complete
• Privacy and content declarations cover the web experience
• Support and privacy URLs work without login
• Reviewer credentials and instructions are current
• Pricing and availability are configured
• A team member is assigned to monitor review messages

If you have not created the builds yet, begin with our guide to converting a website into an app or preview your site in SiteTo.App.