How to get native and cross-platform mobile right
The version of this that works is simpler than the version most people imagine. The short answer to native and cross-platform mobile is that it is mostly a sequence of small decisions, not one big one.
Mobile releases are slower to correct than web ones, so the cost of shipping a mistake is higher. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
What is actually at stake
Cross-platform is a team decision as much as a technical one. The teams that handle this well are rarely the ones with the biggest budgets. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
The steps
- Establish what you have today before changing anything
- Heavy device integration still favours native
- Shipping one codebase badly is worse than two well
- Write down the decision so the next person does not re-litigate it
Shipping one codebase badly is worse than two well. In practice this is a scheduling problem more than a technical one. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
What to do next
In practice
The version of the app your customers are running is rarely the one you just shipped. Three things worth confirming about native and cross-platform mobile before you move on:
- Someone can say what the current setup is without going to look
- Shipping one codebase badly is worse than two well — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you want a second opinion on how yours is set up, ask.