DEV Community: Amanda Gama

MVC, MVP, MVVM in React Native: what survives the trip

Amanda Gama — Tue, 12 May 2026 02:49:13 +0000

MVC, MVP, MVVM all come from worlds React Native doesn't fully have. Half of each pattern dies on import. The other half is what most React Native code is already doing under different names. This post is about which half is which.

What React Native is missing

Before mapping a pattern onto React Native, notice what isn't there.

No swappable view. In Cocoa or WPF, the View is an object you can replace, subclass, or wire to a different controller. In React Native the View is a function call result. There's nothing to swap. The closest equivalent is "render a different component," which isn't the same operation.

No two-way binding. WPF, Knockout, early Angular: the View binds to a property; updating either side updates the other. React went the other way on purpose. State flows down, events flow up, and "binding" is a manual value plus onChange. MVVM assumes the binding does work; in React Native, you do that work.

No framework-managed event loop. MVC and MVP came from worlds where the framework dispatched events to your Controller or Presenter. In React Native the runtime is JS plus React's reconciler. Events arrive at components. There's no router for them above that.

Components are functions, not objects. This is the one that breaks the most. Every pattern named here was designed around classes with explicit lifecycles. Hooks replaced that with closures and effects. The shapes don't line up.

You can ignore all of this and write class HomeScreenController extends Controller if you want. It will compile. It won't feel right, and it will be the only Controller in the app inside a month.

The example

One screen, carried through every pattern. A list of items with loading, error, and refresh. Boring on purpose. The interesting part is where the logic ends up.

function ItemsScreen() {
  // get list, status, retry, refresh from somewhere
  // render based on status
}

Where "somewhere" lives is the whole conversation.

MVC: the Controller has no home

MVC's job split:

Model holds data and rules
View renders
Controller receives input, mutates the model, tells the view to update

In Cocoa, the Controller is a real object. viewDidLoad, tableView(_:didSelectRowAt:), methods you can put a breakpoint on. In Rails, the Controller is the route handler.

In React Native, where would you put one?

function useItemsController() {
  const [state, setState] = useState({ status: 'idle', data: [], error: null })

  const load = async () => {
    setState({ status: 'loading', data: [], error: null })
    try {
      const data = await api.get('/items')
      setState({ status: 'ready', data, error: null })
    } catch (error) {
      setState({ status: 'error', data: [], error })
    }
  }

  return { ...state, load }
}

That's a hook. We called it a controller. It's still a hook. And it lives inside the component that renders, which is the View. The Controller you can put a breakpoint on, the one that has its own lifecycle, doesn't exist here. Hooks ate it.

The other failure mode is worse. People interpret "Controller" as "the screen file with all the logic in it" and end up with 600-line components that nobody calls a controller but that play the same role. That isn't MVC. That's MVC's symptom without its discipline.

What survives: the Model. A real Model layer (use cases, repositories, types) is still useful and still goes in a folder that isn't screens/. The Controller part has no analog worth defending.

MVP: the Presenter, almost

MVP fixed one thing about MVC: the View becomes passive. It only knows how to render and emit events. The Presenter holds the logic and pushes data to the view.

In Android, this looked like:

class ItemsPresenter {
  void onAttach(ItemsView view) { ... }
  void onLoad() { ... } // calls model, then view.showList(...)
}

In React Native, the closest analog is a custom hook that returns a fully-shaped props object, paired with a passive component:

function useItemsPresenter() {
  const [status, setStatus] = useState<'idle' | 'loading' | 'ready' | 'error'>('idle')
  const [items, setItems] = useState<Item[]>([])
  const [error, setError] = useState<Error | null>(null)

  const load = useCallback(async () => {
    setStatus('loading')
    try {
      setItems(await getItems.execute())
      setStatus('ready')
    } catch (e) {
      setError(e as Error)
      setStatus('error')
    }
  }, [])

  useEffect(() => { load() }, [load])

  return { status, items, error, retry: load }
}

function ItemsView({ status, items, error, retry }: Props) {
  if (status === 'loading') return <Spinner />
  if (status === 'error') return <ErrorState error={error} onRetry={retry} />
  return <FlatList data={items} renderItem={...} />
}

function ItemsScreen() {
  const props = useItemsPresenter()
  return <ItemsView {...props} />
}

This works. It's testable: you can render ItemsView with arbitrary props in a Storybook story or a snapshot test, and you can run useItemsPresenter in renderHook without touching the UI.

The friction is honest. You now have three things (screen, presenter, view) where some teams would rather have one. The split feels like ceremony when the screen is small. The first time the same screen needs a tablet variant, an A/B test, or to be reused for a different user role, the split earns its keep.

What survives: the passive view plus presenter hook split, when the split is worth it. What doesn't: calling it MVP. Most React Native engineers will read it as "container plus presentational component," which is the name React used for the same idea before hooks blurred the line.

MVVM: the closest fit, and the most misunderstood

MVVM:

Model as before
View binds to a ViewModel
ViewModel exposes observable state and commands. It doesn't know about the View.

The defining feature is the binding. In WPF, <TextBox Text="{Binding Name}" /> keeps both sides in sync. The ViewModel never imports the View. The View never asks the ViewModel for data; it observes.

React Native has no two-way binding. But the spirit of MVVM, a ViewModel that exposes state and commands and doesn't know who's watching, maps surprisingly well onto two things React Native already has.

Hooks as ViewModels. A custom hook that owns state and exposes commands is a ViewModel. The "binding" is React's render cycle: when state changes, the component re-renders. Same outcome as MVVM, achieved with a different mechanism.

Stores as ViewModels. Zustand, Jotai, MobX. A store that holds state and exposes commands is a textbook ViewModel. The component subscribes via a selector. The store has no idea what's rendering.

const useItemsVM = create<{
  status: 'idle' | 'loading' | 'ready' | 'error'
  items: Item[]
  error: Error | null
  load: () => Promise<void>
}>((set) => ({
  status: 'idle',
  items: [],
  error: null,
  load: async () => {
    set({ status: 'loading' })
    try {
      const items = await getItems.execute()
      set({ status: 'ready', items })
    } catch (error) {
      set({ status: 'error', error: error as Error })
    }
  },
}))

function ItemsScreen() {
  const status = useItemsVM(s => s.status)
  const items = useItemsVM(s => s.items)
  const load = useItemsVM(s => s.load)

  useEffect(() => { load() }, [load])

  if (status === 'loading') return <Spinner />
  if (status === 'error') return <ErrorState onRetry={load} />
  return <FlatList data={items} renderItem={...} />
}

Two properties of MVVM hold here:

The ViewModel doesn't import the View. It can be tested by calling useItemsVM.getState().load() in plain Node, no render tree required.
The View only reads from the ViewModel; it doesn't reach into the Model directly.

What you give up versus classical MVVM: the binding is unidirectional, and there's no INotifyPropertyChanged ceremony. You don't miss it.

The misunderstood part: most "MVVM in React" articles treat hooks as a flawed approximation. They aren't. They're the same idea with the binding mechanism replaced. If anything, they're cleaner. There's no hidden observer registration, just a render that re-runs when state changes.

What survives: most of MVVM's intent. ViewModel-as-hook or ViewModel-as-store is a plausible default for any non-trivial screen. What doesn't: data binding. You wire it manually with value and onChange, and you stop missing it after a week.

What actually survives

Strip the labels. The shared idea behind MVC, MVP, and MVVM is one sentence: keep render separate from logic. They differ on how, on who owns what, on what the framework does for you. They agree that a screen file with API calls, validation, navigation, and rendering is going to hurt.

Three things survive the trip to React Native:

The Model is real. Use cases, repositories, domain types. Lives in its own folder. No imports from the framework. (See clean-architecture-react-native for how to draw that line.)
The View should be small enough to render in a Storybook story. If you can't render a component with arbitrary props because it does its own fetching, you've fused the View and ViewModel without meaning to.
Logic lives in a hook or a store, not in the component. Whether you call it a presenter, a view model, or just useItems, the rule is the same: the component's body should mostly be branches on state and event handlers that delegate.

The patterns are different names for the same advice, dressed for the framework that birthed them.

When the labels actually help

Two honest cases:

Onboarding. If you join a team that says "we use MVVM," you need to know which part of MVVM they kept and which part they redefined. The label is a starting point, not the answer. The right next questions are "where does the logic live" and "what is the View allowed to know."

Cross-platform conversations. If you're talking to a UIKit engineer who writes MVC, an Android engineer used to MVP, or a WPF engineer with two decades of MVVM, the labels are the bridge. Telling them "we use hooks" describes the mechanism, not the architecture. Telling them "the screen is the View, the hook is the ViewModel, the use case is the Model" lets them ask the right follow-ups.

The bad case for labels is cargo-culting. A folder structure with views/, viewmodels/, and models/ doesn't make a codebase MVVM if half the screens still call fetch directly. Folders are documentation. Lint rules and review are enforcement.

The bill at month twelve

The patterns are old. The advice underneath them isn't. React Native doesn't get to skip the question of where logic lives just because hooks make it cheap to put it everywhere. The screen file that does its own fetching, validation, and animation will still be the one you debug at midnight, regardless of which acronym you put on the wall.

Pick a place for logic that isn't the component. Make the component small enough to render with props. Test the logic without rendering. The label matters less than whether the next engineer can find the bug.

Shipping React Native Updates Without the App Store: A Practical Guide to OTA and React Native Stallion

Amanda Gama — Tue, 12 May 2026 02:47:45 +0000

You know the feeling. There's a typo in production copy. A misconfigured feature flag. A small logic bug that snuck past QA somehow. None of it touches native code. It's pure JavaScript, the kind of fix you could push in five minutes if the universe were fair. But the universe isn't fair, and so you wait. You wait for Apple. You wait for the Play Store staged rollout. Hours go by. Sometimes days. All for a one-line change.

This is the gap OTA updates were built to fill. In this article I want to walk through what OTA actually means in React Native land, why everything changed in 2024, and how to get up and running with React Native Stallion, which is probably the most interesting CodePush replacement to come out of that whole mess.

