DEV Community: Hugo Rus

React Native i18n in 2026: A Practical Expo Router Playbook

Hugo Rus — Mon, 03 Aug 2026 07:22:27 +0000

If your React Native app only speaks English, you're leaving most of the world's smartphone users on the table. Here's the modern stack for shipping a multilingual Expo app without three days of glue code.

The Stack

react-i18next for translation management (TypeScript-first, the default choice in the RN ecosystem)
expo-localization for device locale detection (or react-native-localize for bare RN)
Intl for dates, numbers, currencies (built into Hermes)
I18nManager for RTL layout flipping

Setup in 4 Steps

1. Install

npx expo install expo-localization
npm i i18next react-i18next

2. Translation files

locales/
  en.json
  es.json
  ar.json

{
  "welcome": "Welcome",
  "cart": {
    "itemCount_one": "{{count}} item",
    "itemCount_other": "{{count}} items"
  }
}

Use the ICU plural suffixes (_one, _other, _few, _many, _zero). Arabic has six plural forms. Get this right on day one.

3. Bootstrap

// i18n.ts
import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';
import * as Localization from 'expo-localization';
import en from './locales/en.json';
import es from './locales/es.json';
import ar from './locales/ar.json';

const deviceLocale = Localization.getLocales()[0]?.languageCode ?? 'en';

i18n.use(initReactI18next).init({
  compatibilityJSON: 'v4',
  resources: {
    en: { translation: en },
    es: { translation: es },
    ar: { translation: ar },
  },
  lng: deviceLocale,
  fallbackLng: 'en',
  interpolation: { escapeValue: false },
});

export default i18n;

Two production-important bits: compatibilityJSON: 'v4' for modern plural rules, and escapeValue: false because RN already escapes JSX.

4. Wire into Expo Router

// app/_layout.tsx
import { Stack } from 'expo-router';
import './i18n';

export default function RootLayout() {
  return <Stack />;
}

Then in any component:

import { useTranslation } from 'react-i18next';

const { t } = useTranslation();
<Text>{t('cart.itemCount', { count: 3 })}</Text>
// "3 items"

The Gotchas Nobody Warns You About

Never concatenate around t(). Word order changes across languages:

// ❌ Breaks in Japanese, German, Arabic
<Text>{t('hello')} {user.name}!</Text>

// ✅ Whole sentence is one key
<Text>{t('greeting', { name: user.name })}</Text>

RTL doesn't flip everything. Flexbox auto-flips, but you'll need to fix:

left/right, use start/end
Directional icons, wrap in transform: [{ scaleX: -1 }] when I18nManager.isRTL
Hardcoded textAlign

Hardcoded strings in third-party UI kits. Buttons in libraries like RN Elements ship English defaults. Override or pick i18n-aware libs.

Push notifications aren't localized by the phone. Your backend has to send the localized copy or use OS-level notification categories.

Formatting

Never string-concat dates or currencies. Use Intl:

new Intl.DateTimeFormat(i18n.language, { dateStyle: 'medium' }).format(new Date());
new Intl.NumberFormat(i18n.language, { style: 'currency', currency: 'USD' }).format(29.99);

Add @formatjs/intl-datetimeformat polyfills if you need older Android or less common locales.

Testing Discipline

Turn on saveMissing in dev. react-i18next logs every missing key. Fail CI on any.
Pseudo-localize with en-XA. Surfaces hardcoded strings and 30 to 40% longer text for layout stress-tests.
Snapshot per locale. French, German, and Arabic snapshots catch layout regressions.

Shortcut

If you're starting fresh, RapidNative generates the whole i18n scaffold, provider, layout wiring, translation files, RTL flags, from a natural-language prompt. You get the same setup you'd write by hand, in about 30 seconds.

Otherwise: ship it. It's 2 to 3 days of setup and it opens the app to a much larger share of the market.

How to Build a Pet Care App with React Native (2026)

Hugo Rus — Fri, 31 Jul 2026 10:28:00 +0000

Pet care is a well-scoped React Native project: bounded features, cross-platform demand, forgiving users.
MVP is five features: pet profile, health record, appointment tracker, feeding log, push notifications.
Stack: Expo SDK 52+, TypeScript, Expo Router, Supabase, NativeWind, FlashList.
Store UTC in the database, render local with date-fns-tz, or your 8 AM reminder fires at 3 AM after a flight.
Store next_due_at per row. Rabies schedules differ by jurisdiction.
Realistic timeline: 4 to 6 weeks solo if you know React Native, 10 to 12 if you are learning the stack alongside.

