The Mobile App Tech Stack Founders Underrate

What you actually need to know

• Crash reporting (Sentry) must be configured before the first beta distribution. Flying blind to production crashes is not acceptable for a product with real users.
• Fastlane or EAS Build for CI/CD eliminates the manual certificate and provisioning management that consumes engineering time in every mobile project that does not automate it.
• Deep linking must be implemented before launch. Marketing campaigns, push notifications, and shared content all depend on links opening the correct screen in the app.
• OTA updates (Expo EAS Update for React Native) allow bug fixes to ship in minutes without App Store review. For JavaScript-layer bugs, this is the difference between a 15-minute fix and a 5-day wait.
• Push notification infrastructure (Firebase Cloud Messaging) must be set up before the notification feature is needed. It cannot be added quickly when the feature is requested.

The core argument

Founders who plan a mobile app project typically account for the visible features: the screens, the user flows, the API integrations. They often do not account for the infrastructure that makes the app operable: crash reporting, automated builds, deep linking, OTA updates, and push notification delivery. These components are not visible to users when they work; they are acutely visible when they do not.

The team that launches without crash reporting discovers production crashes when users report them in App Store reviews -- days after they started. The team that launches without deep linking discovers the broken push notification navigation the first time a notification campaign sends traffic to the wrong screen. The team that launches without OTA update capability discovers, when the first critical bug is found in production, that the fix takes five days to reach users through the App Store review process.

None of these are rare events. All of them happen to teams that have not set up the infrastructure. The setup time for the full stack -- crash reporting, CI/CD, deep linking, OTA updates, push notifications -- is approximately one week. The ongoing cost of not having it is measured in weeks and months of engineering time spent firefighting problems that infrastructure would have prevented or accelerated fixing.

Crash reporting: Sentry for mobile

Sentry's mobile SDK (React Native and Flutter) captures crashes and provides stack traces, user context, and error trends. Configuration takes 2-4 hours:

```typescript // React Native: index.js import * as Sentry from '@sentry/react-native';

Sentry.init({ dsn: 'https://your-sentry-dsn', environment: __DEV__ ? 'development' : 'production', tracesSampleRate: 0.2, beforeSend(event) { if (__DEV__) return null; return event; }, }); ```

The critical configuration beyond the basic setup: upload source maps in the CI/CD pipeline so production stack traces resolve to readable source code. Without source maps, crash traces show minified code that is not useful for debugging.

Set up three Sentry alerts: any new error (immediate Slack notification), error rate above 1 percent (immediate), and crashes on a specific screen above 0.5 percent (daily digest). These three alerts catch the majority of production reliability issues.

Automated CI/CD with EAS Build

Expo Application Services (EAS) Build provides managed iOS and Android builds without requiring a Mac for the iOS build. The EAS configuration file (eas.json) defines the build profiles:

``json { "build": { "development": { "developmentClient": true, "distribution": "internal" }, "preview": { "distribution": "internal" }, "production": { "autoIncrement": true } } } ``

A GitHub Actions workflow that triggers on pull requests:

``yaml name: EAS Build Preview on: push: branches: [main] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 - uses: expo/expo-github-action@v8 with: expo-version: latest token: ${{ secrets.EXPO_TOKEN }} - run: npm install - run: eas build --platform all --profile preview --non-interactive ``

This workflow builds both iOS and Android on every push to main and distributes to internal testers. The team receives a new build without anyone manually running a build or managing certificates.

For non-Expo React Native projects, Fastlane provides equivalent automation with more configuration overhead. For Flutter, flutter build combined with Fastlane handles both platforms.

Deep linking implementation

