DEV Community: Hugo Rus

Deep-Linking in React Native Was Miserable. Expo Router Made It Accidental.

Hugo Rus — Wed, 15 Jul 2026 13:25:52 +0000

Pre-Expo Router, deep-linking meant react-native-linking + URL schemes + Universal Links + a hand-synced linking config — roughly two weeks of work that broke on every screen rename.
Three things reliably broke in prod: renamed screens (silent 404s), missing params (crashes), and state mismatch (app resets to home instead of stacking).
Expo Router fixes this by making the URL structure be the file structure — there's no separate config to desync.
One gotcha remains: Universal Links still need an apple-app-site-association file and Xcode entitlements. That part's on Apple, not the framework.

Deep-linking used to be the feature that dev teams promised at kickoff and quietly cut before launch. In three separate React Native apps I've shipped, the deep-linking ticket got moved to "next quarter" at least twice before someone finally forced it.

Expo Router changed that — not because it's easier (though it is), but because deep-linking is now the default, not an add-on.

The 2022 baseline

Getting a link like myapp://profile/42 to open the profile screen for user 42 used to require:

react-native-linking set up with a URL scheme in Info.plist and AndroidManifest.xml.
Universal Links (iOS) or App Links (Android) if you wanted https://myapp.com/profile/42 to open the app instead of Safari.
A separate linking config passed to NavigationContainer that mapped URL patterns to screen names and params — kept in sync by hand with the navigator config.
Deep-link testing across cold-start, warm-start, and background-resume paths, each of which broke differently.

By the time you had all four working, you'd spent two weeks and had a URL-to-screen mapping that broke every time someone renamed a screen.

The three things that used to break in prod

Renamed screens. Someone renames ProfileScreen to UserProfileScreen, forgets to update the linking config, and deep links silently 404 to the home screen.
Missing params. myapp://profile (no id) crashes the screen because someone forgot the id fallback.
State mismatch. The user is deep in a Stack navigator when the link arrives; the app resets to home instead of stacking correctly.

What Expo Router does differently

Because the URL structure is the route file structure, you can't have a mismatch between what a URL says and what screens exist. myapp://profile/42 maps to app/profile/[id].tsx because that file exists. Rename the file and the URL structure changes with it. There's no separate config file to keep in sync.

That single property — one source of truth instead of two — eliminates the first failure mode entirely, and makes the other two far easier to reason about.

A support-team flow that just works

My team recently shipped a support-tools feature: our CS team can send customers a link like myapp://support/ticket/T-1234 from a Slack app.

Before Expo Router, that would have been a three-week ticket — design the URL schema, wire the linking config, test across cold-start states. With Expo Router, it was two files (app/support/ticket/[id].tsx and a Slack app integration) and a two-day build.

The link works whether the user has the app closed, in the background, or open on another screen.

The one remaining gotcha

Universal Links — the iOS feature that makes https://myapp.com/profile/42 open your app instead of Safari — still needs an apple-app-site-association file served from your website, plus the right entitlements in Xcode. Expo Router doesn't automate this; it's an Apple-side concern. Set aside half a day for it when you first turn Universal Links on.

Takeaway

Deep-linking used to be a feature you promised in month 1 and delivered in month 4. In an Expo Router app it's a feature you get in month 0 by not opting out.

If your team is still hand-rolling deep-link config in 2026, you're solving a problem the framework already solved.

What's the deep-link bug that cost you the most time — a silent 404, a cold-start crash, or Universal Links entitlements? Drop it in the comments.

How to Build a Video Calling App with React Native and WebRTC

Hugo Rus — Wed, 15 Jul 2026 13:21:07 +0000

WebRTC is built into every modern OS, and react-native-webrtc is production-hardened — you can ship a 1-to-1 video call in a weekend with open-source pieces only.
Every call has four parts: a signaling server (Socket.io), a STUN server (Google's free one), an optional TURN server (for the ~15–20% of calls that can't go P2P), and the peer connection on each device.
This guide builds all of it: signaling, media capture, offer/answer exchange, ICE handling, and the standard call controls.
The hardest part isn't the API — it's the network. Test on real cellular, log ICE state transitions, and don't skip TURN in production.

Ten years ago, adding video calling to a mobile app meant licensing a proprietary SDK, paying per-minute fees, and hoping the vendor didn't disappear. Today, WebRTC is built into every modern OS, react-native-webrtc is production-hardened, and you can ship a working 1-to-1 video call in a weekend. The catch? Nobody tells you the whole story. Most tutorials skip signaling, gloss over Expo compatibility, or quietly funnel you into a paid SDK before you write any real WebRTC code.

This guide walks through the entire flow — from a fresh React Native project to two phones streaming video and audio to each other over a real signaling server. You'll build a video calling app using open-source pieces: react-native-webrtc, Socket.io for signaling, and Google's public STUN server. No SDK lock-in, no per-minute pricing, no black boxes.

What is WebRTC and why use it in React Native?

WebRTC (Web Real-Time Communication) is an open standard that lets browsers and native apps exchange audio, video, and arbitrary data directly between peers with sub-second latency. In React Native, the react-native-webrtc library exposes the same JavaScript APIs you'd use in a browser — RTCPeerConnection, MediaStream, getUserMedia — but backed by native iOS and Android WebRTC bindings that hit the hardware encoder.

That matters for three reasons:

Latency. WebRTC targets sub-500ms glass-to-glass. HTTP streaming protocols like HLS sit at 6–30 seconds. For conversation, WebRTC is the only game in town.
Peer-to-peer by default. For 1-to-1 calls, media flows directly between devices. You don't pay for bandwidth on your server.
No vendor lock-in. The protocol is a W3C standard. You can switch signaling servers, TURN providers, or client libraries without rewriting your app.

The tradeoff: WebRTC hands you plumbing, not a product. You supply the signaling channel, the connection lifecycle, and the UI. That's exactly what we'll build.

The four pieces of every WebRTC call

Before the code, the mental model. Every video calling app has four moving parts, and every bug you'll ever hit lives in one of them.

