Your Median (formerly GoNative) iOS app was rejected as a thin web wrapper under Apple Guideline 4.2. Here is why it happens and how to fix and resubmit.
You wrapped your website with Median, submitted to the App Store, and received a rejection citing Guideline 4.2, Minimum Functionality. Apple's message usually says the app provides a limited experience or is primarily a repackaged website.
This is the single most common rejection for web-to-native wrapper apps. It is not a bug in Median — it is Apple's deliberate policy toward apps that do not offer enough beyond a mobile browser.
The rejection is a judgment about value, not a technical error. Your build compiled, signed, and installed correctly; Apple simply decided it does not do enough to justify being an app.
The good news is that it is usually fixable. The rejection is about perceived value, and you can add real native value and make it visible.
Approached that way, a 4.2 rejection is less a dead end than a prompt to strengthen the product.
Guideline 4.2 exists to keep the App Store from filling with apps that are just bookmarks. When a reviewer opens your app and it behaves exactly like your website in Safari, it fails that bar.
Median wraps whatever you point it at. If your configuration is minimal — just a start URL with no native features enabled — the resulting app has little to distinguish it from the web.
The tool is doing exactly what you asked; the thinness comes from the configuration, not the platform. That is important, because it means the fix is within your control.
Reviewers also consider whether the app is more useful as an app than as a website. A pure content site with no offline use, no push, and no device integration is a classic trigger.
Apple is essentially asking a single question: what does this app give the user that opening the site in a browser would not? If you have no strong answer, expect the rejection.
It also helps to know that the bar is about the app as a whole, not any single screen. Reviewers weigh whether the overall experience justifies a place on the home screen, so a scattering of minor tweaks rarely moves the needle if the core still feels like a website.
The core fix is to add functionality a mobile browser cannot provide. Push notifications are the highest-impact addition and are strongly associated with app-only value.
Enable other native capabilities in Median where they make sense: offline access or caching, native navigation and tab bars, biometric login, camera or file access, and haptics. Each one strengthens your case.
Choose features that genuinely fit your product rather than a random grab bag. A relevant, well-integrated feature reads as intentional; an unrelated one reads as box-checking.
Do not just toggle features on cosmetically. Wire them into real user flows so a reviewer actually encounters them during normal use.
The goal is that a reviewer performing ordinary actions runs into native capability naturally, without having to hunt for it.
Reviewers spend limited time in each app, so surface your native features early and clearly. If push is your differentiator, prompt for permission during onboarding after showing its value.
If you support offline, demonstrate it — let the app open and show cached content without a connection. A blank screen offline actively hurts you.
Consider a brief first-run moment that showcases what the app does natively, so the value is unmistakable within seconds rather than buried several taps deep.
The goal is that within the first minute, it is unmistakable that this is an app, not a wrapped page.
Assume the reviewer will not dig. Whatever proves your app deserves to exist should be visible on the surface, not hidden behind menus.
Sometimes the rejection reflects a genuinely thin experience. If your mobile web app is sparse, adding a native shell will not save it.
Invest in the underlying web app: better mobile layout, faster load, app-like navigation, and interactions that feel purpose-built for a phone. Median can render a great mobile experience, but only if your site provides one.
Small touches compound. Comfortable touch targets, smooth scrolling, and thoughtful handling of the keyboard and safe areas all make the app feel deliberate.
A polished, feature-rich web app inside a native shell with native features is a fundamentally different proposition than a bare site in a WebView.
When the web experience itself is strong, the native features you add reinforce a good product rather than trying to rescue a weak one.
When you resubmit, use the App Review notes field to guide the reviewer. Explicitly list the native features and how to reach them, including any test credentials needed to log in.
If a feature requires an account or specific steps to see, spell that out. Reviewers cannot credit functionality they cannot find.
Be specific about paths: name the screen, the menu, or the action that reveals each native capability. Vague notes waste the reviewer's limited time and yours.
Be direct: state that the app offers push notifications, offline support, and native navigation beyond the website. This reframing often changes the outcome.
Good review notes are one of the cheapest, highest-leverage things you can do, because they aim the reviewer straight at the value you built.
You have two paths. You can reply to the rejection in Resolution Center to discuss or contest it, or you can make changes and resubmit a new build.
If the rejection is clearly about missing functionality, fixing and resubmitting is usually faster than arguing. If you believe the reviewer missed existing features, a polite Resolution Center reply pointing to them can work.
Keep the tone factual and cooperative. Reviewers respond better to a clear pointer to evidence than to a complaint about the decision.
Either way, address the specific guideline cited. Generic changes that ignore the reviewer's reasoning tend to get rejected again.
When in doubt, do both: add real functionality and explain it clearly. That covers you whether the original issue was missing value or missed value.
Be honest with yourself about the product. If your app truly offers nothing beyond a website and never will, Apple's position is unlikely to change, and repeated resubmissions waste time.
In that case, consider whether a Progressive Web App, distributed through the browser, better fits your needs without App Store friction. Not every web product belongs in the App Store.
A PWA can be added to the home screen, work offline with a service worker, and even receive web push on supported iOS versions, all without going through review. For some products that is the better distribution model.
Median is a strong tool when you have real native value to add. The 4.2 rejection is Apple asking you to demonstrate that value — treat it as a prompt to build it, not just to repackage.
Choosing the right container for your product up front saves the cycle of rejection, patching, and resubmission that traps thin wrappers.
No. It is Apple's policy toward thin web wrappers regardless of the tool used. Median gives you native features to add value; the rejection means your current configuration does not yet show enough of it.
Add high-impact native functionality — push notifications is the strongest — enable offline and native navigation, surface these features early, and clearly describe them in the App Review notes when you resubmit.
If the app genuinely lacks native value, fix and resubmit. If the reviewer missed features that already exist, reply in Resolution Center pointing to exactly where to find them, ideally with test credentials.
Apple is unlikely to approve a pure wrapper with no added value. Consider adding real native features, or distribute as a Progressive Web App through the browser instead of the App Store.