My security gate was green on every pull request. It had never scanned a single line.

Every feature is bound to the same chain. Pick a layer to see what it is allowed to touch — and what breaks when the rule is ignored.

📜 4-Module Responsibility Matrix

“Modular” is a claim that is cheap to make and easy to fake with folders. This is the actual Xcode project. Look at the TARGETS list: the three amber icons are three separate framework targets — each one compiles to its own binary, with its own Info.plist, its own dependency manifest and its own test bundle. They are modules, not sub-folders of one big codebase.

Click to enlarge

Minimum deployment target reads iOS 16.0, and the destination list includes iPad, Mac (Designed for iPad) and Apple Vision — which is why AppDeviceType has to resolve .vision behind an availability check rather than assuming iPhone.

🏷 Suffix Families

The same rules the repository audit scripts enforce, running in your browser. Type a Swift type name and pick what it actually is.

🔍 Global Uniqueness — and why it is not about tidiness

Rename and grep operate on text, not on Swift’s understanding of scope. A name that is unique only to the compiler makes automated tooling dangerous. Every one of these actually happened in this repository:

Nesting is not protection. Unique to the compiler, not unique to grep — so these were lifted to top level with full names:

🛡 The API Wire Boundary

Server response shapes must never reach the screen. That is not enforced by review — it is enforced by the compiler, three ways at once:

⚠ NetworkErrorType — one error type, and it is a contract

Whatever the origin — transport, decoding, local storage — it is mapped to one of eight cases before it leaves the data layer. The consequence: a ViewModel catches exactly one type.

NetworkErrorMapperType is deliberately not public — if presentation code ever wants to call it, that is a signal the mapping is happening in the wrong place.

🏭 Container.autoRegister() — the only place protocols meet implementations

FactoryKit calls it once, before the first resolution. There is no window where a service is built with a default and then swapped mid-flight. Because NurKit may not name a NurCommsKit type, every Factory<T> needs a default owned by NurKit itself — and the kind of default is a deliberate decision:

🪨 Two injection styles — and why one is being retired

init(xxxUseCase: any XxxUseCase
     = Container.shared.xxxUseCase()) {
    self.xxxUseCase = xxxUseCase
}

@Injected(\.xxxUseCase)
private var xxxUseCase

Both still exist in the codebase today. New ViewModels use constructor injection; the remaining property-wrapper ones are queued for migration.

🧭 AppRouteType + RouteView — exhaustiveness as a safety net

Navigation lives entirely in the App target. NurUIKit holds Views and ViewModels only — verified: no file in that module references AppRouteType. A screen does not know it has a route.

switch route {
case .auth:      IAuthUseCaseView()
case .launchApp: ILaunchAppUseCaseView()
// forget one → compile error
}

[AppRouteType: () -> View]

📱 4-Flavor Matrix via xcconfig

Each module carries its own Configs/xcconfig/ set, so a flavor is a build-time fact rather than a runtime branch. Firebase reads a per-flavor GoogleService-Info plist and falls back with an explicit warning if the flavor-specific file is absent — a fallback, not a silent failure.

🔧 Deterministic Makefile

make init      # check tools → gems → SwiftGen → XcodeGen → pods → SPM
make update    # regenerate resources + project after adding/moving files
make build     # compile the Production Debug scheme
make test      # full unit suite via the APPLICATION scheme (same as CI)
make lint      # SwiftLint
make open      # open the generated workspace

🧠 Design Decisions — with the question to answer before reversing one

This table exists so a decision already weighed is not quietly undone by whoever arrives next.

🔎 One feature, traced end to end

Email login, from the screen to the wire:

Note the two highlighted rows: those type names appear nowhere above them. That is not a coincidence — it is the API wire boundary, held by the compiler.

make local_build_ipa          # one configuration
make local_multi_build_ipa    # several, sequentially

  configuration   Staging Debug / Release · Production Debug / Release
  destination     App Store Connect · TestFlight
  note            travels to the release notes AND the notification card

The multi variant builds sequentially — each configuration is uploaded before the next starts building. Partial failure is therefore a visible state, not a hidden one: the notification reports how many were selected versus how many actually shipped, so “three of five made it” is something you read rather than something you discover a week later.

Build numbers come from the server, not from a file

Decisions, and what each one costs

Every row below is a trade that was made deliberately. The right-hand column is the part usually left out.

Click to enlarge

Click to enlarge

Click to enlarge

The highlighted row is the one that matters. Tests that fail to compile produce no coverage figure. If “unknown” were treated as “carry on”, the one change that breaks the test target would be the one change that sails through.

Lint advises, tests block

Click to enlarge

The linter is also scoped to source folders only. Test files legitimately need shapes that production code forbids, and a rule that fires there teaches people to silence the rule everywhere.

One run, separate signals

Click to enlarge

The last row is the point of the whole folder: who gets tagged and which key is used are data, not code. Changing who receives a notification is editing one list — it never means opening a lane, and it can never break a build.

A filename is a contract

Every pipeline file carries two prefixes. Together they answer who owns this and where does it run without opening the file — which matters when a directory holds a dozen of them.

The same convention governs the pull request title, and a check rejects anything else. It is a small rule that pays back every time someone scans a list of merged work and needs to know, at a glance, which platform it landed on.

Where the time actually goes

Measured on one green pull request, end to end — the same run whose job graph is shown above, so every figure here can be checked against it. Optimising anything other than the highlighted row would be optimising the wrong thing.

That single number is what decides how many pull requests an hour the queue can absorb. It is also the honest answer to “why not just add more checks?” — every addition is paid for by everyone waiting behind it. The always-on checks (title, diff size, path authorisation, security) do not add to this total: they are separate workflows running in parallel on hosted runners.

What the exercise actually cost, and what it bought

The last row is the honest summary. Three positive runs and one deliberately broken one turned a pipeline I believed was protecting the repository into one I had watched protect it — and the difference between those two verbs is most of what this section is about.