The pet care market keeps growing, and mobile apps are eating an increasing share of it: vet booking, vaccination reminders, feeding schedules. If you've been looking for a well-scoped React Native project to ship, a pet care app is genuinely one of the best options. Bounded feature set, cross-platform relevance, and a user base that's forgiving of a rough v1 as long as it solves a real problem.

Here's the practical build guide, from stack decisions through App Store submission.

Why React Native fits pet care apps

Pet care apps need cross-platform reach (pet owners split evenly between iOS and Android), rich UI (photo-heavy profiles), and native features like push notifications and camera. That is the exact sweet spot for React Native with Expo. They also have a naturally scoped MVP: pet profiles, health records, appointments, reminders. You can ship in weeks, not months.

The MVP feature set

Ship these five features first. Adding a sixth before nailing edge cases (multi-species schedules, deleted pets, timezone-sensitive reminders) is the fastest way to never launch.

Pet profile. Name, species, breed, DOB, weight, photo, microchip ID
Health record. Vaccinations with next-due dates, medications, allergies
Appointment tracker. Vet visits, grooming, boarding with reminders
Feeding log. Food type, portion, schedule
Push notifications. Vaccinations, medications, appointments

The stack

React Native with Expo SDK 52+
TypeScript (non-negotiable for anything you ship)
Expo Router for file-based routing
Supabase for hosted Postgres + auth
NativeWind for Tailwind-style styling
expo-notifications for local push
FlashList (not FlatList) for photo-heavy timelines

Scaffold it

npx create-expo-app@latest pet-care-app --template
# choose "Navigation (TypeScript)"
cd pet-care-app
npx expo install expo-notifications expo-image-picker expo-file-system
npm install nativewind zustand @supabase/supabase-js date-fns

Route structure

app/
  (tabs)/
    _layout.tsx           # Pets | Schedule | Records | Settings
    index.tsx             # pet list
    schedule.tsx
    records.tsx
    settings.tsx
  pet/
    [id].tsx
    [id]/health.tsx
    [id]/appointments.tsx
  appointment/new.tsx
  vaccination/new.tsx

Decide the route tree before writing screens. Nesting everything under (tabs)/pets/[id]/... will bite you when you need to push a full-screen modal.

Data model

Four entities cover the MVP:

Entity	Key fields
`pets`	id, owner_id, name, species, breed, date_of_birth, weight_kg, photo_url
`vaccinations`	id, pet_id, name, administered_at, next_due_at
`appointments`	id, pet_id, type, starts_at, location, notes
`feedings`	id, pet_id, food_name, portion_grams, scheduled_at, given

Two things matter more than you'd expect:

Store next_due_at on the row. Rabies is annual in some jurisdictions, triennial in others. Don't hardcode.
Store UTC in the DB, render local with date-fns-tz. Get this wrong and a reminder set for 8 AM triggers at 3 AM after a flight.

Push notifications the right way

The single feature that separates useful pet apps from forgettable ones:

import * as Notifications from 'expo-notifications';

await Notifications.scheduleNotificationAsync({
  content: {
    title: `${pet.name}'s ${vaccination.name} is due`,
    body: 'Book a vet appointment to stay on schedule.',
    data: { petId: pet.id, vaccinationId: vaccination.id },
  },
  trigger: { date: nextDueAt },
});

Two rules:

Request permissions gracefully. Show a "why" screen before the OS prompt.
Reschedule on AppState.change when the app foregrounds. Timezone and DST drift is real.

The 4 to 6 week problem

Honest timeline for a solo developer: 4 to 6 weeks for a shippable MVP if you're comfortable with React Native. 10 to 12 weeks if you're learning Expo, TypeScript, and Supabase alongside.

Most of that time is boilerplate. Layout, navigation wiring, spacing, empty states, forms. None of it is the interesting part of building a pet care app.

The AI-first shortcut

Tools like RapidNative generate a working React Native + Expo codebase from a natural-language description. The workflow:

Describe the app: "A pet care app with pet profiles, vaccination tracking, appointment reminders, and a schedule tab across all pets."
Get a working app in a few minutes.
Scan a QR code, preview on your real phone.
Click any element to describe changes ("make these cards bigger, add a soft green tint when a task is done").
Export the full React Native + Expo source, or publish directly to the stores.