Component	What it does	What we'll use
Signaling server	Exchanges connection metadata (SDP offers/answers and ICE candidates) between peers before the call starts. Not part of WebRTC.	Node.js + Socket.io
STUN server	Helps a peer discover its public IP so peers behind NAT can find each other.	Google's free `stun:stun.l.google.com:19302`
TURN server	Relays media when direct P2P fails (~10–20% of calls in the wild).	Skipped for the tutorial; production notes below.
Peer connection	The `RTCPeerConnection` object on each device that negotiates and streams media.	`react-native-webrtc`

The dance goes like this: Device A creates an "offer" (an SDP blob describing its media capabilities), sends it through the signaling server to Device B. Device B answers. Both sides then trade ICE candidates — possible network paths — until they find one that works. Media starts flowing.

Prerequisites

Node.js 20+ and either npm or yarn
React Native 0.74+ or Expo SDK 51+ (with Expo Dev Client — Expo Go does not support native WebRTC modules)
Xcode 15+ for iOS builds, Android Studio with API 30+ for Android
Two physical devices for testing. The iOS Simulator has no camera, and the Android emulator's virtual camera is unreliable for WebRTC.

If you're on Expo, make sure you're on the Expo Dev Client workflow, not Expo Go. react-native-webrtc ships native code that Expo Go can't load.

Step 1: Install and configure react-native-webrtc

Create your project and install the library:

npx create-expo-app@latest video-call-tutorial
cd video-call-tutorial
npx expo install react-native-webrtc @config-plugins/react-native-webrtc
npm install socket.io-client

The @config-plugins/react-native-webrtc package handles platform permissions for you. Add it to your app.json:

{
  "expo": {
    "plugins": [
      [
        "@config-plugins/react-native-webrtc",
        {
          "cameraPermission": "Allow $(PRODUCT_NAME) to access your camera for video calls.",
          "microphonePermission": "Allow $(PRODUCT_NAME) to access your microphone for video calls."
        }
      ]
    ]
  }
}

On bare React Native, add these permissions manually:

iOS (ios/YourApp/Info.plist): NSCameraUsageDescription and NSMicrophoneUsageDescription
Android (android/app/src/main/AndroidManifest.xml): CAMERA, RECORD_AUDIO, MODIFY_AUDIO_SETTINGS, BLUETOOTH_CONNECT

Now rebuild the native app — you cannot use hot reload for this step:

npx expo prebuild
npx expo run:ios     # or run:android

Step 2: Build a minimal signaling server

WebRTC gives you the media pipe. It doesn't tell peers how to find each other. You need a signaling server whose only job is to relay three types of messages: offers, answers, and ICE candidates.

Create a server/ folder alongside your app with this index.js:

const { Server } = require('socket.io');
const io = new Server(3001, { cors: { origin: '*' } });

const rooms = new Map();

io.on('connection', (socket) => {
  socket.on('join', (roomId) => {
    socket.join(roomId);
    const peers = rooms.get(roomId) ?? [];
    peers.push(socket.id);
    rooms.set(roomId, peers);
    // Tell this socket about existing peers so it knows to send the offer
    socket.emit('peers', peers.filter((id) => id !== socket.id));
  });

  socket.on('offer', ({ to, sdp }) => {
    io.to(to).emit('offer', { from: socket.id, sdp });
  });

  socket.on('answer', ({ to, sdp }) => {
    io.to(to).emit('answer', { from: socket.id, sdp });
  });

  socket.on('ice', ({ to, candidate }) => {
    io.to(to).emit('ice', { from: socket.id, candidate });
  });

  socket.on('disconnect', () => {
    for (const [roomId, peers] of rooms) {
      const filtered = peers.filter((id) => id !== socket.id);
      if (filtered.length) rooms.set(roomId, filtered);
      else rooms.delete(roomId);
    }
  });
});

console.log('Signaling server running on :3001');

Install and run:

cd server
npm init -y
npm install socket.io
node index.js

That's the entire signaling server. It's 30 lines because it should be. Anything more complex belongs in your app layer.

Step 3: Capture local media

Back in your app, request camera and microphone access. This uses mediaDevices.getUserMedia, which returns a MediaStream you can preview and later attach to the peer connection.

import { mediaDevices, MediaStream } from 'react-native-webrtc';

async function getLocalStream(): Promise<MediaStream> {
  const stream = await mediaDevices.getUserMedia({
    audio: true,
    video: {
      facingMode: 'user',
      width: { ideal: 1280 },
      height: { ideal: 720 },
      frameRate: { ideal: 30 },
    },
  });
  return stream;
}

Render it with RTCView:

import { RTCView } from 'react-native-webrtc';

<RTCView
  streamURL={localStream.toURL()}
  style={{ flex: 1 }}
  objectFit="cover"
  mirror
/>

mirror flips the preview horizontally, which is what users expect for the front camera. On the remote video, leave it off.

Step 4: Create the peer connection

The RTCPeerConnection object is the heart of the call. Give it your ICE server config, add your local tracks, and wire up the event handlers.

import {
  RTCPeerConnection,
  RTCSessionDescription,
  RTCIceCandidate,
} from 'react-native-webrtc';

const pc = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    // In production, add a TURN server here (see below)
  ],
});

localStream.getTracks().forEach((track) => {
  pc.addTrack(track, localStream);
});

pc.addEventListener('track', (event) => {
  setRemoteStream(event.streams[0]);
});

pc.addEventListener('icecandidate', (event) => {
  if (event.candidate) {
    socket.emit('ice', { to: remotePeerId, candidate: event.candidate });
  }
});

pc.addEventListener('connectionstatechange', () => {
  console.log('PC state:', pc.connectionState);
  if (pc.connectionState === 'failed') {
    // Reconnect or tear down
  }
});

Two things worth noting:

addTrack, not addStream. addStream is deprecated in the Unified Plan SDP semantic that all modern WebRTC implementations use.
Trickle ICE. The icecandidate handler fires as candidates are discovered. Send each one immediately rather than waiting for gathering to finish — this shaves seconds off call setup.

Step 5: Exchange offer and answer

The device that initiates the call creates the offer. The receiving device answers. Both sets of SDP are relayed through your signaling server.

Caller:

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
socket.emit('offer', { to: remotePeerId, sdp: offer });

Callee (on receiving the offer):

