Providing an OS feature only to first-party programs is a plainly anticompetitive practice. Using your privileged position in one market (cell phones/cell phone operating systems) to gain an advantage in another market (smart phone applications) that you withhold from your competitors is a textbook case.
I wanted to be outraged at apple, but I really can't. Read WinAPI documentation and try to count all "reserved" parameters for example. OS developers build features just for internal use all the time.
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.
The key distinction is the withholding from your competitors part. WinAPI may have a ton of features labelled "pls no use thx" but MS doesn't block you from distributing a program that uses them anyway.
Microsoft considers documentation status and long term support status to be the same thing. If the behavior of a function / API is not going to remain stable, it isn't documented. If they don't want to pay maintenance/support costs for an API (more rigorous testing, sample code, etc) the API won't be documented.
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.
The only APIs that are locked this way AFAIK are PPL, Defender-disabling, and AV registration, all not exclusive to Microsoft, you just have to sign up to an antimalware developer program and sign an NDA.
That's not the key distinction -- of course Windows will likely have internal-only APIs for its own internal use. The problem is when e.g. there are special internal Windows APIs that Office can use but Lotus/etc. can't, or that Edge can use but Firefox/Chrome/etc. can't.
Yeah, I wasn't trying to be snarky, rather there often seems to be a "private code shouldn't exist, code wants to be free!" ethos that makes my eyebrows twitch in PTSD from reading all of Raymond Chen's tales of depending on undocumented code, e.g.
It's not withholding, it's just not part of the AppStore if you do it. There are plenty of other ways to distribute your software, and yes, Apple will also still co-sign it or provide entitlements if you need those. Just not in the AppStore.
That's not the argument; the argument is that this would be some form of "there is only one method and it is being withheld", which simply isn't the case.
Yeah, this seems reasonable to me. The better thing to get annoyed at Apple for is being slow to implement web standards. I guess you could make the argument that they are choosing to work on stuff like this instead, but I think that’s a weak argument.
The better thing to get annoyed at Apple for is being slow to implement web standards.
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.
>>The better thing to get annoyed at Apple for is being slow to implement web standards.
>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.
Maybe 5 years ago this was a true, they accelerated development and their standards support is pretty good now, better than FF. Again, not counting Chrome's "EEE" non-standard API's, they largely move fast and implement most modern ones. Some PWA stuff is missing which is valid, while Chrome is behind on a few nice design-focused standards Safari has.
Maybe you should read the DOJ suit against Apple. It's pretty clear that one reason (among many) that Apple is getting sued is because of abusive business practices exactly as I described.
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.
Nothing in your comment makes any difference so long as Apple blocks other browser engines on iOS. I honestly don't give a fuck what they do with Safari as long as they allow real Chrome to exist on iOS, which I can then instruct my users to install because Safari is a piece of shit browser.
technically?? With all those modern and useful APIs they don't implement? That's how they're technically better by not having useful tech? Wow. Okay, you do you.
> Private/secret APIs in Windows were a prominent part of the US and EU antitrust lawsuits against Microsoft in the 90s/00s.
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.
Edit: It can probably be argued that Apple is a acting like a monopolist in one or a few areas though?
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.
> It can probably be argued that Apple is a acting like a monopolist in one or a few areas though?
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.
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.
Wait so are all non-standard CSS attributes "anticompetitive"? This seems like wild hyperbole.
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.
You can use `-webkit-tap-highlight-color` on your website or PWA and distribute it any way you want. It will just not work in non-webkit browsers like Firefox.
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).
They just released this feature internally. We have no idea what their plans are for this. The web doesn't broadly and suddenly adopt features like this anyway. It's very likely Apple is working on something to allow 3rd party devs to start using it via safari.
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.
Well the automated parts of the process may still be useful to have the app package run through. Checks like "Does not use private APIs" are important to avoid accidental anticompetitive behavior. When working in large organizations communication is difficult and automatic checks that protect against mistakes are important.
So when Google creates self-serving APIs in a web browser engine, it's anti-consumer and is killing the free web.
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 difference is that Google is by far in a much more dominant position and every dev who leverages Chrome-specific APIs further entrenches that dominance. In the browser space, Apple is the long-trailing runner-up and has far less impact.
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.
If you are ignorant to Apple rules and practices, please don't be obnoxious about it. Apple has developer guidelines for the App Store, and they say you cannot use private APIs!
They do not publish any "proof" to cite beyond what they write there. And they interpret and enforce the rules at their own whim.
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.
Are you really asserting that a CSS selector is a private API? This is either a really wild misunderstanding about the difference between CSS and API, or somehow I totally misread your post. But I did re-read a few times and that seems to be the claim?
But you can't install the Chrome browser engine on iOS, because Apple forces Google to use the Safari web browser engine, as well as any other web browser for iOS that isn't Safari - they all are forced to use Safari under the hood.
Looks like logic is lost here. My point is that the fact that Google used nonstandard feature so many years ago does not end up forcing users to choose a specific platform, which is the complaint there. And every browser has always done something special for itself. Whether "real" Chrome is available on iOS and how Apple comes into the question is completely irrelevant.
Not sure it is "plainly anticompetitive" in the legal sense. In the US, the laws on anti-competitive practices are the Sherman Act and the Clayton act. To be anticompetitive, the courts use the "per se" rule and the "rule of reason". "per se" rule covers things which are specifically listed in the laws as being anticompetitive (eg price fixing).
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).
But there's no evidence yet that it's being used by first-party programs, e.g. by GarageBand or Pages or Mail.app.
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.
What are your thoughts on computer hardware which is much more restrictive? Video game consoles, for example, require all code to be cryptographically signed, meaning that third parties can't publish any software whatsoever without the blessing of the console manufacturer.
>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.
I'm generally opposed to that as well. Agreeing with Muromec's reply, I don't think it is necessarily anticompetitive in the case where the console vendor doesn't favor its first party games, but of course all three do that in practice. The situation is somewhat mitigated by the existence of a flourishing open market alternative (PC games).
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.
I think there is line that a company can cross: using a locked-down appearance setting to make an app look like it is from the company.
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.
Tech was always a business. What this comment is bringing out is the people who see preferred technical choices as some kind of morality play. They aren’t. They never were. It’s childish to believe such things.
Based on other Chrome threads here, we do need to make sure that Apple maintains their exclusive monopoly on browser on iOS to prevent these things from happening. Right? Right?! :P
HN has one of the largest online populations of amateur lawyers with some of the least correct legal opinions in the world. This is one of many, many examples.
Isn't the article saying they added a new css element, but it's not restricted to apple apps only really, just not in documentation yet? for example, this article is preview documentation, of a sort?
No, it says it is restricted. You need to set a private attribute on the webview to enable it. And if you interact with private APIs your app will be rejected in review.
With whom is Apple competing on their own web pages and apps? And how much advantage does some shiny reflection (which, btw, could also be attained by writing the effect yourself) offer them over that competition? It must be something big and obvious, otherwise there's no way it's illegal, but I can't think of it.
If you mean "anti-competitive" without referring to monopolies, then, well, every company does that.
Google or any open source map product. And actually, if we use the SCOTUS approved DOJ v MSFT consent decree as precedent, any app that can't use this private API component would be an impacted party.
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
It’s a way they can make their webview-based apps look “native” more easily than a third party can. If you try out a third-party app and it looks less well integrated visually than a similar first-party app, then the latter has a competitive advantage because of that.
Well for starters, no one else is allowed to publish a browser with their own engine on the AppStore, and they've hampered sideloading for years. In a vacuum, it might be reasonable to block any third-party browser engines, or to put something special in their own that no one else can use on the phone, but combining those is just intentional sabotage. And yes, I know that this specific CSS property isn't all that important, but having an argument about how much they're allowed to intentionally sabotage other browsers on their phones is at best a misguided distraction from the point that they shouldn't be doing it in the first place (and not a particularly good defense either; try arguing with a cop who pulls you over for speeding that the law you broke wasn't really that important and see if it gets you out of the ticket).
> With whom is Apple competing on their own web pages and apps?
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.
I'll concede if you can name one webview that is integrated seamlessly. Maybe the average person wouldn't realise but I think we'd have seen lots of articles about it here. It would be a standard rebuttal to every webview debate, "but Foo is implemented as a webview so it can be done".
Which is probably exactly why this was added. The cheap way to usually tell if someone is using a 3rd party UI toolkit, is to start tweaking the system theming and see if the application follows some scaling/color changes correctly.
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.
There's also, in there somewhere, a corollary about how you don't notice the webviews which don't stick out but just don't feel right. Like, someone mentioned Settings app in MacOS might use them because the icons don't load fast enough.
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.
No kidding. I grew up loving Macs in general, but despite some people's rose-tinted views of classic macOS in the 80's and 90's, I always had uncontrollable pangs of stabbiness every time I had to do anything in the cluttered, clunky, and tiny interface of Chooser.
Thanks! I'm hoping to continue down this path and write up some thoughts on how you might actually achieve seamless in-app webviews at some point but, y'know... time.
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:
> It stands to reason that Apple wouldn't have developed this feature if they weren't using it. Where? We have no idea.
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.
> It stands to reason that Apple wouldn't have developed this feature if they weren't using it. Where? We have no idea. But they must be using it somewhere. The fact that none of us have noticed exactly where suggests that we're interacting with webviews in our daily use of iOS without ever even realising it.
This is what stood out to me. I've never really suspected webviews and can't think of a place now.
I often suspect things in Settings, esp. account/iCloud section to be webviews, just based on how they load (icons appearing a short moment after the page opens for example).
When you tap some of the menu items in the “Saved to iCloud” section, they don’t have the normal grey item highlight that happens with the rest of the settings app.
I’m sure there are many apps like the Apple Store app and parts of the App Store that pull in web views. That’s most likely what this is for. Probably parts of News, Music, Games apps as well.
Actually it does not. It used to, but then was rewritten. The Accessibility Inspector app can be used to see what's the class of the UI elements, if you want to check.
I think it still might. I use it all the time on my laptop, and periodically if I do something funky with the network, the entire view panel says that there was an internal server error in that classic no-CSS Times New Roman font. Do you have a source for this?
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.
I like the glass effects and aesthetics, but I think the functionality in a lot of the apps isn't as good as it was. A lot of things that were easy-to-reach buttons are now tucked away in menus, and harder to find.
That always depends on how difficult discoverability is. For example if you're designing for something like Apple Watch there's very limited place for stuff, so you either pack it or you find ways to only show what's most important, using gestures or menus to do other stuff.
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.
> It's probably better to wait a year or two before critiquing Liquid Glass.
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.
Fair enough, change is annoying to users, plus at the same time there's huge overhead keeping a beta queued up for a year+ while everything slow moves over to a new theme. While management wants something new right away. So it's a difficult compromise I'm sure every frontend dev has had to deal with.
Apple's ecosystem tends to to quickly adapt to new UX. Slightly faster than Android.
I noticed this in safari where the bookmark icon used to be one click was now two. Fortunately you can change it back in the settings by switching the tab layout (whatever that means)
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.
My suspicion is that genpop is not going to like it, broadly, mostly because the only people who seem to think that operating systems should have "personality" are techies. People just don't think like that; most people view these systems as means to an end, and anything that isn't in service to that is, at best, simply an interesting diversion for the first few days.
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.
> the only people who seem to think that operating systems should have "personality" are techies
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.
I don't think so, I think the general population gets happy and excited by new things, because they believe it to be somehow better than the old thing. A new cool visual refresh of the OS is something that people gravitate towards, even when it's mostly a superficial restyling hiding decades of cruft (Windows 11)
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?
> It stands to reason that Apple wouldn't have developed this feature if they weren't using it. Where? We have no idea. But they must be using it somewhere.
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…
Love or hate liquid glass, the paradigm shift from "UI chrome is a wrapper around app content" to "UI is overlayed on top of app content" seems like the future. It's well aligned with AR and better separates UI layout from content for different screen sizes.
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.
VR is still aspirational, but we already have AR making baby steps into everything. Every time you see a QR code for the menu burned into a restaurant table, you're looking at a sort of AR: the phone sees it differently than you. Then there's games, but that seems to be largely a passing fad, like 3D TV.
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.
QR codes do not qualify as Augmented Reality at all. "QR" is a data encoding format. It does not augment reality in any way.
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.
Younger generation is obsessed with nostalgia for Aero/Glass and that whole era's aesthetic. It will definitely become a trend, if not for that then because Apple did it and the industry has lost all innovation outside of "copy whatever Apple does."
As a fan of aero, I hope Google copies the Apple theme with their own aero theme.
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.
> you have to toggle a setting in WKPreferences called useSystemAppearance... and it's private. So if you use it, say goodbye to App Store approval.
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
Honestly, why don't they just add it to Safari as a css property?
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.
> But my suggestion is this: the main reason webviews in apps have such a bad reputation is because you don't notice the webviews that are integrated seamlessly.
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.
Interesting, using webviews is a common shortcut for a lot of functionality, and even native apps will occasionally have some webviews (that you might not even notice) out of convenience (and sometimes necessity).
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...
> the main reason webviews in apps have such a bad reputation is because you don't notice the webviews that are integrated seamlessly
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
> the main reason webviews in apps have such a bad reputation is because you don't notice the webviews that are integrated seamlessly.
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.
At this stage it really feels like features like this’ only purpose is to make older models struggle with basic UI stuff just so people upgrade to the newer devices.
Windows 7 built a design language around it, transparency was never the main attraction.
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).
> Whoever it was at Apple that decided to make this a CSS property is a genius because it makes it incredibly easy to provide different rules based on Liquid Glass support
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.
This looks like a little bit more than a blur, there seem to be some refraction and some other optical-type effects. But realistically its just a blur with marketing.
Providing an OS feature only to first-party programs is a plainly anticompetitive practice. Using your privileged position in one market (cell phones/cell phone operating systems) to gain an advantage in another market (smart phone applications) that you withhold from your competitors is a textbook case.
I wanted to be outraged at apple, but I really can't. Read WinAPI documentation and try to count all "reserved" parameters for example. OS developers build features just for internal use all the time.
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.
The key distinction is the withholding from your competitors part. WinAPI may have a ton of features labelled "pls no use thx" but MS doesn't block you from distributing a program that uses them anyway.
That used to be true but they absolutely do this today :(
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.
Did it? I worked on an EDR product for a decade and the window internal gurus were always talking about undocumented API parameters
Microsoft considers documentation status and long term support status to be the same thing. If the behavior of a function / API is not going to remain stable, it isn't documented. If they don't want to pay maintenance/support costs for an API (more rigorous testing, sample code, etc) the API won't be documented.
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.
The only APIs that are locked this way AFAIK are PPL, Defender-disabling, and AV registration, all not exclusive to Microsoft, you just have to sign up to an antimalware developer program and sign an NDA.
The "turn off Windows Defender PLS, I am an antivirus" API being a principal (and well-justified) example.
That's not the key distinction -- of course Windows will likely have internal-only APIs for its own internal use. The problem is when e.g. there are special internal Windows APIs that Office can use but Lotus/etc. can't, or that Edge can use but Firefox/Chrome/etc. can't.
Sorry, yes. To clarify, it's about withholding features of a product in one market from your competitors in the other market.
Yeah, I wasn't trying to be snarky, rather there often seems to be a "private code shouldn't exist, code wants to be free!" ethos that makes my eyebrows twitch in PTSD from reading all of Raymond Chen's tales of depending on undocumented code, e.g.
*https://devblogs.microsoft.com/oldnewthing/20031015-00/?p=42...
*https://devblogs.microsoft.com/oldnewthing/20031223-00/?p=41...
*https://devblogs.microsoft.com/oldnewthing/20230113-00/?p=10...
*https://devblogs.microsoft.com/oldnewthing/20060109-27/?p=32...
It's not withholding, it's just not part of the AppStore if you do it. There are plenty of other ways to distribute your software, and yes, Apple will also still co-sign it or provide entitlements if you need those. Just not in the AppStore.
That seems like an unnecessary and unreasonable trade barrier. There isn't a technical or user-experience reason to exclude these sorts of apps.
That's not the argument; the argument is that this would be some form of "there is only one method and it is being withheld", which simply isn't the case.
Yeah, this seems reasonable to me. The better thing to get annoyed at Apple for is being slow to implement web standards. I guess you could make the argument that they are choosing to work on stuff like this instead, but I think that’s a weak argument.
And even then, they've made efforts to get better. Safari is starting to edge out Firefox for support of the features I actually want to use
I just want to use color SVGs as favicons. One file format- looks great on any screen at any size. But no, Safari isn’t interested in that feature.
Edit: I looked it up, and apparently its added in Safari 26!
The better thing to get annoyed at Apple for is being slow to implement web standards.
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.
>>The better thing to get annoyed at Apple for is being slow to implement web standards.
>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
Maybe 5 years ago this was a true, they accelerated development and their standards support is pretty good now, better than FF. Again, not counting Chrome's "EEE" non-standard API's, they largely move fast and implement most modern ones. Some PWA stuff is missing which is valid, while Chrome is behind on a few nice design-focused standards Safari has.
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.
Maybe you should read the DOJ suit against Apple. It's pretty clear that one reason (among many) that Apple is getting sued is because of abusive business practices exactly as I described.
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.
So you’re ignoring my entire comment and re-iterating the part I didn’t respond to.
Nothing in your comment makes any difference so long as Apple blocks other browser engines on iOS. I honestly don't give a fuck what they do with Safari as long as they allow real Chrome to exist on iOS, which I can then instruct my users to install because Safari is a piece of shit browser.
Safari is better than Chrome imo, technically, UX and otherwise, but you're entitled to be mad about lock-in. I just wasn't responding to that part.
technically?? With all those modern and useful APIs they don't implement? That's how they're technically better by not having useful tech? Wow. Okay, you do you.
[delayed]
Relative privation fallacy.
“Timmy got away with it. I should get away with it, too.” -Elementary school students
Private/secret APIs in DOS/Windows were a prominent part of the US and EU antitrust lawsuits against Microsoft in the 90s/00s.
> Private/secret APIs in Windows were a prominent part of the US and EU antitrust lawsuits against Microsoft in the 90s/00s.
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.
Edit: It can probably be argued that Apple is a acting like a monopolist in one or a few areas though?
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.
> It can probably be argued that Apple is a acting like a monopolist in one or a few areas though?
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.
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
Microsoft doesn't punish you for using those though.
> I wanted to be outraged at apple, but I really can't. Read WinAPI documentation
But this is exactly why you SHOULD be outraged.
Wait so are all non-standard CSS attributes "anticompetitive"? This seems like wild hyperbole.
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.
You can use `-webkit-tap-highlight-color` on your website or PWA and distribute it any way you want. It will just not work in non-webkit browsers like Firefox.
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).
They just released this feature internally. We have no idea what their plans are for this. The web doesn't broadly and suddenly adopt features like this anyway. It's very likely Apple is working on something to allow 3rd party devs to start using it via safari.
This is much ado about nothing.
If you use this CSS liquid glass effect in your app, Apple will reject it from the App Store.
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?
>it'll pass App Store review just fine.
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.
Why would Apple go through the App Store review process for their first-party apps?
Because it's cheaper to maintain 1 ingestion pipeline than 2.
And it's basically free to create a rule "if it's from apple, auto-approve" even if it's a manual process.
Well the automated parts of the process may still be useful to have the app package run through. Checks like "Does not use private APIs" are important to avoid accidental anticompetitive behavior. When working in large organizations communication is difficult and automatic checks that protect against mistakes are important.
iOS has many private APIs, this one is no different. The fact it's implemented in WebKit is a red herring.
So when Google creates self-serving APIs in a web browser engine, it's anti-consumer and is killing the free web.
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's literally not part of the web because it's not available in Safari or WebKit views in applications.
The difference is that Google is by far in a much more dominant position and every dev who leverages Chrome-specific APIs further entrenches that dominance. In the browser space, Apple is the long-trailing runner-up and has far less impact.
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.
[flagged]
If you use this CSS liquid glass effect in your app, Apple will reject it from the App Store.
Citation needed.
The blog article speculates this, but there is no proof.
Here you go:
> 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...
If you are ignorant to Apple rules and practices, please don't be obnoxious about it. Apple has developer guidelines for the App Store, and they say you cannot use private APIs!
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.
Are you really asserting that a CSS selector is a private API? This is either a really wild misunderstanding about the difference between CSS and API, or somehow I totally misread your post. But I did re-read a few times and that seems to be the claim?
The CSS isn't the issue, it's that the CSS can only be enabled using private platform code, which no app will get approval for.
Did you click my link or read the article? The private API is the WKWebView property.
Bad example since "-webkit-tap-highlight-color" is initially from Apple, not Google
[flagged]
I can install chrome on Windows, Linux and Mac, so I give them a pass. Not to mention that was ancient history.
But you can't install the Chrome browser engine on iOS, because Apple forces Google to use the Safari web browser engine, as well as any other web browser for iOS that isn't Safari - they all are forced to use Safari under the hood.
Looks like logic is lost here. My point is that the fact that Google used nonstandard feature so many years ago does not end up forcing users to choose a specific platform, which is the complaint there. And every browser has always done something special for itself. Whether "real" Chrome is available on iOS and how Apple comes into the question is completely irrelevant.
Not sure it is "plainly anticompetitive" in the legal sense. In the US, the laws on anti-competitive practices are the Sherman Act and the Clayton act. To be anticompetitive, the courts use the "per se" rule and the "rule of reason". "per se" rule covers things which are specifically listed in the laws as being anticompetitive (eg price fixing).
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).
But there's no evidence yet that it's being used by first-party programs, e.g. by GarageBand or Pages or Mail.app.
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.
Only if you consider making UI text unreadable an advantage.
I don't think it's an improvement, but having a GUI that matches user expectations is undeniably a business advantage.
What are your thoughts on computer hardware which is much more restrictive? Video game consoles, for example, require all code to be cryptographically signed, meaning that third parties can't publish any software whatsoever without the blessing of the console manufacturer.
I'm assuming they don't like that either.
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 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.
I'm generally opposed to that as well. Agreeing with Muromec's reply, I don't think it is necessarily anticompetitive in the case where the console vendor doesn't favor its first party games, but of course all three do that in practice. The situation is somewhat mitigated by the existence of a flourishing open market alternative (PC games).
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.
I think there is line that a company can cross: using a locked-down appearance setting to make an app look like it is from the company.
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.
True, this is killing innovation in badly written settings panes implemented with web technologies.
this comment is bringing out the apple blinders in force and i love it. do people really see apple as "the good guy"? tech has zero good guys left
Hey stop bullying the trillion dollar corporation! They are my favourite corporation and their actions are beyond question >:(
Tech was always a business. What this comment is bringing out is the people who see preferred technical choices as some kind of morality play. They aren’t. They never were. It’s childish to believe such things.
not wanting to use something that looks like it was designed to appeal to ages 2-8 is a moral issue?
Shouldn’t this be easily available in Electron/Tauri and React Native apps?
Electron doesn't use WebKit, so definitely not. Not sure about Tauri desktop, but how would you use it for Tauri mobile and React Native?
Woah, TIL. Chromium apparently forked WebKit in 2013. wtf?
So, if you wanted webviews that could leverage this you’d basically need a native swift app with webviews to get access.
Even if you could get it you wouldn't be able to publish it on the App Store due to the permission it requires.
React Native / Expo apps can get liquid glass via the actual underlying native ui elements.
Based on other Chrome threads here, we do need to make sure that Apple maintains their exclusive monopoly on browser on iOS to prevent these things from happening. Right? Right?! :P
This isn't available in the Safari browser.
Its a toss up between anticompetitive being bad and unified standards being good.
Look at the m3/4 macs they are insane machines because even the hardware is unified.
What do you mean by unified? Strix Halo is "unified". The M series platform isn't the only unified platform out there.
The OS and hardware were developed in close collaboration
Somewhat overrated because the release cycle for an OS change can be as little as a day, but the release cycle for a CPU change is like 3-4 years.
How would exposing this CSS extension impact unification of the platform?
How does this give an advantage?
How is Apple withholding Samsung from making applications for Android? What kind of textbooks are you reading?
HN has one of the largest online populations of amateur lawyers with some of the least correct legal opinions in the world. This is one of many, many examples.
Isn't the article saying they added a new css element, but it's not restricted to apple apps only really, just not in documentation yet? for example, this article is preview documentation, of a sort?
No, it says it is restricted. You need to set a private attribute on the webview to enable it. And if you interact with private APIs your app will be rejected in review.
I understand, though conjecture (worked at apple for years) this looks like an imminent "feature" that will become documented.
With whom is Apple competing on their own web pages and apps? And how much advantage does some shiny reflection (which, btw, could also be attained by writing the effect yourself) offer them over that competition? It must be something big and obvious, otherwise there's no way it's illegal, but I can't think of it.
If you mean "anti-competitive" without referring to monopolies, then, well, every company does that.
Google or any open source map product. And actually, if we use the SCOTUS approved DOJ v MSFT consent decree as precedent, any app that can't use this private API component would be an impacted party.
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
It’s a way they can make their webview-based apps look “native” more easily than a third party can. If you try out a third-party app and it looks less well integrated visually than a similar first-party app, then the latter has a competitive advantage because of that.
Well for starters, no one else is allowed to publish a browser with their own engine on the AppStore, and they've hampered sideloading for years. In a vacuum, it might be reasonable to block any third-party browser engines, or to put something special in their own that no one else can use on the phone, but combining those is just intentional sabotage. And yes, I know that this specific CSS property isn't all that important, but having an argument about how much they're allowed to intentionally sabotage other browsers on their phones is at best a misguided distraction from the point that they shouldn't be doing it in the first place (and not a particularly good defense either; try arguing with a cop who pulls you over for speeding that the law you broke wasn't really that important and see if it gets you out of the ticket).
> With whom is Apple competing on their own web pages and apps?
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.
I like "Alastair's Grand Theory of In-App Webviews":
the main reason webviews in apps have such a bad reputation is because you don't notice the webviews that are integrated seamlessly
I think another split is between:
- 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
I'll concede if you can name one webview that is integrated seamlessly. Maybe the average person wouldn't realise but I think we'd have seen lots of articles about it here. It would be a standard rebuttal to every webview debate, "but Foo is implemented as a webview so it can be done".
Which is probably exactly why this was added. The cheap way to usually tell if someone is using a 3rd party UI toolkit, is to start tweaking the system theming and see if the application follows some scaling/color changes correctly.
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.
There's also, in there somewhere, a corollary about how you don't notice the webviews which don't stick out but just don't feel right. Like, someone mentioned Settings app in MacOS might use them because the icons don't load fast enough.
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.
> Apple used to be about insane polish.
I think that's mostly a brand narrative/myth. MacOS has always had warts at any given time.
No kidding. I grew up loving Macs in general, but despite some people's rose-tinted views of classic macOS in the 80's and 90's, I always had uncontrollable pangs of stabbiness every time I had to do anything in the cluttered, clunky, and tiny interface of Chooser.
"All toupées look fake. I've never seen one that I couldn't tell was fake."
"The Toupée Theory of In-App Webviews" is perfect. I might change it in the post.
Fwiw I think the personal attribution gives it a nice touch.
“Alastair’s Toupee’s theory of in-app WebViews”?
Totally agree with the sibling comment, you should own it! Just made me think of that quote haha.
you write really well OP! please keep it up.
Thanks! I'm hoping to continue down this path and write up some thoughts on how you might actually achieve seamless in-app webviews at some point but, y'know... time.
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...
That was a great read! Thanks!
[flagged]
run it
> It stands to reason that Apple wouldn't have developed this feature if they weren't using it. Where? We have no idea.
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.
> It stands to reason that Apple wouldn't have developed this feature if they weren't using it. Where? We have no idea. But they must be using it somewhere. The fact that none of us have noticed exactly where suggests that we're interacting with webviews in our daily use of iOS without ever even realising it.
This is what stood out to me. I've never really suspected webviews and can't think of a place now.
I often suspect things in Settings, esp. account/iCloud section to be webviews, just based on how they load (icons appearing a short moment after the page opens for example).
Yes, those parts of the Settings app are built with web views that embed React Web:
https://news.ycombinator.com/item?id=30648424
Oh so that's why they're terrible and often break with no error messaging or recourse
Probably, but it’s not as if the native parts of Settings are much better.
When you tap some of the menu items in the “Saved to iCloud” section, they don’t have the normal grey item highlight that happens with the rest of the settings app.
The App Store app seems to be using web views extensively.
It is not. Apple made a big deal about the changeover a few years back.
Both Mail and Calendar use web views for starters.
I’m sure there are many apps like the Apple Store app and parts of the App Store that pull in web views. That’s most likely what this is for. Probably parts of News, Music, Games apps as well.
I assume they're going to use it on Apple.com, the same way that they were using backdrop-filter to simulate the frosted glass on earlier iOSes
according to the post, it doesn't exist on Safari
I’m fairly certain Apple Music makes pretty heavy use of webviews.
Actually it does not. It used to, but then was rewritten. The Accessibility Inspector app can be used to see what's the class of the UI elements, if you want to check.
I think it still might. I use it all the time on my laptop, and periodically if I do something funky with the network, the entire view panel says that there was an internal server error in that classic no-CSS Times New Roman font. Do you have a source for this?
As I wrote above, use Accessibility Inspector to inspect the UI.
Nice find!
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.
I like the glass effects and aesthetics, but I think the functionality in a lot of the apps isn't as good as it was. A lot of things that were easy-to-reach buttons are now tucked away in menus, and harder to find.
That always depends on how difficult discoverability is. For example if you're designing for something like Apple Watch there's very limited place for stuff, so you either pack it or you find ways to only show what's most important, using gestures or menus to do other stuff.
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.
> It's probably better to wait a year or two before critiquing Liquid Glass.
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.
Fair enough, change is annoying to users, plus at the same time there's huge overhead keeping a beta queued up for a year+ while everything slow moves over to a new theme. While management wants something new right away. So it's a difficult compromise I'm sure every frontend dev has had to deal with.
Apple's ecosystem tends to to quickly adapt to new UX. Slightly faster than Android.
I noticed this in safari where the bookmark icon used to be one click was now two. Fortunately you can change it back in the settings by switching the tab layout (whatever that means)
> Apple's new glass UI seems to draw a lot of ire
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
> I can visually tell the size of click targets now and the buttons are finally visually distinct from text
The bar is high
True, but Apple did this to themselves. Their flat UI also drew a lot of ire for this initially, especially from accessibility concerned circles.
My suspicion is that genpop is not going to like it, broadly, mostly because the only people who seem to think that operating systems should have "personality" are techies. People just don't think like that; most people view these systems as means to an end, and anything that isn't in service to that is, at best, simply an interesting diversion for the first few days.
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.
> the only people who seem to think that operating systems should have "personality" are techies
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.
I don't think so, I think the general population gets happy and excited by new things, because they believe it to be somehow better than the old thing. A new cool visual refresh of the OS is something that people gravitate towards, even when it's mostly a superficial restyling hiding decades of cruft (Windows 11)
Count me in the "I think this look is horrendous!" crowd, along with the "What were you thinking, Apple?!?!" crowd.
It's just terrible.
Maybe they don't want anyone using it...yet?
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?
> It stands to reason that Apple wouldn't have developed this feature if they weren't using it. Where? We have no idea. But they must be using it somewhere.
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…
Let's pray this liquid jelly doesnt become a trend
Love or hate liquid glass, the paradigm shift from "UI chrome is a wrapper around app content" to "UI is overlayed on top of app content" seems like the future. It's well aligned with AR and better separates UI layout from content for different screen sizes.
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.
I don't buy it.
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
VR is still aspirational, but we already have AR making baby steps into everything. Every time you see a QR code for the menu burned into a restaurant table, you're looking at a sort of AR: the phone sees it differently than you. Then there's games, but that seems to be largely a passing fad, like 3D TV.
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.
QR codes do not qualify as Augmented Reality at all. "QR" is a data encoding format. It does not augment reality in any way.
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.
> seems like the future
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.
“seems” indicates conjecture
Younger generation is obsessed with nostalgia for Aero/Glass and that whole era's aesthetic. It will definitely become a trend, if not for that then because Apple did it and the industry has lost all innovation outside of "copy whatever Apple does."
As a fan of aero, I hope Google copies the Apple theme with their own aero theme.
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.
Wow, I didn't stop to think how Windows Vista is actually quite close to 20 years old now. It and Windows 7 still feel "modern" in my mind.
I do wish they didn't make it bounce and jiggle so much. It changes the whole thing from looking like glass to looking like a gelatinous blob.
Same boat as you - hope it doesn't but I'm pretty sure it will. Apple is doing it, so other companies will jump on the same bandwagon.
Already has
> you have to toggle a setting in WKPreferences called useSystemAppearance... and it's private. So if you use it, say goodbye to App Store approval.
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
That would not get through the App Store review process.
Depends on how you implement it.
Can you give an example of an app in the App Store that uses internal APIs to provide animated home screen widgets?
thinking of youtube.com/watch?v=NdJ_y1c_j_I ?
Honestly, why don't they just add it to Safari as a css property?
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.
> Honestly, why don't they just add it to Safari as a css property?
It's possible that they will in the future, but are still deciding on the API or implementation.
> But my suggestion is this: the main reason webviews in apps have such a bad reputation is because you don't notice the webviews that are integrated seamlessly.
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.
Mapbox is such a pretty piece of software.
Liquid Glass icons look like crap and it's pretty broken on iOS.
Interesting, using webviews is a common shortcut for a lot of functionality, and even native apps will occasionally have some webviews (that you might not even notice) out of convenience (and sometimes necessity).
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...
It's the ugliest trend I've seen since rounded corners and large padding. One can only hope that it will eventually cease to be a nuisance.
> the main reason webviews in apps have such a bad reputation is because you don't notice the webviews that are integrated seamlessly
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
> the main reason webviews in apps have such a bad reputation is because you don't notice the webviews that are integrated seamlessly.
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.
How is this any different from the effect shown in this Codepen?
https://codepen.io/GreggOD/pen/xLbboZ
They're both glass-inspired effects. If you really want to know the differences, your best bet is probably the WWDC session "Meet Liquid Glass".
At this stage it really feels like features like this’ only purpose is to make older models struggle with basic UI stuff just so people upgrade to the newer devices.
Music app, especially the Apple Music side of things, has historically been big on web views.
Did they provide a CSS feature to prevent modals being cut off at the Safari toolbar?
What does liquid glass effect look like?
For those who don't know what the fuck "Liquid Glass effect" is: it's a sort of frosted glass look that apple uses for their UI.
It's being sold as the best thing since sliced bread. Googling it felt like I entered a parallel universe.
Small demo: https://youtube.com/shorts/-2KaGU8G_vE
Windows 7 did it like 15 years ago
Windows 7 built a design language around it, transparency was never the main attraction.
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).
Windows 7's had more character.
> Whoever it was at Apple that decided to make this a CSS property is a genius because it makes it incredibly easy to provide different rules based on Liquid Glass support
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.
> Create something, that nobody asked for
Their UI team asked for it, to use internally (so far), as part of the latest UI style.
What they want to do with USD and <model> tags is terrible too.
one more reason to never build apps for native
[flagged]
[flagged]
No, what Mac OS X did in like 2001 or so.
No, Windows 7 actually did a glass texture, whereas this is just a blur with marketing.
Chromatic aberration ain’t blur
This looks like a little bit more than a blur, there seem to be some refraction and some other optical-type effects. But realistically its just a blur with marketing.