Technical features
The native architecture behind routing, data, animation and system integrations.
Screen architecture
Every screen keeps three responsibilities separate: an Expo Router route mounts it, a composed module fetches and coordinates state, and a feature component renders plain props. pnpm check:layers enforces that direction.
Sheets and filters are routes too. This gives them native back behavior, restoration and deep links instead of rebuilding navigation inside modal components.
Data and interaction
TanStack Query owns server responses, staleness, retries and invalidation. defineQuery declares a key, fetcher and cache policy once so hooks, prefetches and mutations cannot drift onto different keys.
Expo Router owns applied filters, sorting, tabs, dates and selected records. Zustand is limited to durable client choices such as favourites, saved defaults, card layouts and shell coordination. Query results and active board filters are not copied into stores.
Reanimated 4 shared values carry per-frame gesture and scroll state on the
UI thread. Any unbounded or data-driven native collection uses LegendList with
stable keys and render callbacks. A plain ScrollView is for short, fixed
content; detail pages do not get an exception merely because their rows sit
below a header.
System surfaces use Expo Widgets and Notifications for scores, countdowns, hit rates and match reminders.
Match data comes from the Go API. Convex and Better Auth hold accounts and sessions; RevenueCat supplies subscription entitlements. Keeping those boundaries separate prevents product data, identity and purchases from becoming one coupled backend.