socket.on('offer', async ({ from, sdp }) => {
  await pc.setRemoteDescription(new RTCSessionDescription(sdp));
  const answer = await pc.createAnswer();
  await pc.setLocalDescription(answer);
  socket.emit('answer', { to: from, sdp: answer });
});

Caller (on receiving the answer):

socket.on('answer', async ({ sdp }) => {
  await pc.setRemoteDescription(new RTCSessionDescription(sdp));
});

Both sides handle incoming ICE candidates:

socket.on('ice', async ({ candidate }) => {
  try {
    await pc.addIceCandidate(new RTCIceCandidate(candidate));
  } catch (err) {
    console.error('addIceCandidate failed', err);
  }
});

At this point, if you run the app on two devices that can reach each other over the network, video and audio start flowing. You've built a working WebRTC call.

Step 6: Add the call controls

A working call isn't a shippable feature. Users expect mute, video toggle, camera flip, and hangup. All of them are one or two lines with the WebRTC API.

Mute audio:

function toggleMute() {
  localStream.getAudioTracks().forEach((t) => (t.enabled = !t.enabled));
}

Toggle video:

function toggleVideo() {
  localStream.getVideoTracks().forEach((t) => (t.enabled = !t.enabled));
}

Switch camera:

function switchCamera() {
  localStream.getVideoTracks().forEach((t) => t._switchCamera());
}

Hang up:

function hangup() {
  localStream.getTracks().forEach((t) => t.stop());
  pc.close();
  socket.emit('leave');
}

Note: setting track.enabled = false keeps the transport open and sends silence/black frames — much faster to un-mute than fully removing the track.

Common pitfalls (and how to avoid them)

After shipping WebRTC in production a few times, these are the traps engineers walk into.

"It works on Wi-Fi but not on cellular." You need a TURN server. Symmetric NAT on carrier networks blocks direct P2P for a significant chunk of your users. Skipping TURN in tests is fine; skipping it in production leaves 15–20% of calls broken.

"The remote video is black on iOS." Almost always an RTCView rendering issue — the stream URL updated but the component didn't re-render. Wrap <RTCView> in a key={remoteStream.toURL()} to force remount when the stream changes.

"Audio works but video doesn't." Check that both peers actually added a video track before createOffer was called. SDP is negotiated once — if the offer only advertised audio, no video will flow even if you add a video track later. Use pc.addTransceiver up front if you want to reserve the slot.

"Metro bundler complains about require.internal after installing." You installed react-native-webrtc but forgot to rebuild. Native modules can't hot-reload — always npx expo prebuild && npx expo run:ios after installing.

"Calls fail to connect but no errors log." Attach a connectionstatechange handler. WebRTC failures are silent — the connection just doesn't succeed. Also log iceConnectionState transitions; they're the fastest signal that ICE gathering is going wrong.

Scaling beyond 1-to-1

The tutorial above scales fine to two people because media flows peer-to-peer. Add a third person and you have a mesh topology: each participant maintains a peer connection to every other participant. Bandwidth on a mobile device scales O(n) with participants, and CPU scales O(n) with encoding.

Mesh works up to about 4 participants on modern phones. Beyond that, you need a Selective Forwarding Unit (SFU) — a server that receives one stream from each participant and forwards it to the others. Open-source options include mediasoup, Janus, and LiveKit. All three work with react-native-webrtc on the client — only the signaling protocol changes.

For TURN in production, run coturn on a cheap VPS or use a managed provider like Twilio's Network Traversal Service or Xirsys. Budget roughly $0.40 per GB of relayed traffic.

Frequently asked questions

Does react-native-webrtc work with Expo Go?

No. react-native-webrtc ships native iOS and Android modules that Expo Go cannot load. Move to Expo Dev Client or the bare workflow and use EAS Build (or a local expo run:ios/expo run:android) to include the native code.

How much does a WebRTC video calling app cost to run?

For 1-to-1 calls, near zero — media flows peer-to-peer. Your only costs are the signaling server (a $5/month VPS handles thousands of concurrent calls) and TURN relay for the ~15–20% of calls that fall back to relayed mode. Budget $0.40 per GB of TURN traffic.

What's the difference between STUN and TURN?

STUN helps a peer discover its own public IP so two peers behind NAT can attempt a direct connection. TURN is a fallback: when direct P2P fails (usually because both peers are behind symmetric NAT), TURN acts as a media relay. STUN is cheap and free servers exist; TURN uses your bandwidth and typically costs money.

Is WebRTC secure?

Yes. All WebRTC media is encrypted with DTLS-SRTP by default — it's not optional in the spec. The signaling channel is your responsibility; use WSS (secure WebSockets) or HTTPS for whatever you build.

Wrapping up

You now have every piece needed for a production-quality React Native video calling app: a signaling server, a peer connection lifecycle, media capture, offer/answer exchange, ICE handling, and the standard call controls. Add a TURN server, wire the UI to your app's state management, and you're 80% of the way to shipping.

The hardest part of WebRTC isn't the API — it's the network. Test on real cellular connections, log ICE state transitions, and instrument connection failures early. Everything else is UI polish — and if you'd rather move fast on that layer, RapidNative generates the call-lobby, in-call overlay, and post-call screens so you can spend your time on the ICE candidate that just failed instead.

What part of WebRTC bit you hardest — signaling, NAT traversal, or the native build? Drop it in the comments.

How to Build a Project Management App Like Trello in 2026

Hugo Rus — Mon, 13 Jul 2026 13:40:26 +0000

Trello's whole data model is three nested objects: boards → lists → cards. Everything else decorates that skeleton.
The 2026 stack: React Native + Expo, gesture-handler + reanimated for drag, FlashList for perf, Supabase for realtime, EAS to ship.
The hard parts nobody warns you about: drag-and-drop is a physics problem, card ordering is a distributed-systems problem, and offline-first is a data-model problem.
Traditional MVP: 4–8 weeks and $40k+. AI-generated first prototype: under an hour.

How to Build a Project Management App Like Trello in 2026

Trello sold to Atlassian for $425M. The idea? Digital sticky notes. The execution? A decade of polish on one very good primitive.

If you've ever thought about building your own — for a niche Trello ignores, as a portfolio project, or just because you're tired of Power-Ups — this is the modern build guide.