Same output, a real React Native app, different path. Worth trying on the boring 80% of the build so you can spend time on the interesting 20%.

App Store gotchas specific to pet apps

Three things reviewers catch:

Health claims. Track vaccinations and meds without positioning as a medical device. Be explicit in the description.
Background location. If you add walk tracking, justify the permission concretely: "To log your dog's walk route while your phone is in your pocket."
Screenshots. Empty-state screenshots underperform dramatically. Show real pets with real data.

Use eas submit. It handles both stores and eliminates most rejection loops.

Wrapping up

The features are the easy part. Reliable reminders, offline-first data, and fast photo handling are what separate 5-star pet apps from abandoned ones. Nail those, ship a focused MVP, and let owners tell you what's missing.

The manual scaffold above should get you to a working v1 in about a month.

If you're building something in this space, drop a comment with what you're working on. Curious whether anyone has solved multi-pet, multi-timezone reminders cleanly, because that one still feels unsolved to me.

The 4 Notification Categories Users Actually Whitelist (Based on 60 App Interviews)

Hugo Rus — Wed, 29 Jul 2026 05:06:49 +0000

Users whitelist only four notification categories: someone they know did something involving them, a thing they explicitly set up, a transaction they're expecting, and a time-critical alert from a system they trust.
Everything else — feature announcements, recommendations, streaks, re-engagement, promos — gets muted within two weeks.
Users pattern-match to category, not copy. Better push copy optimizes the wrong variable.
Per-category in-app consent (not one system prompt) moved opt-in from 41% to 73% and dropped 30-day mute rate from 34% to 9% in one test.

Over the last six weeks I interviewed 60 people about their phone's notification settings. I asked each to open Settings → Notifications, scroll through every app, and tell me the story behind why each one was on, off, or set to silent delivery.

The pattern was sharper than I expected. Users don't allow or block push app-by-app. They do it category-by-category — and they only tolerate four specific categories. Everything else gets muted within two weeks.

The four categories users whitelist

Across 60 interviews, people named the same four types of notification as ones they actively want:

1. Someone I know did something involving me. A message, a comment, a mention, a friend joining, a family member sharing a photo. Nearly everyone said they never mute these.

2. A thing I explicitly set up. Alarm, reminder, calendar event, medication, workout time. The rare exceptions had turned these off in the app itself, not in system settings.

3. A transaction I'm expecting. Delivery updates, ride arrival, payment confirmation, booking status. Widely kept on, though several used silent delivery to soften the interruption.

4. A time-critical alert from a system I trust. Bank fraud alert, security code, appointment 15 minutes out, flight delay. Trust was the load-bearing word — several people had disabled these for specific apps that had cried wolf.

Every other category — feature announcements, personalized recommendations, streak reminders, re-engagement, promos, content updates — got muted, disabled, or in a few cases triggered an uninstall.

Why category beats copy

The standard growth advice is "write better push copy." A/B test the emoji, tighten the CTA, personalize with the user's name.

That optimizes the wrong variable.

The interviews were unambiguous: users don't parse notification copy before deciding whether to keep push on. They pattern-match to the category. Once your app has sent two notifications from a category they don't want, they mute the whole app — no matter how good the copy was.

So the design question isn't "how do we write a compelling notification?" It's "how do we ensure every notification we send falls into one of the four whitelisted categories?"

The consent conversation to have in-app

The iOS system dialog is a blunt instrument: one yes/no for all future notifications. What users actually want is category-level consent — which iOS supports through notification categories, but almost no app uses well.

The pattern I now recommend:

import * as Notifications from 'expo-notifications';

type Category = 'social' | 'reminders' | 'transactions' | 'security';

async function setupNotificationCategories() {
  await Notifications.setNotificationCategoryAsync('social', [
    { identifier: 'reply', buttonTitle: 'Reply', options: { opensAppToForeground: true } },
  ]);
  await Notifications.setNotificationCategoryAsync('reminders', []);
  await Notifications.setNotificationCategoryAsync('transactions', []);
  await Notifications.setNotificationCategoryAsync('security', []);
}

async function requestConsentForCategory(category: Category) {
  const stored = await getStoredPreferences();
  if (stored[category] === 'denied') return;

  // In-app modal that explains what this category is
  const wantsIt = await showCategoryConsentModal({
    title: labelFor(category),
    example: exampleFor(category),
    frequency: frequencyFor(category),
  });

  await savePreference(category, wantsIt ? 'granted' : 'denied');

  if (wantsIt) {
    const { status } = await Notifications.getPermissionsAsync();
    if (status !== 'granted') {
      await Notifications.requestPermissionsAsync();
    }
  }
}

