So you’ve decided that you want — no need — a new app for your business idea. Good for you! You’ve just entered the bewildering world of app development. We’re here to help lead you through its inscrutable landscape.
We don’t have the required permits, we’ve not registered with a local government body and we can’t promise you’ll come out alive, but we’ve done this before — it’s usually fine.
What is an app?
Let’s start with a simple question: what is an app? Wikipedia tells us that that an app is a piece of software that performs some sort of function to solve a problem. Nowadays we’re all very familiar with apps as we potentially have 100s of them in our pocket.
Smartphones have gone a long way to normalising the idea of apps to the general public. Prior to smartphones, apps were specialised; often known as software “packages”, “programs” or “bundles.” Sometimes they were “shareware,” sometimes they were “freeware.” These archaic terms have made way to a much simpler understanding of what apps are.
Unfortunately, while it looks so simple from the outside, what’s going on behind the scenes is a little bit more complicated.
Where is an app?
The next question we need to ask ourselves is: where does our app need to run? Are we creating the next Candy Crush? We probably want that available on all mobile platforms. Are we making a new financial trading frontend? Might work best as a web application. Are we building nuclear power plant control software? Probably needs to be desktop based or on specialist hardware (we’re currently doing a 2‑for‑1 on all nuclear power plant software — please enquire).
The point here is that there are a large number of platforms that your app could be built for.
Let’s list out some major platforms:
- Mobile and tablet devices
- Android
- iOS
- Windows 10 Mobile
- Desktop devices
- macOS
- Windows
- Linus
- Web Browsers
- TVs
- WebOS
- WebOS
- Wearables
- Galaxy Watch
- watchOS
- Embedded Devices
- Toasters
- Foot Spas
As you can see, there are a huge number of platforms we need to consider when building an app.
What’s more, some of these platforms are public or open source while others are private and proprietary.
For example, if I’m developing a web application, I can use one of a number of software frameworks and technologies to build my app for free. This app will also likely run on a number of different browsers. The web is a great example of an open and free platform that was intended for everyone’s access.
Other platforms are closed gardens. If I’m developing for macOS, I need to pay Apple $100/year for the privilege of publishing apps on their platform. I generally have to use their tools and devices to develop my app.
The Old World
OK, we’ve decided on our initial platform. Now what? Let’s look at how app development traditionally works in this scenario.
Depending on the platform we’ve picked, there are usually a number of programming languages and development environments related to that platform.
Let’s consider a single example: I want to develop an Android app. As the business stakeholder, I see a flyer in my local laundrymat offering Android app development for an attractive price. I get in touch and off we go …
Let’s speculate on what our new developer will do:
- They’ll probably first download the Android Studio IDE (development environment) to make their life easier.
- They’ll write the application code in either Java or Kotlin, the two languages natively supported by Android.
- They’ll interface with the Android SDK, which includes all of the helper tools that the Android team have developed. These tools allow our app to easily talk to the 100s of different sensors and components of a mobile device.
- They’ll build the code to a runnable application instance that you will see on your home screen and be able to test out.
- They’ll finally distribute this application on the Google App Store for others to install.
Keep in mind, they could also take your initial payment and make a beeline to Panama where you’ll never hear from them again. We’ll cover this alternative workflow in a separate post.
As the developer, there are many benefits of the more standardized development approach listed above.
- Integration: they’re using the same tightly integrated tools developed by the Android team to develop the app. These tools are designed to make the process or creating the app really quick and easy.
- Performance: they can directly interface with everything needed on the device. Because they’re developing directly on the Android platform, they can write really fast and performant apps.
- Maintenance: they can generally diagnose problems quite quickly, as they’re using a native environment that is well understood and easy to debug.
Sign me up — this sounds great! In many circumstance, this is great. As long as you know exactly what you need now, as well as in the future, this a perfectly good approach to take.
Here comes the but …
Multi-platform apps
Imagine our app has been very successful and we now want to develop an iOS version. It’s possible that the great Android developer we found above doesn’t know much about the Apple platform. We now need to go find a second developer and pay them to re-develop our app for iOS. What if we then want to deploy the app on the web? We need a third developer. We now want to add a new feature to the app. Time to call all three developers and ask them to create that new feature on each of their platforms. Oh God — time to remortgage the house.
Unless you are a large company with lots of resources, creating a native application on multiple platforms is simply too expensive to take on.
The New World
Welcome to the new world of app development. It’s not necessarily a better world, but it’s certainly a way out for those who want to write big apps on a small(ish) budget.
In this new world, instead of navigating each platform individually, one single platform has been chosen as the defacto environment in which to write all applications. That platform is the web.
For better or worse, we can now create a single cross-platform application using the associated languages of the web (CSS, HTML and JavaScript) and then deploy this to a number of other different platforms like iOS, Android, Linux, Windows, macOS etc.
To do this, we can use one of a number of new frameworks and tools:
- Cordova
- PhoneGap
- Ionic
- Xamarin
- React Native
- Electron.js
- …
Wait, I thought we were done with lists? This seems strangely similar to “the old world?” Well…yes. While we’ve simplified the languages we use to build our apps, as the developer, we still need to choose the tool to build this codebase to a multitude of platforms.
But as a business stakeholder, this means you only need to find a single web developer (or small team) to build an app that can be deployed far and wide. You’ll then have one easy-to-manage codebase that you can build on and you’ll only need to create each new feature once.
- THE END -
…
…
Sadly, it’s not that simple. While this is fantastic in theory, there are a number of potential shortcomings to this approach that you need to be aware of.
- Performance: this is the big one. We now have a web application, running in a web browser, masquerading as a native app. It looks like a native app, but it doesn’t perform as a native app. This isn’t a problem if you are running a simple content-based app, but if you’ve got a game or other app that demands performance, you’re going to have a bad time.
- Integration: again, your app is now operating in the browser, not natively on the device. Want to use the camera? Let’s hope the tool you are using allows you to do that easily on all platforms. Want to get GPS location? Ha! You fool! Didn’t you know this tool doesn’t work with GPS? Surprise! This is a place where not knowing what you need in the future can come back to haunt you.
- Complexity: although we’ve simplified to a single codebase, we now have to take into account the quirks of all the platforms we are interested in. We’ll need to turn on and off features based on our environment, debug issues specific to one platform, and so on.
Summary
The app landscape has gotten more and more murky over the last few years as the web has started to eat up application development, and as more and more people turn to HTML, CSS and JavaScript as their language of choice for building things.
This leaves us with two broad approaches to developing a new app: the native approach vs. the multi-platform approach.
Which you decide upon is largely a question of resources. If you can, it might be worth creating a separate web, mobile and desktop app. If not, the “new world” awaits.
