Your Apps on Every Platform: Android, iOS, Web and Console, and Keeping Versions Under Control

An established money transfer operator rarely has one app. It has an Android app, an iOS app, a web client and the console its own staff use, each released on its own timetable, with customers spread across several versions of each. Most of the time that is fine. On release day, or the day a store review is slow, it is where errors come from.

Keeping that estate under control is not an engineering nicety. Customers on a supported version see fewer errors and fewer surprises, and an operator that controls rollout decides when a change reaches customers rather than finding out afterwards.

This guide is for CTOs, product owners and the app teams who ship your customer apps. It uses RemitSo's Platform & Apps module as the worked example. RemitSo registers your applications, manages their versions, checks that only genuine apps connect and tells your app team what changes in each release. Your team still builds and publishes the apps, chooses when to roll out and supports customers through the change.

Start with an honest list of everything that talks to your backend. In RemitSo, Platform & Apps holds the applications registered for each platform: Android, iOS, Web and Console. Each application is marked active or not.

That active flag matters more than it looks. An old build you no longer support, a test app from a previous agency, a web client you retired last year: if it is still active, it is still part of your estate. Switching off what you no longer support is the first step in controlling what customers use.

The platform matters beyond the app list. In RemitSo, exchange rate rules can give a different rate to the customers of one platform (web, iOS or Android), limits can be set per route and per app, and payment channels can be configured by platform. Keep the app list and those settings in step.

Each app has versions, and customers do not all update on the same day. Some update within hours; some keep an old version for months. Your backend has to work with every version you still support, and your team has to know which ones those are.

In RemitSo, application versions are managed in the console for compatibility and rollout. In practice that gives your team three decisions to make and write down for each app:

• The current version: what a new customer downloads today.
• The oldest supported version: the earliest build you still test against and will answer support tickets about.
• The rollout plan: when a new version becomes the one you expect customers to be on, and what happens to the old one.

Store review times differ between platforms, so a version can be live on Android a day or more before it reaches iOS customers. Plan your rollout around the slower store, not the faster one.

A money transfer backend is a target. Fake or tampered copies of an app can be built to harvest credentials or probe the backend. In RemitSo, only genuine apps can connect: app integrity checks stand between the backend and anything that is not one of your published apps.

For customers, that is protection they never see. For your team, it means the traffic reaching your backend comes from apps you published.

The same thinking applies to sign-in. Sign-in, sign-up, verification codes and password resets are rate-limited in the apps and the console, and a customer who hits the limit is told "too many requests" in their own language. For more on how backends spot fake apps, see mobile app security.

Customers sign in quickly and safely: a one-time code, then a PIN, Face ID or fingerprint. The PIN length is your decision. In RemitSo each deployment chooses its customer PIN length, configurable from four to eight digits.

A longer PIN is harder to guess; a shorter one is quicker to type and easier to remember. Weigh that against your customers and your risk appetite. Decide it before launch where you can, and if you change it later, test what enrolled customers see and brief customer service first.

Two practical points before you change it:

• Tell customer service first. They will hear about it before your app team does.
• Remember the device list. Customers can see every signed-in device and remove a lost phone in one tap; its sessions, PIN and Face ID sign-in stop working. Point support scripts at that, not at a PIN reset.

Planned work is where app estates show their gaps. If an app does not know maintenance is under way, the customer sees an error instead of an explanation.

In RemitSo, apps can ask whether the service is available. A maintenance window is booked ahead with a start, an expected finish and a customer message, and it names what it holds: new transfers, payments, wallet loads (wallets being an optional add-on, where your licence allows), payouts or scheduled work. It never takes the platform down, money already in flight carries on, and it holds until somebody lifts it.

For your app team, that means one job: make sure every supported version asks and shows the message properly. A version that does not is a version that should leave your supported list. See zero-downtime maintenance for the operational side.

Your mobile apps and web client talk to the backend through the Client API. In RemitSo that API is documented inside the console, in the API Documentation module: a live reference served from the deployed route table, so it is kept in step with the API your environment actually runs.

That has a practical benefit for app teams working with an established platform. They do not have to ask anyone for a document that might be out of date; they read the reference for the environment they are building against. Releases are tested on your staging environment first, so the app team can check a new version there before it reaches customers.

For a broader checklist on judging an API, see evaluating a remittance API.

RemitSo releases are numbered by date, every environment shows exactly which release it runs under Environment Overview, and each release note says what changed, whether it needs a maintenance window and what action is needed, including new permissions and alerts. Your app team should read it as their brief.

The release note also tells you whether a maintenance window is needed. Most releases no longer need customers stopped; when one does, book the window and let the apps' availability check carry the message.

The numbers below are illustrative, chosen to show the reasoning rather than to describe any real operator.

An established operator supports four Android versions and three iOS versions. Release day takes the app team most of a day because each version must be tested. Support tickets cluster on the oldest Android build, which handles the maintenance message poorly: customers see a generic error during planned work.

Step 1: decide the supported list

The product owner sets a rule: support the current version and the one before it, on each platform. That retires two Android versions and one iOS version.

Step 2: give customers time

The team publishes the current versions in both stores, waits for iOS review, and uses a broadcast to tell customers that older versions are being retired on a set date.

Step 3: update the records

On the date, the team updates the application versions in Platform & Apps to reflect the new rollout, and checks that only supported applications are active.

Step 4: the next release day

The next release day tests four versions instead of seven. Maintenance messages show properly on every supported version, and the tickets about the generic error stop.

Platform & Apps, with the API reference and release notes around it, keeps your app estate under your control. See the admin features and the customer app features.

• Applications per platform, Android, iOS, Web and Console, each active or not, so your team knows exactly which apps can reach the backend.
• Application versions managed for compatibility and rollout, so your team decides when a version reaches customers and your customers stay on versions that work.
• Only genuine apps connect, so your customers are protected from tampered copies and your team knows the traffic is yours.
• PIN length from four to eight digits, chosen per deployment, so your team sets the balance between security and convenience for your customers.
• Apps can ask whether the service is available, so during planned work your customers see your message, not an error.
• The Client API documented in the console, kept in step with the API, so your app team builds against what your environment actually runs.
• A release note for every release, saying what changed, the action needed and whether downtime is needed, so your team plans release day instead of reacting to it.

What your team still does: build and publish the apps, decide the supported versions, test on staging and support customers through each change.

To see the module against your own apps, book a demo.