Micro-Bundles We Barely Understand, Overdosing on Liquid Glass, and a Flutter Hit Piece

Issue #12

01 July 2025
5 Minutes

Glass, Guts, and Granular Updates


Flutter Freezes, React Native Melts the Glass


Oh, Flutter—good luck with that. In a move that feels less like innovation and more like a carefully worded admission of “maybe next year,” the Flutter team confirmed they won’t be adding support for iOS 26’s “Liquid Glass” UI or Material 3 Expressive directly into the framework’s core. As they put it themselves:


“As with Material 3 Expressive, we are not developing the new Apple’26 UI design features in the Cupertino library right now, and we will not be accepting contributions for these updates at this time.”


If you missed the WWDC fanfare: Liquid Glass is Apple’s new system visual effect for iOS 26, bringing highly dynamic, depth-blurring, and refraction-based UI materials—like frosted glass on steroids. It demands per-pixel depth data, real-time blur, parallax, and layered transparency with high performance. Supporting it isn’t trivial.


Flutter’s reliance on its Skia-based renderer makes layering platform-native visual effects a recurring headache. This isn’t a new problem: things like iOS’s native blurs, shadows, and edge effects have always needed custom workarounds. Liquid Glass amplifies that gap, raising the bar well beyond simple translucency.


Meanwhile, in the React Native community, @saul_sharma is working on a package that promises to unlock every feature of Liquid Glass, from real-time Gaussian blur with iOS depth layers to dynamic refraction. If Saul pulls this off, React Native apps could match or surpass the native Liquid Glass experience.


So while Flutter might need a prayer and a rewrite, React Native devs should keep an eye on Saul’s work—because the full power of Liquid Glass could soon be a drop away.


👉 Flutter Issue #170310

👉 Every iOS 26 Liquid Glass Feature

The React Native Community Moves as One


React Native 0.80 landed two weeks ago
, and across the ecosystem, libraries are quickly aligning with the New Architecture—another clear sign it’s time to consider migrating your app if you haven’t already.


Expo
now supports RN 0.80 via the Expo 54 canary release (expect the stable release later this summer bumping directly to RN 0.81). Core libraries like Gesture Handler 2.26 have added RN 0.80 support alongside updates for newer native features. The latest Radon IDE 1.8 release also brings full support for RN 0.80, making it easier than ever to debug and develop apps on the New Architecture.


Meanwhile, a quieter but important trend: libraries like Unistyles, VisionCamera, and create-react-native-library are adding support for Android 16 KB memory pages. What changed? Older Android devices used 4 KB pages; newer devices (especially some on ARM) use 16 KB pages by default. Without support, native libraries can crash on these devices due to misaligned memory assumptions. Adding 16 KB support ensures stability on modern hardware.


👉 Unistyles 2.43

👉 VisionCamera 4.7

👉 create-react-native-library 0.51


Together, these updates show the community’s momentum: React Native 0.80 isn’t just another release—it marks a turning point where library maintainers are embracing the New Architecture and modern Android requirements in lockstep.



Safe Spaces and Snap-in Screens


React Native Safe Area Context 5.5: Insets Without the Hooks


The perennial struggle of dealing with notches, home indicators, and weirdly shaped screens just got a bit less annoying. React Native Safe Area Context 5.5 introduces SafeAreaListener, a shiny new way to observe safe area changes without forcing your component to re-render every time a phone decides to grow a new chin.


Prior to this update, getting real-time insets meant using hooks like useSafeAreaInsets() or useSafeAreaFrame(), which, while effective, often led to unnecessary re-renders of entire component trees. With the new SafeAreaListener component, you can now subscribe to safe area updates in a more controlled, performance-friendly way, only updating state when it actually matters.

Under the hood, SafeAreaListener calls your onChange handler whenever insets or frame data updates, so you can manage layout adjustments, animations, or metrics logging with precision—without hooks.


👉 React Native Safe Area Context 5.5.0

Granite, Microservices, and Probably a Lot of Unfamiliar Terms


If you’ve ever looked at your decade-old iOS or Android app and thought, “React Native looks great, but I’d rather not torch everything to the ground,” Granite might just be your new favourite toy. This freshly open-sourced framework from the folks at Toss promises to bring React Native into brownfield apps (brownfield apps are existing native apps where you add new features without rebuilding everything).


Of course, libraries like Callstack’s React Native Brownfield already let you embed React Native views in legacy apps. Where Callstack’s solution wires React Native into your existing binary, Granite fully embraces microservice architecture: each React Native screen becomes a tiny, independently built and deployed micro-frontend. Think Lego blocks you can snap into your app one at a time. Need to update the checkout flow? Build and deploy just that screen — no need for a full app release.


To make this magic happen, Granite packs a micro-bundling strategy that slices your React Native code into ~200 KB bundles, optimises them with ESBuild, and ships them to AWS S3/CDN with one command via their CLI. They’ve even baked in infrastructure automation with Pulumi, so you can spin up a complete CDN-backed deployment pipeline with a single TypeScript file.


Here’s a peek at how you’d wire up your micro-bundle for deployment:

So… is this OTA? (Over-The-Air update). Not exactly — but it’s pretty close. Unlike classic OTA tools like CodePush or EAS Update, which replace your JS bundle inside the app binary on the device, Granite hosts each micro-bundle on a CDN. Your app fetches the latest screens dynamically at runtime, giving you OTA-like flexibility with a full AWS-powered setup behind it.


If you’ve been dreaming of incrementally modernising your legacy mobile apps with React Native — without rewriting 100k lines of Objective-C or Java — Granite might be the bridge you’ve been waiting for. Or at least the spark of hope you need when your manager says:


“Can we add React Native? But… slowly.”


👉 Granite



Before you Go…


SnapAI: App Icons, Just Add Water™


SnapAI—built by @betomoedano, yep, that Beto from Code With Beto and Expo fame—is a deceptively simple CLI that unleashes AI‑generated app icons straight into your React Native or Expo project. It taps into OpenAI’s latest image models (think DALL·E under the hood) to produce multi‑format, multi‑size icons in seconds—all by typing one line in your terminal.

Output? Crisp PNGs or SVGs ready for iOS, Android, Expo, CI/CD pipelines. No designer needed, zero manual resizing or renaming—SnapAI even organises file structure and lets you automate batch generation for each theme or variant.


Why does this matter? React Native developers—especially indie devs—often skip over cohesive iconography until late in the game, only to find themselves wasting days in Figma or trawling obscure icon packs. Snapai automates that painful step. The generated assets can match light or dark themes, multiple resolutions, and different style directions (flat, outline, etc.), which can drastically speed up polishing your app’s UI.


👉 Snapai on GitHub

The VaultHitchhiker's Guide
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Take me back to the paradise city, where the grass is green and the girls are pretty, oh, won’t you please take me home…
Made with 👽 tech by Luke Farrell, Seyda and Friosn.
After a couple words from all our loyal sponsors, of course: