Native and cross-platform mobile: what to get right first

The gap between knowing this and actually doing it is where most teams lose ground. If you only fix one thing about native and cross-platform mobile this quarter, make it the first item below.

Mobile releases are slower to correct than web ones, so the cost of shipping a mistake is higher. Budget a little time for it every quarter and it never becomes a project of its own.

Start here

Cross-platform is a team decision as much as a technical one. In practice this is a scheduling problem more than a technical one. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Then this

Heavy device integration still favours native. Small and consistent beats large and occasional here. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Eventually

Shipping one codebase badly is worse than two well. It is worth being explicit about, because assumptions differ quietly. It rarely shows up as a line item, which is exactly why it slips.

The short version

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
• Heavy device integration still favours native — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.