The in-app modal does the real work. It shows a concrete example of the notification the user would receive, states roughly how often ("a few times per week," not "occasionally"), and lets them opt in per category rather than for everything at once.

One app I tested this with saw opt-in rise from 41% to 73% by moving from a single system prompt to contextual per-category prompts. More importantly, 30-day mute rate dropped from 34% to 9%.

The signal every PM misses: silent delivery

iOS's "Deliver Quietly" lets users keep receiving your notifications but hide them from the lock screen and Notification Center. It's a soft mute — chosen when someone wants the app's data but not the interruption.

Most PMs don't track it, because iOS doesn't report it. But you can infer it: if a user's open rate on pushes drops to near-zero while their app opens stay steady, they've likely moved you to Deliver Quietly.

Segment those users. They're one bad broadcast away from a full mute or uninstall. For them, cut sends by 60–80% and fire only category 1 and 3 notifications (people-related and transactional). I've seen apps recover full-delivery status this way for a meaningful share of the quietly-delivered segment.

Redesign around user-declared intent

The biggest shift from these interviews: the notifications users keep are tied to intent they expressed inside the product. They set the reminder. They ordered the food. They followed the person. They asked the bank to alert on fraud.

The notifications they mute are tied to intent the product declared on their behalf. "We think you'd love this new feature." "We noticed you haven't opened us in a week." "Here's a personalized recommendation."

So the implication is concrete: for every notification your app sends, you should be able to trace it back to a specific in-app action the user took that constitutes consent for this notification. If you can't, it belongs in the mute pile. If you can, you're building the trust that keeps push on for the lifetime of that user.

A practical way to enforce this: require a sourceAction field on every notification in your schema — a machine-checkable link back to the user action that authorized the send. It's an annoying constraint at first. Then it becomes the reason your app is still on the lock screen six months in, when competitors have been muted.

Run the interviews yourself. Ten users, thirty minutes each. You'll come back with a notification strategy your PM would never sign off on — and your users will actually welcome.

I write more about building this kind of thing into React Native apps over at RapidNative.

Which of the four categories does your app mostly send? And have you ever caught yourself sending from the mute pile?

Introducing tinbase: A Docker-Free, Supabase-Compatible Backend on Real Postgres

Hugo Rus — Mon, 27 Jul 2026 13:30:19 +0000

tinbase is an open-source (MIT) backend that speaks the Supabase API but runs as a single process on real Postgres 17 — no Docker, no container orchestration.
It's supabase-js compatible, so a lot of existing Supabase client code points at it unchanged.
Because it drops the container requirement, it runs where the full stack can't: lightweight CI, low-spec machines, and in the browser.
Built by Sanket Sahu. MIT-licensed and open to contributions.

If you've run Supabase locally, you know the ritual: install Docker, start the stack, wait for Postgres, GoTrue, PostgREST, Realtime, and Storage to spin up, and watch your laptop fans kick in.

For a lot of workflows — quick local iteration, CI, teaching, browser sandboxes — that's more machinery than the task needs.

tinbase is a different bet: the Supabase API surface, on real Postgres, as one process.

What it actually is

tinbase is an open-source backend that provides Supabase-compatible APIs while running as a single process on PostgreSQL 17, with no Docker requirement.

The design goals in one line each:

Real Postgres, not a shim. It runs on Postgres 17, so SQL behavior matches production. No SQLite dialect gaps to trip over when you deploy.
supabase-js compatible. Client code written against Supabase can, in many cases, point at a tinbase instance without changes.
Single process, no Docker. One thing to start. No container stack to orchestrate or resource-tune.
Runs in the browser. Because it sheds the container requirement, tinbase can run in environments a Docker stack simply can't — including in-browser sandboxes.
MIT-licensed. Fully open source. Inspect it, self-host it, contribute to it.

Why single-process, Docker-free matters

The architecture isn't the point — what it unlocks is.

Faster local loops. A single process starts in a fraction of the time an orchestrated multi-container stack takes. The edit-run-test cycle gets shorter.

Cheaper CI. CI runners are memory-constrained and billed by the minute. Spinning up one Postgres-backed process per job is dramatically lighter than booting the full Supabase container set.