What OTA Updates Actually Are (and Aren't)

A React Native app is really two things in a trench coat. There's the native shell, which is your APK or IPA with all its Java, Kotlin, Objective-C and Swift. And then there's the JavaScript bundle, which is just a file that the shell loads when the app starts. The app stores care about the shell. The bundle is, from their perspective, content.

OTA exploits that gap. Instead of resubmitting the whole app, you swap the JavaScript bundle on the device. Next launch (or whenever you decide), your users are running new code.

What you can ship over the air:

UI changes, copy fixes, styling tweaks
New features written entirely in JavaScript
Business logic updates, API integration changes
Bug fixes that don't touch native modules

What you can't:

Updates to native modules. Added a new library with native code? Time to rebuild.
Permission changes. Camera, location, notifications, all of that.
App icons, splash screens, native configuration
Anything below the JavaScript layer

Both Apple and Google allow JavaScript-only OTA. They've been pretty consistent about it. What they don't allow is using OTA to fundamentally change what your app does after the fact. Hot-fixing bugs is fine. Quietly turning your meditation app into a casino is not.

Why the Whole Landscape Shifted

For years the answer to "how do we do OTA on React Native" was basically: CodePush, paired with App Center, both from Microsoft. It was free, it was well-documented, it worked. Most teams just used it and got on with their lives.

Then in 2024 Microsoft announced they were retiring App Center, with the full shutdown landing in 2025. CodePush as a hosted service went with it.

That left a lot of teams suddenly squinting at their production apps wondering what now. The replacements that emerged:

Expo EAS Update is polished and well-maintained, but tightly coupled to the Expo ecosystem. If you're already there, great. If you're on bare React Native, there's friction.

Self-hosted CodePush is technically possible since the server code is open source. The catch is you're now running infrastructure, scaling it, securing it, and on call for it.

React Native Stallion is newer, fully managed, and was built specifically to fill the CodePush void. It also makes some interesting technical bets (differential patches, bundle signing) that the older tools don't.

The rest of this article focuses on Stallion, because it's what I keep seeing teams reach for when they're migrating off CodePush and don't want to fully commit to the Expo workflow.

What Stallion Actually Gives You

A few things stand out.

Patch updates. Traditional OTA ships the entire JavaScript bundle every time. Your bundle is 20 MB, you fix a one-line bug, every user on the planet downloads 20 MB. Stallion computes a file-level diff and ships only the changed bytes. Their docs claim up to 98% size reduction depending on the change, and from what I've seen that's roughly right. On slow connections this is the difference between an update finishing in seconds and an update never finishing at all.

Bucket-based testing and promotion. Bundles get uploaded to buckets and promoted to production from the dashboard. You can also push a build to internal testers without going through TestFlight or the Play Console, which is honestly the part QA teams get most excited about.

Automatic and manual rollback. Misbehaving release? You can pause it (stops new downloads) or roll it back (reverts existing devices on next launch). Crash-on-startup automatic rollback is also baked in, which I'll get to.

Bundle signing. Every bundle is cryptographically signed, with optional customer-managed keys. This matters more than people realize. An unsigned OTA pipeline is basically a supply chain attack waiting to happen.

Open source SDK and CLI. MIT licensed. The console is hosted.

Setting It Up

Stallion has three pieces. The CLI uploads bundles. The SDK on the device downloads and applies them. The console is where you manage releases. You'll need React Native 0.69 or higher.

1. Install the SDK and CLI

# in your React Native project
npm i react-native-stallion

# globally or in your CI tooling
npm i -g stallion-cli

Then npx pod-install to link iOS.

2. Wire Up the Native Side

You're telling React Native to load its JavaScript bundle from Stallion's storage instead of the default location. On Android that means overriding getJSBundleFile. On iOS, bundleURL.

Android (React Native 0.76+, Kotlin):

import com.stallion.Stallion

override val reactNativeHost: ReactNativeHost =
  object : DefaultReactNativeHost(this) {
    override fun getJSBundleFile(): String? {
      return Stallion.getJSBundleFile(applicationContext)
    }
  }

iOS (React Native 0.76+, Swift):

import react_native_stallion

override func bundleURL() -> URL? {
  #if DEBUG
    return RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
  #else
    return StallionModule.getBundleURL()
  #endif
}

The #if DEBUG matters. In development you want Metro serving fresh bundles, not Stallion. OTA only kicks in for release builds.

3. Add Your Project ID and App Token

Generate both from the Stallion console under Project Settings > Access Tokens, then drop them into your native config.

iOS, in Info.plist:

<key>StallionProjectId</key>
<string>your_project_id</string>
<key>StallionAppToken</key>
<string>spb_your_app_token_here</string>

Android, in res/values/strings.xml:

<string name="StallionProjectId">your_project_id</string>
<string name="StallionAppToken">spb_your_app_token_here</string>

4. Wrap Your Root Component

import { withStallion } from 'react-native-stallion';

const App = () => {
  // your app
};

export default withStallion(App);

That's the whole setup. A new release build of your app will now check Stallion for updates on launch and when it returns to the foreground.

Publishing and Promoting an Update

The actual workflow is pretty boring once you've done it once, which is what you want.

Make your code change.
Build the JavaScript bundle and upload it to Stallion via the CLI.
In the console, pick the bundle and click "Promote Bundle." You specify the target app version, write release notes, and optionally set a rollout percentage.
Next time a user's app comes to the foreground, it checks for updates and pulls the new bundle in the background.

The rollout percentage is the part worth lingering on. By default new releases start at 0%, meaning only users explicitly logged into the SDK (typically your team) get the update. You then dial it up. 5%, 25%, 50%, 100%, watching adoption and crash metrics as you go. It's the same phased rollout pattern you'd use on the Play Store, except you're holding the dial directly instead of submitting paperwork to Google.

Custom Update UX

By default Stallion downloads silently in the background and the new bundle takes effect on the next cold start. For most apps that's the right behavior. Sometimes though you want to prompt the user, especially for important fixes. "Hey, there's an update ready, want to restart now?"

The SDK exposes a hook for exactly this:

import { useStallionUpdate, restart } from 'react-native-stallion';

const UpdateBanner = () => {
  const { isRestartRequired } = useStallionUpdate();

  if (!isRestartRequired) return null;

  return (
    <View style={styles.banner}>
      <Text>A new update is ready.</Text>
      <Button title="Restart" onPress={restart} />
    </View>
  );
};

useStallionUpdate also gives you metadata about the new bundle, including release notes and version info, so you can surface something meaningful rather than a generic "update available" toast.

When Things Go Wrong

This is the part most teams underestimate when they're picking an OTA platform. You will, eventually, ship a broken bundle to production. The question is how fast you can recover.

Stallion gives you two levers from the dashboard.

Pause stops the release from downloading to any new device. Devices that already have it stay on it. Useful when you've spotted a problem but it's not severe enough to roll back.

Rollback pauses the release and tells devices that already pulled it to revert to the previous stable bundle on next launch. This is the nuclear option, and it's the one you want when something is really wrong.

There's also automatic rollback for the worst case: if a new bundle causes the app to crash before it can mark itself as healthy, the SDK reverts on next launch. This is the safety net that lets you sleep through a 3 AM bad deploy. (Not that you should, but you can.)

Some Honest Tradeoffs

OTA is a force multiplier, but it's not free. A few things worth chewing on before you commit.

You're adding a runtime dependency on a vendor. Stallion is well-maintained and the SDK is open source, but your update pipeline now depends on their availability. Worth understanding their SLA story before you wire critical workflows around it.

Native code changes still go through the app store. OTA doesn't reduce that cadence. It just lets you patch JavaScript faster between native releases.

Testing discipline matters more, not less. Faster shipping is also faster shipping of bugs. The teams that get the most out of OTA are the ones with solid CI, automated tests, and the discipline to actually use phased rollouts. Without that you've just built a faster way to break production.

App Store review policies still apply. Don't use OTA to dodge review. Apple has been clear that meaningful changes to app functionality need to go through the normal process.

Wrapping Up

If you're running React Native in production in 2026, OTA isn't really optional anymore. Your competitors have it. Your users expect bug fixes in days, not weeks. The "wait for the next release cycle" argument basically never wins against "patch it tonight."

CodePush is gone. The choices are Expo, build your own, or pick up something like Stallion. For teams on bare React Native who want CodePush-style ergonomics with some modern conveniences (patch updates, signed bundles, dashboard rollouts), Stallion is a reasonable default to evaluate.

Setup is an afternoon. Using it well takes longer, but that's true of any deployment pipeline. Start with internal beta. Ramp through phased rollouts. Watch your crash metrics. Keep the rollback button close.

State management in React: when Redux, Zustand, and Context API actually fit

Amanda Gama — Sun, 10 May 2026 04:27:04 +0000

Every React project hits the same fork around month two. Prop drilling gets old. Someone says "we need state management." The next two days are an opinion war. Redux because it's what we know. Zustand because someone read a blog post. Context because "isn't that built in?"

The mistake isn't picking the wrong tool. It's not noticing that the three you're choosing between solve different problems.

What each one actually is

Quick mental models. Most of the confusion lives there.

Context API is a transport mechanism, not a state library. It lets a value cross the tree without prop drilling. That's it. The "state" that lives in a context is whatever you put in a useState near the provider. When that value's identity changes, every consumer re-renders. No selector layer, no batching, no devtools. It's a wire, not a store.

Redux is a single store with predictable, traceable updates. One reducer, one source of truth, every change goes through the same pipeline so you can replay it. Time travel debugging falls out of the design.

The Redux you remember is probably not the Redux anyone writes today. The action types, the action creators, the reducer switch statements, the connect HOC, the mapStateToProps, the boilerplate that made Redux a punchline: that's old Redux. Redux Toolkit (RTK) is what you'd actually write now. The trauma is real, the boilerplate isn't, and that gap does a lot of unfair work in most "Redux vs X" comparisons.

Zustand is a hook around a store. No provider, no reducer, no actions. You define a store, you read from it with a selector, you call methods on it to update. Closer to "useState that lives outside the component" than to a Flux-style architecture.

The same trivial example in all three, just to feel the gap:

// Context API
const UserContext = createContext<{
  user: User | null
  setUser: (u: User | null) => void
} | null>(null)

function UserProvider({ children }: { children: ReactNode }) {
  const [user, setUser] = useState<User | null>(null)
  return (
    <UserContext.Provider value={{ user, setUser }}>
      {children}
    </UserContext.Provider>
  )
}

const ctx = useContext(UserContext)!
ctx.setUser(next)

// Redux Toolkit
const userSlice = createSlice({
  name: 'user',
  initialState: null as User | null,
  reducers: {
    setUser: (_, action: PayloadAction<User | null>) => action.payload,
  },
})

const store = configureStore({ reducer: { user: userSlice.reducer } })

const user = useSelector((s: RootState) => s.user)
const dispatch = useDispatch()
dispatch(userSlice.actions.setUser(next))

// Zustand
const useUserStore = create<{
  user: User | null
  setUser: (u: User | null) => void
}>((set) => ({
  user: null,
  setUser: (user) => set({ user }),
}))

const user = useUserStore((s) => s.user)
const setUser = useUserStore((s) => s.setUser)

Not a fair fight on its own (Redux earns its weight elsewhere, we'll get there). At the trivial end, though, the boilerplate gap is real.

One honest aside before going further

Before going further: a big chunk of the state you think is client state is actually server state. The user's profile from the API. The list of orders. The dashboard data. None of that is "state your app owns." It's a cache of something the server owns.

TanStack Query (or SWR, or Apollo) handles server state better than any of these three. Caching, revalidation, request deduping, stale-while-revalidate, background refresh, retry: they exist as features there, not in Redux or Zustand. If you're reaching for a state library to hold an array you just fetched, you're reaching for the wrong thing.

The rest of this post is about state your client actually owns: UI state, ephemeral state that spans the app, form draft state, things only your app cares about.

When Context API wins

Values that rarely change but need to cross the tree.

Theme. Locale. Current user (if you're not using a server state library to fetch them). Feature flags. Whether the app is online. The kind of data set once at app start and rarely changes after.

type Theme = 'light' | 'dark'

const ThemeContext = createContext<{
  theme: Theme
  setTheme: (t: Theme) => void
} | null>(null)

function ThemeProvider({ children }: { children: ReactNode }) {
  const [theme, setTheme] = useState<Theme>('light')
  const value = useMemo(() => ({ theme, setTheme }), [theme])
  return <ThemeContext.Provider value={value}>{children}</ThemeContext.Provider>
}

Why Context works here:

It's already in React. No bundle cost, no library decision.
The value rarely changes, so re-rendering every consumer doesn't bite.
You're modeling something that's genuinely local to a part of the tree, not global.

The trap is using Context for state that changes constantly. A form context that updates on every keystroke and re-renders the whole form tree is the bad case everyone hits. People feel the lag, blame React, and reach for memoization instead of recognizing that Context wasn't built for that.

Rough test: if the value updates more than a couple of times per minute, or has more than a few unrelated consumers, Context is going to cost you. Reach for a store.

When Zustand wins

Most apps that aren't huge.

Zustand fits the case where you want a store without the architecture lecture. No provider. No reducer split. Async lives in regular functions on the store, not in middleware. TypeScript inference works without four lines of generic incantations. Selectors mean components only re-render when the slice they care about changes.

type CartState = {
  items: CartItem[]
  addItem: (item: CartItem) => void
  removeItem: (id: string) => void
  checkout: () => Promise<void>
}

const useCartStore = create<CartState>((set, get) => ({
  items: [],
  addItem: (item) => set((s) => ({ items: [...s.items, item] })),
  removeItem: (id) => set((s) => ({ items: s.items.filter((i) => i.id !== id) })),
  checkout: async () => {
    await api.post('/checkout', { items: get().items })
    set({ items: [] })
  },
}))

function CartCount() {
  const count = useCartStore((s) => s.items.length)
  return <span>{count}</span>
}

CartCount re-renders when the count changes. Updating a quantity on an existing item without changing length doesn't re-render it. That selector behavior does real work.

Async is the part where Zustand quietly wins. No debate over thunks versus sagas, no extra dependency. The store action is an async function. It awaits, it sets, it's done. That's the whole pattern.

The catch: Zustand stays small and ergonomic by not giving you much structure. At very large team sizes, with many engineers touching the same store, you start writing your own conventions for splitting stores, organizing actions, handling communication between stores. By the time you've done that for a while, you've reinvented a worse Redux. That's not a reason to skip Zustand. It's a reason to notice the moment when the lack of structure stops being a feature.

When Redux (RTK) wins

Larger teams, larger surface area, complex async, and the case where DevTools earn their keep.

The honest sell for Redux today is the ecosystem. Redux DevTools is still the best experience for debugging state in any framework. Time-travel works. Action history is a real thing you can scroll back through. RTK Query, if you go with it instead of TanStack Query, is genuinely solid for server state and integrates with the rest of the store. Listener middleware (the new alternative to sagas) covers most of the cases that used to need extra libraries for side effects.

type Status = 'idle' | 'loading' | 'error'

const cartSlice = createSlice({
  name: 'cart',
  initialState: { items: [] as CartItem[], status: 'idle' as Status },
  reducers: {
    itemAdded: (state, action: PayloadAction<CartItem>) => {
      state.items.push(action.payload)
    },
    itemRemoved: (state, action: PayloadAction<string>) => {
      state.items = state.items.filter((i) => i.id !== action.payload)
    },
  },
  extraReducers: (builder) => {
    builder
      .addCase(checkout.pending, (s) => { s.status = 'loading' })
      .addCase(checkout.fulfilled, (s) => { s.status = 'idle'; s.items = [] })
      .addCase(checkout.rejected, (s) => { s.status = 'error' })
  },
})

const checkout = createAsyncThunk('cart/checkout', async (_, { getState }) => {
  const items = (getState() as RootState).cart.items
  await api.post('/checkout', { items })
})

Noticeably more file than the Zustand version. Some of the noise is genuine: explicit action types are what make time travel possible, and extraReducers is what lets you express loading, success, and error in one place. Some of it is just RTK being thorough about TypeScript.

When that overhead pays for itself:

More than a handful of engineers touch the same state. The structure stops being a tax and starts being a contract.
You depend on DevTools for debugging. During incident response, replaying a sequence of actions to reproduce a bug is a superpower.
You have complex middleware needs: throttling, debouncing, coordination between stores, optimistic updates with conflict resolution. The listener middleware story is good.
You've already committed to RTK Query for server state. Mixing it with Zustand isn't impossible, but now you're running two state systems.

When it doesn't: small to mid apps, solo dev or small team, no exotic patterns for side effects. RTK isn't bad there. It's just paying for capabilities you won't use.

The dimensions you feel later

The stuff that doesn't show up in a tutorial but matters in month six.

DevTools. Redux: best in class. Zustand: middleware that gives you the same Redux DevTools, basic but works. Context: nothing, you're back to console.log.

Async and side effects. Redux: thunks for simple, listener middleware for complex, RTK Query for server. Zustand: async functions in the store, that's it. Context: not its job, bring your own.

TypeScript. Zustand: clean inference, minimal ceremony. RTK: good but verbose, PayloadAction and RootState show up everywhere. Context: fine for static types, awkward when you want a non-null guarantee inside consumers.

Performance. Zustand and Redux both subscribe through selectors, so components only re-render when their slice changes. Context re-renders every consumer on every value change unless you split providers or memoize aggressively. For state that changes constantly, Context will be the bottleneck before any of the others.

Testing. Zustand stores are plain functions, you can call them in a test without a renderer. RTK reducers are pure, also easy to test. Context-based state usually means rendering a tree, which is heavier and slower.

What I reach for now

In practice, I default to two options: Zustand, or nothing.

For small apps, nothing usually means Context for the few values that need to cross the tree (auth, theme, locale) and useState everywhere else. That covers more apps than people think. The "you need state management" reflex kicks in earlier than the actual need does.

For anything bigger, Zustand. The boilerplate cost is low enough that I'll reach for it the moment a value needs to be touched from two unrelated parts of the tree. Selectors handle re-renders, async fits in the store, TypeScript stays out of the way. I don't reach for Redux on new projects, not because RTK is bad, but because I keep finding I don't need what it gives me.

I'd reach for Redux if I were joining a team that already uses it (don't fight that battle), or starting something where DevTools and a strict structure across a large team are the actual problem to solve. Those are real cases. They're just not most cases.

The decision isn't "which one is best." It's "which problem do I actually have." Context if you have prop drilling and not much else. Zustand if you have shared client state and want a store without ceremony. Redux if you have a team and a surface area large enough to make the structure pay rent.

Pick the smallest one that fits, and trade up only when you feel the seams.

Biometric login on React Native with Keychain

Amanda Gama — Thu, 07 May 2026 02:57:37 +0000

Adding Face ID and Touch ID to a React Native app sounds like a single API call. It isn't. There are three pieces you have to wire together: Keychain for storage, the biometric prompt for the user gate, and your auth code for what to do with the result. react-native-keychain handles the first two well. This post is about wiring all three.

I'll walk through the mental model, a storage pattern that's served me well, the configuration flags that matter, and how to deal with the prompt errors you'll see in production.

The mental model

Biometrics on mobile aren't a separate API. They're a gate on storage.

Keychain (iOS) and Keystore (Android) are key/value stores. The values live in hardware-backed secure storage on each platform. react-native-keychain exposes them with setGenericPassword and getGenericPassword. That's it.

The "biometric login" part is configuration on those two calls. When you write a value, you mark it as biometric-protected. When you read it, the OS prompts the user before handing it back. There's no separate "log in with Face ID" function. You ask Keychain for a value, and the OS decides whether to give it to you.

That's worth sitting with for a second, because it shapes everything else. The biometric prompt is a side effect of trying to read a piece of data. Once you treat it that way, the rest of the design gets a lot simpler.

The two services pattern

You'll end up with at least two namespaces, called "services" in the API. One holds your access token. The other holds a biometric-gated value that exists only to verify the user is present.

The access token namespace is unlocked. Your app reads it on every API call to attach to the Authorization header. You really don't want a Face ID prompt every time you fetch a list.

import * as Keychain from 'react-native-keychain'

await Keychain.setGenericPassword('access', accessToken, {
  service: 'access-token',
})

The biometric-gated namespace stores something the user proves they have access to. The exact value matters less than the act of retrieving it. A random per-device string works fine.

await Keychain.setGenericPassword('biometric-pass', randomValue, {
  service: 'biometric-gate',
  accessControl: Keychain.ACCESS_CONTROL.BIOMETRY_CURRENT_SET,
  accessible: Keychain.ACCESSIBLE.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
  authenticationPrompt: { title: 'Sign in to YourApp' },
})

The flow is: read the gated value (which prompts), and on success, go ahead and use the access token. The gated value isn't the token itself. It's the proof that the current user can use the token.

The reason to keep these separate is background work. A push-notification handler that fetches data needs the access token, but it shouldn't pop a Face ID prompt when there's no UI on screen. Token in an unlocked service, biometrics on a separate service. Background reads stay quiet.

The access control flags that actually matter

Three options on setGenericPassword decide everything.

accessControl is what makes a value biometric. The two values you'll use most are BIOMETRY_CURRENT_SET on iOS and BIOMETRY_ANY on Android. They aren't quite symmetric. BIOMETRY_CURRENT_SET invalidates the value if the user adds or removes a fingerprint or face. Tighter security, more re-enrollments. BIOMETRY_ANY doesn't invalidate on enrollment changes. More convenient, less strict.

iOS gives you stricter invalidation by default. Android gives you a wider gate. BIOMETRY_CURRENT_SET on iOS is a reasonable default unless you have a reason to relax it.

accessible controls when the value is readable. A safe default is WHEN_UNLOCKED_THIS_DEVICE_ONLY. The value is readable only when the device is unlocked, and it doesn't sync via iCloud Keychain to other devices. If the user gets a new phone, they re-enroll. That's the right behavior. You don't want auth state hopping between devices on its own.

authenticationPrompt is the title shown in the OS prompt. Keep it short. The user already knows the prompt is for your app, so you don't need to repeat the app name in the title.

A note on Android string length

One Android quirk worth knowing about. The cipher used for biometric-protected values has a maximum block size, and you can hit IllegalBlockSize if the stored value is long or has characters that expand under the underlying encoding.

In practice, keeping the biometric-gated value to 30 alphanumeric characters or fewer avoids the issue:

import { Platform } from 'react-native'

const formatForKeychain = (value: string) => {
  if (Platform.OS === 'android') {
    return value.substring(0, 30).replace(/[^a-zA-Z0-9]/g, '')
  }
  return value
}

This only matters for the biometric-gated value, where the goal is presence verification, not preserving the original data. Your access token in the unlocked service can be any length.

Reading it back: the prompt and its error modes

getGenericPassword either returns the credentials or throws. The throw is where most of the work lives.

The errors come back as messages on the JS side. iOS messages are localized, so matching on the English string fails for users in other languages. The trick is to match on stable parts. Numeric error code on Android. Symbolic error name on iOS. English message as a fallback for older OS versions.

Three cases are worth telling apart:

User canceled. They tapped "Cancel" or the back button. Close the prompt quietly. No error UI, no logging as an error.

Biometric mismatch. The user's face or fingerprint wasn't recognized. Show "try again" or fall back to password. Soft failure.

Anything else. Hardware unavailable, biometric not enrolled on the device, an unexpected library state. These are the ones worth logging.

Helpers I've used:

function isBiometricUserCanceled(error: Error): boolean {
  const msg = error.message
  return (
    /code:\s*1[03][,\s]/i.test(msg) ||
    /laerrorusercanceled/i.test(msg) ||
    /user canceled the operation/i.test(msg)
  )
}

function isBiometricMismatch(error: Error): boolean {
  const msg = error.message
  return (
    /code:\s*7[,\s]/i.test(msg) ||
    /the user name or passphrase you entered is not correct/i.test(msg)
  )
}

The Android codes come from BiometricPrompt:

7 is ERROR_BIOMETRIC_AUTHENTICATION_FAILED (didn't recognize)
10 is ERROR_USER_CANCELED
13 is ERROR_NEGATIVE_BUTTON (the user tapped your "cancel" button)

The iOS names come from LAError. LAErrorUserCanceled is locale-independent because it's the symbol name. The English fallback in the regex catches older iOS versions where the symbol doesn't appear in the bridged error.

Match on codes first, message second, and treat anything unmatched as the "real error" bucket. That keeps your crash reporter useful. Cancels and mismatches are user actions; only the unexpected stuff needs your attention.

A few practical recommendations

A few opinions, learned the slow way.

Use the biometric-protected value only as a presence proof. Background flows need your access token without a prompt. Token in an unlocked service, biometrics on a separate service. That's what makes background work, well, work.

Keep the stored value opaque. Don't try to pack metadata into the Keychain key or value. If you need metadata about the user or session, put it in AsyncStorage keyed off the service name. Keychain values are awkward to migrate. AsyncStorage isn't.

Log biometric errors with structured tags. Operation, OS, error class. The first time biometric login breaks for a real user, you want to know which class. The second time, you want to know if it's the same class.

Test on real hardware before shipping. iOS Simulator's "Match Touch ID" menu is fine for happy paths. It doesn't reproduce the cancel and mismatch error shapes you'll see on real devices.

Closing

The pieces are simple once you separate them. Keychain is a key/value store with hardware backing. Biometrics are a gate on retrieval. Two services keep background reads from popping prompts. Pick accessControl and accessible based on how strict you want invalidation and how portable you want the value to be. Match errors on codes, not localized messages. Test on real devices.

Done right, "log in with Face ID" is a one-tap experience that keeps working when the user changes their fingerprint, switches devices, or hits a flaky network during a refresh. Most of the work isn't in the library. It's in the small decisions around it.

Spec-Driven Development: Slowing Down to Ship Faster

Amanda Gama — Wed, 06 May 2026 00:53:04 +0000

For a while, AI coding tools made me feel productive in a way that worried me. I'd describe a feature, get 200 lines of code in 30 seconds, skim it, ship it. A week later I'd be back fixing the edge cases I never thought about, because the model didn't either.

That's the gap Spec-Driven Development (SDD) fills.

What it actually is

Write the spec first. Code second. The spec defines goals, constraints, edge cases, and acceptance criteria, and it becomes the source of truth that AI agents (and humans) implement against.

A practical spec isn't a Word doc with three layers of headings. It's closer to a contract:

# Feature: Payments CRUD
## Goal
Allow internal users to create, view, update, and refund customer payments.
## Functional requirements
- Create payment with amount, currency, customer ID, and method
- List payments with pagination and filters (status, date range)
- Update payment metadata (description, tags)
- Issue full or partial refunds
## Non-goals
- Recurring billing (v1)
- Multi-currency conversion at checkout (v1)
## Edge cases
- Refund exceeds original amount
- Update on a payment already refunded
- Concurrent refund requests on the same payment
## Acceptance criteria
- All endpoints return 4xx on invalid input with a structured error
- Refunded payments are immutable except for metadata
- Audit log records actor and timestamp on every write

Short, structured, testable.

Why it's having a moment

SDD isn't new. BDD, formal methods, and design-first APIs all share its DNA. What changed is that AI can now execute against a spec at production speed. The bottleneck stopped being how fast we type and started being how clearly we describe what we want.

Without a spec, vibe-coding with an AI agent produces fast, confident, subtly wrong code. With one, the same agent has guardrails it can be measured against.

The benefits I've actually felt

Less rework. Most of my "the AI broke it" moments were really "I didn't tell it about the edge case" moments. Writing the spec surfaces those before any code exists.

Better PR reviews. Reviewers get the why alongside the what. Conversations move from "is this how you wanted it?" to "does this match the spec?"

Living documentation, for free. The spec lives in the repo, version-controlled, and it's the same artifact onboarding devs read on day one.

Better tests. Acceptance criteria translate directly into test cases. Coverage becomes a question of "did we cover the spec?" instead of "did we hit 80%?"

Cheaper AI calls. Counterintuitive but real. A tight spec means fewer correction loops, which means fewer tokens burned reprompting until something works.

The honest caveats

SDD isn't waterfall in a trench coat, but it can become that if you over-formalize. Specs that try to enumerate every case grind iteration to a halt. The goal is enough spec to remove ambiguity, not a 40-page design doc nobody reads.

It's also harder in brownfield codebases. Reverse-engineering specs from legacy behavior is its own discipline, and worth treating as a separate project.

Where to start

Pick one upcoming feature. Before opening your editor, write the spec: goal, requirements, non-goals, edge cases, and acceptance criteria. Hand it to your AI agent of choice. Compare the output to what you would have vibe-coded.

The win isn't writing more docs. It's thinking before you ship.

A Live Activity isn't a notification

Amanda Gama — Tue, 05 May 2026 01:59:54 +0000

You're in another app and there's a timer counting down at the top of your phone. You lock the screen and the same timer is sitting there. You swipe down to the Notification Center and it's there too, still ticking. It looks like a notification, but a notification can't tick.

That's a Live Activity. It looks like three different surfaces (Dynamic Island, lock-screen banner, Notification Center entry), but they're the same widget, rendered three ways by the OS. I wired one up for Tomoe, a focus timer I built. The punch line: it took a weekend. Most of that weekend was unlearning what I thought a Live Activity was. Once the shape clicked, the code was small.

This post is the shape.

What a Live Activity actually is

Three things that get glossed over in most tutorials:

It's a widget, not a notification. The view code lives in a Widget Extension target, separate from your app. The app pushes state; the extension renders pixels. If you've shipped a Home Screen widget before, this is the same story.

It's driven by a typed ContentState. You declare a Codable struct of "things that change" and call .update() with a new instance. There's no general "set arbitrary text" API. The schema is the contract.

The OS renders the timer. If you reach for Timer or a 1-second TimelineView, you're already off the path. SwiftUI's Text(timerInterval:countsDown:) lets the OS rasterise the countdown for you. Your widget doesn't wake every second. It can't; the budget would never allow it.

Two pieces of plumbing before any of this works. Declare NSSupportsLiveActivities in the app's Info.plist:

<key>NSSupportsLiveActivities</key>
<true/>

…and target iOS 16.2 or later. The 16.0 / 16.1 ActivityKit surface churned, and the workarounds aren't worth it.

The data model

Every Live Activity is keyed by an ActivityAttributes type. You split it into "stuff that's fixed for the life of the activity" (the attributes themselves) and "stuff that changes" (the nested ContentState).

Tomoe's looks like this:

public struct TomoeActivityAttributes: ActivityAttributes {
    public struct ContentState: Codable, Hashable {
        public var endDate: Date
        public var isPaused: Bool
        public var pausedRemainingSeconds: Int
    }

    public var task: String
}

The task name doesn't change once a session starts, so it's an attribute. The end timestamp, pause flag, and the snapshot for rendering paused state all change, so they're in ContentState. Codable + Hashable is how the OS serialises state across the app/widget process boundary.

The detail that costs everyone an afternoon: this file has to be a member of both targets, the app target and the widget extension target. Xcode won't warn you. The activity will start, and then the widget will silently fail to decode the state and render nothing. Check the file inspector before you debug anything else.

The four Dynamic Island slots

Here's where the mental model clicks. The DynamicIsland { … } builder gives you four slots, each for a different state of the same activity:

compactLeading and compactTrailing: the two tiny views you see hugging the camera cutout when only your activity is active.
minimal: what you're demoted to when another app also has an active Live Activity. You're now a circle next to a dot.
expanded: what the user sees when they long-press.

Plus the lock-screen / Notification Center view, which is the top-level body of the ActivityConfiguration. The same view code renders in both places. The OS just changes the chrome around it.

Trimmed to the load-bearing parts, Tomoe's whole widget is:

struct TomoeWidgetLiveActivity: Widget {
    var body: some WidgetConfiguration {
        ActivityConfiguration(for: TomoeActivityAttributes.self) { context in
            LockScreenView(context: context)
                .activityBackgroundTint(cream)
                .activitySystemActionForegroundColor(ink)
        } dynamicIsland: { context in
            DynamicIsland {
                DynamicIslandExpandedRegion(.leading) { /* mark + task name */ }
                DynamicIslandExpandedRegion(.trailing) {
                    TimerView(state: context.state, fontSize: 38, color: .white)
                }
                DynamicIslandExpandedRegion(.bottom) {
                    if context.state.isPaused { Text("paused") }
                }
            } compactLeading: {
                TomoeMark(size: 22)
            } compactTrailing: {
                TimerView(state: context.state, fontSize: 22, color: .white)
            } minimal: {
                TomoeMark(size: 20)
            }
            .keylineTint(accent)
        }
    }
}

Two things to keep in mind.

The compact regions are tiny. Tomoe's brand mark is 22pt; the trailing timer is 22pt at a minimum width of 56pt. Anything bigger overflows. Design for ~40pt of width and treat anything more as a bonus.

The minimal view appears without warning, the moment any other app starts an activity. Don't put information in compactLeading that needs to also be in minimal. Those are different layers, and you don't get a transition between them.

Let the OS tick

The single most useful API in this whole stack:

Text(timerInterval: Date()...state.endDate, countsDown: true)
    .monospacedDigit()

You give it a date range; you get back a Text that the OS counts down for you. It updates without your widget doing anything. This is what makes the timer feel native: no flicker, no off-by-one, no battery cost.

The catch: you can't pause it. The OS counts to the end of the range, period. So when the user pauses, Tomoe swaps to a static label:

if state.isPaused {
    Text(pausedTimeString(seconds: state.pausedRemainingSeconds))
} else {
    Text(timerInterval: Date()...state.endDate, countsDown: true)
}

On pause, I push an update with isPaused: true and a snapshot of the remaining seconds. The widget renders that snapshot until the next state change. On resume, I push a new endDate = now + remaining and we're back on the OS-driven interval.

pausedRemainingSeconds is the non-obvious part: I have to send the value the widget should display, because the widget process has no idea how long ago I paused.

Pushing updates from the app

The lifecycle is three calls. From Tomoe's bridge module, trimmed:

let activity = try Activity.request(
    attributes: attributes,
    content: .init(state: state, staleDate: nil),
    pushType: nil
)

// later, on pause/resume
await activity.update(.init(state: newState, staleDate: nil))

// done
await activity.end(nil, dismissalPolicy: .immediate)

pushType: nil means "I'll push state from this app process." That's right for a timer. The app already knows when the user paused or finished. The other option is .token, which lets you push from a server via APNs. Useful for Uber-style "your driver is here" updates that the app itself can't observe; overkill for anything the foreground app can drive.

The budget you should know about, so you don't design something that fights it:

An activity can live for about 8 hours before the OS forces it stale.
ContentState is capped at ~4 KB encoded.
Updates are rate-limited; push every 100ms and the OS quietly drops most of them.
A stale activity dims on the lock screen but doesn't disappear until you call .end() or the user dismisses it.

That last one matters more than it sounds: passing an endDate in the past does not auto-end the activity. The countdown will show 00:00 and just sit there. You have to call .end() yourself when the timer reaches zero. In Tomoe I do this from the JS layer when the timer fires, since the app is React Native. But the Swift Activity.request / .update / .end API is the same regardless of host. Flutter, RN, native, doesn't matter; the shape is identical.

Things that bit me

Shared types break easily. The ActivityAttributes file has to belong to both targets. Add → File Inspector → check both Target Memberships. If your activity starts but the widget renders empty, this is it. Every time.

Dynamic Island regions ignore overflow. SwiftUI happily lets you put a wide view in compactTrailing. The OS will clip it without a warning at build time. Use .minimumScaleFactor(0.6) and .lineLimit(1) defensively, especially on numeric content where the digit count varies.

Asset catalogs are flaky in widget extensions. I had a brand image that loaded fine in the simulator and failed silently on device. I switched to a SwiftUI-drawn mark (a coloured rectangle with an SF Symbol on top) and the problem went away. If a widget asset isn't appearing on a real iPhone, that's the first thing to try.

Closing

What surprised me about Live Activities is how little there is to them once you've named the parts. A typed ContentState, four Dynamic Island slots, one OS-driven timer view, three lifecycle calls. That's the whole API surface for a focus timer. Most of the hard work happens before you write code: deciding what to put in the compact view, what's worth a long-press to expand, what the paused state should feel like.

I built Tomoe to scratch my own itch for a focus timer that doesn't shout. Three calm scenes: rain, stars, fireflies. Four session lengths. No accounts, no tracking, no streaks to break. The timer follows you out of the app, into the Dynamic Island and onto the lock screen, exactly the way this post describes. Available on the App Store.

Becoming a tech lead, what I wish someone had told me

Amanda Gama — Mon, 04 May 2026 13:07:30 +0000

Becoming a tech lead was the goal from pretty early in my career. I had a clear picture of what the role was. More responsibility, more influence over the work, more of the interesting problems landing on my desk because someone had to figure them out and that someone, finally, would be me. It read like the natural next step. The thing you graduate to once you're good enough.

What that picture didn't include was the part of the job that's about leading people. Not management. I knew management was a separate track. I mean the quieter stuff. Sitting with someone else's frustration and not fixing it for them. Holding a position you're 60% sure of in a room of people who want a confident answer. Realizing the thing blocking the team isn't a technical problem, and that nothing in your background really prepared you for the actual one.

This is the post I wish someone had written for me when I was still aiming for the role. Not the ladder advice. The hard parts.

What changed in the day

The honest version of the shift isn't what you read in leadership posts. Yes, there are more meetings. Everyone says that. The meeting count is the easy part to see and the easy part to adapt to. The ones I took longer to notice were quieter.

The first one is your relationship to shipping. As an engineer, the day has a clean ledger. You opened a PR, you closed an issue, you merged a branch. Even on a slow day there's a diff that proves you were here. As a tech lead, half of your most important work doesn't show up that way. You sat in a meeting and changed the direction of a project. You unblocked someone in a thirty-minute conversation. You wrote a short doc that prevented two weeks of wasted work next month. None of that has a green checkmark next to it. The first few months I felt vaguely guilty at the end of every day, because I couldn't point to a thing I'd built. The fix wasn't to build more. It was to stop measuring my day in commits.

The second is the time horizon. Engineering work runs in days. A bug, a feature, a refactor: a thing you can hold in your head start to finish. The lead work runs in weeks and quarters. A hire decision today shapes the team six months out. A standard you set now shows up in code reviews a year from now. The horizon stretches and the feedback loops stretch with it. You stop knowing whether a call you made was a good one for a long time, and sometimes you never really know.

The third is that the day stops having a clean end. When you closed the laptop as an engineer, you were done. The remaining work was on a list, sitting still. As a lead, the open threads keep moving while you sleep. Someone hit something hard at 11pm. A project is drifting and you can feel it without anyone saying so. There's always a thing you could think about more. The skill is learning to put it down anyway.

The fourth is a new kind of fatigue. Coding is mentally taxing in a contained way. You're tired, you go for a walk, you come back. The fatigue from a day of decisions and context switches is different. It doesn't lift the same way. It's lower-grade and longer-tailed. Nobody warned me about it, and I spent the better part of a year thinking I was just under-sleeping.

What advice I stopped giving

There's a list of things I used to say to junior engineers with full conviction. Most of them I'd picked up from people I respected, and some I'd defended in arguments. Sitting in the lead chair quietly took a few of them apart.

I stopped telling people to always push back on bad requirements. The advice isn't wrong, exactly. It's too neat. The version I gave didn't account for what bad requirements actually look like in the wild: usually a partial picture from someone who's already negotiated three other constraints you can't see. The right move is rarely "push back." It's "ask what changes if X." Most of the time the requirement isn't bad. You just don't know what it's load-bearing for yet.

I stopped saying ship fast as a default. Speed matters. The trouble is that ship-fast gets treated as a virtue independent of context, which is how teams end up shipping things that take a year to undo. Some decisions deserve to be slow. Anything that's expensive to reverse (a data model, a hire, a public commitment, a foundational dependency) deserves the time. Speed on the reversible stuff, slowness on the rest. I should have been more careful about which one I was preaching.

I stopped telling people to always speak up in meetings. The advice was pitched at people who under-contribute, which is a real failure mode. But there's an opposite one I didn't account for: the person who fills every silence and pushes the team into worse decisions because nobody slowed them down. Sometimes the best thing you can do in a room is wait. Let the question sit. See what someone else says.

I stopped saying the right tech wins. It doesn't. Alignment wins. The team that picked the okay-but-aligned tool will out-ship the team that picked the better-but-contested one almost every time. The energy you spend defending a technical choice is energy you don't spend using it. I'd watched this happen to other teams and thought we were the exception. We weren't.

The pattern under all of those: the advice I used to give was advice for the version of the job I'd imagined. Sitting in the chair changed which trade-offs I could see.

The rituals that survived

Most of what I did to stay organized as an engineer didn't survive the role change. Tickets I lived in stopped being where my work happened. The PR queue stopped being a useful daily anchor. The deep-work blocks I'd guarded for years got eaten by a calendar I no longer fully controlled. I had to rebuild a lot of it.

What survived is small. Two habits, one rule.

The first habit is a written end-of-day. Five lines, plain text, takes three minutes. What I decided today. What I'm still unsure about. Who's blocked on me. Who I'm blocked on. One thing I want to start with tomorrow. I tried more elaborate systems and they all collapsed within a month. The five-line version has stuck because it's small enough that I actually do it on bad days, which are the days you most need it.

The second habit is reading code I didn't write, on purpose, every week. Not to review it. Just to read it. As a lead it's easy to drift away from the codebase, and a few weeks of that is enough that your suggestions in design reviews start feeling slightly off to the people doing the work. An hour a week of just reading what the team is shipping keeps the drift smaller. It doesn't make me an expert in everything. It makes me less wrong.

The rule is: don't bring up pattern-y problems without sitting with them for 24 hours first. Not the urgent ones. Those go straight up. I mean the "something feels off about how we're approaching X" ones. If I raise that in the moment, half the time I'm reacting to one bad meeting, not a real problem. If it still feels true the next day, it's worth bringing up, and I bring it up better. The 24-hour rule has saved me from a lot of needless team-level drama, almost all of it self-inflicted.

What I assumed would stick and didn't: the deep-work blocks. I tried to defend them and lost. Most days now my best heads-down hour is the one between waking up and the team coming online, not a block I scheduled. Recreating engineer rhythms in a lead's calendar was a year of frustration before I gave up.

Also gone: my old habit of replying to messages in batches. As an engineer it was a productivity move. As a lead, leaving four people waiting six hours each is its own kind of cost.

What I'd tell my earlier self

A short list of things I'd say to the version of me who was aiming for this role.

The job is mostly about people, even the technical parts. The technical parts that are still purely technical mostly aren't yours to do anymore. Make peace with that earlier than I did.

You don't need to have the answer. You need to make sure the team gets to one. Those are different jobs and they require different muscles. The first one is the one you spent a decade training. The second one is mostly new.

Confidence will be asked of you in moments when you don't have it. Faking it doesn't work, because people can tell. Saying "I'm not sure, here's how we'll find out" works almost every time, and the people you respect most are the ones who already do this.

Most of the advice you give right now is for the role you have, not the one you're aiming at. That's not a problem. Just know that some of it will quietly stop being true.

The role isn't a promotion in the way you imagine. It's a different job. You'll be a beginner again at parts of it, and the bits where you're a beginner will turn out to be the most important bits.

The hard parts are the job. Not a side effect of it. Not something to optimize away. If you want the role, the part you're nervous about is most of what you'd be doing.

Push notifications, the iceberg under one feature

Amanda Gama — Mon, 04 May 2026 02:29:09 +0000

It's a one-line item on the roadmap. "Send a push notification when X happens." Estimate is two days, three if the backend doesn't have FCM credentials yet. There's a library for it.

The library is the visible part. The other 90% is platform lifecycle, registration state machines, race conditions with navigation, payload archaeology, and a half-dozen iOS and Android quirks. Nobody writes them down. You learn them after you ship, when the bug reports start coming in.

I built this stack with custom native modules, wrapping APNs on iOS and FCM on Android directly, instead of reaching for Notifee, React Native Firebase, or OneSignal. The trade was the obvious one. I gave up the abstraction the libraries provide and got control over every edge case in return. The decision wasn't ideological. The failure modes I cared about were already filed against those libraries, unfixed.

This post is what's underneath. Not the library you import. The work the library is hiding from you, or trying to.

The waterline: registration is a state machine, not a function call

The tutorial version is one line:

const token = await messaging().getToken()
sendToBackend(token)

What's actually happening is a few rounds of back-and-forth between the OS, your app, and the push provider. At least three places it can quietly stop working.

On iOS, registration is split across delegate methods. The token comes back as NSData, not a string, and you hex-encode it before anyone outside the AppDelegate gets to see it:

- (void)application:(UIApplication *)application
didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {
  const unsigned char *bytes = deviceToken.bytes;
  NSMutableString *hex = [NSMutableString stringWithCapacity:(deviceToken.length * 2)];
  for (NSUInteger i = 0; i < deviceToken.length; ++i) {
    [hex appendFormat:@"%02x", bytes[i]];
  }
  [[NSNotificationCenter defaultCenter]
      postNotificationName:@"DeviceTokenRegistered"
                    object:nil
                  userInfo:@{ @"token": hex }];
}

That's the documented part. Three things aren't.

iOS 18+ silently drops the first registration call if you make it immediately after the user grants permission. No error, no callback, nothing. A 1.5 to 2 second delay and one retry recovers from it almost every time:

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2.0 * NSEC_PER_SEC)),
               dispatch_get_main_queue(), ^{
  if (![UIApplication.sharedApplication isRegisteredForRemoteNotifications]) {
    [UIApplication.sharedApplication registerForRemoteNotifications];
  }
});

