16.5 · Resource bundles, localisation in modules, and feature flags

Code is only half a module. Images, strings and data must travel with it, and behaviour you ship dark must be switchable without a release.

Mental model. A module owns its resources and finds them through its own bundle, never the app’s. A flag is a decision deferred to build time or run time.

Resources in modules

<code>Bundle.module</code>, processed resources and localisation.

1. How do resources and localisation work inside a module: Bundle.module, process versus copy, and strings tables? 16.5.1 · L3
   Inside an app target, resources live in the main bundle (Bundle.main). A module in its own package has its own resource bundle, and code must look there…

Flags

Compile-time and runtime feature flags.

1. How do you use feature flags: compile-time versus runtime, ownership, and modularisation by team? 16.5.2 · L5
   A feature flag lets you separate deploying code from turning behaviour on. Two kinds, with different jobs. Compile-time flags (#if FEATURE_X, set with -D…

More in Modularization & SPM

• 16.1 · Targets, products, modules, and access across module boundaries
• 16.2 · SPM, CocoaPods, Carthage and XCFrameworks, and shipping binaries
• 16.3 · Static and dynamic linking, duplicate symbols, and the dependency graph
• 16.4 · Build settings, configurations, xcconfig, and compile times
• 16.6 · Multi-hour CI, affected-module builds, caching, and Tuist and Bazel
• 16.7 · Version rules, pins, conflicts, unsafe flags, mirrors and inspecting the graph
• 16.8 · Conditional settings, platform minimums, language modes, traits and plugins
• 16.9 · What really crosses a module boundary: inlinable bodies and imports