Teaching and demos that just run. Workshops and tutorials can hand out a real backend without first walking every participant through installing and configuring Docker. That alone removes the most common "it doesn't work on my machine" failure at the start of a session.

Browser and constrained environments. In-browser IDEs and low-spec machines that can't host the full container stack can still run a real Supabase-compatible backend.

How it compares

If you want a lighter local Supabase, you've probably weighed these:

Option	Real Postgres?	Docker-free?	Supabase-compatible?
Full Supabase CLI stack	Yes	No	Yes
SQLite-based shim	No	Yes	Partial
Hand-rolled Postgres + PostgREST	Yes	Depends	You wire it
tinbase	Yes	Yes	Yes

The gap tinbase fills: the realism of Postgres-backed Supabase, without the Docker overhead, and without dropping to a non-Postgres engine that diverges from production.

Who it's for

Developers who want a fast local Supabase without the container tax
Teams trying to cut CI time and cost
Educators and content authors who need a reproducible backend in a tutorial
Anyone building in a browser sandbox or on constrained hardware

Getting started

tinbase is single-process and Docker-free, so setup is meant to be minimal: install, start the process, and point a supabase-js client at it.

The full documentation and source are at tinbase.dev.

If you've been avoiding local Supabase because of the Docker overhead, this is worth a look — especially for CI and teaching setups.

Running Supabase locally today? What's your current setup — full CLI stack, a shim, or something hand-rolled? Curious what the pain points have been.

How to Prototype a Mobile App in Hours (Wireframe React Native)

Hugo Rus — Fri, 24 Jul 2026 09:34:12 +0000

The wireframe → clickable prototype → coded prototype pipeline collapses into a single step.
Four phases: capture the wireframe (20–40 min), generate the base app (2–3 min), iterate visually (1–2 hrs), ship to real hardware (30 sec).
Traditional first testable build: 2–4 weeks. AI-native: 1–3 hours. Most of the compression is eliminating role handoffs.
Best wireframe input isn't a sketch — it's a competitor screenshot, or a precise written paragraph.

The three artifacts most guides conflate

One clarification that trips up most prototyping conversations:

Wireframe — static layout. No interactivity.
Clickable prototype — hotspots wired between static screens (Figma, InVision). Can't run real logic.
Working prototype — real React Native code, real navigation, real state, installable on device via QR.
Production app — the working prototype plus backend, auth, analytics, store listing.

Most "prototyping" tutorials stop at rung two. The interesting compression is going from rung one straight to rung three.

The four-phase workflow

1. Capture the wireframe (20–40 min)

Any medium that captures screens, elements, and tap behaviour works: hand sketch, whiteboard photo, Excalidraw, Figma frame, competitor screenshot, or a written paragraph.

Treat the wireframe as disposable. Its job is to be input to the generator, not a deliverable.

2. Generate the base app (2–3 min)

Feed the wireframe plus a one-paragraph description into an AI mobile app builder. You get back a live React Native + Expo app with routing, styled screens, and stubbed data.

It's about 70% right — good enough to iterate against.

3. Iterate visually (1–2 hours)

The base app has ~30% wrong. Point-and-edit is the accelerator: click any element in the live preview, describe the change ("make cards rounder, move price to top-right"), and the underlying code updates. Product teams typically do 30–50 micro-iterations in the first hour.

Two rules for this phase:

Don't accept the first version of any screen.
Don't over-specify visuals before validating flow. Colours are cheap; navigation is expensive.

4. Ship to real hardware (30 sec)

Scan a QR code, install into a preview client on iPhone or Android, and use the app on real hardware.

This is where the bugs Figma can't show you actually surface: thumb-tap zones, safe areas, keyboard behaviour, dark mode.

Traditional vs. AI-native

For a 5-screen MVP:

Phase	Traditional	AI-native
Wireframing	4–8 hours	20–40 min
Hi-fi design	2–5 days	Skipped
Clickable prototype	4–8 hours	Skipped
Coded prototype	1–3 weeks	2–3 min
Iteration cycle	1–3 days per round	30 sec to 2 min
Real-device install	4–8 hours (Xcode/TestFlight)	30 sec (QR)
First testable build	2–4 weeks	1–3 hours

The compression is mostly the elimination of role handoffs. When one operator drives the whole loop, the "waiting for someone else" hours evaporate.

Which wireframe inputs convert best

Ranked worst → best by signal-to-noise:

