Feature Requests

With Expo, you can write iOS and Android experiences in JavaScript using React Native.
Full-Screen Notification Support (for incoming calls)
Add support for displaying full-screen notifications on both Android and iOS — similar to WhatsApp, Telegram, or Zoho Cliq — to enable incoming call or urgent alert experiences directly through Expo Notifications without requiring ejecting or native modules. Motivation Currently, Expo’s expo-notifications API supports displaying high-importance notifications, actions, and categories. However, there’s no way to display a full-screen notification that can wake the screen, bypass the lock screen, or launch a specific activity/view — which is essential for: Incoming call UIs (VoIP or video calls) Alarm-style urgent alerts Emergency or real-time attention events These are standard capabilities in native Android (fullScreenIntent) and iOS (via CallKit), but there’s no managed Expo-level support yet. Proposed Solution Add a property to displayNotification() like: await Notifications.displayNotificationAsync({ title: 'Incoming Call', body: 'John is calling...', android: { category: 'call', importance: Notifications.AndroidImportance.HIGH, fullScreenIntent: true, // 👈 new property fullScreenAction: 'IncomingCall', // optional target view }, ios: { fullScreen: true, // optional; may require CallKit integration }, }); This would internally use: Android: NotificationCompat.Builder.setFullScreenIntent() iOS: Integrate with CallKit or allow a custom full-screen modal when unlocked. Benefits Enables true calling experiences in Expo-managed projects (like WhatsApp or Cliq). Removes the need to eject or use libraries like react-native-callkeep or notifee. Allows apps to handle real-time communication flows entirely in Expo.
0
Co-location of Components in Expo Router
Background As someone coming from a web development background, I have thoroughly enjoyed working with React Native and particularly with Expo Router. The simplicity of just creating files in the app folder to define routes is incredible and reminds me of Next.js routing, but there is one feature I feel is missing — "co-location" of components and related logic per-route . Motivation for Co-location Currently, with Expo Router, every file placed in the app folder automatically becomes a route module. This is great for ease of use, but it presents a challenge when trying to group components and logic specific to that route. For example, components or business logic that only belong to a specific route must be placed in separate global-level folders (commonly components or newly created folders like sections ). This forces developers to either: Place unrelated components together, increasing cognitive load when managing or scaling the app. Maintain a parallel structure that mimics the app folder, creating redundancy and clutter. Many tutorials also encourage the use of a global components folder. While this works, it is not always appropriate. For instance: Global components folders are generally better suited for reusable components. Components meant only for one specific route don’t benefit from being in a global location. By introducing a way to co-locate components alongside their respective route modules , developers can build better-organized applications and eliminate structural inconsistencies. --- Proposed Solution: Co-locating components in Expo Router Introduce route-specific file conventions that enable Expo Router to distinguish route modules from other files within the app folder. This way, we can co-locate components and logic specific to a route without unintentionally turning those files into routes. Example of the Desired Folder Structure: ```plaintext app/ specialists/ index.tsx # Route module tabs.tsx # Route-specific component audiologist-avatar.tsx # Route-specific subcomponent utils.ts # Route-specific helper logic settings/ index.tsx header.tsx # Route-specific component ``` Key Points about the Structure: Only files with specific names (e.g., index.tsx , route.tsx , screen.tsx ) are treated as routes. Any additional files within the same folder are ignored by the router and can freely co-exist alongside the route files. ### Routing Behavior Expo Router would look for special filenames (similar to Next.js's page.tsx convention). Suggested conventions include: index.tsx : The default file that generates the route. route.tsx or screen.tsx : Alternate names to increase flexibility. All other files in the same folder are ignored by the router but remain accessible as part of the same module. This clarifies the distinction between route modules and supporting files, allowing for tight co-location of related components and logic. --- Benefits of this Approach: Improved Organization : Co-locating every route-related piece (components, logic, utilities, etc.) into a single directory eliminates the need to maintain separate components or sections directories. Minimal Changes to Existing Pattern : Developers already familiar with Expo Router won’t find significant disruption to their workflow. The change is purely optional and additive. Simpler Scaling : With all route-related specifics in one folder, refactoring, moving, or scaling a route becomes much easier. Inspired by Next.js Router : This feature draws inspiration from the Next.js routing convention that uses page.tsx to identify routes, allowing the co-location of non-route files. --- Summary This proposed feature will make Expo Router even more powerful by allowing the co-location of route-specific components, logic, and utilities within the same directory as their route module. By recognizing only specific filenames (e.g., index.tsx , route.tsx ), it maintains Expo Router's simplicity while significantly enhancing organizational capabilities. This enhancement aligns with Expo Router's intuitive approach and ensures developers can keep their codebases lean, consistent, and easily maintainable. ---
0
Load More