A web design and development studio

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.

If you made it this far, you may also like

Creating an infinite gallery with vanilla JS


In the maiden voyage of Stylin', I'll show you how to build a simple, smooth gallery using just a couple lines of code.