Napkin sketch photo — works, but expect nuance loss. Pair it with a written description.
Whiteboard photo — better. Whiteboards force larger, more legible drawings.
Excalidraw / FigJam — excellent. Digital media produce clean shapes and labels.
Figma frame — very good. Layout and hierarchy transfer cleanly.
Written PRD paragraph — underrated. A precise three-to-four sentence description often beats a bad sketch.
Competitor screenshot — highest signal. It's already a mobile UI, so layout, typography, and interaction all transfer.

Hour by hour: a food-delivery MVP in one afternoon

Two-person team, five screens (restaurant list → detail → cart → checkout → order tracking):

0:00–0:30 — Whiteboard sketch, phone photo.
0:30–0:38 — Upload plus a one-paragraph description. Base app generated.
0:38–1:20 — First iteration pass. Point-and-edit, roughly 40 changes.
1:20–1:35 — QR install on both team phones. Two nav bugs surface; fixed in 3 minutes.
1:35–2:20 — Send the QR to three test users, collect feedback in a shared doc.
2:20–3:15 — Second iteration pass. Address the top ten UX notes.
3:15–3:30 — Publish a shareable preview URL, drop it in Slack.

Three and a half hours end to end, iOS and Android, on real phones.

When not to use this workflow

The AI loop isn't universal. Stay traditional when:

Novel interaction patterns with no precedent. Generators pattern-match; no pattern means no output quality.
Regulated industries (medical, aviation, financial trading) that need documented decision trails.
Pixel-perfect exec-review demos with no budget for a "70% then iterate" opening state.

For the other 90% — CRUD apps, marketplaces, social, dashboards, internal tools — the compressed loop wins on speed, iteration count, and cost.

If you want to run the loop end to end, RapidNative does the sketch/prompt/screenshot → React Native + Expo → QR-preview pipeline in one editor.

What's your current wireframe-to-code gap? Curious whether the competitor-screenshot trick works as well for others as it has for me.

Recruiting 12 Real Testers for Your Google Play Closed Test (Without Buying Them)

Hugo Rus — Wed, 22 Jul 2026 11:02:33 +0000

Buying testers fails three ways: Play's fraud detection flags dormant accounts, bought testers never open the app (so engagement doesn't count), and you're dependent on a third party to satisfy a store requirement.
Three source pools that work: your existing audience (highest quality), community trades on r/androiddev and r/indiedev (fastest), and your personal network (last resort).
A warm-list invite converts 40–50%. Anonymous forums convert 5–10% — which is why you need multiple pools.
Play watches for meaningful engagement, not just opt-ins. Four touches over 14 days keeps testers active.

You need 12 opted-in testers for 14 days before Google Play will let you ship. Buying them looks like the shortcut.

It usually isn't. Play's ML is good at spotting bought accounts, and it will silently reset your 14-day counter.

Here's how to recruit 12 real humans in 3–4 days instead.

Why paid services fail

The tester-service business exists, and some of it works. Most of it has three failure modes:

Play's fraud detection flags dormant or newly created accounts. Your test "has 12 testers" but Play doesn't count them.
The testers opt in and never open the app. The engagement signal doesn't register.
You're now dependent on a third party to satisfy a store requirement. If they turn shady, your launch is stuck.

And even when it works, you've spent $50–200 on 12 accounts that will never use your app again. You had to do the harder work anyway — you just paid extra for the privilege.

The three source pools

1. Your existing audience (highest quality)

Newsletter subscribers, followers, Discord or Slack members. Even 200 subscribers converts to 10–15 testers with a good ask.

If you don't have this: start building one on day one of your next project. This requirement is a recurring tax, not a one-off.

2. Community trades (fastest)

r/androiddev — weekly beta-swap threads
r/indiedev — weekly "test my app" threads
Indie Hackers — milestones section
Discord communities in your product's category (game dev, productivity, etc.)

The trade is simple: "I'll test your app, you test mine." Both parties get closer to their 12, and communities enforce reciprocity so quality stays high.

3. Personal network plus amplification (last resort)

Friends, colleagues, family — then their networks via a "know anyone with an Android who'd help?" broadcast. This usually gets you the last three or four you need.

The invite template

Subject: Would you spend 5 minutes to help me launch my app?

Hey [name],

I'm launching [app name] on Android next month. Google now requires 12 testers for 14 days before I can ship publicly.

If you have an Android phone and 5 minutes, you'd be helping me a lot by:

Clicking this link: [tester opt-in URL]

Installing when the app appears in your Play Store

