I spent three weekends building the same app twice. Not as an experiment — I had a real decision to make. We're adding a mobile companion to one of our internal tools at work, a task management system that runs on Spring Boot microservices. My team has touched Dart before; I'm more comfortable with JavaScript. Neither of us had shipped serious mobile work in the last two years. The only honest way to pick a stack was to build something real in both frameworks and compare what I found.
The app I built isn't a toy. It pulls tasks from a REST API, caches them locally with SQLite, fires scheduled push notifications when deadlines approach, and has smooth list animations on a bottom-nav layout with three tabs. Simple enough to build in a weekend. Complex enough to expose real differences between the two frameworks.
Here's what I found — including a result that surprised me.
The App
Before comparing, let me be specific about what I built. Both versions:
- Fetch tasks from a paginated REST endpoint with auth headers
- Cache responses locally using SQLite
- Support optimistic updates when marking a task complete
- Schedule local push notifications 1 hour before each task's due time
- Use a bottom navigation bar with three tabs
This isn't production code — it's a controlled comparison. Both apps hit the same mock API running on my MacBook. Same UI design, same feature set, different frameworks.
Setup and Developer Experience
Flutter's setup is more involved upfront. You run flutter doctor, chase down Android SDK versions, configure Xcode command-line tools. On a clean Mac it took me about 45 minutes to get a green build on both simulators. The error messages are usually specific enough to guide you, but it's mechanical work.
React Native with Expo took 15 minutes. npx create-expo-app, pick a template, run npx expo start, scan the QR code. Done. The friction delta is real, especially if you're onboarding a team that's new to mobile development.
The catch: Expo's managed workflow works brilliantly until you need a native module that isn't in Expo's SDK. Then you eject, and you're roughly back to the same complexity as a bare React Native setup. For this test app, I stayed in managed Expo and hit no walls.
Writing UI Code
This is where the frameworks feel most different day-to-day.
Flutter uses widgets — everything is a widget, composable and explicit. Here's the task list item:
class TaskTile extends StatelessWidget {
final Task task;
final VoidCallback onComplete;
const TaskTile({super.key, required this.task, required this.onComplete});
@override
Widget build(BuildContext context) {
return ListTile(
title: Text(
task.title,
style: task.completed
? const TextStyle(decoration: TextDecoration.lineThrough)
: null,
),
subtitle: Text(task.dueAt.toLocal().toString().substring(0, 16)),
trailing: task.completed
? const Icon(Icons.check_circle, color: Colors.green)
: IconButton(
icon: const Icon(Icons.radio_button_unchecked),
onPressed: onComplete,
),
);
}
}
React Native with TypeScript:
type TaskTileProps = {
task: Task;
onComplete: () => void;
};
export function TaskTile({ task, onComplete }: TaskTileProps) {
return (
<TouchableOpacity
style={styles.row}
onPress={task.completed ? undefined : onComplete}
>
<View style={styles.info}>
<Text style={[styles.title, task.completed && styles.completed]}>
{task.title}
</Text>
<Text style={styles.due}>{formatDate(task.dueAt)}</Text>
</View>
{task.completed ? (
<Ionicons name="checkmark-circle" size={22} color="#4CAF50" />
) : (
<Ionicons name="radio-button-off" size={22} color="#999" />
)}
</TouchableOpacity>
);
}
Both are readable. The Flutter version is more verbose but more structured — you're always in an explicit tree of typed widgets. The React Native version feels immediately familiar if you write React for the web, which is either an advantage or a liability depending on your team's background.
One thing I noticed: Flutter's hot reload is faster and more reliable than React Native's throughout a full day of development. Not dramatically — but consistently.
State Management
I used Riverpod in Flutter and Zustand in React Native. Both are lightweight and explicit. I deliberately avoided Provider or Redux for a project this size.
Flutter with Riverpod:
final tasksProvider = AsyncNotifierProvider<TasksNotifier, List<Task>>(
TasksNotifier.new,
);
class TasksNotifier extends AsyncNotifier<List<Task>> {
@override
Future<List<Task>> build() => _fetchTasks();
Future<void> completeTask(String id) async {
final previous = state;
state = AsyncData(
state.value!
.map((t) => t.id == id ? t.copyWith(completed: true) : t)
.toList(),
);
try {
await TasksApi.complete(id);
} catch (_) {
state = previous;
}
}
}
React Native with Zustand:
interface TaskStore {
tasks: Task[];
loading: boolean;
fetchTasks: () => Promise<void>;
completeTask: (id: string) => Promise<void>;
}
export const useTaskStore = create<TaskStore>((set, get) => ({
tasks: [],
loading: false,
fetchTasks: async () => {
set({ loading: true });
const tasks = await TasksApi.fetchAll();
set({ tasks, loading: false });
},
completeTask: async (id) => {
const previous = get().tasks;
set({
tasks: previous.map((t) => (t.id === id ? { ...t, completed: true } : t)),
});
try {
await TasksApi.complete(id);
} catch {
set({ tasks: previous });
}
},
}));
The patterns are nearly identical — optimistic update, rollback on failure. The ergonomics are a wash. If you already know one of these libraries, it takes an afternoon to feel comfortable with the other.
Performance
This is where the narrative shifted for me.
Flutter renders through its own engine. Impeller is now the default on both iOS and Android in 2026. It doesn't use native UI components — it draws everything itself. This means frame-perfect consistency across platforms and animations that don't depend on a JavaScript thread.
React Native's new architecture — JSI plus Fabric, stable and enabled by default since RN 0.74 — eliminated the old async bridge. Thread communication is now synchronous. This closed a significant performance gap in 2024-2025.
In practice, for this app, I couldn't reliably tell the difference on a modern device. Both hit 60fps on the list scroll. The gap appears when you push harder — complex custom animations, heavy computation, very long lists. Flutter still wins there, but you have to be building something demanding to care.
Build sizes: Flutter release APK was 21MB. React Native bare was 18MB. Flutter carries its engine everywhere.
Ecosystem and Third-Party Libraries
React Native benefits from the entire JavaScript ecosystem. Need a date picker, a chart library, a PDF generator? There's an npm package. The question is always whether it has real native bindings or is a pure-JS fallback.
Flutter's pub.dev is smaller but more curated. Packages tend to be higher quality and better maintained because the community is more focused. For common needs — HTTP clients, SQLite, push notifications, state management — the Flutter ecosystem is solid.
Where Flutter still lags: some SDKs ship their React Native version first and Flutter second, sometimes months later. Analytics tools, some payment gateways, specific third-party integrations. If your app depends on one of these, check the Flutter SDK availability before committing.
For push notifications specifically, both flutter_local_notifications and Expo Notifications worked cleanly in my test. No meaningful difference in API quality. Flutter's setup requires touching native config files directly; Expo abstracts that away.
What I Shipped
I shipped the Flutter version. The decision came down to factors specific to my situation.
UI consistency — our app has custom list animations and a design language that needs to look identical on iOS and Android. Flutter's renderer guaranteed that without platform divergence.
Existing Dart exposure — my team had briefly used Flutter in 2023. The ramp-up cost was lower than switching to a mobile-specific React/TypeScript setup everyone would need to learn from scratch.
No exotic SDK requirements — we don't depend on any third-party SDK that would put us at risk of the "Flutter SDK coming soon" problem.
Desktop is on the roadmap — Flutter's single codebase across mobile, desktop, and web matters for us. We already run a Spring Boot backend; adding a Flutter desktop client for internal ops is straightforward.
If our team had been JS-heavy, or if we'd needed to share components with a web frontend, React Native would have been the right call.
The Honest Summary
Flutter makes more sense when:
- Pixel-perfect custom UI — you control the renderer entirely
- Performance-heavy animations — no JS thread bottleneck
- Targeting beyond mobile — Flutter Desktop and Web are real options in 2026
- Team is willing to learn Dart — the investment is smaller than it looks
React Native makes more sense when:
- JS-heavy team — zero ramp-up if your team already knows React
- Sharing logic with web — React Native Web and shared business logic are mature
- Expo speed for MVPs — managed Expo is genuinely the fastest path to a working app
- Broad SDK availability — some third-party SDKs still prioritize RN bindings
Neither framework is a mistake in 2026. The "Flutter vs React Native" war of 2019-2022 produced a lot of hot takes that aged poorly. Both ship real production apps. Both have active communities. Both have converged enough that your team's background matters more than the framework's raw capabilities.
The one thing I'd push back on: don't pick React Native just because everyone on your team knows JavaScript. Mobile development has enough platform-specific quirks — permission flows, background tasks, notification entitlements, keychain storage — that the framework choice is secondary to understanding how iOS and Android actually work. That learning is required either way.
What are you running in mobile production in 2026? And if you switched frameworks at some point — Flutter to React Native or the reverse — what finally pushed you over the line?
Originally published on Medium.
Top comments (0)