This isn't in any Apple doc. I found it after enough TestFlight users on iOS 18 reported notifications "just not working."

Tokens change. APNs rotates them on app reinstall, restore-from-backup, or migration to a new device. FCM rotates on its own schedule. If you don't dedupe registrations, you re-register the same device on every cold start and your backend's device tables grow forever.

Token callbacks outlive their context. A token refresh that fired pre-logout can land post-logout, and re-bind the device to the previous user. The cheap fix: hold a lastRegisteredToken ref and short-circuit any callback whose token matches what you just sent.

That's three places one line of pseudocode is hiding.

Permissions are three different things

iOS, Android pre-13, Android 13+. Each one is a different model, and you handle all three in one codebase.

iOS is the cleanest. Request Alert | Sound | Badge once, the OS gives you a yes/no. There are extras most apps never use: provisional authorization (notifications go straight to the notification center), critical alerts (bypass Do Not Disturb), time-sensitive alerts on iOS 15+. The core flow is one async call. Catch: if the user denies, you can never re-prompt. They go to Settings or nothing.

Android pre-13 has no runtime permission for notifications at all. As long as the user installed your app, you can post. But on Android 8+ you have to create a notification channel first or the notification is silently dropped. The channel is also where importance, sound, and vibration live, not the notification itself:

