An honest, developer-focused review of Median (formerly GoNative), the web-to-native wrapper for iOS. What it does well, where it falls short, and who should actually use it.
Median, formerly known as GoNative, is a service that wraps an existing website or web app inside a native iOS and Android shell. At its core, that shell is a WebView — a full-screen native browser component that loads your URL — surrounded by native chrome and a set of optional native plugins.
The pitch is simple. If you already have a responsive, mobile-friendly web app, Median lets you ship it to the App Store and Google Play without rewriting it in Swift or Kotlin.
You configure the app through a web-based dashboard: set your start URL, pick an app name and icon, toggle features like push notifications, and Median produces the native project and build for you.
That dashboard-first model is the defining characteristic of the product. Rather than opening an IDE and managing a native codebase, you make choices in a form and rebuild.
This review focuses on the iOS side and what it means for Apple-platform developers. The Android story is broadly similar, but Apple's review culture and tooling create specific considerations that deserve their own treatment.
On iOS, Median's shell is built around WKWebView, Apple's modern web rendering component. Your web content runs inside that view, and native plugins bridge JavaScript to native capabilities the browser alone cannot reach.
This is fundamentally a hybrid approach. It is not native SwiftUI or UIKit, and it does not compile your web code into native views the way a framework like React Native does.
That distinction matters for how the app feels and how Apple treats it. A Median app behaves like a website that happens to live in an app icon, augmented with native navigation, native tab bars, offline handling, and device APIs where you wire them up.
Because WKWebView is the same engine that powers Safari on iOS, your app inherits Safari's rendering behavior, its JavaScript engine, and its quirks. If a page renders correctly in mobile Safari, it will usually render correctly in the wrapper.
For teams whose product is genuinely web-first — a SaaS dashboard, a content platform, an internal tool — this fit can be excellent. The web is the product, and the shell simply gives it a home on the device.
For products that need heavy native interaction, complex gestures, or performance-critical rendering, the fit is weaker. Those apps will fight the WebView rather than lean on it.
Median's strongest selling point is the breadth of native plugins layered on top of the WebView. These typically include push notifications, native navigation bars and sidebars, tab bars, biometric authentication hooks, deep linking, and access to device features like the camera or file uploads.
A JavaScript bridge lets your web code call native functions. For example, your web app can trigger a native share sheet or request a push token through documented JavaScript commands rather than reimplementing them.
This bridge is the conceptual heart of the platform. It is how a page running inside a browser view reaches out to capabilities that browsers deliberately keep at arm's length.
The configuration dashboard is the other headline feature. Instead of maintaining an Xcode project by hand, you adjust settings in a web interface and rebuild, which keeps the whole app definition in one place.
Median also offers a native app-building and App Store submission service, positioning itself as an end-to-end path from URL to published app. That service can package and sign a build so you avoid most manual archive steps.
The exact scope of plugins and services evolves, so always confirm current capabilities against the official documentation at median.co rather than relying on a snapshot. Feature availability, plugin names, and bridge commands change between releases.
The biggest strength is speed to market. If you have a working mobile web app, you can have a testable iOS build in a fraction of the time a native rewrite would take.
Maintenance is centralized. Because your app is fundamentally your website, most updates ship the moment you deploy your web code — no App Store review cycle required for content and logic that live on the web.
That single property changes the economics of shipping. Bug fixes, copy changes, and new features reach users the instant your server updates, which is a genuine advantage over pure native release cadences.
The plugin catalog covers the features most web-first teams actually ask for, which spares you from writing and maintaining Objective-C or Swift bridge code yourself. You configure a feature instead of implementing it.
The abstraction also lowers the iOS skill barrier. A web team without a dedicated iOS engineer can get surprisingly far, which is the whole reason wrappers like this exist.
Finally, keeping one web codebase behind both an iOS and an Android shell reduces duplication. You maintain your product once and let each shell present it, rather than staffing parallel native teams.
The day-to-day workflow with Median is unusual for mobile development because most of it happens outside a traditional IDE. You iterate on your web app in your normal stack and treat the shell as configuration.
For debugging, the most valuable tool is Safari's Web Inspector, which can attach to the WKWebView running on a connected device. This gives you the same console, network panel, and DOM inspection you would have for a normal website.
That means most of your debugging skills transfer directly. Failed requests, JavaScript exceptions, and layout problems surface in the inspector exactly as they would in the browser.
Where the workflow gets less familiar is anything touching the native shell: signing, entitlements, plugin configuration, and build validation. Those steps follow Apple's rules, not the web's.
Median's dashboard smooths a lot of that, but it does not eliminate it. When a build fails Apple's automated validation or a code-signing issue appears, you are back in Apple's world and may need Xcode to diagnose it.
The realistic expectation is that routine work stays in the web and dashboard, while a minority of harder problems still pull you toward Apple's toolchain.
The most important limitation is Apple's own review policy. App Store Review Guideline 4.2, Minimum Functionality, explicitly targets apps that are little more than a repackaged website. A thin wrapper with no meaningful native value can be — and regularly is — rejected.
Median gives you the tools to add native value, but it cannot guarantee approval. That risk is inherent to the web-wrapper category, not specific to Median, and you should plan for it from the start.
Performance is another honest tradeoff. A WKWebView app inherits web performance characteristics: it will rarely feel as fluid as a well-built native app, especially for animation-heavy or gesture-heavy interfaces.
You are also bound to what the WebView and the exposed bridge support. If a device capability is not surfaced through a plugin or the bridge, you cannot simply drop into native code the way you could in a fully native project.
There is also a hard structural limit worth stating plainly: no wrapper, formatter, version manager, or AI assistant actually builds, signs, and submits an App Store app for you end to end. Median automates a great deal, but final release still requires a valid Apple Developer Program membership.
Any hands-on debugging, code signing, or archive troubleshooting ultimately routes through Xcode and Apple's toolchain. Treat Median as a powerful accelerator, not a replacement for the Apple release process.
Median is a commercial product with paid plans, and it has historically offered tiers aimed at hobbyists through to businesses, along with optional done-for-you services. Because pricing and plan structure change over time, this review deliberately avoids quoting specific numbers.
Check the current pricing page at median.co before committing. Confirm exactly what each tier includes — which plugins, how many apps, whether App Store submission assistance is bundled or separate, and what ongoing costs look like.
Pay attention to whether a plan is a one-time or recurring cost, and whether certain plugins or services sit behind higher tiers. Those details determine the real total cost of ownership more than the headline figure.
Remember to budget for the Apple Developer Program membership as a separate, mandatory annual cost paid directly to Apple. That fee is required to distribute on the App Store regardless of which wrapper or framework you use.
In other words, no wrapper's pricing replaces Apple's own fee. Whatever you pay Median sits on top of what you owe Apple to publish.
Median is a strong choice for teams whose product is already a capable mobile web app and who want a fast, maintainable path onto iOS without staffing a native team. Content platforms, SaaS tools, community sites, and progressive web apps are the sweet spot.
It is a weaker choice if your app needs deep native performance, complex offline behavior, rich native UI, or heavy device integration — those are better served by React Native, Flutter, or true native development.
It is a risky choice if your web app offers little beyond what a mobile browser already provides, because Apple's Guideline 4.2 stands directly in that path. Invest in genuine native value — push notifications, offline support, device features — before you submit.
The decision often comes down to an honest audit of your own product. If the web experience is already good and you mainly need distribution, Median fits well. If the web experience is thin, no shell will rescue it.
Overall, Median does exactly what it claims: it wraps the web into a native shell competently and quickly. Go in clear-eyed about the WebView tradeoffs and the App Store rejection risk, and it can be a very efficient tool.
Yes. Median is the rebranded name of the service formerly called GoNative. It is the same web-to-native wrapping product, now under the Median name and domain.
It creates a native iOS app shell built around WKWebView. The shell and its plugins are native, but your app's core content and logic run as web code inside the WebView rather than as native SwiftUI or UIKit screens.
There is no guarantee. Apple's Guideline 4.2 can reject thin web wrappers. Median gives you native features to add value, but approval depends on whether your app offers meaningful functionality beyond a mobile website.
You need an active Apple Developer Program membership to publish on the App Store. Median automates much of the build, but final signing, submission, and any deep debugging ultimately involve Apple's tooling and Xcode.
Median uses paid tiers, and pricing changes over time, so check median.co for current numbers. Budget separately for the mandatory Apple Developer Program annual fee paid directly to Apple.