Issue #18
Two weeks out from React Universe Conf and suddenly the community feels like a countryside field at dusk—bugs chirping, breeze whispering, not much else. Most of the big announcements were dumped at React Universe Conf, so the timeline looks eerily quiet.
But of course, our job is to rummage through the forgotten corners of the web and see if something—anything—actually happened in React Native land these past two weeks.
Spoiler: plenty did. So grab your organic kombucha, sit back, and enjoy the unstoppable march towards progress.
We covered this back in #16 but Expo SDK 54 ships with React Native 0.81 and precompiled iOS frameworks. Expo Router v6 also lands with some upgrades of its own. Link Previews now give you iOS-style peek-and-pop snapshots straight from <Link>, and Native Tabs bring proper iOS/Android system-level navigation (beta, under unstable_ imports). That means scroll-to-top, native transitions, and yes — on iOS 26, even that Liquid Glass tab bar.
Okay, so I’m sorry about this, because I bet if you hear the words Liquid Glass again you’ll probably track me down and punch me in the face.
Here’s the update: Apple’s shiny new .icon format. It’s basically their replacement for shovelling around folders of PNGs — a bundled, layered icon project that knows about light/dark modes and all the sizes you’ll never forget to export.
Expo now supports pointing app.json at one of these bundles, so instead of a single icon.png you can just do:
Which means you can design icons with Apple’s Icon Composer and ship layered, frosty-glass designs that gracefully fall back on older iOS versions.
Now, since we’re already on the topic of Liquid Glass, it’s worth mentioning that Expo UI for iOS is in beta, giving you SwiftUI-style primitives right inside your Expo app. You’re still writing React, but the views under the hood are native SwiftUI, complete with support for Liquid Glass modifiers, button variants, and a few other modern iOS niceties. The components in Expo UI have a 1-to-1 mapping to SwiftUI views.
It’s not a revolution, but it is a neat way to get the current Apple look without rewriting your app in Swift. Here’s how a simple stack uses SwiftUI with Expo:
Compiling with Xcode 26 isn’t optional if you want to play with the iOS 26 toys. EAS Build and workflows default to Xcode 26 for SDK 54 projects, so most cloud builds are already there. If you’re building locally, you’ll need to update Xcode yourself.
Test your app. Apple’s Liquid Glass looks slick in a demo, but in practice it can just as easily make your UI into unreadable slush if you’re not careful. Better to catch that now than have your “next-gen aesthetic” end up looking like a batch of Heisenberg’s finest.
👉 Expo 54
True story: I wear my RevenueCat t-shirt to every standup. Sadly, they don’t sponsor this newsletter (though I wish they did). But today we’re not talking about them — we’re talking about Expo IAP. No, Expo didn’t resurrect their old IAP module from the grave (sigh). This time it’s a community effort that’s brought a new one back.
If you’ve ever tried wrangling in-app purchases in React Native, you’ll know it feels less like a checkout flow and more like a checkout chokehold. Enter expo-iap, a shiny new Expo module from @hyochan. Think of it as react-native-iap’s Expo-first sibling, raised on a strict diet of OpenIAP compliance (an open standard that defines a consistent way to handle in-app purchases across platforms so devs don’t have to reinvent the wheel for every store) and better integration with Expo’s module system.
Under the hood, it’s pulling in Google Play Billing v8.0 on Android (hello, Kotlin 2.0+ headaches) and Apple’s StoreKit on iOS. That means you’ll need to fiddle with expo plugin properties to get the right Kotlin version pinned, because Expo’s core still hasn’t fully caught up. Once you are setup purchases flow through a clean, spec-aligned API.
Is it perfect? Probably not — subscriptions, receipts, and edge-cases still need careful testing. But if you’re building an Expo app and want IAP without ejecting into native chaos, this library is currently the most promising ticket in town.
👉 Expo iAP
Expo just rolled out App Integrity, a tidy wrapper around Google Play Integrity (Android) and Apple App Attest (iOS) so your backend can tell a real app on a real device from a bot, a tampered build, or Chad’s curl script. The pitch is simple: the client requests an attestation, gets a signed verdict from the platform, and your server verifies it before handing over the good stuff.
For the sake of not making this newsletter look like your App.tsx before you discovered folders, we’re going to show you an example of what this looks like on Android. Why Android and not iOS, you may ask? Honestly, because some guy complained on Reddit that we’re “too iOS-centric,” so take it up with him.
Here’s what your frontend will look like:
Then, on your server-side application, you would do something like this:
Under the hood, Android uses Play Integrity’s Standard flow (verdicts like device/app integrity), while iOS leans on App Attest to prove the app bundle and device are legit. You still have to wire up server-side verification (no magic there), but you get a consistent client API across both platforms—without dragging Firebase App Check into a project that doesn’t use Firebase.
👉 Expo App Integrity
Software Mansion are back at it again, this time sneaking a full-blown rich text editor into React Native — but without the WebView baggage. react-native-enriched is exactly what it sounds like: ̶y̶e̶t̶ ̶a̶n̶o̶t̶h̶e̶r̶ ̶r̶a̶d̶i̶o̶a̶c̶t̶i̶v̶e̶ ̶e̶l̶e̶m̶e̶n̶t̶ ̶f̶r̶o̶m̶ ̶S̶o̶f̶t̶w̶a̶r̶e̶ ̶M̶a̶n̶s̶i̶o̶n̶’̶s̶ ̶n̶a̶m̶i̶n̶g̶ ̶l̶a̶b̶ a native-backed text input that lets you do all the usual formatting tricks (bold, italics, strikethrough, headings, lists, quotes).
Essentially, it’s just a fancy TextInput. You still need to set up all your UI controls for the actual “editor” part of your interface, but the EnrichedTextInput gives you some utility methods to style the text within it.
Instead of wrangling state for every keystroke, it runs natively, which means buttery-smooth input even as you sprinkle in mentions, links, or the occasional inline image. There’s even an onChangeHtml event for when you inevitably need your notes/comments/messages stored as markup. Android is feature ready; iOS is catching up with features like code blocks and images still in the queue.
Of course, this doesn’t run in Expo Go (custom dev client required), and if you’re still dragging your feet on upgrading past RN 0.79, don’t bother it’s ̶c̶o̶o̶l̶ ̶k̶i̶d̶s̶ new-architecture only . But if your app has any kind of user-generated content, this might be the first time “rich text in React Native” doesn’t immediately trigger your WebView PTSD.
Do you work with someone with hawk eyes — someone who can stop you while you could be building features to ship humans to Mars or clean the ocean, just to point out that the borders on the rectangles you shipped don’t look Apple-enough?
That’s a squircle: not a circle, not a square — a mathematically smug corner that eases into the edge like it’s been sanded by angels.
react-native-fast-squircle hooks straight into the native renderer so your <View> becomes a FastSquircleView—with borders, shadows, clipping, the lot—at speeds the author claims are ~10× faster than SVG hacks. No WebViews, no Skia detours, just native iOS/Android shapes doing posh geometry at 120fps.
The API’s almost suspiciously simple: set cornerSmoothing from 0 (plain rounded rect) to 1 (full “designer just said iOS”)—defaulting to 0.6 to mirror Apple’s “continuous” feel. Caveats are sensible: you’ll need a custom dev client (no Expo Go) and a quick prebuild; after that it behaves like a normal <View> that’s been to finishing school. If your app ships avatars, cards, tiles or any UI that wants to whisper “premium” instead of yelling “borderRadius: 12”, this is… ludicrously on-brand.
By the way, on another note, we won the React Universe Conf meme contest—just in case y’all had any doubts about who the best “memers” are around here ✌️.
#MakeYourOwnMemes.