fun ensureChannel(context: Context) {
  if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    val channel = NotificationChannel(
      CHANNEL_ID,
      "General",
      NotificationManager.IMPORTANCE_HIGH
    ).apply {
      description = "App notifications"
      enableVibration(true)
    }
    val manager = context.getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager
    manager.createNotificationChannel(channel)
  }
}

IMPORTANCE_HIGH is what enables heads-up banners. IMPORTANCE_DEFAULT puts the notification in the tray with no popup. The user can override your importance from settings, and you have no recourse.

Android 13+ added POST_NOTIFICATIONS as a runtime permission. You declare it in the manifest, request it at runtime, and check the SDK level before requesting because the API doesn't exist below 33. Like iOS, a denied permission has to be re-granted from system settings.

The branch you actually write:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
  if (ContextCompat.checkSelfPermission(context, POST_NOTIFICATIONS) != GRANTED) {
    ActivityCompat.requestPermissions(activity, arrayOf(POST_NOTIFICATIONS), 1)
  }
}
ensureChannel(context)

Three platforms, three permission models, one codebase. None of this is in the tutorial.

Three app states, three completely different code paths

This is the centerpiece of the iceberg. The same notification has to be handled three ways, depending on what the app is doing when it arrives.

State	iOS callback	Android callback	OS shows banner?	App can react before tap?
Foreground	`willPresentNotification:`	`onMessageReceived` (FCM service)	No (you choose)	Yes
Background	`didReceiveNotificationResponse:` (on tap)	`onMessageReceived` + tap intent	Yes	No
Quit / killed	`launchOptions[...RemoteNotificationKey]`	Intent extra in `MainActivity`	Yes	No