The Trello data model (learn this first)

Three nested objects. That's it:

Boards — one per project
Lists — columns inside a board
Cards — the actual work items

Everything else — labels, checklists, automation, integrations — decorates that skeleton.

Must-have MVP features

Board list + create board
Draggable lists per board
Draggable cards between lists
Card detail (title, description, due date)
Assignees + team invites
Real-time sync
Offline read, queued writes
Push notifications on mentions

Deliberately skip for v1: Gantt, automation, custom fields, integrations. Trello itself took years.

The 2026 stack

Frontend

React Native + Expo (managed workflow)
react-native-gesture-handler — drag primitives
react-native-reanimated — 60fps card animations
@shopify/flash-list — hundreds of cards without frame drops
react-native-mmkv — local persistence (faster than AsyncStorage)

State

Redux Toolkit or Zustand
Optimistic updates are non-negotiable — the drop must feel instant

Backend

Supabase (Postgres + Realtime + Auth) or Firebase
Three tables: boards, lists, cards with a position float per card

Real-time

Supabase Realtime or Firestore listeners
CRDTs (Yjs, Liveblocks) if you need deep collaborative editing later — overkill for v1

Push

Expo Notifications → APNS/FCM

Publish

EAS Build + EAS Submit → App Store & Play Store

The hard parts nobody warns you about

1. Drag-and-drop is a physics problem. Card position, list scroll, screen-edge auto-scroll, haptics, cancel gestures. Budget 2–3 weeks of tuning after "it works."

2. Ordering is distributed systems. Two users drop cards at position 3 simultaneously — what happens? Fractional indexing is the usual answer, but it needs re-balancing.

3. Offline-first is a data-model problem. Per-mutation IDs, conflict rules, sync UI. A full week of design work.

4. Push notifications require devops. APNS certs expire. Silent notifications get throttled. You will hit this.

5. App Store review will reject something. Usually your privacy policy. Budget one rejection.

The AI shortcut

Since 2023, the "generate a working mobile app from a prompt" tools have gotten genuinely good — not "here's a broken scaffold" good, but "here's a running Expo project on your phone" good.

I've been using RapidNative for this. It outputs real React Native + Expo code — the same stack you'd write by hand — with a full export button. No proprietary runtime.

The pitch for a Trello clone specifically: Kanban is a well-known pattern. The AI has seen a thousand board layouts. The generic first version is instant, so you skip straight to what makes your app different.

Concrete workflow

Step 1 — Generate the shell

Prompt:

"Build a project management app for small teams. Users see a list of boards on the home screen. Each board has three columns — Backlog, In Progress, Done — with cards that can be dragged between columns. Cards have a title, description, due date, and assignee avatar."

You get four screens (board list, Kanban view, card detail, new-card form) in about a minute.

Step 2 — Iterate with point-and-edit

Click an element in the preview, describe the change:

Column header → "Make this pill-shaped with a subtle color per column"
Card → "Add a checklist with progress bar"
FAB → "Open a bottom sheet instead of a new screen"

Step 3 — Test on your actual phone

Scan the QR code with your camera. The app loads on your iPhone/Android in seconds. Drag a card. Feel the momentum. Desktop previews lie.

Step 4 — Layer in the differentiators

"Add a weekly review screen showing all cards completed in the last 7 days grouped by assignee"
"Add a template gallery: Bug Tracker, Content Calendar, Sales Pipeline"
"Add haptic feedback on successful card drop"

Step 5 — Export or publish

Export the code and take it to a developer for backend integration, or publish directly to the App Store and Google Play. Either way, you own the code.

Traditional vs. AI-generated

	Traditional team	AI-generated
First prototype	4–8 weeks	< 1 hour
App Store submission	3–6 months	1–2 weeks
Team size	1 designer + 2 devs	1 person
Realistic MVP cost	$40k – $120k	< $50/month
Code ownership	Yours	Yours (full export)

The traditional path still wins for deep custom logic (proprietary ERP integrations, bespoke real-time engines). For everything else, AI-first plus human polish for the last 20% is the fastest path to production in 2026.

What to build next

Once v1 is out and you have retention data:

Calendar view + Gantt for dated cards
Automation rules
Templates gallery
Comments + @mentions + push
Attachments (inline previews)
Time tracking per card
AI triage (auto-labels, priority, weekly summaries)

Each is a prompt away with generation, and a sprint away in traditional dev.

The bottom line

Trello is 15 years of polish on one great idea. You will not out-execute Atlassian at their own game. But you can absolutely serve a niche they ignore — freelance photographers, film crews, D&D dungeon masters — better than they ever will.

The bottleneck used to be time and money. It isn't anymore. Pick a niche, ship in weeks, iterate on real feedback.

If you want to try the AI path, RapidNative is free to start — you'll have a Kanban board running on your phone before your next coffee.

What niche would you build a Trello for? Drop a comment.

The React Native Accessibility Bugs Every App Ships With (And How to Fix Them)

Hugo Rus — Fri, 10 Jul 2026 11:21:34 +0000

The React Native Accessibility Bugs Every App Ships With (And How to Fix Them)

I've reviewed a lot of React Native codebases in the last year. Every single one shipped with the same six accessibility bugs. Here they are, with fixes.

Quick context: WCAG 2.2 AA is the operative standard for mobile app accessibility in 2026 — the EU's Accessibility Act made it enforceable last year, and ADA lawsuits against mobile apps are climbing. React Native gives you the tools to comply. Most teams just don't use them right.

Bug 1: Icon-only buttons with no label

// Broken
<Pressable onPress={addToCart}>
  <Icon name="plus" />
</Pressable>

// Fixed
<Pressable
  accessibilityRole="button"
  accessibilityLabel="Add to cart"
  accessibilityHint="Adds one to your current cart"
  onPress={addToCart}
>
  <Icon name="plus" />
</Pressable>

VoiceOver reads the first one as "Button." Zero context. Every icon-only tap target needs accessibilityLabel.

Bug 2: FlatList rows read as a wall of text

Each Text child gets read as a separate element. Users swipe 6 times to hear one product tile.

<Pressable
  accessibilityLabel={`${product.name}, ${product.price}, ${product.rating} stars`}
