Beyond the Try-Catch: Engineering Resilient Universal Architectures

I’ve spent the better part of a decade building mobile and web apps, and if there’s one thing that keeps me up at night, it’s the try-catch block. It’s the "hope for the best" of programming. You wrap some code, you catch an unknown error, and you pray your fallback logic covers every edge case from a spotty 5G connection in a tunnel to a malformed JSON response from a legacy API.

In my recent work with Expo, I realized that the universal nature of our apps—running on iOS, Android, and Web—doesn't just double our reach; it triples our failure surface area. That’s when I stopped reaching for standard promises and started reaching for Effect.

The Problem with "Normal" Error Handling

In a standard Expo app, your data fetching usually looks like this:

const fetchData = async () => {
  try {
    const response = await fetch('https://api.example.com/data');
    const data = await response.json();
    return data;
  } catch (e) {
    // Is this a network error? A parsing error? A 404?
    // TypeScript has no idea.
    console.error(e);
  }
};

This is "untyped" failure. Your compiler can’t help you. If you forget to handle a specific error type, the app crashes, or worse, stays in a permanent loading state. When you're building cross-platform, these failures manifest differently across environments.

The Breakthrough: Effect

Effect is a functional programming library for TypeScript that treats errors as first-class citizens. Instead of throwing exceptions that blow up the stack, Effect returns errors in the type signature.

When I paired this with Expo, the architecture of my universal apps shifted from "defensive" to "deterministic."

Step 1: Modeling Success and Failure

Instead of an async function that might throw, I define a program. Here is how I handle a native module interaction (like Expo SecureStore) using Effect:

import * as SecureStore from 'expo-secure-store';
import { Effect, Context } from "effect";

class StorageError { readonly _tag = "StorageError" }

const getAuthToken = Effect.tryPromise({
  try: () => SecureStore.getItemAsync('auth_token'),
  catch: () => new StorageError()
});

Now, the type of getAuthToken isn't just Promise<string>. It's an Effect<string | null, StorageError, never>. The TypeScript compiler now forces me to handle StorageError before I can use the result. This is a game changer for senior engineers responsible for app stability.

Step 2: The Universal Layer

One of the biggest breakthroughs I had was using Effect's Layers to handle environment-specific logic in Expo. Imagine you have a logging service that uses a native mobile logger on iOS/Android but standard console logging on Web.

interface Logger {
  log: (message: string) => Effect.Effect<void>;
}

const Logger = Context.Tag<Logger>();

// Native Implementation
const NativeLogger = Layer.succeed(Logger, {
  log: (msg) => Effect.sync(() => NativeSentry.captureMessage(msg))
});

// Web Implementation
const WebLogger = Layer.succeed(Logger, {
  log: (msg) => Effect.sync(() => console.log(`[Web]: ${msg}`))
});

Using Expo’s platform-specific file extensions (.web.ts vs .ts), I can provide the correct Layer at the root of my application. My business logic remains completely pure and platform-agnostic.

Why This Matters for Expo Developers

Expo allows us to iterate incredibly fast. But speed often leads to fragility. By integrating Effect:

1. Eliminate "Zombies": No more components stuck in loading because a promise rejected silently.
2. Retry Policies: Effect has built-in primitives for retrying failed network requests with exponential backoff. Doing this manually in a useEffect is a nightmare; in Effect, it's .pipe(Effect.retry(Schedule.exponential(1000))).
3. Traceability: When a user on an Android 11 device in a low-bandwidth area hits an error, Effect's built-in tracing tells me exactly which part of the pipeline failed, not just "Unexpected token < in JSON".

Final Thoughts

Moving beyond the try-catch isn't just about using a new library; it’s about a mindset shift. It’s about admitting that failure is an expected part of the lifecycle of a mobile app.

If you're building complex, universal apps with Expo, I highly recommend looking into Effect. It turns the "chaos" of cross-platform development into a predictable, type-safe engine. Your users (and your Sentry quota) will thank you.

Keep building, keep breaking things, but start catching them properly.