Building native enterprise apps is (probably) the wrong approach

I’ve spent the previous few years now building apps for various enterprises. These have generally been data entry apps and included the fleet management sector and enforcement officers (formerly called bailiffs). Most enterprise apps tend to be fairly simple and mainly allowing CRUD operations to be performed.

In such cases, x-platform development is the obvious choice of development. Most enterprise apps don’t require native functionality and most perform fairly un-sophisticated data entry.

The key question then is when to go native and when to go x-platform when building an app for the enterprise.

When to use x-platform technology.

- Your app doesn’t require native device functionality either now or in the forseeable future. Don’t build native “just because you might need it later”. That is breaking the YAGNI (you ain’t gonna need it) principle of software development. You are adding substantially to your development costs for something that may never happen. If you have designed and developed your app using good separation of concerns, then it shouldn’t be an onerous task to build the front-end of the app natively in the future if requirements change. If you app is poorly designed, then obviously changing across to native later on will incur more significant development costs.

- Your app requirements are fairly simple. If you are developing an app that will allow users to perform simple CRUDoperations then this doesn’t require native development. X-platform tooling builds these sorts of apps easily. Input forms and grids are easily achieved. Building a simple CRUD app natively makes no sense at all. The marginal gains in performance and UI / UX will be completely over-shadowed by the more than significant increased development costs.

- You have a small development team and don’t have the resources to build native apps. Unless you are a large development team such as Facebook with the required specialist skills for developing native apps, then building x-platform allows you to build, test and ultimately release multiple versions of the app simultaneously i.e. to the Apple and Google stores at the same time. Far too many times I’ve heard the phrase “We have an app for platform X but not for Y. We’re still working on Y”. Unless you have the resources and skills to release to all your intended platforms at the same time, then chances are you’ve made the wrong technical decision.

Making the wrong choice with regards to your mobile app can be costly. You are effecively doubling your development resources both in terms of time and cost. These are not trivial costs. Unless you have a specific reason for building your app natively, then you should seriously consider going x-platform. There are many options to take. Some of the more current x-platform tools even build native UI controls for the target device, giving the end user an almost identical experience.

There are obviously very good reasons for building your app natively, but in my experience, general purpose data entry apps for the enterprise don’t meet those requirements. In such cases, x-platform will be the better choice. Even if you have the necessary skills and a team capable of building such an app, it still doesn’t mean that you you should. And if you don’t have the necessary team size and skills, then you almost certainly shouldn’t go native unless you can afford to have this work outsourced.

Before deciding what tools and technologies to use when building your next enterprise app, be sure to very carefully consider the costs and benefits involved. Making the wrong decision can be costly.

A father, cyclist, vegetarian, atheist, geek and multiple award winning technical author. Loves real ale, fine wine and good music. All round decent chap.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store