>
  <View accessibilityElementsHidden importantForAccessibility="no-hide-descendants">
    <Text>{product.name}</Text>
    <Text>{product.price}</Text>
    <Text>{product.rating}</Text>
  </View>
</Pressable>

Bug 3: Modal backdrops that don't hide from VoiceOver

pointerEvents="none" stops touch. It does not stop VoiceOver from reading the background content. You need:

<Modal>
  <View accessibilityViewIsModal>
    {/* modal content */}
  </View>
</Modal>

Plus accessibilityElementsHidden={true} on the underlying screen.

Bug 4: Loading spinners that announce silence

Sighted users see the spinner. VoiceOver users hear nothing and assume the app froze.

useEffect(() => {
  if (isLoading) {
    AccessibilityInfo.announceForAccessibility('Loading orders...');
  }
}, [isLoading]);

Bug 5: Custom toggle switches missing `accessibilityRole="switch"`

The built-in <Switch> handles this. Custom animated switches almost never do:

<Pressable
  accessibilityRole="switch"
  accessibilityState={{ checked: isOn }}
  onPress={() => setIsOn(!isOn)}
>
  <AnimatedThumb on={isOn} />
</Pressable>

Bug 6: Dark mode contrast failures

#888888 on #121212 = 3.5:1. That's under WCAG AA for body text. Dark themes don't get a pass — run every color combination through a contrast checker. Enforce it in your design tokens, not per-component.

Touch targets: WCAG 2.2 SC 2.5.8

Minimum 24×24 CSS pixels. Aim for 44×44 to match iOS and Material guidelines:

<Pressable
  style={{ minWidth: 44, minHeight: 44 }}
  hitSlop={{ top: 12, bottom: 12, left: 12, right: 12 }}
/>

hitSlop extends the tap area without changing layout — huge for tight icon rows.

The testing stack that actually catches this

Four layers:

@react-native-ama/core — runtime overlay in dev builds that flags missing labels, contrast failures, and undersized targets.
@testing-library/react-native — getByRole('button', { name: 'Add to cart' }). If the query fails, your a11y is broken.
axe DevTools Mobile — automated WCAG audit in CI.
Manual VoiceOver + TalkBack — five minutes per release. No tool replaces this.

The angle nobody talks about

Retrofitting accessibility is expensive. Starting with WCAG-aligned defaults is nearly free. That's part of why we built RapidNative — the AI-generated code ships with accessibilityLabel, accessibilityRole, and AA-compliant color tokens by default. You still test with VoiceOver, but you're fixing 5 bugs per screen instead of 50.

WCAG 3.0's editor's draft (Jan 2026) moves to outcome-based scoring, but 2.2 AA is what regulators will hold you to for years. Build the habits now.

What Indie React Native Devs Say About EAS 90 Days In

Hugo Rus — Wed, 08 Jul 2026 14:17:11 +0000

I surveyed 30 indie React Native devs about their EAS Build experience 90 days after migrating from other CI.
The surprise: the top reported gain wasn't "faster builds" — 19 of 30 said some version of "I stopped fearing the build."
The first-30-days friction clustered around credentials, native module compatibility, and env var propagation.
Devs bought Priority tier reactively, after one stalled build cost them a business moment.
The real frame: build velocity is a downstream metric for how much you're willing to iterate.

Over the last month I asked 30 indie React Native devs a short set of questions about their EAS Build experience 90 days after they migrated from whatever their previous CI was (Bitrise, Codemagic, App Center, GitHub Actions, home-rolled). The sample is small and biased — mostly people in the Expo Discord and RN subreddits — but the patterns were tight enough to be worth writing up.

Here's what came out of it, and why one finding surprised me.

How we ran the survey

Five open-ended questions:

What did you migrate from, and why?
What did you expect to gain? What did you actually gain?
What broke or frustrated you in the first 30 days?
Did you upgrade to Priority tier? If so, when and why?
If you were advising a friend about to migrate, what would you tell them?

Responses via DM, ~10–15 minutes each. 30 devs, spread across roughly a dozen countries.

The trust-in-the-build finding that surprised us

Question 2's "what did you actually gain" was where the interesting pattern emerged. I expected answers like "faster builds" or "less YAML" — and got some of those. But the phrase that came up in 19 of 30 responses, unprompted:

I stopped fearing the build.

Or close variants. "I stopped avoiding native module changes." "I stopped batching commits." "I started shipping small changes daily instead of holding them until a batch was safe."

The pattern underneath: when your build pipeline is flaky, you develop compensatory behaviors. You batch changes to reduce the number of builds. You avoid touching native modules because a failed native build costs a day. You wait until Friday to try the risky refactor, because if it breaks you can lose a whole afternoon debugging CI instead of code.

A reliable build removes those compensatory behaviors. What devs called out as the gain wasn't the build itself — it was the freedom to iterate the way they'd want to iterate if CI weren't a threat.

That's a hard thing to sell on a marketing page. But it's the actual product.

What breaks the trust — and how devs recover

The first-30-days frustrations clustered into three:

Credential setup. iOS certificate + provisioning profile onboarding was the #1 pain point. Devs who let EAS manage credentials had a smoother start than those who imported their existing P12s. Advice from experienced devs: let EAS manage, then export if you need to.
Native module compatibility. When a native module didn't play well with EAS's build environment, the error messages were opaque. Recovery pattern: eas build --local to reproduce the failure on your own machine, then debug from there.
Environment variable propagation. EXPO_PUBLIC_* vs. runtime env vs. app.config.js extras — devs got confused about which one to use where. The consensus fix was to standardize on EXPO_PUBLIC_* for anything client-side and never look back.

Devs who hit these in the first two weeks and stuck it out ended up as advocates by day 90. Devs who hit these and bounced back to their old CI usually did so before day 14.

The Priority-tier decision point most indies hit

Question 4 showed a consistent inflection: solo devs stayed on free/Production tiers, but devs who moved to Priority did so because of a specific incident — a launch day where queue time cost them a demo, or a design review that stalled because a build was in queue.

Most didn't buy Priority preemptively. They bought it reactively, after one bad wall-clock moment. Once they had it, none of the 8 respondents on Priority downgraded.

The rough decision rule that emerged: if a stalled build has ever cost you a business moment (a meeting, a demo, a customer), Priority pays for itself the next month.