Deep linking connects URLs to specific screens in the app. For iOS, Universal Links connect web URLs (e.g., https://app.example.com/matches/123) to in-app navigation. For Android, App Links provide the same functionality.

The implementation requires two components: a hosted verification file (the apple-app-site-association file for iOS, the .well-known/assetlinks.json for Android) that verifies the app's ownership of the domain, and a link handling function in the app that parses the URL and navigates to the correct screen:

```typescript // React Native with react-navigation function useLinkHandling() { const navigation = useNavigation();

useEffect(() => { const handleUrl = ({ url }: { url: string }) => { const parsed = new URL(url); const pathParts = parsed.pathname.split('/').filter(Boolean);

if (pathParts[0] === 'matches' && pathParts[1]) { navigation.navigate('MatchDetail', { matchId: pathParts[1] }); } else if (pathParts[0] === 'profile') { navigation.navigate('Profile'); } };

const subscription = Linking.addEventListener('url', handleUrl);

// Handle the link that launched the app (cold launch) Linking.getInitialURL().then(url => { if (url) handleUrl({ url }); });

return () => subscription.remove(); }, []); } ```

Testing deep links during development: npx uri-scheme open "yourapp://matches/123" --ios or adb shell am start -d "yourapp://matches/123" for Android.

OTA updates with EAS Update

Expo EAS Update pushes JavaScript bundle updates to installed apps without App Store review. Configuration:

``bash eas update:configure eas channel:create production ``

After configuration, deploying an update to production users:

``bash eas update --channel production --message "Fix match schedule crash" ``

Apps configured with EAS Update check for updates on launch (or on a schedule) and download new bundles in the background. The next launch uses the updated bundle.

The update appears for users within minutes of the push -- not 5-7 days. For a critical bug that is affecting 10 percent of sessions, this is the difference between a 15-minute fix deployment and a nearly week-long user experience problem.

OTA updates are limited to the JavaScript layer. Native module changes, permission additions, and native library updates require a full App Store build and review.

Common mistakes founders make with mobile infrastructure

1. Treating the infrastructure as something to add after launch. By launch, the infrastructure should already be running in the TestFlight/beta environment. Adding crash reporting after launch means the first production crashes are discovered through App Store reviews, not through Sentry alerts.
2. Not automating certificate management before the team grows. A two-person team managing iOS certificates manually may be fine. A five-person team with manual certificate management will have build failures every time a certificate expires or a new developer needs access. Automate before the team grows, not after the first failure.
3. Not testing deep links on both platforms before launch. Deep link behavior is different on iOS and Android. Universal Links require HTTPS and a hosted verification file. App Links require a SHA-256 certificate fingerprint in the verification file. Test both independently.
4. Not setting up push notification infrastructure until a feature requires it. Push notification setup takes 1-2 days; it does not need to wait until a specific feature. Set up Firebase Cloud Messaging, register device tokens at app launch, and store them in the database. When the notification feature is eventually needed, the infrastructure is already in place.
5. Underestimating OTA update value by not calculating the alternative cost. For a bug affecting 5 percent of sessions, the cost is 5 percent of session value per day for as many days as the App Store review takes. OTA update for a JavaScript bug takes 30 minutes to deploy. That comparison makes the OTA infrastructure investment clearly worthwhile.

Where to start: a 3-step mobile infrastructure setup

Step 1: Set up Sentry and configure source map upload in the build pipeline before the first TestFlight. Crash reporting must be running before users touch the app. Every day without it is a day where production crashes are invisible to the engineering team.

Step 2: Configure EAS Build and the CI/CD pipeline to produce builds automatically on every push to main. Manual builds are eliminated; every merged PR produces a distributable build. Set up internal distribution for the team and TestFlight for external beta testers.

Step 3: Implement deep linking for the three most important navigation destinations. The notification-opened destination, the shared content destination, and the marketing campaign destination are the three cases that matter before launch. Test both the cold launch and background-to-foreground cases for each.

The Infrastructure That Makes the App Operable

Yashveer Singh. Founder of Yashveer Labs. The Prominence Football Academy app launched with the full infrastructure stack in place: Sentry for crash reporting, EAS Build for CI/CD, Universal Links for deep linking, EAS Update for OTA, and Firebase Cloud Messaging for push notifications. In the first two weeks of public access, Sentry caught four crashes that affected fewer than 0.5 percent of sessions each -- small enough that users might not have reported them in reviews, but visible in Sentry immediately. Two were fixed with OTA updates (JavaScript layer) within hours. Two required App Store builds. The OTA fixes reached users in under 30 minutes; the App Store fixes took four days. The infrastructure difference between the two categories is the thing founders do not plan for -- until they need it.

Related reading

• The Mobile Build Pipeline: Fastlane, EAS, and the Path of Least Pain
• The Mobile App Analytics Stack for 2026
• The Mobile App Lifecycle Hooks Founders Should Know
• The Hybrid Mobile Architecture: WebView Heavy Apps in 2026