So you’ve decid­ed that you want — no need — a new app for your busi­ness idea. Good for you! You’ve just entered the bewil­der­ing world of app devel­op­ment. We’re here to help lead you through its inscrutable landscape.

We don’t have the required per­mits, we’ve not reg­is­tered with a local gov­ern­ment body and we can’t promise you’ll come out alive, but we’ve done this before — it’s usu­al­ly fine.

What is an app?

Let’s start with a sim­ple ques­tion: what is an app? Wikipedia tells us that that an app is a piece of soft­ware that per­forms some sort of func­tion to solve a prob­lem. Nowa­days we’re all very famil­iar with apps as we poten­tial­ly have 100s of them in our pocket.

Smart­phones have gone a long way to nor­mal­is­ing the idea of apps to the gen­er­al pub­lic. Pri­or to smart­phones, apps were spe­cialised; often known as soft­ware pack­ages”, pro­grams” or bun­dles.” Some­times they were share­ware,” some­times they were free­ware.” These archa­ic terms have made way to a much sim­pler under­stand­ing of what apps are.

Unfor­tu­nate­ly, while it looks so sim­ple from the out­side, what’s going on behind the scenes is a lit­tle bit more complicated.

Where is an app?

The next ques­tion we need to ask our­selves is: where does our app need to run? Are we cre­at­ing the next Can­dy Crush? We prob­a­bly want that avail­able on all mobile plat­forms. Are we mak­ing a new finan­cial trad­ing fron­tend? Might work best as a web appli­ca­tion. Are we build­ing nuclear pow­er plant con­trol soft­ware? Prob­a­bly needs to be desk­top based or on spe­cial­ist hard­ware (we’re cur­rent­ly doing a 2‑for‑1 on all nuclear pow­er plant soft­ware — please enquire).

The point here is that there are a large num­ber of plat­forms that your app could be built for.

Let’s list out some major platforms: 

  • Mobile and tablet devices
    • Android
    • iOS
    • Win­dows 10 Mobile
  • Desk­top devices
    • macOS
    • Win­dows
    • Linus
  • Web Browsers
  • TVs
    • WebOS
  • Wear­ables
    • Galaxy Watch
    • watchOS
  • Embed­ded Devices
  • Toast­ers
  • Foot Spas

As you can see, there are a huge num­ber of plat­forms we need to con­sid­er when build­ing an app. 

What’s more, some of these plat­forms are pub­lic or open source while oth­ers are pri­vate and proprietary. 

For exam­ple, if I’m devel­op­ing a web appli­ca­tion, I can use one of a num­ber of soft­ware frame­works and tech­nolo­gies to build my app for free. This app will also like­ly run on a num­ber of dif­fer­ent browsers. The web is a great exam­ple of an open and free plat­form that was intend­ed for every­one’s access. 

Oth­er plat­forms are closed gar­dens. If I’m devel­op­ing for macOS, I need to pay Apple $100/​year for the priv­i­lege of pub­lish­ing apps on their plat­form. I gen­er­al­ly have to use their tools and devices to devel­op my app. 

The Old World

OK, we’ve decid­ed on our ini­tial plat­form. Now what? Let’s look at how app devel­op­ment tra­di­tion­al­ly works in this scenario.

Depend­ing on the plat­form we’ve picked, there are usu­al­ly a num­ber of pro­gram­ming lan­guages and devel­op­ment envi­ron­ments relat­ed to that platform. 

Let’s con­sid­er a sin­gle exam­ple: I want to devel­op an Android app. As the busi­ness stake­hold­er, I see a fly­er in my local laun­dry­mat offer­ing Android app devel­op­ment for an attrac­tive price. I get in touch and off we go …

Let’s spec­u­late on what our new devel­op­er will do:

  • They’ll prob­a­bly first down­load the Android Stu­dio IDE (devel­op­ment envi­ron­ment) to make their life easier.
  • They’ll write the appli­ca­tion code in either Java or Kotlin, the two lan­guages native­ly sup­port­ed by Android.
  • They’ll inter­face with the Android SDK, which includes all of the helper tools that the Android team have devel­oped. These tools allow our app to eas­i­ly talk to the 100s of dif­fer­ent sen­sors and com­po­nents of a mobile device.
  • They’ll build the code to a runnable appli­ca­tion instance that you will see on your home screen and be able to test out.
  • They’ll final­ly dis­trib­ute this appli­ca­tion on the Google App Store for oth­ers to install.

Keep in mind, they could also take your ini­tial pay­ment and make a bee­line to Pana­ma where you’ll nev­er hear from them again. We’ll cov­er this alter­na­tive work­flow in a sep­a­rate post. 

As the devel­op­er, there are many ben­e­fits of the more stan­dard­ized devel­op­ment approach list­ed above. 

  • Inte­gra­tion: they’re using the same tight­ly inte­grat­ed tools devel­oped by the Android team to devel­op the app. These tools are designed to make the process or cre­at­ing the app real­ly quick and easy.
  • Per­for­mance: they can direct­ly inter­face with every­thing need­ed on the device. Because they’re devel­op­ing direct­ly on the Android plat­form, they can write real­ly fast and per­for­mant apps.
  • Main­te­nance: they can gen­er­al­ly diag­nose prob­lems quite quick­ly, as they’re using a native envi­ron­ment that is well under­stood and easy to debug.

Sign me up — this sounds great! In many cir­cum­stance, this is great. As long as you know exact­ly what you need now, as well as in the future, this a per­fect­ly good approach to take.

Here comes the but

Mul­ti-plat­form apps

Imag­ine our app has been very suc­cess­ful and we now want to devel­op an iOS ver­sion. It’s pos­si­ble that the great Android devel­op­er we found above does­n’t know much about the Apple plat­form. We now need to go find a sec­ond devel­op­er and pay them to re-devel­op our app for iOS. What if we then want to deploy the app on the web? We need a third devel­op­er. We now want to add a new fea­ture to the app. Time to call all three devel­op­ers and ask them to cre­ate that new fea­ture on each of their plat­forms. Oh God — time to remort­gage the house.

Unless you are a large com­pa­ny with lots of resources, cre­at­ing a native appli­ca­tion on mul­ti­ple plat­forms is sim­ply too expen­sive to take on.

The New World

Wel­come to the new world of app devel­op­ment. It’s not nec­es­sar­i­ly a bet­ter world, but it’s cer­tain­ly a way out for those who want to write big apps on a small(ish) budget.

In this new world, instead of nav­i­gat­ing each plat­form indi­vid­u­al­ly, one sin­gle plat­form has been cho­sen as the defac­to envi­ron­ment in which to write all appli­ca­tions. That plat­form is the web.

For bet­ter or worse, we can now cre­ate a sin­gle cross-plat­form appli­ca­tion using the asso­ci­at­ed lan­guages of the web (CSS, HTML and JavaScript) and then deploy this to a num­ber of oth­er dif­fer­ent plat­forms like iOS, Android, Lin­ux, Win­dows, macOS etc.

To do this, we can use one of a num­ber of new frame­works and tools:

  • Cor­do­va
    • Phone­Gap
    • Ion­ic
  • Xam­arin
  • React Native
  • Electron.js

Wait, I thought we were done with lists? This seems strange­ly sim­i­lar to the old world?” Well…yes. While we’ve sim­pli­fied the lan­guages we use to build our apps, as the devel­op­er, we still need to choose the tool to build this code­base to a mul­ti­tude of platforms. 

But as a busi­ness stake­hold­er, this means you only need to find a sin­gle web devel­op­er (or small team) to build an app that can be deployed far and wide. You’ll then have one easy-to-man­age code­base that you can build on and you’ll only need to cre­ate each new fea­ture once.


Sad­ly, it’s not that sim­ple. While this is fan­tas­tic in the­o­ry, there are a num­ber of poten­tial short­com­ings to this approach that you need to be aware of.

  • Per­for­mance: this is the big one. We now have a web appli­ca­tion, run­ning in a web brows­er, mas­querad­ing as a native app. It looks like a native app, but it does­n’t per­form as a native app. This isn’t a prob­lem if you are run­ning a sim­ple con­tent-based app, but if you’ve got a game or oth­er app that demands per­for­mance, you’re going to have a bad time.
  • Inte­gra­tion: again, your app is now oper­at­ing in the brows­er, not native­ly on the device. Want to use the cam­era? Let’s hope the tool you are using allows you to do that eas­i­ly on all plat­forms. Want to get GPS loca­tion? Ha! You fool! Did­n’t you know this tool does­n’t work with GPS? Sur­prise! This is a place where not know­ing what you need in the future can come back to haunt you.
  • Com­plex­i­ty: although we’ve sim­pli­fied to a sin­gle code­base, we now have to take into account the quirks of all the plat­forms we are inter­est­ed in. We’ll need to turn on and off fea­tures based on our envi­ron­ment, debug issues spe­cif­ic to one plat­form, and so on.


The app land­scape has got­ten more and more murky over the last few years as the web has start­ed to eat up appli­ca­tion devel­op­ment, and as more and more peo­ple turn to HTML, CSS and JavaScript as their lan­guage of choice for build­ing things. 

This leaves us with two broad approach­es to devel­op­ing a new app: the native approach vs. the mul­ti-plat­form approach.

Which you decide upon is large­ly a ques­tion of resources. If you can, it might be worth cre­at­ing a sep­a­rate web, mobile and desk­top app. If not, the new world” awaits.