Opening it a couple of times over the next 2 weeks

That's the whole ask. You'll get free access to the paid version as a thank you.

[your name]

This converts 40–50% on a warm list. Anonymous forums convert 5–10% — which is exactly why you need more than one pool.

Keeping them engaged for 14 days

Play watches for meaningful engagement. If your 12 testers opt in and never open the app, the requirement isn't satisfied.

Day 1: Welcome message with "here's what to try" (two or three specific flows).
Day 5: A genuine "what's confusing so far?" ask. This gets you feedback and another session.
Day 10: Preview of what's shipping in the next update. Another reason to open.
Day 14: Thank you, plus "the app goes to production tomorrow."

Four touches, each with real value. Not spam.

Turning testers into first users

Your 12 testers just spent 14 days with your app. That's the highest-quality feedback pool you will ever have. Before the closed test ends:

Send a proper survey. Not "rate 1–5." Ask: "What almost stopped you from using this?" and "What would you tell a friend it does?"
Ask for a testimonial, with permission to quote.
Ask whether they'd upgrade to paid at launch. Their answer is your first real customer signal.

The reframe

You started this hunting 12 accounts to satisfy Google. You finish with 12 engaged real users, genuine feedback, a few testimonials, and possibly your first paying customers.

The Play requirement is annoying. The discipline it forces is actually a launch playbook.

If you're stuck at "have the app, need the testers," letsdeploy.it handles the release side so you can focus on recruiting. The 12 humans still have to come from you.

How did you find your 12? I'm curious which pool actually worked — the swap threads or the personal network.

7 Things That Break When You Convert a Web App to React Native

Hugo Rus — Wed, 22 Jul 2026 09:51:38 +0000

There is no div, no span, and no cascading CSS. Every layout primitive changes.
localStorage, window, document, and most browser APIs simply don't exist.
flexDirection defaults to column, not row. This one silently breaks every layout you wrote.
Routing, image handling, forms, and scrolling all need native equivalents.
None of it is hard individually. It's the volume that kills weekend projects.

AI web app builders got very good very fast. You can describe an app to Lovable, v0, or Bolt and have a working web product the same afternoon.

Then you try to put it on the App Store, and you discover the thing nobody mentions: a web app and a native app share a language, not a platform. They both run JavaScript. Almost nothing else transfers.

I've done this conversion enough times to know exactly where it hurts. Here are the seven things that break, in roughly the order you'll hit them.

1. Every HTML element is gone

There is no div. No span. No p, h1, button, ul, or img.

React Native has its own primitives, and the mapping isn't one-to-one:

// Web
<div className="card">
  <h2>Title</h2>
  <p>Body text</p>
  <img src={url} />
</div>

// React Native
<View style={styles.card}>
  <Text style={styles.title}>Title</Text>
  <Text>Body text</Text>
  <Image source={{ uri: url }} />
</View>

The important gotcha: all text must be wrapped in <Text>. A bare string inside a <View> throws. On web you can drop text anywhere; here it's a hard error, and it's the single most common first crash.

2. CSS doesn't cascade — and half of it doesn't exist

React Native uses a JavaScript style object, not a stylesheet. That means:

No cascade. A style on a parent doesn't inherit down to children. Set fontSize on a View and the Text inside ignores it.
No selectors. No classes, no descendants, no :hover, no media queries.
No units. Numbers are density-independent pixels. padding: 16, not padding: '16px'.

const styles = StyleSheet.create({
  card: {
    padding: 16,
    borderRadius: 12,
    backgroundColor: '#fff',
  },
});

Also missing: float, grid, position: fixed, and most of the box model shorthand you're used to. Flexbox is the layout system — essentially the only one.

3. `flexDirection` defaults to `column`

This is the one that quietly wrecks everything.

On the web, display: flex defaults to flex-direction: row. In React Native, every View is already flex, and the default direction is column.

So every horizontal row you built on the web stacks vertically after the port, and you won't get an error — just a layout that looks wrong everywhere at once.

// You have to be explicit
<View style={{ flexDirection: 'row', alignItems: 'center' }}>

Budget an afternoon just for this.

4. Browser APIs don't exist

No window. No document. No localStorage. No fetch cookies, no DOM measurement, no alert().

The replacements:

Web	React Native
`localStorage`	`AsyncStorage` (or `expo-secure-store` for anything sensitive)
`document.querySelector`	refs
`window.location`	Expo Router / React Navigation
`alert()`	`Alert.alert()` from `react-native`
CSS media queries	`useWindowDimensions()`