Each row hides something.

Foreground. iOS does not show a system banner when the app is open. You decide. The decision is one option mask returned from willPresentNotification::

- (void)userNotificationCenter:(UNUserNotificationCenter *)center
       willPresentNotification:(UNNotification *)notification
         withCompletionHandler:(void (^)(UNNotificationPresentationOptions))handler {
  NSDictionary *aps = notification.request.content.userInfo[@"aps"];
  BOOL silent = [aps[@"content-available"] intValue] == 1 && !aps[@"alert"];
  handler(silent
    ? UNNotificationPresentationOptionNone
    : UNNotificationPresentationOptionAlert
        | UNNotificationPresentationOptionSound
        | UNNotificationPresentationOptionBadge);
}

Skip this delegate method and foreground notifications vanish. You'll spend a week wondering why testing-on-device fails to reproduce what users are seeing.

Android has no equivalent. The FCM service runs on every notification regardless of state, so you detect foreground yourself:

val info = ActivityManager.RunningAppProcessInfo()
ActivityManager.getMyMemoryState(info)
val isForeground = info.importance == IMPORTANCE_FOREGROUND

Foreground: suppress the system notification, let JS render its own banner. Background: build the system notification and post it.

Background. The OS shows the banner. Your code runs only when the user taps. iOS hands you the payload via didReceiveNotificationResponse:. Android hands you the intent in MainActivity.onCreate or onNewIntent.

