Mobile App Modularization: Architecture and Implementation
Problems Solved by Modular Architecture
A monolith app with 50+ screens where everything lives in one module — that's a story of an 8-developer team waiting 4 minutes for a full build on every change, and how one team's feature breaks another's tests because both import the same singleton. Modular architecture solves these exact problems. We help teams modularize applications from 20 to 200 screens, based on Apple Human Interface Guidelines and over 10 years of experience. Our modularization service costs between $15,000 and $100,000 depending on project size, and can save you over $100,000 annually. The service includes modular scheme design, core-module implementation, feature migration, and build configuration.
- Build speed. Changing one file in a feature module triggers a rebuild only for that module. Modularization cuts incremental build time by 3–5x — from 7–11 minutes to 45–90 seconds (real case).
- Merge conflicts. When multiple teams work in the same
.pbxprojorbuild.gradle, conflicts are inevitable. Modules isolate code: feature branches rarely collide. - Test isolation. Tests of one module don't depend on changes in another. You can run only the affected module's tests.
How We Do It: Stack and Practices
Module Separation
The standard approach is feature-based division with a shared core layer:
:app — entry point, DI graph, navigation :core:network — HTTP client, interceptors :core:storage — DB, SharedPreferences/DataStore :core:ui — common components, theme :core:auth — tokens, AuthInterceptor :feature:profile — user profile :feature:catalog — product catalog :feature:checkout — checkout flow :feature:orders — order history Each :feature:* module depends only on :core:* and knows nothing about other features. Navigation between features is done via abstraction: a NavigationManager in :core used by each feature for transitions without directly importing another feature module. On Android — Navigation Component with NavGraph at :app level, deep links registered in module manifests. On iOS — Coordinator pattern or Router with protocol-based navigation.
Android. Each :feature:* is a separate Gradle module (:feature:catalog → catalog/build.gradle.kts). Gradle Configuration Cache + Build Cache (~/.gradle/caches) radically cut rebuild time: change only :feature:checkout — it alone is rebuilt. --configuration-cache in Gradle 8 is stable. Kapt → KSP: migrating annotation processors from Kapt to KSP (Kotlin Symbol Processing) yields +30–50% in code generation speed.
iOS. Modules are implemented via Swift Package Manager (local) or as Framework targets in an Xcode workspace. Swift Package Manager supports local packages via path: in Package.swift. Workspaces with multiple projects (Feature1.xcodeproj, Feature2.xcodeproj) are legacy; the modern approach is a monorepo with local SPM packages + one main .xcodeproj. Tuist or XcodeGen auto-generate .xcodeproj from config files, eliminating merge conflicts in .pbxproj.
DI in Modular Architecture
The DI graph should not be monolithic. On Android — Hilt with @InstallIn(SingletonComponent::class) for core dependencies and @InstallIn(ViewModelComponent::class) for feature-specific ones. Each feature module declares its own @Module classes; Hilt assembles the graph at compile time. This means: if :feature:catalog is not included in :app, its DI module is not compiled and does not affect the build.
On iOS — manual DI via Resolver/Swinject, or a pure factory pattern without a DI framework. In a modular app, a DI framework on Swift is less critical: dependencies are passed through initializers, and the Composition Root in :app assembles everything.
Why Modular Architecture Is Better Than a Monolith?
A modular app saves up to 40% of the development budget in the long term (based on our experience). Compare: in a monolith, one error in shared code can paralyze an entire team for a day, while in a modular app the problem is localized. Google I/O demonstrated that Play Feature Delivery can reduce the base APK size by 30–50%.
Dynamic Delivery and Optional Modules
Android allows delivering feature modules on demand via Play Feature Delivery (formerly Dynamic Delivery). The user downloads the base app; heavy features (AR try-on, offline maps) download on first use. SplitInstallManager controls downloads, SplitCompatActivity handles activation. iOS has no direct equivalent — App Clips cover a different niche.
| Comparison | Monolith (one team) | Modular (6 teams) |
|---|---|---|
| Full Android build time | 7 minutes | 4 minutes (with Build Cache) |
| One-module rebuild time | 7 minutes | 45–90 seconds |
| Monthly merge conflicts | 15–20 | 2–5 |
| Parallel work capability | Limited | Full |
Case study. Retail app: 6 teams, 80+ screens, Android + iOS. Before modularization: full Android build — 7 minutes, iOS — 11 minutes. After splitting into 14 modules with Build Cache configured: incremental build when changing one feature module — 45–90 seconds. Merge conflicts in shared code dropped roughly threefold. Parallel feature development without team blocking. Time savings estimated at 30–50% over the long haul. Average modularization budget depends on project complexity and is determined after an audit. For a typical 50-screen app, modularization costs $30,000–50,000, yielding annual savings of $100,000 in reduced merge conflict resolution and faster builds. The investment typically pays for itself within 6 months.
What’s Included (Deliverables)
Our deliverables include:
| Deliverable | Description |
|---|---|
| Architecture audit | Analyze current codebase, identify dependencies, circular references, build bottlenecks |
| Modular scheme design | Module diagram, interfaces, migration roadmap |
| Core module implementation | Create core layers (network, storage, ui, auth) |
| Feature migration | Each feature is extracted into its own module while maintaining functionality |
| Build configuration | Build Cache, Configuration Cache, CI/CD incremental builds |
| Documentation | Module READMEs, navigation schema, naming conventions |
| Team training | Workshops on modular development, code reviews at early stages |
| Post-launch support | 2–4 weeks of post-release support, fixing inconsistencies |
We provide detailed documentation, repository access, team training, and post-release support.
How Modularization Works: Step by Step
- Analyze current architecture — identify dependencies and cycles.
- Design modular scheme — module diagram and interfaces.
- Implement core modules — core layers (network, storage, ui).
- Migrate features — each feature becomes its own module.
- Configure build — Build Cache, Configuration Cache, CI/CD.
- Test and document — module tests, navigation schema, README.
- Support and train team — code reviews, workshops on modular development.
Timelines and Cost
| Project size | Estimated timeline | Estimated cost |
|---|---|---|
| 20–40 screens, 1–2 teams | 4–8 weeks | $15,000–25,000 |
| 50–100 screens, 3–5 teams | 2–4 months | $30,000–50,000 |
| 100+ screens, complex dependencies | 4–8 months | $60,000–100,000 |
Cost is calculated individually after an audit of the architecture and existing code dependencies. Order an audit — we will assess your project and propose an optimal modularization plan. Call or write to us to discuss details. Find out how modularization can accelerate your development — get a consultation today.
Common Mistakes in DIY Modularization
Circular dependencies. :feature:profile imports :feature:orders, :feature:orders imports :feature:profile. Gradle won't build — circular dependency. Solution: extract shared models to :core:domain or :shared:models; both features depend only on that.
Too granular modules. :core:extensions with 5 extension functions — overhead without benefit. A rational minimum: a module is justified if it can be changed independently and does not depend on modules that change more often.
Resource ID conflicts. On Android, merging resources from multiple modules causes name collisions. Convention: module prefix for all resources (catalog_item_card_background, not just item_card_background). R class isolation via android.nonTransitiveRClass=true in gradle.properties is mandatory for large projects.
Why Entrust Modularization to Professionals?
We have over 10 years of experience in mobile development and have completed more than 40 projects with modular architecture. We guarantee a smooth transition without team downtime. Apple Developer and Google Associate Android Developer certifications validate our expertise. Contact us for a consultation — we will help you accelerate development and reduce cost of change.