How We Manage Multiple Angular Mobile Apps in a Monorepo

🧩 Managing Multiple Mobile Apps with a Monorepository

At Bluesunrise, we worked with a client who needed multiple similar mobile apps. These apps shared functionality, components, and design. To build and maintain them efficiently, we decided to use a monorepo architecture.

This allowed us to keep everything in one place, reduce development cost, and share logic through a custom Angular library.

🗂️ Project Structure

We created a single GitHub repository containing multiple applications and a shared library:

root/
├── apps/
│ ├── pnumbers/
│ ├── fnumbers/
│ ├── mnumbers/
│ ├── weld-office/
│ └── weld-lib/ ← shared library
├── package.json ← common dependencies and scripts

• Each app has its own package.json file with app-specific dependencies.
• The root package.json includes shared dependencies and common build/run scripts.
• The weld-lib project is a shared Angular library, used by all applications for styling, components, services, and utility logic.

⚙️ How Angular Handles It

All apps are registered in the angular.json configuration file. Each app has its own settings for building, serving, testing, etc.

Here’s a simplified part of it:

"projects": {
  "pnumbers": {
    "root": "apps/pnumbers",
    "projectType": "application",
    "architect": {
      "build": {
        "options": {
          "outputPath": "apps/pnumbers/www",
          "styles": [
            "apps/pnumbers/src/styles.scss",
            "apps/weld-lib/assets/styles/weld-global.scss"
          ]
        }
      }
    }
  },
  "weld-lib": {
    "projectType": "library",
    "root": "apps/weld-lib"
  }
}

This approach makes it easy to define separate build and serve configurations for each app while sharing the core functionality from weld-lib.

✅ Benefits of a Monorepo

Using a monorepository gave us several advantages:

• ✔ Everything in one place

  No need to switch between multiple repositories or manage separate Git histories.

• ✔ Reduced development & maintenance cost

  One setup for CI/CD, linters, formatters, and test tools.

• ✔ Shared library

  All apps use the same shared components, styles, and utilities from weld-lib, which simplifies updates and bug fixes.

• ✔ Easier consistency

  It’s easier to enforce a consistent design system, architecture, and code practices across all applications.

⚠️ Challenges to Consider

While monorepos are powerful, they also introduce complexity. Here are a few trade-offs we had to manage:

• ❌ Increased project complexity

  With multiple apps and a shared library, the overall structure becomes harder to navigate for newcomers.

• ❌ Managing node_modules

  You have to manage:

  • The root-level node_modules (for shared packages)
  • The app-specific node_modules (for app-only packages)

• ❌ Shared library updates

  Changes in weld-lib may impact all apps. You need to carefully test all apps after shared library changes.

• ❌ Custom Capacitor plugin integration

  We used custom Capacitor plugins for some apps. Managing those within the monorepo adds extra build steps and configuration challenges.

🚀 Final Thoughts

Despite the extra complexity, the monorepo approach was the right decision for this project. It helped us move fast, keep things DRY, and ensure a consistent experience across all the mobile apps.

If your team is working on multiple similar projects, or you plan to scale, a monorepo might be the perfect fit.