A step-by-step guide to turning your existing website or web app into a native iOS app shell using Median (formerly GoNative), from configuration to a testable build.
Wrapping a website with Median assumes you already have a working, mobile-responsive web app reachable over HTTPS. Apple's App Transport Security expects secure connections, so make sure your site is served over TLS with a valid certificate.
You will also need a Median account and, for App Store distribution, an active Apple Developer Program membership. The membership is a separate, mandatory cost paid directly to Apple.
Enrollment in the developer program can take time, so start it early rather than at the end. It is a common cause of avoidable launch delays.
Finally, be honest about content. Median wraps the web you point it at, so if your mobile web experience is rough, the app will be rough too.
Fix the responsive layout first. Test your site in mobile Safari at real phone sizes and make sure navigation, forms, and media all behave before you wrap anything.
Sign in at median.co and start a new app. Median's workflow is dashboard-driven, so most configuration happens in a web interface rather than in code.
Enter your app name and, most importantly, your start URL. This is the web address the WebView loads when the app launches.
Use your production or a dedicated staging URL, not localhost, because the device needs to reach the site over the public internet. A private address that works on your desktop will not resolve from a phone.
Double-check that the URL loads cleanly in mobile Safari before continuing. If it does not load in the browser, it will not load in the wrapper either.
Treat the start URL as the single most important setting in the whole project. Almost every blank-screen problem later traces back to a bad or unreachable start URL.
Set your bundle identifier, app icon, and launch screen. The bundle identifier is a reverse-DNS string like com.yourcompany.appname, and it must match what you register in your Apple Developer account.
Choose that identifier carefully, because it is effectively permanent once the app is on the store. Changing it later means creating a new app record.
Upload a high-resolution square icon. Apple has strict icon requirements, and Median will generate the required sizes from your source image, but start with a clean, high-resolution asset with no transparency.
Choose a launch screen or splash configuration that matches your brand. A polished launch experience is one of the small touches that helps an app feel less like a bare website.
Consistency across these identity settings matters for review as well as branding. An app that looks intentional and finished reads as a real product rather than a quick wrapper.
This step is not optional if you plan to ship to the App Store. Apple's Guideline 4.2 targets apps that merely repackage a website, so you must add native capability.
In the Median configuration, enable features that a browser cannot offer on its own. Common choices include push notifications, native navigation or tab bars, offline handling, and device integrations like camera or file access.
Wire your web app to use Median's JavaScript bridge for these features where applicable. The more your app does that a mobile web page cannot, the stronger your position in review.
Do not enable features cosmetically and leave them unused. A reviewer needs to actually encounter native functionality during normal use for it to count in your favor.
Think of this as the difference between a bookmark and an app. Reviewers make that judgment, so give them clear native functionality to point to.
Push notifications are usually the highest-impact single addition, because they represent value that a mobile website genuinely cannot deliver in the same way.
Decide how users move through the app. Median supports native navigation elements such as a top navigation bar, a sidebar menu, and a bottom tab bar mapped to URLs on your site.
Mapping native navigation to your existing URLs is one of the easiest ways to make the app feel purpose-built rather than like a scrolling web page. Users get familiar iOS controls that drive your web content underneath.
Configure what happens when the device is offline. A blank white screen on connection loss is a poor experience, so set up an offline page or cached fallback if the plugin supports it.
Graceful offline behavior also helps at review time, since it is a concrete native feature a bare website would not have.
Also define your external-link behavior. You typically want links within your domain to stay in the app and third-party links to open in the system browser, which keeps users from getting lost in unrelated sites inside your shell.
Once configured, use Median to generate an iOS build. For testing, Median's companion preview app or a development build lets you load your configuration on a real device before producing a distributable binary.
Test on an actual iPhone, not just a simulator or desktop browser. Touch targets, scrolling, keyboard behavior, and safe-area insets around the notch and home indicator all behave differently on real hardware.
Walk through every critical flow: login, navigation, forms, media, and any native plugin you enabled. Confirm push registration works and that back navigation behaves sensibly.
Pay particular attention to authentication and any redirects. Sessions, cookies, and third-party login flows sometimes behave differently inside a WebView than in a full browser.
Use Safari's Web Inspector attached to the device to watch the console and network activity during these tests. It is the fastest way to catch a script error or failed request before it reaches users.
When the app works on device, prepare for distribution. You will need an App Store Connect record, signing credentials tied to your Apple Developer account, and screenshots plus metadata.
Median can produce the signed build and offers submission assistance, but the final release still runs through Apple's systems and requires your developer membership. There is no wrapper, tool, or AI assistant that fully removes Apple's signing and review steps for you.
Complete the App Privacy questionnaire honestly. Because the app is web-based, be clear about what your site and any plugins collect, including analytics and push tokens.
Write an accurate App Store description that highlights the native functionality, not just the website. This reinforces to reviewers that the app is more than a wrapper.
Use the App Review notes field to point reviewers at your native features and provide any test credentials they need. Reviewers cannot credit functionality they cannot find or reach.
One advantage of the Median approach is that most updates ship through your web deployment. When you push web changes, users see them without waiting on App Store review.
That makes your normal web release process the primary way you improve the app. Content, logic, and layout changes flow through instantly.
Reserve native rebuilds and resubmissions for changes to the shell itself: new plugins, updated icons, SDK updates, or configuration changes. Those are the things that actually live in the binary.
Monitor crash reports and user feedback. Even though the content is web-based, the native shell can still surface platform-specific issues that only appear on certain iOS versions or devices.
Keep an eye on Median's own updates too. Staying reasonably current with the shell helps you meet Apple's evolving requirements, such as periodic minimum SDK version bumps.
No. Median's dashboard-driven workflow means you configure the app without writing Swift. However, for App Store submission and any deep troubleshooting you may still touch Apple's tooling, so basic familiarity helps.
No. The device loads your start URL over the public internet, so use a publicly reachable HTTPS URL. Use a staging domain if you do not want to point at production yet.
Basic configuration can take under an hour, but adding native features, testing on device, and preparing App Store assets realistically takes longer. Budget time for review iterations.
Yes for web content and logic, because that lives on your server. Changes to the native shell, plugins, or app configuration require a new build and App Store submission.