I took the SwiftUI code that Rork Max generates, layered iOS 26's new Liquid Glass on top, and shipped three apps to the App Store. Rork Max handled the new APIs more gracefully than I expected. The bigger surprise was how easy it is to over-apply Liquid Glass — the effect is supposed to feel pleasant, yet a screen full of it quickly looks busy and unreadable. This note is what I learned from those three real builds.
Decide where Liquid Glass goes before you write a single line
Liquid Glass is a translucent material that warps the background underneath; iOS 26 uses it across system UI like Control Center, notifications, and tab bars. To get the same feel inside an app, SwiftUI gives us the .glassEffect() modifier and a GlassEffectContainer for grouping multiple glass surfaces.
What worked best for me was deciding up front where the effect lives and where it does not. Apply it everywhere and the whole app starts to glare; apply it nowhere and the app looks like an old citizen on iOS 26. After three builds I settled on this rule of thumb:
- Use it for persistent operational UI: bottom tabs, floating action buttons, playback controls, share sheets.
- Skip it in reading surfaces: article bodies, settings screens, dense list rows.
- Use it carefully for buttons sitting on modal sheets, where the background color shifts and contrast can collapse.
If you organize screens the way I describe in the Rork Max SwiftUI native iOS development guide, this boundary maps almost cleanly onto the layout you already have.
How to ask Rork Max for it — one prompt line that changes the output
Because Rork Max generates SwiftUI from natural-language prompts, your wording controls whether Liquid Glass shows up at all. The pattern I came back to was attaching two short lines per screen:
"Apply iOS 26
glassEffectto the bottom tab bar and the floating playback control, and group them inside aGlassEffectContainer. Keep article lists on a regular background."
With that hint, Rork Max consistently produces something close to this:
// MiniPlayer.swift — playback control generated by Rork Max
struct MiniPlayer: View {
var body: some View {
GlassEffectContainer(spacing: 12) {
HStack(spacing: 16) {
Button(action: togglePlay) {
Image(systemName: "play.fill")
.font(.title3)
}
.glassEffect(.regular.interactive())
Text("Now Playing — Sample Track")
.lineLimit(1)
.frame(maxWidth: .infinity, alignment: .leading)
Button(action: skipForward) {
Image(systemName: "forward.fill")
}
.glassEffect(.regular)
}
.padding(.horizontal, 16)
.padding(.vertical, 10)
}
.padding(.horizontal, 12)
}
private func togglePlay() {}
private func skipForward() {}
}The expected result is a single floating glass slab whose tint shifts as the underlying scroll view moves. The .regular.interactive() modifier on the play button gives a subtle press-down response, which is the cue that this surface is something you can actually tap. If you forget the interactive variant on tappable elements, testers often describe the result as "pretty but feels like a screenshot" — the depth cue is doing more work than its visual subtlety suggests. On the flip side, applying interactive glass to non-tappable labels invites mistaken taps, so I keep the pattern strict: interactive on buttons, plain on decorative surfaces.
Falling back on iOS 25 with the smallest amount of code
Even after a full iOS 26 cycle, install share is roughly half-and-half early on. My own production logs showed about 40 % of sessions still on iOS 25 in the first week. Liquid Glass APIs are iOS 26 only, so you need a graceful fallback or builds will fail against older SDKs.
The smallest version of this is a single view extension that all of your call sites go through:
// View+GlassFallback.swift — degrade to .ultraThinMaterial on iOS 25 and below
extension View {
@ViewBuilder
func appGlassEffect() -> some View {
if #available(iOS 26.0, *) {
self.glassEffect(.regular)
} else {
self.background(.ultraThinMaterial, in: Capsule())
}
}
}Call .appGlassEffect() instead of .glassEffect(.regular). Tell Rork Max once that "every .glassEffect call should go through the appGlassEffect extension," and the generated code becomes fallback-safe across re-runs. If a build against the iOS 25 SDK no longer reports Cannot find 'glassEffect' in scope, you are done.
Three failure modes I kept hitting on real devices
Once the apps were on TestFlight, the recurring complaints from external testers came from the material itself rather than from anything Rork Max was doing wrong.
The first was glass buttons becoming invisible on light backgrounds. Liquid Glass amplifies the brightness of whatever sits behind it, so on white the edges essentially vanish. The fix is small — either drop a soft shadow such as .shadow(color: .black.opacity(0.08), radius: 8, y: 2) behind the surface, or push the page background down to .systemGroupedBackground so there is something to refract.
The second was flicker during scrolling. In every case I diagnosed, the cause was multiple .glassEffect() calls living outside a shared GlassEffectContainer. Independent glass surfaces recompute their backgrounds against each other, which throws away frames. Wrapping siblings in a single container clears it up almost every time.
The third one bit me personally during testing: a near-blank screen for users who enable Reduce Transparency. Check UIAccessibility.isReduceTransparencyEnabled inside the appGlassEffect extension and substitute Color(.systemBackground).opacity(0.95) when it is on. Readers spending real time in your app should never end up unable to see a button because of a system setting. Adding the check once in the extension means every screen behaves correctly without any per-screen plumbing, and it took me a single regeneration with Rork Max to roll the change across an existing project.
None of these caused App Store rejections on my side, but a single review that says "I cannot see the buttons" tanks the rating fast. Readability outranks Liquid Glass — that is the firmest takeaway from shipping these.
Watch the device tier — Liquid Glass costs more than it looks
Liquid Glass uses live background sampling, which is more expensive than the static .thinMaterial blurs you may be used to from earlier iOS versions. On the iPhone 17 Pro and the latest iPad Pro the impact is invisible. On older devices that still get iOS 26 — the iPhone 14 line and the base iPad — you can see frame drops if a single screen has more than three independent glass surfaces, especially during scroll.
Two habits kept my numbers stable in Instruments. First, share a single GlassEffectContainer for all surfaces in the same coordinate space, instead of attaching .glassEffect() to multiple distant views. Second, avoid putting glass over animated content such as a Lottie hero or a video preview; the material has to recompute every frame, which is where the visible jank shows up. If you must overlay glass on motion, tighten the area to the smallest practical rectangle so the GPU has less to sample.
Also worth knowing: Rork Max defaults to one container per logical control group, which is the right call. If you ask it to "remove the GlassEffectContainer to simplify the code," resist the urge. The container is doing real work for you on mid-tier devices, even if the visual diff looks identical on a brand-new phone.
Protect your defenses from Rork Max regenerations
Rork Max rewrites files when you regenerate, which means the appGlassEffect extension and accessibility checks you added by hand can disappear without warning. The setup that worked for me was reserving one folder that Rork Max never touches.
I create a Sources/AppExtensions/ folder for view extensions, color tokens, and accessibility helpers, and tell Rork Max in the project prompt that "files under Sources/AppExtensions/ are out of bounds." Regenerations leave the folder alone, and the fallback layer survives. If you want to go further and tune the Xcode side as well, the merge strategy in the Rork Max × Xcode native optimization workflow walks through how to keep manual edits across regenerations.
If you are pairing Liquid Glass with Apple Intelligence sheets, the Rork Max guide to Apple Intelligence integration is worth reading next — it covers how to layer glass over Writing Tools and Image Playground surfaces without contrast collapsing.
Start with the bottom tab bar only
The cleanest start across all three apps was Liquid Glass on the bottom tab bar, and nowhere else on the first ship. That single move makes the app feel native to iOS 26 with almost no readability risk, and it is one prompt line away in Rork Max. Push a TestFlight build of an app you already use, hold it in your own hand, and judge the new material in context. Expanding from there to floating playback controls or share sheets is a much safer second step than trying to redesign every screen at once. I would also keep a quick log of which screens still feel busy after the change. Liquid Glass rewards restraint, and a small in-app journal of "too much" moments has been the most reliable feedback loop I have for tuning the next iteration.