apps/mobile

Mobile (Expo)

Target: single React Native codebase for iOS and Android under apps/mobile (not scaffolded in the repo yet — same programme as web). Expo provides EAS builds, OTA updates for eligible JS changes, and native modules for maps, location, and push.

Stack

Visual design matches the cultural design language used on web — same roles for colour, type scale, and motion rhythm (native controls styled; not generic Material as the brand default).

  • Expo SDK, Expo Router (file-based routing)
  • TanStack Query v5, Zustand
  • Persistence: MMKV (or similar) for cart; Secure Store for tokens
  • @stripe/stripe-react-native (or hosted Checkout in WebView — pick one pattern)
  • react-native-maps + expo-location for nearest stall
  • expo-notifications for reminders; device token registration to API when ready
  • packages/validators for shared input validation

Planned folder tree

apps/mobile/
├── app/
│   ├── (tabs)/index.tsx            # Home
│   ├── (tabs)/packages.tsx
│   ├── (tabs)/bookings.tsx
│   ├── (tabs)/profile.tsx
│   ├── packages/[slug].tsx
│   ├── booking/cart.tsx
│   ├── booking/checkout.tsx
│   ├── booking/confirmation.tsx
│   ├── auth/login.tsx, register.tsx
│   ├── _layout.tsx
│   └── +not-found.tsx
├── components/
├── hooks/
├── stores/          # Zustand + MMKV
├── lib/
│   ├── api-client.ts
│   ├── auth.ts
│   └── notifications.ts
├── constants/
├── app.json / app.config.ts
└── eas.json

Screen checklist

  1. Splash + onboarding
  2. Home
  3. Services / packages list + filters
  4. Package detail + add to cart / book
  5. Cart + checkout (pilgrim + ancestor flows per package type)
  6. Find nearest stall (permissions, map, sorted list)
  7. My bookings + detail
  8. Profile
  9. Notifications (local + push when configured)

Updates during the mela

Expo Updates can ship JS/asset fixes quickly. Apple’s guidelines still apply: no undisclosed native capability changes. Plan store releases for native dependency upgrades.

Auth on mobile

Align Better Auth with a supported mobile session model (cookies vs bearer). Document the chosen approach in Backend API so both clients share one contract.