Building a mobile app, especially one already on Firebase? Use Remote Config, not wagle. Firebase gives you first-class iOS, Android, Flutter and Unity SDKs, on-device caching, real-time push, bundled A/B testing, and (even after the September 1 2026 move to usage-based pricing) a free tier most apps never exceed. wagle has no mobile SDKs at all: if your client is a phone, the comparison ends here. wagle earns a look only for server-side teams (Go or TypeScript) who want three things Firebase doesn't give cleanly: a real project-and-environment model instead of one template per project (Firebase's answer is to spin up a second Firebase project and sync it yourself), a flag-first lifecycle with per-write typed edits and actor-attributed history rather than a whole-template config console, and no Google-ecosystem coupling. In exchange you accept a young product from a single maintainer; weigh that before deciding.
Competitor claims re-verified 2026-07-19 · sources at the bottom
Two languages: Go and TypeScript/React. No mobile SDKs at all: no iOS, Android, Flutter or Unity. If your client is a phone, stop here and use Firebase; this is not close.
The mobile default: first-class native SDKs for iOS, Android, Flutter, Unity and C++, plus Web and a server Admin SDK. On-device caching and offline fallback built in.
SDKs seed a snapshot, poll for changes and evaluate locally; if wagle is unreachable they keep serving the last snapshot: stale, not broken.
Same architectural family: clients cache values on-device, fall back to the last fetched values (then in-app defaults) when offline, and get real-time push via a websocket. This continuity is a tie, not a wagle advantage.
A real (project, environment) model on day one: per-environment serving state, project-wide identity, and the environment folded into the bucketing hash so each one rolls out independently.
No environments inside a project: one template per Firebase project. Google's own guidance is a separate Firebase project per environment, which then needs CI/CD scripts to keep dev, staging and prod in sync (and it's easy to forget one).
Flag-first: typed per-flag edits through one atomic write path, each appending actor-attributed, per-version diffable history.
A config console with real version history: every publish records who, when and how, and you can roll back to any stored version. But versioning is whole-template (a publish replaces the entire template), there are no approval or change-request workflows, and audit is at snapshot granularity, not per-flag.
One meter: SDK syncs (the config pull, the only call that reaches the service). Local evaluations are free and unlimited because they never touch wagle.
Historically free with Firebase; from September 1 2026, usage-based on fetch requests: 100k/day free, then $0.06 per 10k up to 10M/day and $0.01 per 10k above, with a 30-day grace period. Cached reads are free. Similar philosophy to wagle (both meter the pull, not the eval); the honest note is that 'free forever' is ending, not that wagle is cheaper.
No Google dependency: targeting, history and billing are wagle's own. The flip side is narrow reach: only two SDK languages exist today.
Deep Google coupling: targeting audiences, A/B tests and Personalization run through Google Analytics, and billing rides the Firebase/Blaze (Google Cloud) account. A strength if you live in Firebase, friction if you don't.
Per-project versioning is a monotonic counter with no hard ceiling; segment values are capped at 10,000 entries (paste-only).
Hard ceilings: 3,000 parameters and 2,000 conditions per template type, and only 300 lifetime stored template versions (deleted versions still count); older history ages out.
Third-party sources only: reviews, buyer data, and their own published docs and pricing; never their marketing copy, never our opinion of them.
The why & how page states every deliberate limitation plainly, the fastest way to rule wagle in or out.