Hacker News Reader

Comment by theshrike79 | Hacker News Reader

IMO the actual reason for Liquid Glass is that they can do it natively. 3rd party UI frameworks can't copy it without a massive performance hit.

This brings a more clear divide between fully native iOS applications and React Native -style "build once and cross-compile" -platforms.

View on HN

I get where you're coming from but React Native(RN) is a bad example. RN is actually native and uses native components. So any native view will be supported, including Liquid Glass. e.g. https://expo.dev/changelog/sdk-54-beta#ios-26-and-liquid-gla... or https://github.com/callstack/liquid-glass

I wrote about this topic earlier, I believe there is one main reason for Apple to go in this direction: universal design language (spatial computing, Vision Pro). Of course, there can be many side-effects (or reasons) that can be the actual main reason instead, such as 'innovation' or like you mention, guiding people to use the native systems, we'll never know. In my eyes, the universal design language is the main reason. Apple is and always has been design-focused.

While this may be a nice side-effect of that direction, I am quite sure that Apple was not even considering such 3rd party impacts when they decided.

Looking back at the announcement, it's more likely that the Management had to decide on the key message for the unveiling prior to the event, and there wasn't much "media-disruptive" to choose from.

So Liquid Glass got elevated to top priority and then all teams got the order to ensure it is present in as many apps as possible.

Any third party UI frameworks which does NOT reuse the platform. There are different views on this. Perhaps that in the long run, that may make more sense since you may want to facilitate the same user experience across devices anyway. Especially for branded apps. So Liquid glass or not would not matter that much, especially if this is simply a design fad like the numerous ones before it.

Now my personal inclination is to integrate with the platform still, as someone currently in the process of building such 3rd party frameworks. Less work for me as the platform handles rendering, keyboard events etc.

The only issue is that on iOS, UIKit is far easier to interact with than SwiftUI. And Swift is too large a language and SwiftUI not simple enough for my taste. Just too bad it is difficult to piggy back on what exists in SwiftUI and is not available in UIKit (yet). There are ways to bridge in a tripartite way perhaps.. But I digress...

If the native apps end up looking worse than the web apps then they played themselves...

>3rd party UI frameworks can't copy it without a massive performance hit.

Do you believe pixel shaders are some unique magic that only Apple has the secret sauce to and noone else can use? There were some efficient implementations of liquid glass for flutter before the iOS beta was even released. Glass effects are dime a dozen on shadertoy, they're one of the most basic effects you could learn to do when learning about texture sampling.

The platforms that will take a large performance hit are the ones that can't drop down to the native platforms, i.e. the web.

But will someone spend the time to recreate a pixel-perfect Liquid Glass effect?

(Actually, someone probably will. People are weird that way.)

I'm pretty sure any recreation will still be just that little bit off compared to the native one, which is their intention IMO.

Reply on news.ycombinator.com