Your Median (formerly GoNative) iOS app launches to a blank white screen and the WebView never loads. Here are the most common causes and how to fix each.
You open your Median app on iOS and see nothing but a blank white screen. The native shell launched, but the WebView never rendered your website.
This is a common and fixable issue. Because a Median app is fundamentally a WKWebView loading your URL, a blank screen almost always means the WebView could not load or render that URL.
The blank white color is itself a clue: it is the default empty state of a WebView that has nothing to show. Something prevented your page from loading or painting.
The key to fixing it is isolating whether the failure is the network, the URL, the content, or a security policy blocking the load.
Work through the causes below in order rather than guessing, and you will almost always land on the culprit quickly.
One reassuring point before you start: a blank screen is rarely a bug inside Median itself. In the large majority of cases the shell is fine and something about your URL, your certificate, your content, or the network is stopping the page from loading.
The most basic cause is an incorrect start URL. If the configured address is misspelled, points to a dead page, or is not publicly reachable, the WebView has nothing to show.
Open the exact start URL in mobile Safari on the same device and network. If it fails there, it will fail in the app.
This single test separates a configuration problem from an app problem faster than anything else. The app can only load what the browser can load.
Also confirm the URL is not pointing at localhost or an internal-only address. The device must reach the site over the public internet, and a private URL that works on your desktop will be blank on a phone.
Check for subtle issues too, like a URL that redirects to a page the WebView cannot follow, or one that requires a VPN your test device is not on.
Apple's App Transport Security requires secure connections by default. If your site is served over plain HTTP, or has an invalid or expired TLS certificate, iOS may block the load and you get a blank screen.
Verify your site loads over HTTPS with a valid certificate. Check certificate expiry, correct domain coverage, and that there are no mixed-content issues pulling insecure resources.
Certificate coverage matters as much as validity. A certificate valid for your apex domain but not a subdomain you actually load will still fail.
Mixed content is a subtle trap: an HTTPS page that loads an HTTP script or asset can fail or render incompletely inside the WebView even when it looks fine elsewhere.
Because a lapsed certificate breaks every user at once, treat certificate monitoring and automatic renewal as part of keeping the app alive, not just the website.
If the page loads but a JavaScript error halts rendering, you can end up with a white screen. Some web code behaves differently inside WKWebView than in Safari.
Watch for reliance on APIs unavailable in the WebView context, or scripts that assume a desktop environment. A single early exception can prevent your app from painting anything.
Single-page applications are especially vulnerable, because one uncaught error during bootstrap can leave the entire view empty rather than degrading gracefully.
To diagnose, connect the device to a Mac and use Safari's Web Inspector to inspect the WKWebView. The console will show errors and failed network requests happening inside the app.
The inspector is the single most powerful tool for this class of problem. It turns an opaque white screen into the same readable console you use for any website.
Sometimes the screen is not truly broken — it is just slow, and there is no visual feedback. A heavy first page over a slow connection can look identical to a failure.
Configure a loading indicator or splash behavior in Median so users see progress. Optimize your initial page weight so the first paint arrives quickly.
Large unoptimized images, blocking scripts, and heavy above-the-fold frameworks all push out that first paint. Trimming them helps every user, not just those on slow networks.
Test on a throttled connection. What loads instantly on office Wi-Fi may hang for seconds on mobile data, and users will assume the app is broken.
A visible spinner or progress bar changes the perception entirely: a slow-but-working app feels reliable, while a silent white screen feels dead.
If the device is offline or the connection drops during launch, the WebView cannot fetch your page and shows blank. Without an offline fallback, this is a white screen.
Configure an offline page or cached fallback in Median if supported, so the app degrades gracefully instead of showing nothing.
Even a simple cached message that says the app is offline and offers a retry button is far better than an empty view that gives the user no information.
This also improves your App Store review position, since graceful offline behavior is a native feature that distinguishes the app from a bare website.
Handling connectivity well therefore does double duty: it fixes a real failure mode and strengthens your case against a Guideline 4.2 rejection.
Work through this order. First, open the start URL in mobile Safari on the same device — if it fails, fix the URL or server.
Second, confirm HTTPS with a valid certificate and no mixed content. Third, connect to Safari Web Inspector and check the console for JavaScript and network errors inside the WebView.
Fourth, test on different networks including cellular and a throttled connection, to separate a slow load from a true failure.
Fifth, verify your Median configuration uses the correct, current start URL and rebuild if you changed it. This sequence isolates nearly every blank-screen cause.
Following the steps in order matters, because each one rules out a whole category of cause before you spend time on the next.
Add a robust loading state and an offline fallback so transient failures never present as a dead white screen. These are quick wins that improve both reliability and reviewer perception.
Monitor your site's uptime and certificate expiry, since a lapsed certificate will break every user's app at once. Automate certificate renewal if you can.
Set up alerts so you learn about an outage or an expiring certificate before your users do. The app's health is tied directly to your web infrastructure's health.
Finally, test each new build on real hardware and multiple networks before shipping. WKWebView quirks and connectivity edge cases are far easier to catch before release than after.
Building these checks into your release routine turns the blank-screen problem from a recurring emergency into something you rarely see again.
It also pays to keep a short internal runbook of the diagnosis order above. When a report comes in, whoever is on call can follow the same five checks instead of rediscovering them under pressure, which shortens the time from complaint to fix.
The WebView could not load or render your start URL. Common causes are a wrong or unreachable URL, an HTTP or invalid-certificate site blocked by App Transport Security, JavaScript errors in the WebView, or no offline fallback when the connection drops.
Connect the iPhone to a Mac and use Safari's Web Inspector to inspect the WKWebView. The console shows JavaScript exceptions and failed network requests happening inside the app, which pinpoints most blank-screen causes.
Effectively yes. Apple's App Transport Security requires secure connections by default, so an HTTP site or one with an invalid or expired certificate can be blocked, producing a blank screen. Serve valid HTTPS with no mixed content.
Configure an offline page or cached fallback in Median if supported, and add a loading indicator. Graceful offline behavior prevents dead white screens and also strengthens your App Store review position.