Quit. The app process is dead. The OS shows the banner. On tap, the app cold-starts, and your notification handler doesn't exist yet. JavaScript hasn't been loaded. The payload is delivered as a launch option (iOS) or an intent extra (Android), and you have to retrieve it after React mounts:

const initial = await Notifications.getInitialNotification()
if (initial) {
  setRedirectTarget(parseNotification(initial, { bootingApp: true }))
}

On Android, the cleanest move is to write the payload to SharedPreferences in the FCM service when the app isn't running, then read it back when JS comes online. Skip this and the launch intent gets consumed by the OS before your code is alive to see it.

The mistake I made first was writing one handler. They look like the same event from JS. They are not. The cold-start payload on iOS is shaped differently from the foreground one. The Android intent doesn't look like the FCM message your foreground handler receives. We'll get to that.

The race nobody warns you about

A user taps a notification. The app was killed. The OS hands you the payload before:

React has mounted
Your navigation container is ready
Auth state has hydrated from storage
The initial data fetch has resolved

Call navigation.navigate(...) here and three things can happen, all bad. You crash. You no-op silently and the user is stuck on the splash screen. Or you navigate, but auth is empty. The screen renders unauthenticated and bounces them to login. Confusing, since they came in through a notification that implied they were already signed in.

The fix is a "deferred redirect" pattern. Notifications never navigate directly. They write a target into context state. A separate effect watches both the target and a readyToRedirect flag, and only fires when every precondition holds:

const readyToRedirect = useMemo(
  () => isLoggedIn
     && !isFirstLogin
     && hasSeenOnboarding
     && !isHydrating,
  [isLoggedIn, isFirstLogin, hasSeenOnboarding, isHydrating]
)

useEffect(() => {
  if (readyToRedirect && redirectTarget) {
    navigationRef.current?.dispatch(
      CommonActions.reset({
        index: 1,
        routes: [{ name: 'Home' }, { name: 'Detail', params: redirectTarget }],
      })
    )
    setRedirectTarget(null)
  }
}, [readyToRedirect, redirectTarget])

The same pattern handles a more annoying case: the user is in the foreground, a notification comes in, they tap the in-app banner, but their session expired between the banner appearing and the tap. The redirect waits in state until auth re-hydrates, then fires. The tap doesn't get lost.

The corollary is about when you register listeners. Don't register on app startup. Register only when appStateVisible === 'active' && isLoggedIn. Otherwise the very first launch (fresh install, logged out, no auth state) fires a redirect to a screen the user can't open, and the navigator throws.

A "wait until ready" gate sounds trivial until you count how many things have to be ready. In production I count four: auth, navigation, hydrated storage, first paint. Miss any one and the bug only reproduces on cold starts triggered by notifications. Every notification.

The payload is not the payload

A notification on iOS arrives in three or four shapes depending on app state.

Foreground: top-level title, body, custom data on customData
Cold start (from launchOptions): aps.alert.title, aps.alert.body, custom data still on customData
Silent push: aps.content-available: 1, no alert, custom data only

Android adds another twist. FCM only allows string-string maps in the data field, so any structured custom data is JSON-stringified by the sender. You parse it on the JS side, in a try/catch, with a logged warning on failure. Skip the try/catch and a single malformed payload from the backend silently breaks your entire notification handler.

The only sane move is a normalizer. One parseNotification that returns a single shape, and the rest of the app only ever sees that shape:

type ParsedNotification = {
  type: 'redirect' | 'silent' | 'broadcast'
  title: string
  body: string
  targetId?: string
  url?: string
}

function parseNotification(raw: RawNotification, opts: ParseOpts): ParsedNotification {
  if (opts.platform === 'android') {
    const data = safeJSON(raw.customData) ?? {}
    return { type: data.type ?? 'broadcast', title: raw.title,
             body: raw.body, targetId: data.id, url: data.url }
  }
  if (opts.bootingApp) {
    return { type: raw.aps.customData?.type ?? 'broadcast',
             title: raw.aps.alert?.title ?? '',
             body: raw.aps.alert?.body ?? '',
             targetId: raw.aps.customData?.id }
  }
  return { type: raw.aps.customData?.type ?? 'broadcast',
           title: raw.title, body: raw.body,
           targetId: raw.aps.customData?.id }
}

Tests cover each variant: cold-start iOS, foreground iOS, Android with valid JSON, Android with malformed JSON. The malformed-JSON test is the one that catches the bug. Every time the backend ships a payload change without telling mobile, the test fails before it ships.

The bits you'll only learn by shipping

Things that aren't in any tutorial. I learned each of these from a bug report.

Notification Service Extensions have a 30-second budget. If you're modifying notifications in a Service Extension (decryption, downloading rich media, sending delivery receipts), the OS kills the extension and delivers the original payload if you overshoot. Set a 5-second timeout on any HTTP work the extension does. The user gets the notification either way, but you don't want a silently-truncated payload because the network was slow.

App icon badges are yours to manage. The OS doesn't decrement them when the user reads a notification. You set the count from the app, from the server, or both, and reset to zero when the relevant view mounts.

Delivery receipts are a fourth code path. If you want to know which notifications were actually delivered, you wire receipts in three places: the Service Extension fires "received" before the user sees the banner, the foreground/tap handler fires "read on tap," and silent push fires "received" again. None of these deduplicate. The backend has to.

Token refresh fires while you're logged out. FCM rotates on its own schedule. If your registration code doesn't check whether anyone's logged in, you'll re-bind the device to a stale or wrong user. Guard with a stored lastRegisteredFor and a "user is currently logged in" check.

Direct boot. If you want notifications to surface while the device is encrypted-and-locked (post-reboot, pre-unlock), your FCM service needs directBootAware="true" in the manifest, and you can only access protected storage. Most apps don't need this. The ones that do really need it.

Foreground listener leaks. Register on resume, unregister on background. Otherwise context updates fire after the relevant component unmounts, and you log a setState on unmounted component warning every time a notification arrives. The user sees nothing wrong. Your error logs fill up.

None of these are in the README. They become the README, after.

What I got back

What I have now is a push notification system that survives every state combination I've actually seen: cold start, mid-login, kill-and-relaunch, OS reboot, denied-then-granted permissions, foreground notification while a session is timing out. The path the user actually takes is rarely the one in the demo video.

A few concrete things came out of it:

A parseNotification normalizer with tests covering four payload shapes, runnable in plain Node, no native bridges required
A clean seam: native owns registration, foreground display, OS plumbing, intent retrieval. JS owns parsing, navigation, product logic. They don't drift because they speak through one event shape.
A deferred-redirect pattern that handles cold-start, foreground, and re-auth races with one piece of code

And the cost. Every iOS major version, every Android API bump, I have to revisit this. The libraries would have absorbed some of it. I chose not to use them because the failure modes I cared about (iOS 18 registration, cold-start payload divergence, silent push receipts, the navigation race) were already filed against those libraries, unfixed. That's the trade I made. I'd make it again, knowing the maintenance cost up front.

Push notifications were a one-line item on the roadmap. The line item was true. It just wasn't the whole shape.

The loop that changed how I write mobile tests

Amanda Gama — Sun, 03 May 2026 03:59:22 +0000

Mobile tests are where the bugs actually live. A signup flow that works on an iPhone 15 falls apart on a lower-end Android because the keyboard pushes a button off-screen. A push notification mid-flow leaves the app in a state nothing else reproduces. Memory pressure on a four-year-old Android does things you can't make a simulator do.

I wrote simulator-only tests anyway, for years. Real-device runs took ten to thirty minutes per cycle, the device farm queue was unpredictable, and CI on physical hardware was expensive enough that someone always wanted to talk about cost. So tests got written for the simulator, the device-specific bugs found their way to production, and we caught them in Sentry instead of in CI.

The thing that changed wasn't a better device farm or a faster CI. It was Claude Code writing the tests, BrowserStack MCP driving the devices, and the whole loop closing inside a single session. Claude writes a test, BrowserStack runs it on an actual iPhone, Claude reads the failure (screenshot, view tree, error trace) and fixes the test. Then it runs again. The cycle is under a minute. I never opened the test file.

That's the post. The tools matter, but what changed test authoring was the loop closing fast enough that I could stay in it.

The shape that changed

The mental model is simple. Old loop: write a test, push, wait for CI, read logs, guess at the failure, fix, push again. Best case ten minutes per iteration, often half an hour. Most of the wait is travel time: uploading the build, queuing for a device, tearing down. Almost none of it is the test itself.

New loop: Claude writes a test, the BrowserStack MCP runs it on a real device that's already provisioned, Claude reads the structured failure (screenshot, accessibility tree, console output, error stack), edits the test, runs it again. End-to-end under a minute on the happy path.

The speed isn't the value. The value is that the loop stays tight enough to stay in. Ten-minute iterations mean you context-switch out and come back cold. Sub-minute iterations mean the same problem is still in your head when the next result lands. You think about the test, not about what you were doing while you waited for CI.

The MCP is mostly invisible in this. It's just "Claude can drive real devices the way it drives anything else."

What the loop actually looks like

The clearest example was when I asked Claude to build an onboarding flow test from scratch: fresh install through to the home screen, with sign-up, email verification, and a multi-step intro along the way.

I described it in plain English. Claude wrote the first version: a script with the steps, selectors pulled from the screenshot it took on app launch, and an assertion at each milestone. It started a session on an iPhone 15, ran the test, and the test failed at step two.

The failure was a selector ambiguity. There were two elements matching [name="email"]: the visible field and a hidden form used for autofill detection. Claude saw both in the accessibility tree, picked the wrong one, and the typed text vanished into the hidden one. The test waited for the "verify your email" screen and timed out.

Claude fixed the selector to getByRole('textbox', { name: 'Email address' }) and re-ran. Past step two. Failed at step four. The third onboarding screen has an animated transition, and the tap on the next button fired before the animation finished, so the tap landed on a different element underneath. Claude added a wait on the transition end. Past step four. Eventually green.

Then I asked it to run the same test on a lower-end Android. Same code, different device. Failed on step three. The email verification deep link opens differently on Android. The Gmail app intercepts before the browser does, and the test was driving Chrome. Claude rewrote the verification step to use an alternative verification strategy for tests instead of clicking the link in the email. Re-ran on both devices. Green on both.

This whole sequence took maybe fifteen minutes. I didn't open a test file. I read every diff in the chat, said "yes" or "wait, why" three or four times, and the test ended up in the repo. The thing that made it work wasn't any single capability. It was that I could stay in the loop the whole time.

Where my role moved

I wasn't writing test code. I was reading it.

The most useful thing I did was catch the moments where Claude "fixed" a test by making it less strict. The pattern I learned to watch for: a test starts failing intermittently, Claude adds a wait longer than the original timeout, the test goes green. The wait isn't fixing flakiness. The wait is hiding it.

The cleanest example was a test that asserted the home screen rendered within 200ms after login. It started failing on the lower-end Android. Claude bumped the wait to ten seconds, the test passed, and we moved on. I caught it in review: the home screen was actually taking five seconds to render on that device because of an image-decode regression that had landed two days earlier. The test was supposed to catch exactly that. The "fix" deleted the catch.

This is the part the "LLM writes the tests" pitch always undersells. Claude is fast enough at authoring that it'll write a hundred tests in the time it would take me to write ten. Most of those tests are fine. Plenty pass because they assert close to nothing. If you don't read them, you ship a green suite that catches nothing, which is worse than no suite at all.

