fernandorojo

> If you were to do it all over again, would you think about building on native technologies instead?

Although it took a lot of effort, it was a new set of UI patterns for React Native, and it hadn't really been done well yet.

Where most RN teams go wrong is they never dip to native code. On the contrary, we wrote a lot of native code, both for our own packages and for updating RN core itself.

The benefits with React Native's composition model are hard to beat. For example, thanks to React's composition with hooks and components, we will likely be able to open source most of the problems we solved into an easy-to-consume library. Or at least that's the hope!

Yeah that's what we use (and we showed it in the patch in the blog post).

There was a bug on a particular iOS 26.2 beta, but it looks like it's already fixed

TIL a Cordova app won

Imagine being the first one!

I ultimately prefer React Native's composition model over SwiftUI.

Something that attracts me to RN is that it's easy to drop down to native. We use SwiftUI for a number of components under the hood. But for a full app, React Native felt better.

Our biggest usage of AI was actually a code review bot which lives on GitHub PRs. It reviews our code on every commit. It was originally an internal tool, but it's now Vercel Agent.

We also used v0 for prototyping ideas and designs for the native app.

For the live activities, we used expo-apple-targets. That helps bootstrap it, link assets, etc. The UI itself is SwiftUI. The hard part here was actually the server-driven events for the activities during the stream. Live activities can be annoying to work with using APNs.

You can just use Share.share() from react-native directly for the share sheet.

Checking on this Firefox issue now, thanks for sharing.

Overall, our focus right now is iOS, but we want to do Android at some point. Even though we used React Native, we also wrote a good amount of native Swift code under the hood to power native modules.

Interesting, that actually should work.

Are you on iOS 26.2 by chance? I'm currently investigating a regression on interactive keyboard dismissal specific to iOS 26.2.

Thanks for sharing, sorry about that. We had an issue on the backend with Apple sign in that we just fixed today. Mind signing out and back in to see if it's fixed?

Author of the blog post here. Happy to answer any questions.

This is cool. I hadn’t come across an objective measurement of accents before.

I’m fan of Daishi’s other work (like Zustand and react-hooks-global-state) so I’m intrigued to see this drop. As a longtime Next.js fan it’s cool to see simplified versions of new tech emerge.

Ah, makes sense.

Tamagui basically solves the part of styling + rendering UI. It works on both web and native.

As for logic/data fetching...this has gotten far, far better in React over the past few years.

For data fetching, assuming you're using REST, @tanstack/react-query is incredible. It gives you a "hook" to wrap any async function, and returns loading states, errors, etc.

In the past, people used Redux, but it's out of fashion now. I prefer a library called zustand whenever I need non-data related global state management.

What do you mean? Tamagui is only concerned with UI. Data and state management live in the react world using hooks.

That's a cool site. I like the use of iframes.

Of course, happy it's helpful.

I wouldn't let its native support pigeonhole it as a React Native-only library.

In my experience, it rivals other web-only libraries, especially with the compiler.

LambdaTest is helpful for these cases FWIW

Somewhat, but it's better. It's like forking React Native Web and solving all of its styling shortcomings.

I used Tamagui to build a number of screens for a new product we're working on, and I saw 90+ lighthouse scores on every page. The fact that I can get that, with SSR support, inline styles, psuedo selectors, typed themes, and that it works on iOS and Android is novel.

I built the first library for React Native that supported Web/responsive design (Dripsy), so it's cool for me to see Tamagui taking this idea to the extreme.

Cool idea. I’ll definitely check it out. We’ve been thinking of making something similar internally.

React Native + Next.js refers to using the same code in both a native app and website (built with Next.js).

The hardest part of sharing code between apps and websites, however, is the navigation code. Websites have flat navigation. You have one page mounted at a time. When you navigate to another page, the original one unmounts and a new one renders.

Native navigation has a different paradigm altogether. Rather than use simple URLs to account for most of the navigation state, native apps have complex tabs, stacks, and more. When you change tabs on Spotify, you expect the previous tab to maintain its state, scroll position, nested screen, etc.

Given all of these considerations, it's previously considered impossible to use the same code for apps and websites, even if they're all written with React.

Solito solves the navigation problem by offering a unified API across Web and Native. This lets you write your code one time with React Native, and use it on both iOS, Android and Web.

From the docs:

> Solito treats URLs as your source of truth. Your Next.js app and React Native app don't communicate at all. They live in total isolation. Solito works by doing this: give me a URL, I'll detect what platform you're using, and then I'll figure out how to navigate to the screen for that URL.

I don't view a single codebase as the goal necessarily. While I see the benefit to doing a WebView everywhere, I prefer the React Native approach: write once, run anywhere by using the underlying native components of each system. Because it has such a great unified API for building UI, React Native is a good abstraction to use the same code everywhere. But what draws me to it is the fact that it maps onto native elements.

That said, I'm sure there are good arguments for Capacitor!

Those kinds of implementation details won't be hard to add to Solito. The API I'm using is that of Next.js. If they adapt to suspenseful approaches to routing, Solito will too.

There are also experiments in the works to make React Navigation lazy load code with suspense on the Native side by bringing Webpack to Native: https://github.com/EvanBacon/expo-auto-navigation-webpack

Another added bonus of this approach is that it will have a pages/ folder API like Next.js.

I don't see why Solito won't be able to support these use-cases as they arise.

Glad it's helpful!

Solito gives a “solo dev” the power to build for multiple platforms.

I built our entire product from scratch for iOS, Android and Web. Rather than rushing to hire a team to do each thing, I felt that if I built the right abstraction layers, it could all be done by one person.

It can be a lonely road when you’re the only one, but Solito helps you feel a little less solo

Someone has brought up adding a Remix integration to Solito, too. It's certainly possible from my end, the question is if Remix would make it possible. Many remix APIs like Form seem to be very browser-specific, so it wouldn't share nicely with React Native.

That said, I opened this discussion on the Remix repo a while ago: https://github.com/remix-run/remix/discussions/1578

If you're using shared screens outside of Remix marketing pages, though, then I imagine a solito/remix could exist to bring the same features the Next integration has to a Remix one.

1. you can code share with iOS and Android. 2. the primitives provided by React Native solve the many bugs you get from low-level CSS and HTML.

there are many other reasons, I touch on all of them in my Next.js + React Native talk at Next.js Conf: https://www.youtube.com/watch?v=0lnbdRweJtA

I built https://beatgig.com with React Native and Next.js as the only front-end engineer and designer, and our iOS app and website share 99% of code across hundreds of screens.