| ▲ | kuschku a day ago |
| 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? |
|
| ▲ | a day ago | parent | next [-] |
| [deleted] |
|
| ▲ | ezfe a day ago | parent | prev | next [-] |
| iOS has many private APIs, this one is no different. The fact it's implemented in WebKit is a red herring. |
| |
| ▲ | catsma21 a day ago | parent | next [-] | | you failed to address the point of the comment you replied to. | |
| ▲ | bigyabai a day ago | parent | prev [-] | | 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. | | |
| ▲ | cosmic_cheese a day ago | parent [-] | | 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. | | |
|
|
|
| ▲ | charcircuit a day ago | parent | prev | next [-] |
| >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. |
| |
| ▲ | jakelazaroff a day ago | parent [-] | | Why would Apple go through the App Store review process for their first-party apps? | | |
| ▲ | charcircuit a day ago | parent [-] | | Because it's cheaper to maintain 1 ingestion pipeline than 2. | | |
| ▲ | Draiken a day ago | parent [-] | | And it's basically free to create a rule "if it's from apple, auto-approve" even if it's a manual process. | | |
| ▲ | charcircuit a day ago | parent [-] | | 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. |
|
|
|
|
|
| ▲ | reaperducer a day ago | parent | prev [-] |
| 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. |
| |
| ▲ | pupatlas 21 hours ago | parent | next [-] | | 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... | |
| ▲ | wahnfrieden a day ago | parent | prev [-] | | 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. | | |
| ▲ | brookst a day ago | parent [-] | | 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? | | |
| ▲ | c-hendricks a day ago | parent | next [-] | | 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. | |
| ▲ | wahnfrieden a day ago | parent | prev [-] | | Did you click my link or read the article? The private API is the WKWebView property. |
|
|
|
