OBDX lets a mobile app either load its screens from the server or carry them inside the app. It gets discussed as a performance trade-off, and it is one, but that is the smaller half. What it really decides is who has to release before a customer sees a changed screen — the OBDX team, or the mobile team and the app stores. There is also a detail that catches people: if you bundle the built UI locally you cannot edit it, because it is webpack-minified. Taking local UI properly means inheriting the UI build too.
Every OBDX mobile project arrives at this fork, usually in week two, and usually with the wrong framing. Someone demonstrates that local screens feel snappier, everyone agrees, and the decision is made on that basis. Eighteen months later the bank discovers it needs an app store release to change a piece of regulatory wording on a transfer screen.
The mechanics are simple enough. With remote UI, the app loads its screens from the server where the OBDX UI is hosted, and you point the app at that host in configuration — the server URL in app.properties on Android, app.plist on iOS. With local UI, the screens live in the mobile workspace and ship inside the app. Oracle's Mobile Application Builder guides describe the UI as hostable on the remote server, on a local machine, or saved locally in the mobile workspace; the first and third are the production options, and the middle one is how you develop.
The question that actually matters
Forget rendering speed for a moment and follow a single screen change from decision to customer.
Neither row is wrong. A bank that renders everything remotely has bought central governance and consistency, and has given up some craft at the interface. A bank that hosts everything locally has the opposite, and has accepted that a wording change now needs a store submission. Most should sit deliberately in between.
The webpack detail
Here is the part that surprises teams after they have committed. The OBDX UI is built with webpack, and Oracle's documentation notes that the built UI cannot be modified from within the mobile workspace, because it is minified. So "bundle the UI locally" splits into two quite different propositions.
You can ship the built artefact, in which case the app carries a UI it cannot alter and every change still originates upstream in the UI build. Or you can take the unbuilt UI, customise it and rebuild it yourself — which is what most teams actually want when they say local UI, and which means inheriting the UI build pipeline as something your mobile team now owns and maintains.
That second option is a real commitment. It is entirely doable, and it is how you get an app that feels designed rather than wrapped. But it needs to be a decision with a name against it, not a side effect of wanting faster screens.
What about offline
Local UI is often justified on offline resilience, and the argument is weaker than it looks. If the screen definitions ship with the app, the interface can render without a server — but the data behind it cannot. There is limited value in drawing a balance screen you have no balance for.
Where it genuinely matters is any journey that must work with no coverage: a document capture flow in a basement branch, an onboarding step in a rural location, a queued instruction a customer composes on a plane. Those are real and they do argue for local, but they are specific journeys rather than a whole-app position. Decide them individually.
How we usually land it
The split that tends to survive contact with a live bank: screens whose content is policy-driven and changes often — terms, disclosures, product lists, campaign surfaces — served remotely, so compliance can move without a release train. Screens where interaction quality is the product — login, the transfer flow, anything with meaningful animation or gesture — hosted locally, with the mobile team owning the build.
Then write the rule down. The failure mode here is not choosing wrongly; it is nobody choosing, so the balance gets set by whichever approach the first three screens used, and the bank discovers its release governance by accident a year later. The same applies to the other architectural calls in an OBDX deployment, which we covered in the architecture explainer.
Questions we get asked
What is the difference between remote and local UI?
Where the screens come from. Remote: the app loads them from the OBDX UI host, configured via the server URL in app.properties (Android) or app.plist (iOS). Local: they are bundled in the mobile workspace and ship with the app. Oracle's guides list remote server, local machine, or saved in the workspace — the middle one is for development.
Which is faster?
Local, generally — no network round trip before the interface renders, which shows most on first launch and poor connections. But caching and good loading states narrow that gap, whereas the governance difference can't be engineered away. Speed is the wrong variable to decide on.
Why is this really about release ownership?
Because it decides what must happen before a customer sees a change. Remote: deploy to the UI host, customers get it next session. Local: rebuild UI, rebuild app, store review, customer updates. One routes changes through the OBDX team, the other through the mobile team and the app stores.
Can you modify UI once it's bundled locally?
Not if you took the built UI — it is webpack-minified and Oracle's docs note it cannot be modified from within the mobile workspace. Either ship the built artefact and accept changes come from upstream, or take the unbuilt UI and rebuild it yourself, which means owning the UI build pipeline.
One-time setting or per-screen?
It can be either, and treating it as one-time is how banks end up somewhere they didn't pick. The pattern that survives: policy-driven, frequently-changing screens remote; screens where interaction quality is the product, local. What matters is that someone owns the rule explicitly.
Does remote UI work offline?
Not meaningfully — if screen definitions come from the server, the app can't render much without it. For most retail journeys that matters less than it sounds, since the data needs the server anyway. It matters for journeys that must work with no coverage, and those are worth deciding individually.
We make this call per screen on OBDX mobile builds, and we write the rule down at the start rather than discovering it later. If you are mid-project and the balance has drifted, it is recoverable — but it is easier to decide than to unwind.