111–120 of 208 posts
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'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.
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…
Earlier quoted context omitted.
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.
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 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.
Earlier quoted context omitted.
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?
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.
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.
Earlier quoted context omitted.
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...
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.