Data Visualisation: Building An Emergency Alerts App For MacOS

3 SIDED CUBE has been working on emergency alerting apps since the dawn of time… or at least almost the dawn of the company.

In 2012 we released the Emergency apps for The American Red Cross, and since then we have worked on creating additional disaster apps for both the GDPC (Global Disaster Preparedness Centre) and for The British Red Cross.

Our emergency apps work on the backbone of our alert API; a web service which scrapes data from multiple disaster-feeds across the globe to provide a system which can alert you to pretty much any disaster.

From volcanic eruptions to earthquakes and even nuclear attacks, all based on a set of ‘monitored locations‘ which you register with the API.

This data, (and more specifically the possibilities it provides) has always fascinated me and over the last few years, fueled the idea to work on a basic macOS app in my spare time.

The app allows you to view global disaster alerts at any point in the stored-history of our alerts system.

The macOS app has flourished into a great visualisation of not only our alerts data; but also a way to contextualise it with weather overlays (Radar, Satellite, Rainfall e.t.c.). Live lightning strikes and the Hurricane Tracker feature present in our American Red Cross Emergency apps, making it a great visualisation of disasters around the world.

Building it has also enabled me to take a dive into the world of macOS development, which has been a great learning curve for me and furthered my understanding as an iOS developer.

Whilst it’s interesting, somewhat useful (allows project managers to find locations with currently active alerts for testing), and informative to see our disaster information globally…

I wanted to spend this week making it even more useful for us and the end users of our iOS apps!

An issue we’ve had at times with our emergency apps is users claiming they did or didn’t receive an alert that they expected to, and debugging this can be complex; especially without access to the user’s device.

I pictured a ‘developer mode’ within the macOS app where you can take the user’s account information (accessible from the app settings) from their iOS or Android device and ‘take over’ their account from the macOS app.

Up until this point, doing something similar to this would have required a project manager to apprehend one of our server developers and getting him or her to manually do checks on the user’s account.

But with this update, it would become trivial for them to check the user’s account themselves.

With any major update to a project, there is always a bit of a task (Especially if you haven’t touched the code in a while) of updating it to work on the latest Operating System or with the latest version of the language you’re working in.

For me, I came back into this project mid-way through a re-write from Objective-C to Swift, and needing to upgrade to support macOS Sierra and above.

It saves time (and budget) in the long run to work on your code regularly and keep it up to date.

There are two pieces of information we need to take over the user’s account:

1. Their account identifier (A random string generated by the iOS app they are using)
2. Their device’s identifier (A system generated string identifying the user’s device).

Getting these from the iOS apps required me to write a small line of code to add to those projects and make them visible in the iOS settings apps. But luckily (for me) they were already available in our Android apps.

Once I had these, it was a simple task of creating a basic UI for the user to enter these two pieces of information, and then a not so simple task of making our pre-existing code interact with our alerts system, and accept these overrides to the account it is using.

Once I got there though, it became immediately obvious how powerful this was going to be in debugging issues for our users.

Removing a location on my test iOS device and refreshing on the macOS app immediately reflected the change. 

The new feature allowed me to see critical information about the users’ account; which emergencies they wanted alerts for and whether they had a push token (used to send push notifications to a user).

Emergency for macOS is still very much an internal tool, and the current implementation of the debug mode still requires a bit of technical knowledge to use.

In the future, I want to build a better UI around the debug mode rather than just showing the raw data which it is currently displaying. To make it even easier for our Project Managers to debug critical issues for real end-users of our apps, who rely on them for protection and to keep themselves safe.

I also dream of the day when this can be made available to the public, and they too can receive critical, worldwide, disaster alerts and information for themselves and their loved ones.