The bottleneck moved from authoring to judgment. Authoring is the part Claude is fast at. Judgment (does this test catch the right thing, is this assertion meaningful, is this wait masking a regression) is the part that's still mine. The work didn't disappear. It changed shape.

The MCP setup is where the time went

The loop only works when the MCP layer is reliable. When it isn't, you spend the day debugging the harness instead of writing tests.

The first day was almost entirely setup. BrowserStack credentials, MCP server config, tool permissions in Claude Code, the allowed device pool, network rules for the test backend. Each piece is documented somewhere. None of them are documented in the same place. I had four tabs open the whole time.

The tool surface is the bigger thing to plan for. The BrowserStack MCP exposes a finite set of actions: start session, run command, take screenshot, fetch logs. Most of what you want maps onto that cleanly. A few things don't. Driving a native permission dialog on iOS isn't a clean MCP action; you end up wrapping platform-specific helpers or carving a backdoor into the app for tests. Anything biometric is off the table without that backdoor.

Session lifetime caught me twice. BrowserStack sessions time out after a fixed window, devices disconnect under load, and the queue backs up during US business hours. The loop has to survive a session dying mid-test. I added a thin wrapper that re-acquires the device when the MCP returns a session-ended error and retries from the last clean assertion. That wrapper isn't optional. Without it, every long test run had a 30% chance of dying for no reason related to the code under test.

Permissions in Claude Code itself were the smaller surprise. By default, Claude asks before each tool call. The fiftieth time it asks to call the same BrowserStack action is the moment you regret it. I set a permission rule allowing that specific tool without prompts, and the loop got noticeably tighter. Skip this and you spend the day clicking "yes."

None of that is the loop changing test authoring. It's the boring tax for getting there. But it's a real day or two of setup, and skipping it in this post would be misleading. The pitch is "Claude writes the tests"; the reality is "Claude writes the tests after you spend a day making the harness work."

What you actually get

Coverage we wouldn't have written by hand. The cost of writing a test dropped enough that the question stopped being "is this worth a test" and started being "is this worth reading." We added tests for flows we'd been ignoring for years (the edge paths, the rare-but-real failure modes) because the marginal cost was small enough not to argue about.

Real-device coverage in CI, instead of simulator-only with prayers. The lower-end Android catches the things the iPhone 15 doesn't. The 200ms-versus-five-second image regression I mentioned earlier would have shipped if the test had stayed on a simulator.

The hidden cost is the one I keep coming back to: you have to read what Claude writes. If you don't, you accumulate tests that pass without testing anything, and the suite stops being a signal. The discipline shifts from authoring to reviewing. Most teams assume whoever writes the test is the one reviewing it. That works when writing is the slow step. When writing is fast and reviewing is the slow step, the assumption breaks. I haven't seen many teams notice yet.

It's not autonomous. The day it is, the discipline that survives won't be writing tests. It'll be deciding which ones still mean something.

Migrating a legacy React app from webpack to Vite

Amanda Gama — Sun, 03 May 2026 02:57:49 +0000

The codebase was old. React 16 with class components everywhere. React Router v3 with routes-as-children. A webpack 4 config that had been edited by a dozen people over five years and contained loaders nobody could explain. The dev server took 45 seconds to come up. Hot reload was 8 seconds on a good day, 20 on a bad one. The production build was 6 minutes. CI deploys took 14 minutes end to end.

I'd been dismissing Vite for two years. "Webpack works." It did work. It was also bleeding an hour a day off the team in dev server restarts, slow HMR cycles, and CI queues piling up behind each other.

Here's the catch: you don't migrate a legacy webpack project to Vite on its own. You end up migrating webpack, React, React Router, your test runner, and half your dependencies, because the things that make Vite fast are the same things that won't tolerate code from 2018. This post is about what that actually looks like.

What Vite actually does differently

The mental model shift is small, but it changes everything that follows.

Webpack bundles your app before serving it. Every dev server start walks the dependency graph, compiles every module it touches, links them, and produces a bundle. The bigger your app, the longer the wait, and it scales linearly. HMR is fast in theory, but in practice the graph invalidation is heavy enough that a 200ms code change turns into a 4-second rebuild.

Vite serves source files directly to the browser as native ES modules. Your App.tsx is requested by the browser, transformed on demand by esbuild, and sent back. Nothing gets bundled in dev. The cost of starting the server is the cost of starting a Node process plus reading config, not the cost of compiling your app.

For production, Vite uses Rollup. Bundling still happens, just not in the dev loop where it hurts.

webpack dev:    parse all -> compile all -> bundle -> serve
vite dev:       start server -> compile what the browser asks for

That's the whole insight. Everything else is a consequence.

The numbers

The dev server times told the story I expected:

Metric	webpack	Vite
Cold start	42s	1.1s
HMR (small change)	4-8s	50-200ms
Full reload	6-9s	400ms

The build times were less dramatic but still real:

Metric	webpack	Vite
Production build	5m 40s	1m 50s
Type check (separate)	45s	45s

The interesting part is type checking. Vite doesn't type-check your code. It strips types with esbuild and trusts you. If you want type safety in CI, you run tsc --noEmit separately. That stays exactly as slow as it was. So don't expect Vite to magically speed up TypeScript. It makes the transformation faster, not the checking.

What CI actually looked like before and after

The CI deploy was the win I didn't expect. Total deploy time went from 14 minutes to 5. The build itself only accounted for about 4 minutes of that improvement. The other 5 minutes came from second-order effects:

Smaller Docker layer. Rollup tree-shakes more aggressively than my webpack config ever did. Bundle size dropped 18%, and the image pushed faster.
No more cache thrashing. Webpack's persistent cache was 800MB, and CI was spending 90 seconds restoring it every run. Vite doesn't need one.
Parallel-friendly. Type check, lint, and build can run as three independent jobs. With webpack, the build dominated everything else, so splitting was pointless.

CI cost dropped about in line with wall-clock time. Not surprising, but watching the bill go down felt good.

The migration itself

The webpack-to-Vite swap on its own is a two-day job. On a legacy codebase, you don't get that luxury. The whole thing took closer to three weeks once you count the React upgrade, the router rewrite, and the test runner change that came along with it.

Start with the easy part: the build tool config.

Install:

npm install --save-dev vite @vitejs/plugin-react

A minimal vite.config.ts:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import path from 'path'

export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
  server: {
    port: 3000,
  },
  build: {
    outDir: 'dist',
    sourcemap: true,
  },
})

The index.html moves to the project root and becomes the entry point, not a template anymore. That's a real shift. Webpack treated HTML as an output. Vite treats it as the input. Your script tag points at your TS entry directly:

<script type="module" src="/src/main.tsx"></script>

Once that clicks, half the config changes make sense.

What came along for the ride

This is the part the tutorials skip. Vite assumes a modern stack. A legacy app doesn't have one, and that gap is where most of the real work hides.

React itself. React 16 will technically run under Vite, but @vitejs/plugin-react expects the new JSX transform that landed in React 17. You can pin an older plugin and limp along, or take the upgrade. I took the upgrade. Going to React 18 was straightforward once the build was clean, and Strict Mode caught a handful of effect bugs that had been hiding for years. Class components keep working. They just look increasingly out of place next to everything else.

React Router. This was the biggest single chunk of work. v3's API (routes-as-children, browserHistory as a singleton, onEnter hooks for auth) is just not compatible with v6's declarative <Routes> and useNavigate. There's no codemod that does it cleanly. I migrated in stages:

// v3
<Router history={browserHistory}>
  <Route path="/" component={App}>
    <Route path="users/:id" component={UserPage} onEnter={requireAuth} />
  </Route>
</Router>

// v6
<BrowserRouter>
  <Routes>
    <Route path="/" element={<App />}>
      <Route path="users/:id" element={<RequireAuth><UserPage /></RequireAuth>} />
    </Route>
  </Routes>
</BrowserRouter>

The mechanical translation is easy. The painful part is everywhere the old code reached into the router imperatively: browserHistory.push() from a saga, withRouter HOCs wrapping class components, route lifecycle hooks doing data fetching. Each one needs a real rewrite.

Budget honestly for this. The router upgrade took longer than the actual Vite swap.

Babel plugins you forgot you had. The old webpack config was running half a dozen Babel plugins for proposal-stage syntax that's been in the language for years: optional chaining, nullish coalescing, class properties. esbuild handles all of those natively, so you can delete them. But if any plugin was doing real work (a custom transform, an i18n extractor, an instrumentation pass), that has to become a Vite plugin or move to a separate step.

The dependency graveyard. Every legacy project has one. A charting library that hasn't published since 2019. A date picker pinned to a specific patch version. A state library the company forked internally. Anything shipping pure CommonJS without an exports field is going to fight Vite's dep optimizer. Some you can pre-bundle. Some need replacing. A few you'll end up patching with patch-package because the maintainer is gone.

Vite-specific gotchas

Beyond the legacy upgrade work, these are the traps that hit any webpack-to-Vite migration:

Environment variables. process.env.FOO becomes import.meta.env.VITE_FOO, and only variables prefixed with VITE_ are exposed to the client. That's a security feature (webpack would happily leak any env var you referenced), but it broke about 40 references in my codebase. Find-and-replace is your friend.

Dynamic imports with variable paths. This works in webpack and breaks in Vite:

const mod = await import(`./locales/${locale}.json`)

Vite needs to know the set of possible matches at build time. Use import.meta.glob:

const modules = import.meta.glob('./locales/*.json')
const mod = await modules[`./locales/${locale}.json`]()

CommonJS dependencies. Vite is ESM-first. Most modern packages are fine. Older ones with module.exports need optimizeDeps.include to pre-bundle them. Otherwise you get cryptic "default export" errors at runtime, and they only show up in production, because dev doesn't bundle.

Jest doesn't speak Vite. If you used jest with babel-jest configured to match webpack, your test setup is now misaligned with your build. The cleanest path is Vitest, which shares Vite's transform pipeline. The migration is mostly mechanical (describe, it, expect are the same), but the mocking syntax differs from Jest in spots. Budget half a day.

Public path / base URL. If your app is served from a subpath, webpack's publicPath becomes Vite's base. Forget this and you get a working dev build and a broken production deploy. I learned that one the hard way.

What didn't get better

Bundle analysis is worse. Webpack's analyzer ecosystem is mature. Vite's is fine, but less detailed. If you spend real time tuning bundle size, you'll feel the gap.

The plugin ecosystem is smaller. Most things you need exist, but expect to occasionally write a Rollup plugin where webpack would've had three options.

SSR setup is more hands-on. Vite supports it, but you wire it together yourself. If you were running a framework on top of webpack that handled SSR for you, switch to a framework on top of Vite (Remix, Next, SvelteKit) instead of doing it raw.

Was it worth it

For a greenfield project, Vite is a no-brainer. For a legacy app, it's messier. You're not just swapping a build tool. You're paying down years of tech debt because Vite forces you to. That's a feature, not a bug. Just budget for it honestly.

The dev experience win paid for itself the first week the team was on the new stack. After years of training your muscle memory to tolerate slow HMR, watching it feel instant is a small daily joy.

The deploy time win mattered more than I expected. Halving CI meant we merged to main more often, which meant smaller PRs and faster review cycles. That compound effect over a quarter was bigger than the raw numbers suggest.

The hidden win was the dependency cleanup, and I didn't see it coming. The migration forced a real audit of every package in package.json. A third of them were dead code or had modern replacements. The codebase that came out the other side was lighter and easier to onboard onto, and that part had nothing to do with Vite directly.

If you're on legacy webpack and your dev server takes more than 20 seconds to start, migrate. Just don't pitch it to your manager as a two-day job. It's a quarter of modernization work with a fast build tool at the end of it, and the payoff keeps showing up long after you're done.

Working remotely, the parts that actually mattered

Amanda Gama — Sun, 03 May 2026 02:51:28 +0000

