How I Structure My Cross-Platform Projects (Flutter + React Native)

When working on multiple mobile projects using both Flutter and React Native, one of the biggest challenges is maintaining clean, scalable, and consistent folder structures. Over the past few years, I’ve refined a project structure that works well across both platforms — making it easier to onboard new devs, scale features, and manage codebases long-term.

In this post, I’ll walk you through how I organize my cross-platform apps, what patterns I follow, and tips to keep things modular whether you’re using Dart or JavaScript/TypeScript.

🧱 Why Project Structure Matters

A well-structured codebase:

• 🧠 Reduces cognitive load
• 📦 Encourages separation of concerns
• 🔄 Makes scaling features easier
• 🧪 Simplifies testing
• 👥 Makes collaboration smooth

🔷 Flutter Project Structure (Feature-First)

Here’s a simplified structure I use for most Flutter apps:

lib/
├── core/                 # Shared base utilities (theme, constants, env)
│   ├── utils/
│   ├── services/
│   └── widgets/
├── features/             # Grouped by feature
│   ├── auth/
│   │   ├── data/
│   │   ├── domain/
│   │   ├── presentation/
│   ├── home/
│   └── ...
├── app/                  # Routing, DI, App entry
│   ├── router.dart
│   └── app.dart
main.dart

✅ Tips:

• Each feature/ has its own models, logic, and UI
• Use core/ only for global, truly shared logic
• app/ handles GoRouter, GetIt, and entry setup
• Separate presentation, domain, and data layers for clean architecture

🟣 React Native Project Structure (Feature-First with Hooks)

src/
├── assets/               # Fonts, images, icons
├── components/           # Shared UI components
├── features/             # Feature modules
│   ├── auth/
│   │   ├── screens/
│   │   ├── hooks/
│   │   ├── services/
│   │   └── types.ts
│   ├── home/
├── navigation/           # React Navigation config
├── context/              # App-wide context providers
├── utils/                # Reusable helper functions
├── config/               # env, constants, themes
App.tsx

✅ Tips:

• Each feature/ folder has its own hooks, services, and views
• Avoid bloated context – use Zustand, or useReducer inside hooks
• Centralize navigation in /navigation
• Shared logic like formatDate, apiClient, etc. live in /utils

🔄 What They Have in Common

Principle	Flutter	React Native
Feature-first	lib/features/	src/features/
Global utils/constants	lib/core/	src/utils/
Routing config	lib/app/router.dart	src/navigation/
Scoped UI components	lib/core/widgets/	src/components/
Modular business logic	data/domain layers	hooks/services per feature

🚀 Pro Tips for Cross-Platform Consistency

• Use naming conventions across both platforms (auth, home, profile, etc.)
• Match your features/ structure between Dart and JS
• Define a shared folder structure standard in your team docs
• Use mono-repo tools like Nx (for RN + web) or Melos (for Flutter) if your projects grow
• Set up aliases/import paths to avoid deep relative imports

🏁 Conclusion

Whether you’re building in Flutter or React Native, a feature-first structure will keep your project modular, testable, and easier to grow. I’ve used this layout across client projects, startup MVPs, and multi-dev teams — and it’s held up every time.