the main reason webviews in apps have such a bad reputation is because you don't notice the webviews that are integrated seamlessly

- people who have gone down the webview path, and know how difficult it is to do well

- people who have been told they can simply package their webapp into a native application

You can probably guess which group has more people

In the meantime (hey, it's already a thread of self-promotion) my last writeup was about the native views WKWebView generates when you use hardware accelerated CSS transforms:

https://alastair.is/learning-about-what-happens-when-you-use...

I can't help but lament just a little bit. Apple used to be about insane polish. Just think about the mentality that created the rounded screen corners on the original Mac. That's just crazy and I admire it.

I think that's mostly a brand narrative/myth. MacOS has always had warts at any given time.

In this case some subset of apple provided apps weren't following the theme and they fixed it by adding a private css property.

Vs some other OS vendor that likely removed most of the theme controls so they didn't have to keep fixing a huge pile of 1/2 baked abandoned toolkits scattered across their product portfolio.

Granted, this is just UI tweak so I'm not convinced it has to be private, but they probably just don't want to have to maintain that forever.

Spent so much time trying to repro some functionality only to realize that Windows has an allow list for what apps it listens to for certain APIs.

Historically Microsoft had a 100% back compat guarantee for APIs, so the second an API was documented its external interface was frozen in stone forever. There are still APIs around to this day that have misspelled struct fields because someone made a typo 30+ years ago.

If an API isn't documented it is "use at your own risk", although if enough large software starts depending on it, the API may have to be frozen anyway (or compatibility shims put into place) to avoid breaking popular software programs.

*https://devblogs.microsoft.com/oldnewthing/20031223-00/?p=41...

*https://devblogs.microsoft.com/oldnewthing/20230113-00/?p=10...

Now that Safari supports the HTML5 date picker (since iOS 14.1 - five years ago), this is more of a meme than fact-based reasoning. Unless you believe Google including something in Chrome automatically makes it a "standard."

I have a list (unfortunately on a device I can't access now) of web standards that are supported on Safari and Firefox, but not on Chrome. I need it because one web site I work on is 100% Safari users (about 800 people), and another is mostly Android (about 70%). So I need a cheat sheet of which does what.

>Now that Safari supports the HTML5 date picker (since iOS 14.1 - five years ago), this is more of a meme than fact-based reasoning

Apple forces all browsers on iOS to use the Safari browser engine, which they intentionally hobble by not implementing APIs that other browser engines have had forever so that Apple can force developers to create native apps for iOS which Apple then can extract 30% (or whatever they decide it is today) revenue from, where they can't do that from a web application. This is one of many reasons Apple is being sued by the DOJ for antitrust violations, and one reason they got sued by the EU and lost.

https://www.justice.gov/archives/opa/media/1344546/dl

Go here:

https://caniuse.com/?compare=chrome+143,safari+26.0&compareC...

Note the non-supported Safari API's, the vast majority are not web standards.

Apple forcing Safari on iOS is present day, today, not 5 years ago (but it was also 5 years ago too, ever since there was an iOS webview). If Apple doesn't want to implement it, then they shouldn't force other browser makers to use their hobbled browser engine.

Your comments are some Stockholm-syndrome level nonsense you're spouting to protect your favorite brand.

I really never commented on lock-in, even said it's fine to dislike it. You're fighting an imaginary opponent here.

I really just pointed out that Safari largely caught up on web standards. It's Google doing the whole "embrace, extend, extinguish" thing that IE pioneered by stuffing non-standards into their browser so they can lock people in.

FTFY

Without IE we wouldn't have XMLHTTPRequest, something used by practically every web developer in existence today. Innovation happens, and apparently so do walled gardens that outright forbid any competition.

It's one thing to not implement web bluetooth, web midi, and other APIs on your own browser, it's quite another to block anyone else from doing so with their web browsers. The EU thought so too and forced Apple to let other browsers use their own engines. But not in the US yet, until the DOJ completes the case against Apple.

I’d love to debate you on the rest, but it’s a debate that’s been had here at least a thousand times.

** What matters is that Apple is still blocking other browser vendors from using anything but Safari. **

The fact you can't or won't see how fucked up that is tells me everything I need to know about you.

Edit: I looked it up, and apparently its added in Safari 26!

It mattered because Microsoft had 95% of the operating system market at the time and was using its monopoly position to take over the web, even after signing a decent decree with the US government.

The current web monopolist (Google) was coincidentally founded 2 months after the US antitrust lawsuit against Microsoft was decided (july - september 1998).

Similarly meh results with US vs Google two weeks ago.

I don't think that's a credible argument. Apple, at best, has about 55% smartphone marketshare in the United States--and significantly less in most other countries.

Remember, having a monopoly isn't itself illegal; it's using the monopoly to disadvantage competitors, especially in emerging markets, which was what the Microsoft case was all about.

I don't think there's a legal justification for suggesting that Apple creating a private feature only they can use--for now--gives them unfair advantage in the market.

I wouldn't be surprised if Apple makes it a public feature in a future release of iOS 26.

https://www.justice.gov/archives/opa/media/1344546/dl

“Timmy got away with it. I should get away with it, too.” -Elementary school students

But this is exactly why you SHOULD be outraged.

Is Google's "-webkit-tap-highlight-color" also anticompetitive? Should we ban the current practice of shipping proprietary CSS attributes while sometimes also proposing them for standardization?

It's just really hard for me to read that as a legit complaint.

What apple does and what the article talks about: They have a CSS property that ONLY they can use, you can't put that in your PWA, it won't work (no matter the browser).

This is much ado about nothing.

If Apple uses this CSS liquid glass effect in their apps, it'll pass App Store review just fine.

Do you see the issue now?

But when Apple creates self-serving APIs in a web browser engine, it's just another private entitlement, a red herring and their right as the proprietor of Safari.

The lady doth protest too much, methinks.

It appears that this particular API is restricted to embedded webviews, too (doesn’t work in Safari), so it has no bearing on the open web, unlike APIs such as WebUSB in Chrome.

Do you have any evidence of this claim? It's possible that neither Apple or third party developers are able to ship apps through the app store with it.

Citation needed.

The blog article speculates this, but there is no proof.

They do not publish any "proof" to cite beyond what they write there. And they interpret and enforce the rules at their own whim.

The private API is here: https://github.com/WebKit/WebKit/blob/613c42873c56e2b2073f91... it's on WKWebView and resembles other private APIs they forbid access to

Apple absolutely does reject apps for using private APIs. Here is a famous case where they started rejecting Electron apps for private API use: https://9to5mac.com/2019/11/04/electron-app-rejections/ You are welcome to sit and wait for Apple to publish proof that this new private API is just like the others but you shouldn't bother others demanding they cite it for you when clarification will not come for this particular API and there is already precedence on how they handle it categorically. You also shouldn't spread false confidence that it's OK to use these APIs due to lack of "proof" which meets your own standards when it can and has resulted not only in apps being removed but also threat of developer accounts being terminated. (Even if this is rare.)

I understand it can be confusing: they don't do it consistently and they change their enforcement of it over time as they please. Even when it's not done automatically, they can and have inspected closely "by hand" if they are looking for a reason to punish. It is a liability.

> Apple App Review Guidelines: 2.5.1 Apps may only use public APIs and must run on the currently shipping OS.

https://developer.apple.com/app-store/review/guidelines/

And here's the (private) field that needs to be enabled on your webview to enable the CSS property. Otherwise (according to the author) it's just ignored: https://github.com/WebKit/WebKit/blob/613c42873c56e2b2073f91...

The issue is NOT that the property is non-standard or proprietary. The issue is that the property is locked to first party Apple stuff.

Simple example:

I can go set "-webkit-tap-highlight-color".

I CANNOT go set "-apple-system-glass-material".

The difference is that apple's is a private plist permission, and they won't let you set it, because of their control over a different set of software features (app distribution, browser installs, OS).

The complaint is entirely that distinction: It's not that apple has a safari only CSS property. It's that Apple has a safari only CSS property that they only allow first party Apple apps to use.

Google took heat the same way when they gave extra permissions in Chrome to their Google Office extensions.

Apple does plenty of bad things, and many are worse than this, but it doesn't mean it's not fair to point out this one is bad, too.

It all comes down to "the vendor can do things with your computer you can't do yourself" in the end.

It's not even that. A console vendor that locks down everything behind the TPM helps to not deal with cheaters is arguably fine. A console vendor that is also a game develop and caps the FPS of all games that aren't their own is abusing their monopoly position in one market to gain unfair advantage on a different market.

More broadly, and not based on antitrust grounds but on property rights grounds, I am opposed to every kind of DRM. First, it should be legal to circumvent any and all DRM/anti-copying measures. Second, it should be illegal to deprive the next owner of their property rights so that you can exert ownership control over a product past its sale.

If I buy a computer, do nothing but install a keylogging rootkit on it, and sell it on to someone else, I would rightly risk jail time. "The malware is part of the product" is not a valid excuse. DRM is also malware. It should be prosecuted as such, and if existing legislation is found wanting, more specific laws need to be written.

So, if you wanted webviews that could leverage this you’d basically need a native swift app with webviews to get access.

For example, if there was a glowing light on the edge of the phone that only lights up with stock apps and company apps, and that signfies for security that an app belongs to a company, that is ok.

I don't consider design/appearance to be a feature. YMD.

If you mean "anti-competitive" without referring to monopolies, then, well, every company does that.

I'm an antitrust nerd - 20+ years since I made my first PACER account as a teenager to get documents from interesting cases..

95% of what people call "anticompetitive" or "monopolistic" has no legal bearing. People don't know the legal definition of those words and bandy them about based on vibes.

This however, is a very very clear case of violations of precedent. If we look at Microsoft's final judgement https://www.justice.gov/atr/case-document/final-judgment-133 see F(1)(a), H(2)(b), while these stipulations haven't been applied to Apple, if I were in a market dominant position, I'd be super careful about capricious restrictions like the example undocumented API, and behavior that mimics patterns of activity that were seen as actionably sanctionable to similar market dominant forces

With every other app using a web view.

> without referring to monopolies

Of course it’s about monopolies. Safari is still “privileged” to be forced default browser. Making an alternative, Apple ensured to be very hard and expensive. So gating any kind of first party feature is a big no.

Look at the m3/4 macs they are insane machines because even the hardware is unified.

This isn't in the list of per se anticompetitive practises so it would need to be covered by the "rule of reason". That would require someone to demonstrate actual harm to competition that flowed directly from the illegal nature of the practise and was not compensated by some offsetting procompetitive benefit and there is no less restrictive alternative.

I don't see how a CSS property would meet the standard of actual harm to competition, especially since noone is stopping you from making your own liquid glass css if you want to (as far as I can see).

It's also quite likely that it's a) not being used at all, and the private API is just for internal testing until it's ready to be made public, and/or b) used by certain OS components that aren't competing with third-party apps (e.g. somewhere in the Settings panel).

And while I agree with your assertion in theory, some cosmetic styling is probably about the least important, most trivial example you could come up with... can't really get myself worked up about this one.

This is what stood out to me. I've never really suspected webviews and can't think of a place now.

https://news.ycombinator.com/item?id=30648424

Apple's new glass UI seems to draw a lot of ire, but I... kinda like it? It feels like the OS has some actual personality again instead of just being flat and boring. I can visually tell the size of click targets now and the buttons are finally visually distinct from text again. I view it as a welcome change. It's not just "nostalgia" either. It has actual utility.

I installed the iOS 26 Beta to test some things on the websites I maintain in advance of it going public, and while there are some issues here and there I think the overall direction to add more personality back into the OS is a good one. Normies will love it.

Mobile apps having less UI elements immediately visible is not all bad. The hard part of new UX concepts like the new iOS camera button sliding feature is that it's new. Users aren't immediately familiar with it. Not every OS functionality uses it consistently. Etc.

It's probably better to wait a year or two before critiquing Liquid Glass. Change is always risky and takes time to fully roll out and the ecosystem to adopt it widely.

Releasing a broken operating system with "it'll be better in a year or two" simply doesn't work for me. If things haven't improved by the time Sequoia is EOL (which they very well me, I'm about 50/50 on it right now), I'm just going to move to Linux.

Apple's ecosystem tends to to quickly adapt to new UX. Slightly faster than Android.

The bar is high

It's just terrible.

One thing I dislike the most about liquid glass is the new bottom tab bar that's been inserted into every first-party app. Apple Music got it the worst. There's now an additional click required to "move" between the Search interface and the remaining four tabs (Home, New, Radio, Library). When you click on Search, you need to click the the Search Box again to get a keyboard. All of these interactions have extremely sophisticated and slow animations; e.g. when on Home, clicking on Library slides a bubble across the tab bar that blows up beyond the tab bar itself, reflecting the intermediate tabs and underlying content, in a way that is tremendously distracting and serves no purpose. Neither Reduce Transparency nor Reduce Motion have any impact on these animations, on the latest release.

In fact, many of Apple's first party apps appear to have forgotten that Reduce Transparency and Reduce Motion even exist as accessibility options, or at best have half-assed their implementation. For example, with Reduce Motion enabled, clicking on an album in Apple Music deploys a much more subtle animation (good); clicking the back button uses that same subtle animation (good); but swiping back from the left uses the flowery, unnecessary animation that you'd get with Reduce Motion off. Apple Podcasts has the same problem. iMessage, as far as I can tell, totally disregards the Reduce Motion setting and does nothing different, and implements the Reduce Transparency setting not by softening the transparency as other apps do, but instead underlaying a #000000 black background on every item that did have transparency. There's dozens of examples all across iOS, and we're quite literally days from release; dropdowns such as the Apple Notes or Apple News hamburger [...] menu should animate less under Reduce Motion, but don't; when buttons are disabled on the keyboard, such as Apple News -> Search -> empty search box, the Enter button is greyed out in the wrong, barely legible color, only when Reduce Transparency is enabled, the list goes on.

I am not so sure. It might even be the opposite. Techies and designers gave us the flat UI aesthetic, Material UI, Windows Metro design, etc. Techies also nitpick design and aesthetics far more than average folks do. Techies and designers derided Windows XP, but most average users thought it was "cute" and "fun" compared to the "boring" previous design. It is definitely the most memorable release in the past 30 years as far as UI goes. This iOS version could wind up being similar after so many years of the flat UI.

The bugs/kinks are a good point though, and I have noticed some UX changes too that I am unsure about. This is the first complete UI redo in long time for iOS, so I am sure they will get these things worked out over time.

Some of it is because of looks, but the overwhelming majority of criticism is due to bugs and legibility and accessibility issues. Liquid Glass is at best half-baked, especially on macOS. It got tweaked so much from their WWDC presentation, you can tell it was rushed and no one really thought it through.

As a short example, go into System Settings, do a search, then scroll the view and look at the search bar. Or go into a folder, scroll it, and watch the contents screw with the title.

> Normies will love it.

Here’s a sample of one hating it.

https://www.threads.com/@chrispirillo/post/DOpUPrIiYdX

is this true? i know very little of iOS development but i swear i remember watching a decompilation of an app that used various internal APIs to provide animated home screen widgets

I'm neutral on this first implementation (some good, some bad). But I think the approach will be picked up by essentially everyone. Good news for you, there's nothing saying the overlay UI model has to be transparent. Some will probably be opaque but still floating.

First, AR is currently aspirational at best. After decades of failures.

Second, overlaying translucid UI over content makes separation of UI from content worse, not better.

Windows Aero tried that 2 decades ago and, while it looked cool, they reverted.

https://en.m.wikipedia.org/wiki/Windows_Aero

I know, it barely qualifies as AR... but while I love watching the bleeding edge of tech, I'm glad overall that we're slow-rolling this kind of thing.

The only tangential use of QR codes in AR is when a QR code is sometimes used as an anchor point, but the QR code isn't AR, it's merely an anchor point, and there are many other types of anchor points used for AR that are not QR codes.

If you're pointing a phone at a QR code and see some 3D thing pop out of it, that also isn't QR being AR, that's QR encoding data and the phone doing whatever it wants with that data. It could just as easily be a logo causing the AR device to do the same thing, or really any other kind of marker the AR program recognizes. QR codes are just convenient as they encode various kinds of data, so the program that scans it can react to what data is encoded in the QR code.

Please, please cite sources for this. Without context you are really just drawing conjecture here.

Apple certainly seems invested in the idea of an AR future. But users do not - ARkit integrations are few-and-far between, Pokemon Go is a dead fad and Vision Pro failed harder than almost any other contemporary Apple product. It seems less like Apple is skating to the puck, and more like they're begging someone to pass to them. But the rest of the industry seems content ignoring the AR industry to invest away from Apple into stocks like Nvidia. Simultaneously, Apple threw away their stake in consortiums like Khronos, signalling a lack of desire to engage in new software standards.

With how many roadblocks Apple is facing here, I have no idea how you'd conclude that forcing AR on their users is a preferred paradigm.

There are some places where I hope Apple improves things like legibility and contrast, but I'll take anything over the bland, flat designs of the Window 8 era.

It's being sold as the best thing since sliced bread. Googling it felt like I entered a parallel universe.

Which is smart. Contrast is king, especially on consumer hardware where grandma might not see too well in her late age. It wasn't the glass effects of Vista or Yosemite that appealed to people, it was the high-contrast UI elements and skeuomorphic design elements (neither of which are present in liquid glass).

What is genius here? Create something, that nobody asked for, create an in-house CSS property to use across approved apps. Genius? I would simply call this a dirty trick.

There are a lot of things, that they could have implemented, according to the CSS spec. But they decided to spend workforce on this shit. Yeah, they are a business and free to do whatever they want with their money. But I don’t like their choices.

Their UI team asked for it, to use internally (so far), as part of the latest UI style.

https://codepen.io/GreggOD/pen/xLbboZ

Integration is one thing.

The more important thing is resource consumption: Steam for example always gulps 300MB of my precious RAM for two Webview processes that aren't needed anywhere - and earlier versions actually offered a flag to disable the webviews from getting started. On Android, apps using WebView routinely means that either all other apps get OOM'd or in the worst case, the app itself gets OOM'd from its own web view with very weird side effects when whatever the webview was used for is done.

Apple themselves run into these exact cases and develop a compromise for themselves, while at the same time telling third party developers that aren't allowed to use the exact same compromise, and they MUST use Apple's native UI if they want liquid glass...

very true, and why I got out of mobile app development when I noticed like a decade ago, scrubbed my whole resume of it to switch to other kinds of dev

I'm surprised there is still demand for that though, but I've found other solutions to be good enough, when a phone is involved

My guess would be that the App Store apps on iOS and macOS and the Music app rely on these seamless web views for a lot of their dynamic layout content.

I'm confident we'll have a ton of websites trying to replicate the Liquid Glass aesthetic, and will do so in a way that will eat half your laptops CPU.

As the article notes, with this in CSS, it's extremely easy to have different CSS depending on whether this is available or not. At the same time, it's not like other browsers don't do "non-standard" things.

I'm not saying I love Liquid Glass and I want it everywhere, but I prefer to have proper Liquid Glass everywhere on Safari, over having a custom unoptimized laggy unpolished version of it.

It's possible that they will in the future, but are still deciding on the API or implementation.

Why must they be using it somewhere? The amount of dead code and features in common software is ridiculous. They might've changed directions 5 times through this, and the CSS property came in #2 and went out of use in #4…

If I had to guess, probably in the iCloud settings inside of the Settings app. Also in the App Store/Music/TV account page (when you tap on your avatar in the top right of the app.) A bunch of those pages have quite well hidden web views pretending to be native ones, mainly loading things from the iTunes backend services (the give away is normally that you can long press <a> links and a web page preview pops up.) It's probably being used for the user guide inside of the Tips app as well.

That's where I'd be looking at least.

I'm sure they know with the latest OS release that a lot of people are going to want to start using this immediately, perhaps they want to work out the public use of it internally first?

There's definitely some unfounded accusations going on in this thread about this too. Maybe they're right? Maybe they're wrong?