Modularity in Mobile Development — Essence, Principles, and Organization

What Is Modularity in Mobile Development

Modularity is a way of organizing code where an application consists of loosely coupled modules, each providing a strictly defined functionality through a public interface. Unlike monolithic architecture where all classes reside in a single project, the modular approach splits code into physically independent build units.

The main goal of modularity is complexity management. A developer can focus on one module without keeping the entire codebase in mind. Each module has its own area of responsibility and can be developed, tested, and deployed independently of the others. This is especially valuable in projects with 10+ developers, where parallel work on a monolith leads to frequent merge conflicts.

It is important to distinguish modularity from layered architecture. Layers (Presentation, Domain, Data) divide code by technical criteria, while modules divide by functional criteria. A “User Profile” module can contain its own layers inside. In practice, the modular approach and layered architecture are combined: each module has its own three-layer structure.

Types of Modules and Their Purpose

Feature modules are the most popular type of module. Each screen or group of related screens is separated into its own module: Onboarding, Profile, Settings, Feed. A feature module contains everything needed for the feature to work: UI, business logic, data layer. Module boundaries are protected — other features cannot access its internal classes.

Core modules contain common infrastructure: networking, database, analytics, design system. They do not depend on feature modules, but feature modules depend on them. This separation guarantees that changing an analytics SDK will not affect the networking layer, and vice versa. Core modules are reused across features without code duplication.

Shared Modules for Common Logic

Shared modules contain code used by multiple features: data models, utilities, constants, custom Views. The main problem with shared modules is the risk of turning into a dump (“misc module”) where heterogeneous code accumulates over time. Rule: a shared module must have a clear theme, for example “shared-ui” or “shared-models”.

On Android, shared modules are often separated into libraries with the lib prefix: lib-network, lib-database, lib-ui-components. On iOS, the same function is performed by internal Swift Packages inside a Workspace. In practice, teams limit the number of shared modules to 3–5 to avoid creating an excessive dependency network that complicates the build.

Test Modules and Testing Isolation

Separate test modules allow running tests only for the changed module without executing the entire test suite. This reduces CI/CD pipeline time from hours to minutes. Module-level isolation ensures SoC at the build level: a networking layer module cannot accidentally import UI libraries in its tests.

Each module must have a clearly defined public API. On Android, this is achieved through access modifiers and api vs implementation in Gradle. On iOS, through public/internal access modifiers and managed dependencies via Package.swift. Reducing visibility to the minimum necessary is a key practice of modular design.

Modularity in Android: Gradle Modules

Gradle supports modular architecture natively: each module is a separate build unit with its own build.gradle file. Android projects use a combination of an application module (app) and several library modules. Library modules cannot be run as an application but can be published as AAR to a repository.

A key feature of Gradle is parallel building of independent modules. If modules A, B, and C do not depend on each other, Gradle compiles them simultaneously using all CPU cores. In projects with 20+ modules, this reduces a full build from 15 to 3–5 minutes. Incremental builds of a changed module take seconds.

Gradle provides two types of dependencies between modules: api (transitive) and implementation (non-transitive). The difference is critically important for modularity: implementation hides transitive dependencies from module consumers. If the :profile module uses :networking via implementation, consumers of :profile do not know about :networking and cannot access it.

// settings.gradle — module declarations
include ':app'
include ':feature:profile'
include ':feature:settings'
include ':core:network'
include ':core:database'

// build.gradle feature/profile — module dependencies
dependencies {
    implementation project(':core:network')
    implementation project(':core:database')
    implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.8.0'
}

The code shows the structure of a modular Android project. Settings.gradle lists all modules, and each feature module's build.gradle specifies only the core modules it needs. The build system automatically resolves transitive dependencies and builds modules in the correct order.

Modularity in iOS: Swift Package Manager and CocoaPods

Swift Package Manager (SPM) has been the standard modularity tool in iOS since 2019. SPM allows splitting an application into Swift Packages, each of which can be a library or executable. A Package defines modules (targets) and their dependencies through Package.swift. SPM is integrated into Xcode and does not require additional tools.

CocoaPods remains the main dependency manager for third-party libraries. Podfile and Podspec define the modular structure, and CocoaPods generates a workspace with separate pod projects. For their own project modularity, teams increasingly choose SPM because it is built into Xcode and requires no installation.

In iOS modularity, access control plays an important role: public, package, internal, fileprivate, and private. A module publishes only those types that need to be accessible to other modules. Internal implementation details are hidden behind internal and private modifiers. This prevents hidden dependencies between modules.

// Package.swift — modular structure of an iOS project
let package = Package(
    name: "MyApp",
    platforms: [.iOS(SupportedPlatform.iOSVersion.v17)],
    products: [
        .library(name: "ProfileFeature", targets: ["ProfileFeature"]),
        .library(name: "NetworkCore", targets: ["NetworkCore"]),
    ],
    dependencies: [
        .package(url: "https://github.com/Alamofire/Alamofire.git", from: "5.9.0")
    ],
    targets: [
        .target(name: "ProfileFeature", dependencies: ["NetworkCore"]),
        .target(name: "NetworkCore", dependencies: ["Alamofire"]),
    ]
)

Package.swift declares two library products: ProfileFeature and NetworkCore. ProfileFeature depends on NetworkCore but does not know about the existence of Alamofire — it is hidden inside NetworkCore. Such isolation is a direct application of SoC at the module level: changes in the HTTP client do not require recompilation of ProfileFeature.

Benefits and Challenges of Modular Architecture

The main advantage of modularity is development speed. Teams work in parallel on different modules without code conflicts. The CI/CD pipeline builds only the changed modules and runs only their tests. Feedback time decreases, and release frequency increases. Spotify, Uber, and Airbnb published case studies of migrating to modular architecture with 2–3x metric improvements.

The second advantage is error isolation. A bug in the Profile module does not affect the Payments module if there are no direct dependencies between them. This is especially important in applications with high-risk functionality (payments, medical data), where an error in an unrelated screen should not block the release of critical functionality.

The main challenge is dependency management. With poor design, a module graph emerges where changing one module cascades to rebuild dozens of others. The solution is to follow the acyclicity rule: the module dependency graph must be a directed acyclic graph (DAG). Tools like Gradle Module Graph Assert help detect cycles at build time.

The second challenge is increased initial setup time. Creating a modular architecture requires more time at the project initialization stage. Small projects with 1–3 developers may not benefit from modularity, spending time maintaining module boundaries without a real need for parallelization. The solution is to start with a monolith and extract modules as the team grows.

Feature-First vs Layer-First Approaches

The feature-first approach groups modules by functionality: each screen or group of screens becomes a separate module. The layer-first approach divides code by technical criteria: separate modules for UI, business logic, and data. In practice, most teams choose feature-first with core modules — this provides better isolation and clear project navigation.

The choice between approaches depends on team size and feature predictability. If you know exactly which screens will be in the project, feature-first allows each developer to be responsible for their own module. If functionality changes frequently and overlaps between screens, layer-first provides more flexibility in reusing code across different features.