/ios-dependency-injection

Configure protocol-based DI with property wrappers and Factory/Swinject. Use when setting up dependency injection or factory patterns in iOS.

hoangnguyen0403@hoangnguyen0403

GitHub

From plugin

agent-skills-standard

538200 skills1 MCP

Install

$ npx -y skills add hoangnguyen0403/agent-skills-standard --skill ios-dependency-injection --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/ios-dependency-injection

Context preview

The summary Claude sees to decide when to auto-load this skill.

Configure protocol-based DI with property wrappers and Factory/Swinject. Use when setting up dependency injection or factory patterns in iOS.

SKILL.md

ios-dependency-injection.SKILL.md

name: ios-dependency-injection
description: Configure protocol-based DI with property wrappers and Factory/Swinject. Use when setting up dependency injection or factory patterns in iOS.
metadata:
  triggers:
    files:
    - '**/*.swift'
    keywords:
    - "@Injected"
    - Resolver
    - Container
    - Swinject
    - register
    - resolve

iOS Dependency Injection

Priority: P0 (CRITICAL)

Implementation Workflow

1. **Prefer initializer injection** — Pass dependencies through `init` as primary approach. 2. **Inject protocols** — Always depend on protocols instead of concrete classes for testability. 3. **Choose DI library** — Use `Factory` for lightweight DI, `Swinject` for enterprise-grade container-based projects. 4. **Apply correct scoping** — Singleton for app-wide services (Auth, Network); Unique/Transient for ViewModels; Graph/Cached for feature flows.

See [protocol-based DI and Factory registration examples](references/implementation.md)

Anti-Patterns

**No Global Singletons**: Inject services via initializer
**No Inline Service Resolution**: Pass dependencies via constructor; avoid `Resolver.resolve()` in business logic
**No Concrete Class Dependencies**: Depend on protocols for testability