Set up Dbrij Ship step by step: what you need, what to press, and how you know each step worked.
By the end, your mobile app checks in with Ship, and you can flip a setting or ship an update without a store release.
Before you start, have these ready
Ship is your company's release desk for mobile apps. Once your app carries the Ship SDK, you can change what it does from the server: push a fixed JavaScript bundle to phones that already installed it, flip a feature flag, change a config value, or pull the emergency brake, all without submitting a new build to the app stores and waiting for review.
It works in layers. The dynamic layer, flags and config, works on every stack, from React Native to fully native Swift and Kotlin, because it is just data over HTTPS. Code push, replacing the app's JavaScript bundle, works on JS stacks (React Native, Capacitor and other webview apps) because the app stores explicitly allow updating interpreted code. Every other stack gets asset packs on the same release rail instead: a zip of the files the app reads at runtime, staged and rolled back like a bundle, which covers a wrong price, a wrong word or the wrong image without waiting for a review. That split is not a Ship limitation; it is the store rules, and Ship is built to keep you inside them.
A release is one bundle on one channel: a version label, the store binary versions it runs on, and a rollout percentage. Devices are assigned to rollout buckets deterministically, so a phone that got the update keeps it, and widening from 10% to 50% only adds devices. A new release on the same channel supersedes the old one; phones that already applied the old one stay healthy and move up when the new rollout admits them.
A flag is a boolean you gate features behind, with its own staged percentage. A config value is any JSON your app reads at runtime: an API URL, a price table, a banner message. Both can differ per channel, so staging can run tomorrow's behaviour while production stays put. They apply on the next check in on every stack, including apps with no code push at all.
The kill switch is the last resort: flip it and every device gets an empty answer, falling back to the defaults built into your app. Use it when a config value or release has done something bad enough that serving nothing is safer than serving anything.
Both app stores allow apps to download interpreted code as long as it does not change what the app fundamentally is, and both forbid downloading native executable code. That is why code push exists for React Native and Capacitor and not for Swift or Kotlin, which compile to exactly the thing the rule names, and it is why Ship's dynamic layer exists: flags, config and server driven behaviour are data, not code, and are safe on every stack. Flutter is the one that could go either way, since its VM can interpret as well as compile; reaching that door means maintaining a fork of the Flutter engine, which Ship does not do, so Flutter apps get the dynamic layer and their releases stay with the stores.
Keep updates within the spirit of the rules: fixes, improvements and UI changes to the app you shipped, never a different app smuggled through an update. Ship keeps an audit trail of every release for exactly this reason.
Ship is a flat monthly product subscription with 2,000 monthly active devices included across all your apps. Past that, each started block of 1,000 extra devices bills as a metered overage; check ins and updates never stop at the cap, because a mobile release that silently stops updating is worse than a bill.
Dbrij is Nigeria’s company operating system: the first Nigerian built platform to put team chat, video meetings, email, HR, tax compliant payroll, customer support, marketing, analytics and cloud hosting in one product on one subscription.