I've been working remotely for a while, and most of what I picked up in the first six months turned out to be wrong, or wildly overrated. Not bad advice exactly. Most of it sounds reasonable when you read it. It just isn't doing the work it claimed to. The "wake up at 5am, dedicate a workspace, use the Pomodoro technique, journal every morning" stack is a kind of theater. Some of it helps a little. Most of it is energy you spend trying to feel productive instead of being productive.

What actually helped was less visible. Almost all of it was about removing small frictions, not adding discipline. The good weeks came from making fewer parts of the day cost mental energy. Not from squeezing more output out of willpower.

Here's what's stuck.

Your setup matters, but most of it doesn't

The setup advice you find online tends to confuse two different things: gear that looks good on your desk and gear that actually changes how you work. The list that genuinely helped me is short and boring.

A second monitor. This is the only piece of "setup" I'd call non-negotiable. Doing most knowledge work on a single laptop screen is the equivalent of writing in a notebook with the previous page glued shut.

A chair you can sit in for six hours without your back giving notice. You don't need the $1,500 ergonomic one. You need one that doesn't make you fidget by 3pm.

A decent headset. Not for the audio quality, though that helps. For the "I'm wearing headphones" signal that lets you ignore the world without feeling rude. The mic built into most laptops is fine.

Enough light. Especially in winter, especially for video calls. A cheap overhead light plus something at face level is the floor.

Things that didn't change anything for me: a mechanical keyboard, a fancy webcam, a standing desk, a third monitor, cable management trays, a "cozy" lamp, a houseplant. Some of those are nice. None of them changed how much I got done. If you're spending more than a weekend setting up your workspace, you're probably procrastinating with extra steps.

Routines beat motivation, but lighter than you'd think

The hardcore routine content (wake at 5am, cold shower, journal, gym, deep work block before email) is impressive on Instagram and unsustainable in real life. I tried versions of it. The version that survived was much smaller.

Two rituals, one rule.

The first ritual is a fixed start. Same first action every morning, regardless of what's on the calendar. For me it's coffee plus ten minutes reviewing what I want to get done before lunch. Not the whole day. Just the morning. The point isn't planning. It's the transition from "not working" to "working," so you don't burn the first hour ramping up.

The second is a fixed end. Before closing the laptop, write down the first task you'll start tomorrow. One sentence, on paper or in a note. This sounds stupid until you realize how much energy you waste at the start of every day re-deriving where you left off.

The rule is: don't open Slack first thing. Anything genuinely urgent will still be urgent in 90 minutes. The first block of the day is the only one where you reliably have full focus, and burning it on reactive replies is the single biggest productivity leak I had to fix.

What I gave up: time-blocking the whole day, color-coded calendars, hourly check-ins with myself, gratitude journals. Not because they're bad, but because for me they were maintenance overhead disguised as productivity.

Communication is half the job

The thing nobody really warns you about is how much of remote knowledge work is writing. Slack messages, PR comments, design docs, status updates, weekly summaries. If you can't write reasonably clearly, remote work is going to be harder than it was in the office, where tone and presence covered a lot of gaps.

A few things I've changed:

I default to written updates over meetings. The standing weekly check-in I used to do is now a five-bullet update I write on Friday afternoons. Read in two minutes, no scheduling cost, searchable for later. The meetings I keep are the ones that need actual discussion. Not status, not "alignment," not "syncing."

I'm slow to reply on purpose. If you answer every Slack within ten minutes, you've trained the team to use you as a synchronous resource, which is the opposite of remote. An informal four-hour SLA on non-urgent threads is usually enough to let people figure things out themselves before pinging.

I write outcomes, not activities. "Shipped the new auth flow" is useful. "Worked on auth all afternoon" isn't. Everyone's calendar is full of work; what people actually want to know is what came out of it.

I avoid the 15-minute "quick sync." It's never quick. Either it's a question that could be answered in writing in three minutes, or it's a real conversation that deserves 30 minutes and a doc. The middle case mostly doesn't exist, and treating it like it does is how a calendar gets eaten.

Protect deep work like it's a billable hour

Two hours of uninterrupted focus is more valuable than eight hours of fragments. This is the most-repeated and most-ignored piece of remote-work advice. It's true, and most people (me included, until recently) treat it as aspirational rather than enforceable.

Here's what actually works:

Two-hour blocks on the calendar, marked busy, treated as real meetings. Not "focus time." That's too vague to defend against your own future self. Specific: "Architecture review draft: do not book over."

Notifications off during those blocks. Slack quit, email closed, phone in another room. The phone-in-another-room thing sounds dramatic; it's the single change that made the biggest difference for me. Reaching for the phone to "check something" was costing me twenty minutes per occurrence and I wasn't tracking it.

One context switch (a non-urgent message, a notification, a quick check of something) costs around twenty minutes of lost focus on hard work. Not because the switch is long, but because the climb back is. If you understand that and still switch, fine. Most of us don't, and the cost compounds across the day.

The hardest part is letting things sit. Replies waiting, threads moving, a question someone just asked. All of it can wait until your block is done. That's the muscle.

When you add travel to the mix

I've been working remotely while traveling for stretches, and the honest version is that travel makes most of the above harder, not easier. The Instagram pitch (laptop on a beach, perfect productivity) is selectively true on a small number of days, and it costs you on most of the others.

The things that get harder, in rough order of how much they hurt. Time zones first. You're either disconnected from your team for half the day, or answering Slack at midnight. Then internet. A hotspot stops being optional and becomes the actual connection in most places. Then environment. A different desk, different chair, different noise floor every week or two. The compounding effect of "decent enough" beats the effect of "novel" within about a month.

What helps, if you do it anyway: pick places with infrastructure first and aesthetics second. Carry a backup hotspot on a different carrier. Don't try to start work the day you arrive somewhere new. The first 24 hours is logistics, not output. Protect at least four hours of overlap with your team, wherever you are.

What you give up is real: deeper rest, a stable rhythm, a setup that gets a little better every month. Travel is fun. It's also a tax on output. If the location is the point, you'll love it. If the work is the point, you'll find that traveling less makes the work easier, which is worth knowing before you sign a six-month lease somewhere far away.

What I've stopped believing

A few things I dropped along the way.

That gear matters much beyond the basics. It doesn't.

That every hour of the day needs to be productive. Most of mine aren't, even on good days, and trying to force them just adds anxiety to the unproductive ones.

That working from "cool" places makes you happier. It makes the photos better. The day-to-day feels about the same.

That async means everything has to be in writing. Some conversations need to be conversations. Trying to write your way through every disagreement, every nuanced design call, every piece of feedback is its own kind of overhead.

That discipline is the answer. Most days, removing one source of friction beats adding one new habit. The version of remote work that lasted, for me, has fewer rules than the version I started with, and the ones that remain are mostly about what I don't do.

Clean architecture in React Native isn't about layers

Amanda Gama — Fri, 01 May 2026 03:46:40 +0000

Every React Native codebase I've worked on hits the same wall around month four. A screen that started at 80 lines is now 400. Half of it is useEffect chains coordinating API calls. A push notification mid-flow leaves the app in a state nobody can reproduce.

Clean architecture in React Native isn't about folders or layers. It's about whether you can still reason about your app when async, navigation, and native modules collide.

The shape that fails

The default React Native architecture is "everything lives where it's first needed." API calls land in the handler that triggers them. State sits in the screen that displays it. Native modules get called from the button that activates them. It works for the first month.

What it doesn't survive:

Async outliving its caller. A user kicks off a request, taps a notification, lands on a different screen. The original promise resolves into a setter that no longer makes sense.
Native modules in the UI. A screen calls NativeModules.Audio.start() directly. iOS 17 changes the audio session semantics. Three screens break, not one.
Auth races. A token refresh fires while three other requests are in flight. Two retry, one logs the user out, one leaks the old token.
Drift. The same "send a message" logic lives in two screens. One gets a validation rule added. The other doesn't.

The pattern that produces all of this:

const handleSend = async () => {
  const res = await api.post('/messages', input)
  setMessages(prev => [...prev, res.data])
}

Nothing wrong with this code on its own. The problem is the second time it gets written, slightly differently, in another screen.

Three layers, one rule

Skip the diagram. The minimum viable framing:

Presentation. Screens, components, hooks. Renders. Orchestrates.
Domain. Use cases. Pure logic. No react, no fetch, no NativeModules.
Data. API clients, storage, native bridges. Knows about the outside world.

One rule: the UI talks to the domain, never to data directly.

That's the post. The rest is what enforcing that rule does to the bugs above.

Use cases are the boundary

The shift in code is small:

// Before: handler decides how things work
const handleSend = async () => {
  const res = await api.post('/messages', input)
  setMessages(prev => [...prev, res.data])
}

// After: handler delegates
const handleSend = async () => {
  await sendMessage.execute(input)
}

The use case is where the logic actually lives:

class SendMessage {
  constructor(private repo: MessageRepository) {}

  async execute(input: SendMessageInput) {
    // validation, business rules, orchestration
    return this.repo.send(input)
  }
}

This isn't ceremony. The point is that SendMessage is the only place anyone outside the domain learns how a message gets sent. Two screens calling it can't drift apart, because there's only one of it.

The repository is the other half:

interface MessageRepository {
  send(input: SendMessageInput): Promise<Message>
}

The use case depends on the interface. The implementation lives in the data layer. The UI imports neither. It imports the use case, calls execute, and stops thinking.

Where React Native makes you pay for shortcuts

This is the part most "clean architecture" posts are silent on. Web apps have UI and API. React Native has UI, API, navigation lifecycle, native modules, background/foreground transitions, and OS-level interruptions. The cost of mixing layers compounds with each one.

Async outliving the screen. A request starts on screen A and resolves after the user is on screen C. If the resolution reaches for component-local setters, navigation refs, or context that no longer exists, you get a bug that only reproduces when someone moves fast. A use case gives you one place to attach cancellation, idempotency, or "is this caller still listening?" guards. The screen doesn't need to know.

Native modules don't belong in handlers. NativeModules.Audio.start() in a button handler ties the UI to platform behavior. Platform behavior is the part most likely to diverge between iOS and Android, between OS versions, between simulator and device. Wrap the module in a repository, expose a use case (StartRecording), and the UI is platform-agnostic. The platform-specific logic has one home, and you know where to look when iOS changes.

Auth and rehydration races. Token refresh overlapping with three in-flight requests is the canonical React Native bug. If your auth logic is split across an axios interceptor, a context provider, and a screen, the race is unfixable. There's no single thing to serialize. A RefreshSession use case that owns the queue makes it tractable. Boring, but tractable.

Tests stop pretending

The biggest practical payoff isn't reuse. It's that tests stop needing the framework.

it('sends a message via the repo', async () => {
  const repo = new FakeMessageRepo()
  const useCase = new SendMessage(repo)

  await useCase.execute({ body: 'hi' })

  expect(repo.sent).toHaveLength(1)
})

No render tree. No react-test-renderer. No mocked NativeModules. No Detox. The use case runs in pure Node and exits in milliseconds.

Most of the value of architecture is what becomes testable, not what becomes "clean."

The trap

A few ways this goes wrong:

Optional architecture isn't architecture. "I'll just call the API directly this once" is how you end up with three places that do the same thing badly. Either the boundary is enforced or it isn't.
Three layers for a two-screen app is waste. If your app is a login and a list, you don't need a use case layer. Apply this when the complexity earns it, usually somewhere between the third real feature and the second engineer.
Folders aren't boundaries. You can have a domain/ directory and still call fetch from a screen. The directory structure is documentation. ESLint rules and code review are enforcement.

The other cost is upfront friction. A new feature now touches three files instead of one. For a few weeks that feels worse, not better. It pays off the first time a bug reproduces only on Android, only after a notification, only when offline. You find the cause in one place instead of grepping six.

What you actually get

Clean architecture in React Native isn't a goal, and it isn't about being clean. Something will go wrong at month twelve, in a way you didn't predict. It's the bill you pay so the code you're staring at is still one you can reason about.