Features
Your app is full of features — a screen, a menu item, a button, an export, a whole flow. Normally whether each one is on, off, in beta, or behind a paywall is baked into the build you ship, so changing it means another release. Onelo Features is a remote control panel for the features in your own app. The feature itself stays in your code; Onelo controls who sees it and how — live, from the dashboard, without shipping a new build or waiting on an app-store review.
The loop is simple: you declare features in code in your app's codebase; the Onelo Features SDK reports them to the dashboard; and there you manage and decide each feature's visibility — on for everyone, locked behind a plan, in beta for a few testers, badged as new, teased as coming-soon, or hidden entirely. Click Deploy and connected apps reflect the change within seconds. It works the same in your client app (Swift, JS…) and your backend (Python…).
Reach for it when you want to:
- Ship dark, switch on later — merge unfinished work behind a hidden feature and flip it the day it's ready.
- Beta to a few — open a feature to specific testers or one plan, watch how it goes, then roll it out to everyone.
- Gate by plan — make a feature part of a paid tier; users on other plans see a locked padlock or an upgrade prompt.
- Kill a problem instantly — something broke in production? Hide the feature in seconds, with no release.
Everything you edit happens in one of two parallel worlds — Test and Live. You shape and try features in Test, then Promote them to Live when you're happy. Production users only ever read the Live world.
What your app sees — the status
Whatever you set up, your code only ever deals with one thing: for each feature, the SDK resolves a single status for the current user, and your UI renders by it. Render by status, not a boolean — that keeps locked, coming-soon and upsell features visible (a padlock or a badge) instead of vanishing.
| Status the app reads | What to render |
|---|---|
| enabled | Visible and fully usable. |
| new | Visible and usable, with a NEW badge. |
| beta | Visible and usable, with a BETA badge. |
| coming_soon | Visible but not usable — a “coming soon” teaser. As a plan-gated cell it can also carry a tap-to-upgrade (same CTA rule as greyed / upsell). |
| greyed | Visible but locked — a padlock. Tap-to-upgrade when the feature’s CTA toggle is on (default) and a higher plan grants it; greyed just omits the “Available in …” tease. |
| upsell | Visible, locked, with an “Available in …” tease — tapping opens your upgrade flow when the CTA toggle is on (default) and a higher plan unlocks it. |
| hidden | Not rendered at all. |
These are the values the SDK returns — and what helpers like isEnabled / isVisible read for you. See SDK integration.
Where that status comes from — two layers
You produce that resolved status from two separate dashboard controls. They sit on different layers, and — on purpose — don't use the exact same list of options:
| Layer | What you set | Options |
|---|---|---|
| Feature statusRegistry · one per feature | The baseline everyone gets — or “hand off to the rules”. | ActiveNewBetaComing SoonGreyedTargetedHidden |
| Plan & user visibilityPlans / Targeting · per plan or user | What a specific plan or user sees. Plan rules apply to any non-hidden feature once the paywall is on; per-user rules require Targeted. | EnabledNewBetaComing SoonLockedUpsellHidden |
greyed, shown as Greyed in the Registry and Locked in plan visibility.)So: set a feature's status in the Registry; set it to Targeted to let plan and targeting rules decide per user; and use Inspect to see which layer won for any user.
How a feature reaches your app
You declare it in code
onelo.features.feature("advanced-export"). See SDK integration.The SDK reports it — while running in Test
ONELO_FEATURE_ENVIRONMENT variable — not by which key you hold. While an app runs in Test, the SDK reports the feature names it uses and they appear in the Registry as hidden. Discovery only ever writes in Test — Live never grows on its own. See Discovery & Deploy access.Deploy to Test
Promote to Live, then Deploy to Live
The SDK resolves it, and stays in sync
The dashboard, tab by tab
Open your app → Features. Pick an Application, choose the Test/Live environment, then work across four tabs (plus Inspect):
Tab 1 · Registry
The master list of every feature the SDK has reported. Set each one's status, search and group them, archive or clear, and run Discover Features.
Tab 2 · Packs
Bundle features into named groups so one plan or targeting rule applies to all of them at once. Composition is per-environment.
Tab 3 · Plans
The feature × plan matrix. Decide what a buyer of each plan actually gets — enabled, locked, an upsell, or your fallback — exactly what the SDK resolves.
Tab 4 · Targeting
Rule-based visibility for specific users or plans. User rules win over plan rules; order decides ties.
Inspect
Search any user and see the exact status they get for every feature — and the rule that decided each one. Read-only.
Set it up
SDK
Install the SDK, read statuses, identify users for per-plan targeting — copy-paste snippets for macOS/Swift, Python and every other platform.
Guide
How the SDK auto-registers features, why discovery is Test-only, and how authorized dev devices (deploy access) are pinned and unpinned.
Guide
How Test and Live stay separate, what Deploy to test means, the Promote-to-Live summary, and Clear all features.
Guide
Publishable vs secret keys, and how Onelo binds each key to your app — origins, client secret, PKCE, App Attest / Play Integrity / codesign, and IP allowlists.