Conclusion: build velocity is a downstream metric

The most useful frame from these 30 conversations: build velocity is a downstream metric. What you actually care about is how much you're willing to iterate. Build velocity feeds into willingness to iterate; willingness to iterate feeds into product quality.

If you're thinking about migrating to EAS, or from EAS, or between EAS tiers, the question worth asking your team isn't "what's our build time?" — it's "when did we last hold a change because we didn't trust CI would let us ship it small?"

Answer that honestly and you know what to do next.

If you're building React Native apps and want to skip straight to a project that's already wired for this kind of fast iteration, RapidNative generates React Native + Expo apps you can preview and export.

How about you — when did you last hold a change because you didn't trust CI? Drop a comment.

Checkout UX in React Native: What 12 User Tests Taught Us About Payment Flow Design

Hugo Rus — Wed, 01 Jul 2026 11:55:06 +0000

We ran 12 moderated user tests on a React Native + Stripe checkout flow. Six users completed on the first try; six hit visible friction.
Double-taps happened because the payment sheet took 300–500ms to init on tap. Fix: init on the previous screen's mount.
Total mismatches (app showed $42, sheet showed $39) made users back out. Match totals to the cent.
Button copy matters: "Pay $42" beat "Buy Now" beat "Continue to Payment."
Users look right above the button in the last second before tapping — put price, item, and trust anchors there.

We ran 12 moderated user tests on a checkout flow in a React Native app last month. Same app, same product, same price. The task was simple: buy the thing.

Six of the twelve completed on the first try. Six had visible friction. This post is what we found and what we changed.

The setup

React Native + Expo + Stripe PaymentSheet. A physical iPhone 13 and Pixel 6a, five sessions per device plus two on an older Android. Screen recording and voice-over throughout. The button that opened the payment sheet was labeled "Continue to Payment" at the start of the study.

Finding 1 — the double-tap

Five of the twelve users tapped the payment button twice. Not deliberately — the first tap didn't visibly do anything for 300–500ms while the sheet initialized, so they tapped again thinking they'd missed. On slower devices, the second tap opened a second Stripe sheet on top of the first.

The fix is straightforward and undocumented: initialize the sheet on the previous screen's mount, not on the button press. When the user reaches the checkout screen, the sheet is already ready. The tap opens it instantly — no spinner, no double-tap.

React.useEffect(() => {
  initPaymentSheet({ paymentIntentClientSecret });
}, []);

Finding 2 — the total mismatch

Three of the twelve backed out at the payment sheet. The reason: our app showed $42, the Stripe sheet showed $39. The app was rendering with-tax; the sheet was showing pre-tax because we hadn't passed the tax breakdown. One user said out loud: "wait, is this the wrong item?"

The lesson: whatever total your app shows must match the sheet's total to the cent. Either pass the tax in the PaymentIntent, or show pre-tax on the checkout screen and let the sheet add tax. Never let the two disagree.

Finding 3 — button copy

We ran a mini A/B on the button that opens the sheet: "Continue to Payment" vs. "Buy Now" vs. "Pay $42." Six users saw each variant across the sessions.

Rough result: "Pay $42" converted best — specific, action-oriented, no ambiguity. "Buy Now" was next. "Continue to Payment" was the worst: the word "continue" made users expect another step, so they hesitated.

Finding 4 — where users look right before tapping

Eye-tracking would've been nice; we used the think-aloud protocol instead. Consistently, users glanced at the area immediately above the button in the last second before tapping. That's where they wanted the price, the item name, and any trust anchors (card logos, "Secured by Stripe").

Not at the top of the screen. Not in the header. Right above the button. Design that area like it's the last decision surface — because it is.

Finding 5 — the receipt matters

Half the users, once payment succeeded, immediately swiped to close the app and check their email for a receipt. If the receipt didn't arrive in the first 5 seconds, they came back to the app anxious.

We reduced this by showing a "Receipt sent to X" toast on the success screen, with the email address visible.

The checklist you can steal

Init PaymentSheet on mount, not on tap.
Match totals exactly between the app and the sheet.
Use action-specific button copy — "Pay $42" beats "Continue to Payment."
Put price, item, and trust anchors immediately above the payment button.
Show a "receipt sent to X" confirmation before the user swipes away.

None of these are surprising in retrospect. All of them showed up in user testing before we noticed them in code — which is the whole argument for testing checkout with real people before you ship it.

If you'd rather start from a checkout that already bakes these patterns in, RapidNative generates React Native + Stripe flows with the payment sheet, total handling, and success states wired up.

What's the worst checkout friction you've hit as a user? Drop a comment.

How We Got an LLM to Reliably Generate Theme-Aware React Native Apps

Hugo Rus — Tue, 30 Jun 2026 07:11:44 +0000

Asking an LLM to "generate a React Native screen with dark mode" gives you inconsistent results — useColorScheme on one screen, a dark: prefix on another, a hardcoded bg-white on a third.
The fix isn't a better prompt. It's moving theme switching out of the model's job and into the project scaffold.
Every generated app starts from a theme.ts (light + dark via NativeWind v4 vars()), a root ThemeProvider, and a tailwind.config.js binding semantic class names to CSS variables.
Five system-prompt rules keep the model writing className="bg-background" and nothing else.
You export a clean Expo project with no runtime dependency on us.

How We Got an LLM to Reliably Generate Theme-Aware React Native Apps

If you've ever asked an LLM to "generate a React Native screen with dark mode support," you know the result. Sometimes you get useColorScheme. Sometimes you get a dark: prefix. Sometimes you get a hardcoded bg-white. Sometimes you get all three in the same file.

This post is about how we built theme-aware UI as a property of every generated app in RapidNative — an AI mobile app builder — instead of leaving it as a per-prompt gamble. We'll cover the prompt rules, the scaffold the model writes into, and the architectural choices that made dark mode boring and predictable. (Which, in this context, is high praise.)

The honest version of the problem

For human developers, the standard dark mode recipe in React Native is well documented: call useColorScheme, branch on the result, persist the user's preference, tint the status bar with expo-status-bar. Books have been written.

For LLMs generating code, that recipe is a minefield:

The model has to remember the pattern on every generated screen.
It has to apply it consistently to components it's never seen together.
It has to handle native primitives (ActivityIndicator, RefreshControl, Switch) that take hex colors, not class names.
It has to not invent new variations of the pattern (which it loves to do).

In our early experiments, the failure mode was always the same: one screen looked perfect in dark mode, the next one looked unreadable, and the third one had bg-white hardcoded because the model decided that screen "needed to feel clean."

The structural fix: theme switching as a foundation, not a per-component decision

We stopped trying to make the model handle color scheme detection. Instead, we made every generated project start from a scaffold that includes:

A theme.ts file with two named exports — lightTheme and darkTheme — each declared via NativeWind v4's vars() helper, mapping semantic CSS variable names to RGB triplets.
A ThemeProvider.tsx that picks the right vars object and applies it to the root view.
A tailwind.config.js set up so class names like bg-background and text-foreground resolve to those CSS variables at runtime.

Now the model never writes color scheme logic. It writes <View className="bg-background"> and trusts the foundation to handle the switch.

The system prompt rules that make it stick

The hard part isn't designing the scaffold. It's getting the LLM to use it correctly every time. Our system prompt encodes five rules that, taken together, get us a near-100% hit rate on theme correctness across generated screens.

Rule 1: semantic classes only. No dark: prefix. No bracket values like bg-[#ffffff]. No hardcoded hex in className.

Rule 2: theme.ts is fill-in-the-blanks. The model can change RGB values; it cannot restructure the file, rename exports, or change variable keys. This invariant is what lets our editor parse it and our theme editor UI work.

Rule 3: ThemeProvider is off-limits. Specifically: never pass value={...} to it. LLMs love passing reasonable-looking props. This one would silently break theme switching, so we forbid it by name with the consequence spelled out.

Rule 4: inline hex only from theme.ts. When a native primitive needs a color prop, the model derives the hex from theme.ts's RGB values using an isDark ternary — never a literal.

Rule 5: don't add unrequested variables. Including useColorScheme. The model is told explicitly not to inject color scheme detection that the user didn't ask for, because the system handles it.

Each rule on its own is small. Together they collapse a huge surface area of failure modes into "the model writes semantic class names, full stop."

Deterministic brand palettes

Every project gets a unique palette derived from a hash of its project ID. We pick a brand hue and accent hue, then generate matched light and dark palettes via HSL-to-RGB conversion. The model receives a pre-composed theme.ts it's told to emit verbatim on the first generation, so the brand identity stays consistent as the project grows.

The two-mode palette is generated together, from the same hue, in the same color space. That's the trick to making dark mode feel like the same product as light mode instead of an afterthought.

The export

When you download a project, you get a clean Expo workspace with theme.ts, the provider, NativeWind configured, and every screen using semantic classes. No runtime dependency on us. It's a standard React Native + Expo project that happens to have well-organized theming because the AI was given strict rules about how to build it.

What I'd take from this for any AI-codegen project

If you're shipping an LLM-powered code generator, three things from this approach generalize:

Move correctness into the scaffold, not the prompt. Anything the foundation can enforce structurally is one less thing the model can mess up per call.
Forbid patterns by name with consequences. Don't say "use semantic classes." Say "no dark: prefix, no hex in className." The model responds to specific bans much better than positive guidelines.
Make file shape an invariant. If your post-processing tools (parsers, editors, watchers) depend on file structure, lock that structure in the prompt. The model will respect it if you're explicit.

Full deep-dive on the architecture (three theming layers, the brand-palette directive, the in-editor theme parser, the live preview, and what shows up in the export ZIP) is on our blog: How RapidNative Generates Theme-Aware React Native UIs.

What's the worst LLM-generated theming mess you've had to clean up? Drop a comment with what you're building.

A Freelance React Native Workflow That Cuts MVP Delivery From 4 Weeks to 1

Hugo Rus — Mon, 29 Jun 2026 13:22:57 +0000

A Freelance React Native Workflow That Cuts MVP Delivery From 4 Weeks to 1

If you freelance on React Native, your build time isn't where you think it is. It's not in component code — it's in the workflow loop around it: pre-kickoff scaffolding, Figma-to-real-app translation, scope-change re-quotes. This post walks through a freelance delivery workflow I've been running with an AI app builder (RapidNative) and the actual tradeoffs I've hit shipping client projects with it.

The starting state: where freelance React Native time actually goes

Real numbers from my last 12 client projects (solo, $80/h blended, 4-week MVPs):

Phase	Avg hours	What I was actually doing
Pre-kickoff scaffolding	18h	Expo init, navigation, theme, auth screens, basic state
Discovery + design alignment	14h	Figma walkthroughs, "what does this look like on a phone" debates
Initial screen build	35h	6–8 screens, basic CRUD, mock data
Revisions round 1	10h	Translating Figma feedback into code
Mid-project scope change	14h	Re-quoted, sometimes absorbed
API wiring + polish	18h	The actually interesting work
Total	~109h

The boring 70% is the first three rows. AI is genuinely good at those.

The workflow I run now

1. Pre-kickoff: paste the brief, get a working app

Before the kickoff call, I paste the client's brief into RapidNative. ~10 minutes later there's a working Expo project on a QR code. No npx create-expo-app, no theme tokens, no navigation wiring. The generated project includes Expo Router navigation, a basic design system, screens implied by the brief, and realistic mock data.

This is the step that costs me 18 hours on a traditional project. It now costs me 10 minutes plus a coffee.

2. Kickoff call: demo on the client's phone, iterate live

The QR code matters more than the build itself. The client scans, the app opens on their phone, they tap through their own app during the call. When they want a change — "this button should be green," "remove this onboarding screen" — I use the point-and-edit mode. Click the element, type the change, watch it update on their phone in real time.

This compresses what used to be a week of feedback loops into one call. The technical reason: feedback against a real interactive app is concrete. Feedback against Figma is theoretical.

3. Async iteration via team collaboration

Between calls, I invite the client into the project as a collaborator. They can comment on specific screens or drop their own prompts for small changes. I wake up to a punch list with screenshots attached to the specific screen.

If they're non-technical, point-and-edit is dangerous to give them write access on — but a comment-only role is fine.

4. Mid-project scope change: absorbed in an afternoon

The week-3 "can we add a referral flow?" used to cost me 14 hours of build + 2 hours of awkward emails. Now it's a prompt — "add a referral flow with a share button on the profile screen, a stats screen, and a redemption screen" — and an afternoon of polish. I usually absorb it. The math works because the cost is now hours, not days.

5. Export → VS Code → ship

When the prototype is signed off, I export to a real React Native + Expo repo and continue in VS Code:

Replace mock data with real API calls
Wire auth properly (the AI scaffolds the screens but I always rewrite the actual flow)
Add the custom business logic the brief mentioned but the AI guessed at
Run on a device, fix the inevitable native quirks
Submit to App Store / Google Play

The export is a normal Expo project. npx expo start runs it locally. No vendor lock-in.

What AI does well, what it doesn't

Well:

Scaffolding: navigation, theme, layouts, screens
Standard UI patterns: list/detail, forms, settings, onboarding
Stylistic iteration: "make this look like X"
Mock data and basic state management

Not well:

Payments (Stripe / RevenueCat / IAP) — always rewrite by hand
Custom auth flows with edge cases — scaffolds the screens, you write the actual flow
Real-time / WebSocket-heavy features
Anything with non-obvious business logic — the AI guesses, and the guess is usually wrong in subtle ways

The split is convenient: the "well" column is the part of freelance projects that's hardest to bill for. The "not well" column is the part you should be billing premium rates on anyway.

Practical tips after ~10 projects on this workflow

Export early. First day of the project, export the code and run it locally. Catches any environment issues before the demo.
Don't generate, then edit, then regenerate. Once you've started hand-editing in VS Code, treat the AI builder as a prototype tool, not a continued source of truth. Mixing both creates merge pain.
Use point-and-edit for visual changes, prompts for structural changes. Trying to do structural changes through point-and-edit produces inconsistent results.
For complex flows, scaffold them as separate small prompts, not one big prompt. Asking the AI to "build a complete e-commerce checkout with payment, shipping, tax, and confirmation" produces worse output than asking for each screen individually.
Keep a client-notes.md in the project root. AI builders don't preserve the "why" behind decisions; you do.

The economics question every freelancer asks

If a 4-week MVP becomes a 1-week sprint, do you cut your price 75%? No. You either:

Hold the price and shorten the timeline (clients love this)
Hold the price and run 3–4× more projects per year
Productize: "Mobile MVP in 7 days for $X" as a fixed offer

The speed itself is the value. Most clients pay for outcome, not hours.

Try it on your next brief

The fastest test: take your next client brief, paste it into RapidNative, and see what comes back in 10 minutes. If it's useful, you saved 2 days of scaffolding. If it's not, you spent 10 minutes.

I've found it's reliably useful for the 70% of freelance work that's the same on every project. Your mileage with the other 30% — the custom business logic that's why the client hired you — is up to you.

If you've already explored this space, the export pipeline post goes deeper on what the output actually looks like.

DEV Community: Hugo Rus

Deep-Linking in React Native Was Miserable. Expo Router Made It Accidental.

The 2022 baseline

The three things that used to break in prod

What Expo Router does differently

A support-team flow that just works

The one remaining gotcha

Takeaway

How to Build a Video Calling App with React Native and WebRTC

What is WebRTC and why use it in React Native?

The four pieces of every WebRTC call

Prerequisites

Step 1: Install and configure react-native-webrtc

Step 2: Build a minimal signaling server

Step 3: Capture local media

Step 4: Create the peer connection

Step 5: Exchange offer and answer

Step 6: Add the call controls

Common pitfalls (and how to avoid them)

Scaling beyond 1-to-1

Frequently asked questions

Does react-native-webrtc work with Expo Go?

How much does a WebRTC video calling app cost to run?

What's the difference between STUN and TURN?

Is WebRTC secure?

Wrapping up

How to Build a Project Management App Like Trello in 2026

How to Build a Project Management App Like Trello in 2026

The Trello data model (learn this first)

Must-have MVP features

The 2026 stack

The hard parts nobody warns you about

The AI shortcut

Concrete workflow

Traditional vs. AI-generated

What to build next

The bottom line

The React Native Accessibility Bugs Every App Ships With (And How to Fix Them)

The React Native Accessibility Bugs Every App Ships With (And How to Fix Them)

Bug 1: Icon-only buttons with no label

Bug 2: FlatList rows read as a wall of text

Bug 3: Modal backdrops that don't hide from VoiceOver

Bug 4: Loading spinners that announce silence

Bug 5: Custom toggle switches missing accessibilityRole="switch"

Bug 6: Dark mode contrast failures

Touch targets: WCAG 2.2 SC 2.5.8

The testing stack that actually catches this

The angle nobody talks about

What Indie React Native Devs Say About EAS 90 Days In

How we ran the survey

The trust-in-the-build finding that surprised us

What breaks the trust — and how devs recover

The Priority-tier decision point most indies hit

Conclusion: build velocity is a downstream metric

Checkout UX in React Native: What 12 User Tests Taught Us About Payment Flow Design

The setup

Finding 1 — the double-tap

Finding 2 — the total mismatch

Finding 3 — button copy

Finding 4 — where users look right before tapping

Finding 5 — the receipt matters

The checklist you can steal

How We Got an LLM to Reliably Generate Theme-Aware React Native Apps

How We Got an LLM to Reliably Generate Theme-Aware React Native Apps

The honest version of the problem

The structural fix: theme switching as a foundation, not a per-component decision

The system prompt rules that make it stick

Deterministic brand palettes

The export

What I'd take from this for any AI-codegen project

A Freelance React Native Workflow That Cuts MVP Delivery From 4 Weeks to 1

A Freelance React Native Workflow That Cuts MVP Delivery From 4 Weeks to 1

The starting state: where freelance React Native time actually goes

The workflow I run now

1. Pre-kickoff: paste the brief, get a working app

2. Kickoff call: demo on the client's phone, iterate live

3. Async iteration via team collaboration

4. Mid-project scope change: absorbed in an afternoon

5. Export → VS Code → ship

What AI does well, what it doesn't

Bug 5: Custom toggle switches missing `accessibilityRole="switch"`