Skip to content

How to build mobile apps like the world is ending

January 20, 2023Henry Deacy5 min read

Banner with RN, Expo, and Github logos.

When I began my career as an app developer, the main appeal to me was the idea that I could create without material. I didn’t need paint, bricks or steel, just my keyboard and enough time. Of course, another aspect which is becoming harder and harder to overlook is energy usage, and more importantly the carbon associated with it. The carbon footprint of the cloud is now larger than that of the commercial aviation industry, so it is vital that the software industry does what it can to mitigate the impact it is having on climate change.

With this in mind, I’ve put together five ideas that you could consider when building your own application. They are:

  1. Write apps for everyone
  2. Choose where to operate
  3. Choose when to operate
  4. Prioritise your features
  5. Think old school

There is a lot to say on each of these, and I’d love to devote an entire article to each one in the future, but for now here are some basic ideas to get you started - hopefully you’ll see that these are all achievable goals, will have an impact on the planet and more often than not help you in building a better app for yourself.

Write apps for everyone

One of our main priorities when it comes to sustainable app development is minimising operating time. Every second that an app is running requires energy, so has some small but direct impact on our carbon footprint. Scale this up to the billion users that Tik Tok has, and saving each user one second becomes 32 years of savings.

While you’re likely to have already looked into ways to save your average user time, you may be working on one of the ~30% of apps not compliant with basic accessibility standards. Considering one in six people are disabled (rising to one in four Americans), it’s likely that a good number of your users are going to face challenges while using your app which lead to higher energy consumption.

Most accessibility changes also make the experience better for all your users - some will lead to clearer screens and more obvious functionality, and others will lead to offering features which may be used universally in the future (e.g. subtitles). With so many reasons to make your app accessible already, it’s just an added bonus that doing this will lower your carbon emissions per user as well.

Choose where to operate

If you are interested in keeping your app’s carbon footprint low, you are likely already using cloud computing instead of your own servers. But while cloud service providers operate in ways that minimise the amount of energy you’ll use and in this way cut your carbon footprint, you can go one step further by ensuring that the energy you are using is renewable.

One way to do this is to consider in which region you are storing your data. If you choose to keep your data in, for example, Norway, your SCI (a.k.a. Software Carbon Intensity, the amount of carbon your software uses per kiloWatt hour) will be lower than if you keep your data somewhere like the United Kingdom. The main trade offs here include security policies in different countries and a delay in latency - which, if large enough, could lead to increased emissions - but by looking at the renewable energy each country produces you may find a balance between these considerations that works for you.

Choose when to operate

However, even once you’ve landed on a particular region to optimise your SCI, there may be more you can do to use as little carbon as possible. Say your app has a daily backup for all users at midnight each night - a smart time to do it as your users are likely to be offline. But imagine you’ve also done a ton of research for the previous step and picked a country famed for its excellent use of solar energy. If that region is in a similar time zone to your own then you won’t be reaping the benefits of the clean energy as their grid is likely to be using a lot more non-renewable energy at night time.

There are two options to mitigate this. The first option is to consider time zones as well when picking your region. The second option is to move whatever processes you can so that your heaviest workload is being done at the greenest times of day. With our daily backup, you’ll likely still want it to run at midnight local time, so option one is for you, but it’s worth considering both as much as possible!

Prioritise your features

Having an app that stands out from the rest is no easy feat, and the temptation might be to ensure your app can do absolutely anything your competitors can and more. But every single feature brings with it added complexity, and likely a higher carbon footprint. According to the Standish Group CHAOS Report 2020, about 80% of features on most apps are unused by almost all users, so ask yourself if having that extra video is worth the incremental cost to the planet.

There are also other benefits for yourself in the short term. Fewer features means fewer lines of code to maintain, likely fewer security vulnerabilities and a cheaper energy bill. Also, when a user wants to clean up their phone to get some memory space back, they’re likely to begin their purge by getting rid of the largest apps that they don’t use enough - so your sleek, low waste app will survive another day.

Think old school

Around 150 million phones are thrown away each year, with nearly 5 million of them going to landfills. Since a common reason for changing to a new phone is better performance, one thing you can do to discourage this behaviour is to ensure your app performs well on even the oldest phones still on the market.

A great way to do this is to optimise load times on legacy devices. Not only does this work effectively to deter you from ignoring performance constraints, but with everything running at its slowest, it is a lot easier to spot the particular pain points when it comes to getting through a particular user flow as efficiently as possible. I used this strategy recently on a React Native App while running Flipper and managed to find a point where the same static object was being rendered three times! Finding and fixing issues like this saves your users time and keeps phones from going to waste.

Final thoughts

If you manage to implement these five tips and tricks you’ll end up with an app that can be used easily by everyone, runs largely on clean energy, especially for its heaviest workloads, doesn’t have unnecessary bulk and loads quickly even on the oldest phones on the market. And you’ve likely saved yourself time, money and security issues in the process!

Stay tuned for follow up articles, where I’ll look at each of these five points in more detail.