fetch does survive, which is a small mercy — your API layer mostly ports as-is.

5. Routing is a different model

URL-based routing doesn't exist natively. There's no address bar and no history object.

Expo Router gets you closest to a web mental model — it's file-based, so app/profile/[id].tsx maps to /profile/42 — but you still have to think in stacks and tabs rather than pages. Back isn't "previous URL," it's "pop the stack."

Deep links also need real configuration on both platforms (URL schemes, Universal Links on iOS, App Links on Android). That's a genuine chunk of work with no web equivalent.

6. Scrolling and lists are explicit

On the web, content overflows and the browser gives you a scrollbar for free. In React Native, nothing scrolls unless you say so.

<ScrollView>{/* short content */}</ScrollView>

<FlatList
  data={items}
  keyExtractor={(item) => item.id}
  renderItem={({ item }) => <Row item={item} />}
/>

And use FlatList (or FlashList) for anything long — ScrollView renders every child at once and will tank your frame rate on a list of 500 items.

7. Forms and keyboards need real work

<input> becomes <TextInput>, and it needs configuration the browser handled implicitly: keyboardType, autoCapitalize, autoComplete, secureTextEntry, returnKeyType.

Then there's the keyboard itself. On mobile it physically covers the bottom of the screen, so your submit button disappears behind it unless you wrap the form in KeyboardAvoidingView with different behavior values per platform.

There is no web equivalent to this problem, and it catches everyone once.

What this actually adds up to

Individually, none of these are hard. A competent React dev can work through any one of them in an hour.

The problem is that there are seven of them, and they compound — plus certificates, provisioning profiles, screenshots at five device sizes, a privacy nutrition label, and a reviewer who might say no anyway.

That's the honest reason so many AI-built web apps never reach a store. The build was a weekend. The port and the submission are a different project entirely.

If you'd rather not do that project, RapidNative converts Lovable apps into real React Native + Expo builds and handles the full App Store and Play Store submission — signing, screenshots, metadata included. You get the source code and keep ownership of it, and if your app uses Supabase, the native build points at the same project with no migration.

Which of these seven got you first? For me it was flexDirection — I spent two hours convinced my styles weren't applying at all.

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.

DEV Community: Hugo Rus

React Native i18n in 2026: A Practical Expo Router Playbook

The Stack

Setup in 4 Steps

1. Install

2. Translation files

3. Bootstrap

4. Wire into Expo Router

The Gotchas Nobody Warns You About

Formatting

Testing Discipline

Shortcut

How to Build a Pet Care App with React Native (2026)

Why React Native fits pet care apps

The MVP feature set

The stack

Scaffold it

Route structure

Data model

Push notifications the right way

The 4 to 6 week problem

The AI-first shortcut

App Store gotchas specific to pet apps

Wrapping up

The 4 Notification Categories Users Actually Whitelist (Based on 60 App Interviews)

The four categories users whitelist

Why category beats copy

The consent conversation to have in-app

The signal every PM misses: silent delivery

Redesign around user-declared intent

Introducing tinbase: A Docker-Free, Supabase-Compatible Backend on Real Postgres

What it actually is

Why single-process, Docker-free matters

How it compares

Who it's for

Getting started

How to Prototype a Mobile App in Hours (Wireframe React Native)

The three artifacts most guides conflate

The four-phase workflow

1. Capture the wireframe (20–40 min)

2. Generate the base app (2–3 min)

3. Iterate visually (1–2 hours)

4. Ship to real hardware (30 sec)

Traditional vs. AI-native

Which wireframe inputs convert best

Hour by hour: a food-delivery MVP in one afternoon

When not to use this workflow

Recruiting 12 Real Testers for Your Google Play Closed Test (Without Buying Them)

Why paid services fail

The three source pools

1. Your existing audience (highest quality)

2. Community trades (fastest)

3. Personal network plus amplification (last resort)

The invite template

Keeping them engaged for 14 days

Turning testers into first users

The reframe

7 Things That Break When You Convert a Web App to React Native

1. Every HTML element is gone

2. CSS doesn't cascade — and half of it doesn't exist

3. flexDirection defaults to column

4. Browser APIs don't exist

5. Routing is a different model

6. Scrolling and lists are explicit

7. Forms and keyboards need real work

What this actually adds up to

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

3. `flexDirection` defaults to `column`

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