MekariFlag

Context

Feature flags are easy to add and hard to keep clean. Used directly, a flag SDK tends to leak across an app: call sites differ, identity handling is inconsistent, and tests either hit the real provider or get skipped. The result is rollout code that’s risky to change and awkward to verify.

MekariFlag exists to make feature flags boring — a single, predictable wrapper that standardizes how flags are read, who they’re evaluated for, and how they behave under test.

Approach

The wrapper is a thin abstraction over a feature-flag provider (Flagsmith as the default), distributed internally via CocoaPods. The design decisions that matter:

• Abstract the provider, not just the call. A provider interface means the default can be swapped for a custom or in-memory implementation without touching feature code.
• Make identity explicit. Flags are evaluated against a known identity, so targeting and per-user rollout behave consistently across the app.
• Design for the test, not just the runtime. Because the provider is an abstraction, tests can inject a mock and assert behavior deterministically instead of depending on a live service.

How it works

App code asks the wrapper for a flag’s value through one consistent API. At runtime that resolves against the configured provider; in tests it resolves against a mock. Identity is threaded through so the same flag can return different values for different users in a controlled way. Swapping providers is a configuration concern, not a refactor.

Outcome

The payoff is safer feature rollout, cleaner integration in app code, easy provider switching, and genuinely testable flag logic — the difference between flags as a liability and flags as a routine release tool.

What I’d build next

Useful additions are compile-time flag definitions to catch typos, a lightweight audit of which flags are still in use, and tooling to flag (no pun intended) stale toggles that should be cleaned up.