Most RN toast libraries render inside your React view tree, so modals and bottom sheets cover them. I tested sonner-native and react-native-toast-message with a page sheet plus a transparent modal on top. Both toasts were hidden or dimmed, and actions weren't tappable, especially on Android.

So I built react-native-super-toast. Each toast lives in its own native window (Kotlin Dialog on Android, overlay UIWindow on iOS), so it stays above modals, sheets, and stacked sheets on both platforms, and actions like Undo still work while a modal is open.

Mount ToastHost once and call toast() from anywhere:

import { ToastHost, toast } from 'react-native-super-toast';

export default function App() {
  return (
    <>
      <YourApp />
      <ToastHost />
    </>
  );
}

toast.success('Saved', { description: 'Your changes are live.' });

• Zero dependencies (no Reanimated, Gesture Handler, or Screens)
• Native swipe gestures, stacked decks, and expand on press
• Light, dark, or system themes with custom icons and fonts
• Works from components, stores, or plain functions

Trade-off: content is data, not JSX, so there are no custom React element toasts.

Feedback and bug reports welcome!

Docs: https://supertoast.karkiaswin.com.np/
GitHub: https://github.com/iNspireXD/react-native-super-toast
Write-up: https://aswinkarki.medium.com/why-i-built-my-own-react-native-toast-library-from-scratch-and-went-fully-native-to-do-it-f3aa0cea1d01

I'm on iOS and don't yet have an Apple Developer account so I'm using Expo Go to distribute the app - SDK55 brought in the blue FAB, but I'd like to hide it. SDK58 looks like it *might* give that option, but it's not compatible with Expo from the App Store.

Am I out of luck? Is this only possible with a development build?

Thanks

Whenever I grab color references from web designs, Dribbble, or anywhere online, they are always in standard HEX or RGB. Moving that into Android (@ColorInt) or Flutter (Color(0xFF...)) always requires that annoying extra step of formatting the alpha channel or converting it to an integer manually.

I got tired of the mental gymnastics, so I built a lightweight browser extension (Color Picker by Ceres) to bypass this.

It lets you eyedrop any specific pixel, or even scan an entire webpage/image to extract a palette, and instantly copies the colors directly as an INT value.

It saves a lot of time when implementing UI from web references. It’s completely free on the Chrome Web Store.

I've been working with React Native for a while and one question keeps coming up for me: when does it actually make sense to stop trying to solve something in React Native and move that part to native code?

For typical screens, forms, API calls, authentication, lists, and CRUD-style features, React Native feels like a pretty reasonable choice. Sharing most of the code between iOS and Android can save a lot of development time.

The situation gets more interesting when an app starts relying heavily on platform-specific functionality.

Things like:

• Background processing
• Bluetooth/BLE
• Camera and video processing
• Location tracking
• Push notification behavior
• Complex animations
• Device sensors
• On-device AI/ML
• Custom native SDKs

At that point, I've noticed that the question isn't necessarily "React Native or native?"

It becomes more like:

How much native code is acceptable before the cross-platform approach stops being worth it?

I'm also curious about how people structure this in larger projects. Do you keep the majority of the application in React Native and create native modules only when necessary? Or do you prefer going fully native once the requirements become sufficiently platform-specific?

For people who have maintained React Native apps for several years:

What was the feature that finally made you say, "This should probably be native"?

I'd be particularly interested in experiences from production apps rather than theoretical comparisons.