A shared module is the part of a KMM project that holds code used by both Android and iOS. It commonly contains business logic, data models, and network requests. Keeping this code in one place improves maintainability and allows teams to update core behaviour without rewriting the same logic twice.
Expanded Definition
In Kotlin Multiplatform Mobile, a shared module is the cross-platform code layer that packages logic once and reuses it across Android and iOS targets. It is typically where teams place domain rules, validation, data mapping, and network client code that should behave consistently regardless of device platform. That makes the shared module a software architecture decision as much as a code organisation choice.
The term is often used loosely, so definitions vary across teams and vendors of tooling. Some treat only pure business logic as shared, while others extend the module to include platform abstractions, serialization, and repository implementations. The practical boundary is usually determined by how much platform-specific code is required to keep the module portable and testable. For governance and risk discussions, the key question is not whether code is “shared” in theory, but whether the shared layer creates a single control point for correctness, security checks, and release discipline. The most common misapplication is assuming that any reusable code is automatically safe to centralise, which occurs when platform dependencies or secrets handling are pushed into the shared module without clear separation.
Examples and Use Cases
Implementing a shared module rigorously often introduces architectural constraints, requiring organisations to weigh code reuse and consistency against platform-specific flexibility and integration effort.
- A mobile banking app keeps transaction validation and balance formatting in the shared module so both platforms apply the same business rules before submission.
- A retail app stores API response models and error mapping in shared code so Android and iOS display consistent checkout failures and retries.
- A health app centralises consent-state logic and synchronisation rules in the shared layer to reduce drift between platforms, while keeping device permissions native.
- A product team places encryption-related helper logic in shared code only where it is platform-neutral, leaving key storage and secure enclave access to native components.
- A release team uses the shared module to standardise logging and request construction, then validates the resulting artefacts against NIST Cybersecurity Framework 2.0 expectations for protected data handling and governance.
Why It Matters for Security Teams
Shared modules matter because they concentrate behaviour that can affect both platforms at once. If authentication checks, input validation, certificate handling, or API request logic are implemented once and reused everywhere, a defect or insecure assumption can propagate across the whole mobile estate. That is especially important where mobile apps interact with identity systems, session tokens, or backend services that must enforce consistent access decisions.
Security teams also need to understand the boundary between shared and native code so that sensitive functions are not moved into a layer that lacks platform protections. A shared module should support maintainability without becoming a place where secrets, hard-coded endpoints, or device-specific trust decisions accumulate. When identity-bearing workflows such as login, consent, or token refresh are involved, the shared layer should be reviewed alongside the surrounding IAM controls rather than treated as a pure development convenience. The most common failure mode is discovering that a flaw in shared business logic affected every release channel after a production incident, at which point the shared module becomes impossible to ignore.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Shared modules affect secure development and change control across mobile platforms. |
| NIST SP 800-53 Rev 5 | SA-11 | Shared modules should be tested for defects before reuse spreads them across targets. |
| ISO/IEC 27001:2022 | A.8.25 | Secure development practices govern reusable code components like shared modules. |
| NIST SP 800-63 | Identity workflows in shared code can influence authenticator and session handling. | |
| OWASP Non-Human Identity Top 10 | Shared modules may centralise token and secret handling relevant to NHI governance. |
Treat shared code as a controlled asset and review it within secure development practices.
Related resources from NHI Mgmt Group
- What breaks when organisations patch only a parser module but leave shared document-processing libraries unpatched?
- Why do shared accounts create such a large security problem in higher education?
- How should teams respond to a local Linux privilege escalation flaw in shared environments?
- How should regulated teams decide between shared SaaS and tenant-owned identity platforms?
