A step-by-step guide to getting your Median (formerly GoNative) web-to-native iOS app through App Store Connect and Apple review, with the pitfalls that trip up wrapper apps.
Before diving in, set expectations. No wrapper, formatter, or AI assistant fully builds, signs, and submits an App Store app on your behalf. Median automates a large part of the work, but the final release runs through Apple's systems.
That means you need an active Apple Developer Program membership, an App Store Connect record, valid signing credentials, and an app that meets Apple's guidelines.
Median offers a submission-assistance service and can produce the signed build, which removes much of the manual Xcode work. Even so, the account, the credentials, and the review outcome are yours.
Apple holds the app owner responsible, not the tool that generated the build. That is why the developer membership and credentials must be under your control.
Going in with that understanding prevents the common frustration of expecting a one-click publish and then hitting Apple's required steps.
A useful way to frame it is that Median removes the mechanical work, while you retain the accountable work. The build automation is real and valuable, but the parts Apple insists a responsible developer must own stay with you.
If you have not already, enroll in the Apple Developer Program. This is required to distribute any app on the App Store and is a separate annual cost paid directly to Apple.
Enrollment can take time, especially for organizations that need a D-U-N-S number for a company account. Start early so it does not block your launch.
A D-U-N-S number identifies your business to Apple and can itself take days to obtain if you do not already have one. Individual accounts avoid this but publish under a personal name.
Once enrolled, you get access to the developer portal and App Store Connect, the two systems you will use throughout submission.
Decide up front whether you want an individual or an organization account, because it affects how your developer name appears on the store and cannot be casually changed later.
In the Apple Developer portal, register an App ID that matches the bundle identifier you set in Median. Enable any capabilities your app uses, such as push notifications.
Median typically manages or guides the signing process, but the identifiers and certificates ultimately live in your Apple account. Consistency across Median, the developer portal, and App Store Connect is essential.
Capabilities you forget to enable here will surface later as validation failures when the build is uploaded. Turn on exactly what your app actually uses.
A mismatch in bundle identifier is one of the most common causes of build upload failures, so verify it carefully.
Treat the identifier as the thread that ties everything together. If it is identical everywhere, most signing and entitlement problems simply do not happen.
In App Store Connect, create a new app record. Enter the app name, primary language, bundle identifier, and SKU.
The SKU is an internal identifier for your own tracking and is not shown to users, but it must be unique within your account. Pick something meaningful.
This record is where your build, metadata, pricing, and review information all come together. Take time to fill it out accurately, because reviewers read it.
Pay special attention to the app description and keywords. For a wrapper app, use this space to emphasize native functionality, not just that it is your website in an app.
Everything a reviewer sees before opening your app shapes their expectations. A description that foregrounds native features primes them to look for the value you built in.
Produce your signed release build with Median and get it into App Store Connect. Median's process handles the archive and signing so you generally do not have to run Xcode Organizer manually, though the build must still pass Apple's automated validation.
After upload, the build appears in App Store Connect after processing, which can take from minutes to longer. Watch for validation emails from Apple flagging entitlement or signing issues.
Those automated checks catch problems like a missing entitlement, an invalid icon, or an unsupported configuration before a human ever reviews the app. Read any rejection email carefully and fix the exact item cited.
Use TestFlight to test the exact build you plan to ship. Internal testing lets your team confirm the release binary behaves like your development builds did.
Remember that TestFlight builds use the production push environment, so if you test notifications here, send through production APNs rather than the sandbox.
Apple requires screenshots for the device sizes you support, an app description, keywords, a support URL, and a privacy policy URL. Prepare these in advance.
Screenshots should show your actual app, ideally highlighting native elements like navigation bars, tab bars, or a notification. Marketing-only imagery that misrepresents the app can itself trigger rejection.
Complete the App Privacy questionnaire honestly. Because your app is web-based, be clear about what data your website and any plugins collect, including analytics and push tokens.
Apple expects the privacy answers to match what the app actually does. An inaccurate questionnaire is a compliance problem, not just a paperwork one.
Also set your age rating and category accurately. Misclassification is an easy, avoidable reason for rejection or delay.
When everything is complete, submit for review. Expect Apple to scrutinize web-wrapper apps under Guideline 4.2, Minimum Functionality, which targets apps that are essentially repackaged websites.
Your best defense is genuine native value: push notifications, offline support, device features, and native navigation. Make sure those are present and, ideally, mention them in the review notes.
Use the App Review notes field to list your native features explicitly and explain how to reach them. Include test credentials if any feature is behind a login, because reviewers cannot credit what they cannot access.
If you are rejected, read the reviewer's message carefully. Rejections often cite specific guidelines, and a targeted fix plus a clear resubmission note frequently resolves them faster than starting over.
Respond to the specific guideline cited rather than making generic changes. Addressing the exact concern is what actually moves a resubmission forward.
After approval, you control the release: immediate, scheduled, or phased. Choose based on how confident you are and whether you want to monitor a gradual rollout.
Phased release rolls the update out to a percentage of users over several days, which lets you catch a serious problem before it reaches everyone.
Post-launch, most of your updates ship through your web deployment without new submissions. Reserve App Store resubmission for shell changes, new plugins, or SDK and configuration updates.
Keep an eye on Apple's periodic requirement changes, such as minimum SDK versions. Median updates its shell over time, so staying current with its releases helps you meet Apple's evolving rules.
Build a habit of periodically rebuilding on the latest shell even when nothing is broken, so a forced SDK requirement never catches you unprepared right before a deadline.
Finally, keep your metadata and privacy answers accurate over time. If your web app starts collecting new data or you add a plugin that touches the camera or location, update the App Privacy details and, when relevant, resubmit so the store listing keeps matching reality.
Median can produce the signed build and offers submission assistance, which removes much of the manual work. But you still need your own Apple Developer Program membership, and the review outcome depends on your app meeting Apple's guidelines.
Median automates the archive and signing, so you may not open Xcode for a routine submission. For deep debugging of signing or validation errors, Apple's tooling and Xcode are still the ultimate fallback.
The most common reason for wrapper apps is Guideline 4.2, Minimum Functionality, when the app looks like a repackaged website. Adding real native features and describing them in review notes reduces this risk.
Review times vary and Apple does not guarantee a fixed window. Submitting a complete, accurate record with clear native functionality tends to move faster than an incomplete or borderline wrapper submission.