Preface
Apple added a private CSS property to WebKit that enables the Liquid Glass effect, and it sparked debate.
Apple has a private CSS property to add Liquid Glass effects to web content discovered and introduced -apple-visual-effect. Usage like this worked perfectly:
.toolbar {
border-radius: 50%;
-apple-visual-effect: -apple-system-glass-material;
height: 75px;
width: 450px;
}
Animation in action: https://alastair.is/content/media/2025/09/glass_with_ipad_new_frame.mp4
Using it requires enabling private API settings, which gets App Store rejection—so third-party developers cannot use it in practice.
Main Argument
Telling WebView Apps Apart Is Hard
Maybe because I have worked on WebView apps for a long time, developer friends sometimes message me: "Is this app a WebView? Take a look."
Unless the app uses a specific mobile UI framework like Ionic Framework or omits license notices, you cannot tell if it is a WebView.
You might guess from button hover—iOS defaults to highlight and lift while web often uses opacity and less box-shadow change—but both sides customize that, so you cannot be sure. Same for transition effects.
Honestly, trying to spot "WebView-ish" apps is a developer pastime. 😄
What People Mean by "WebView-ish"
When people say something feels "WebView-ish," it often points at poorly made apps: "slow," "unnatural effects," "not really native." More informed folks say "WebView-ish." Apple's private CSS property brought attention to the long-standing "in-app WebView wig theory."
Simply put: only bad WebView apps got noticed, so people thought "WebView app = bad," while seamless WebView apps never entered the conversation. Like shouting "wigs look fake!" at an obvious wig while ignoring someone wearing a convincing one. 😄
Apple's First-Party Apps Use WebViews Too
The author inferred that -apple-visual-effect exists because Apple uses it in first-party apps. BigGo reported similarly:
Apple uses web views in places like iCloud settings—icons load with slight delay and some menu items lack standard iOS highlight. Mail and Calendar are also reported to embed web views for certain features.
So criticism like "WebView-ish" or "WebView apps are bad" is at least partly off-target today. Combining native-only features with flexible WebView (including updates)—or building entirely on WebView—is a valid choice.
Summary
As far as I know, WebView criticism goes back at least to Facebook's WebView app failure around 2012.
Sencha, which built JavaScript frameworks, quickly shipped Fastbook to "troll" Facebook—"it's an implementation problem, not WebView"—with comparison videos. That era was heated and fun.
https://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story/
More than ten years later, web and devices evolved. Apple uses WebViews in first-party apps. If you still assume "WebView apps are bad," I hope this article updates that impression to the wig theory.
See you again.