THE MOBILEFLARE BLOG

Six months of MobileFlare

It has been just over six months since MobileFlare went live on the App Store. What started as a question (if something happened to me right now in this crowd, how would anyone know?) has turned into something I am genuinely proud of.

The app is live on both iOS and Android. It has been downloaded by people in multiple countries. We have had messages from stewards, event organisers, parents, and concertgoers.

This blog has been a record of the journey. The arguments about button colours. The App Store review delays. The moment Android went live. The quiet pride of shipping v1.3.0 with Spotlight. I've tried to write it as honestly as I could: the frustrations alongside the progress.

MobileFlare is a long game. Awareness is the whole challenge now. The app is ready. People just need to know it exists before the moment they need it. That's the work ahead.

Why the screen itself?

One of the questions I got early, when I started talking to people about the concept, was: why the screen? Why not sound? Why not vibration? Why not a notification that gets sent to nearby phones?

Sound fails in noise. At a concert, the ambient level makes shouting nearly useless, and a phone alarm would be worse. Vibration communicates nothing to someone who isn't holding the phone. Bluetooth mesh networking between phones is unreliable, power-hungry, and requires other people to have already downloaded the app to function.

The screen is different. It is the brightest, most attention-catching surface on your person. It works in darkness. It is visible at distance. It communicates information (colour) that can be pre-agreed. It works offline. It works in noise. It requires no infrastructure. It is already in your hand.

The answer was always the screen. The question was what to put on it.

Deciding on four signals

The question of how many signals MobileFlare should have came up early and got decided quickly: four. The reasons are worth recording.

Too few and you lose the specificity that makes the system useful. A single "help" signal tells you something is wrong, but not what a responder should be bringing with them. A medic running toward a Red signal needs to know to alert security, not bring a water bottle. A steward running toward a Yellow signal needs to start thinking about crowd management, not medical intervention.

Too many and the system breaks down. In a crisis, you cannot have someone scanning through a menu of eight options trying to find the right one. Four is a number a person can hold in their head without thinking.

The four signals (Red, Yellow, Green, Blue) map to the four most common distinct scenarios in crowd emergencies: personal safety threat, crowd pressure, medical emergency, and welfare need. They cover the space without overlap.

What "works offline" actually means

I say "works offline" a lot. It's one of the most important things about MobileFlare. But it's worth being specific about what that means and why it matters for crowds specifically.

At a large outdoor festival, mobile signal can be genuinely terrible. Thousands of people in a field all trying to use the same cell towers. At a sold-out indoor arena, the situation can be similar: concrete walls, a lot of radio interference, everyone on their phones. The moments when you're most likely to need help are often the moments when your signal is worst.

MobileFlare works offline because there's nothing to send. There's no server. No message to transmit. The app changes the colour of your screen. That's it. The only data it uses is the power in your battery.

The hold-to-activate question

One of the design decisions I keep returning to is the hold-to-activate mechanism. You don't tap a signal button; you press and hold for a fraction of a second before the screen activates.

This was almost cut. The counterargument is real: in an emergency, every millisecond counts. Why add any friction at all?

The answer is pocket activations. A tap-only interface in someone's pocket at a live event, with thousands of people pressing against each other, would result in accidental activations constantly. A false Red signal at a concert could pull stewards away from other situations. The hold is the minimum viable safeguard against that.

We tested the duration until we found something that felt like a clear intent gesture without feeling like a delay. The current implementation is the right call.

On naming signals

Naming the four signals was harder than naming the app itself.

The names have to work in two directions simultaneously. They need to be instantly understood by the person sending the signal, who may be panicked, in a crowd, in a dark venue, with limited time to read anything. And they need to be understood by the people receiving it: a steward, a medic, a security officer who has never used the app before but has seen the colour key once on a briefing card.

The current names (Personal Safety, Crowd Pressure, Medical Emergency, Water Please) are the result of many iterations. "Water Please" in particular went through a lot of versions. "Dehydration" is clinical and alienating. "I Need Water" is too long. "Water" alone feels incomplete. "Water Please" is immediate, human, and just slightly soft, which is right, because it's a welfare request, not an emergency. The politeness is intentional.

Thinking about venue partnerships

One of the things I keep coming back to is that MobileFlare works best when the people around you know what it means. An app that only you have downloaded is half an app.

The ideal scenario is a venue (a concert hall, a festival site, an arena) where the signal key is printed on a card that staff carry, displayed on a poster at the entrance, and where the app has been recommended in the pre-event communications. At that point, anyone who needs help has a real shot at being found.

The venues page has downloadable resources: a staff reference card, a publicity card for audiences, and an A3 poster. If you work at a venue or run events and want to talk about how MobileFlare could work for your audience, the form is there.

On building something nobody asked for

MobileFlare was not the result of market research. Nobody came to me and said "we need a crowd safety app." It came from a feeling: the feeling of standing in a dense crowd at a concert and realising that if something went wrong, I had no good way to communicate it.

Building something nobody asked for means you spend a lot of time explaining why it matters. The people who get it immediately are usually the ones who have been in that crowd, or who remember Hillsborough, or who watched the Astroworld documentary and felt the same thing I felt: that the gap between someone needing help and that help arriving is partly a communication problem.

The people who don't get it yet usually will, eventually. Something happens at an event, and suddenly the question becomes obvious. I'd rather MobileFlare exists before that moment than after it.

Spotlight: the thinking behind it

I've had a few questions about why Spotlight is part of MobileFlare at all. It's not an emergency feature. It doesn't fit the "distress signal" framing. So why include it?

A few reasons. First, the practical reality: crowd disorientation is extremely common at large events, and the consequences of it can escalate. Getting separated from a group can, in the wrong circumstances, lead to someone being alone and vulnerable. A non-emergency version of the visibility tool makes sense.

Second, it gives people a reason to have the app open before they need it for an emergency. Familiarity with the interface matters in a crisis. If you've used Spotlight at five events, you know exactly where the emergency buttons are if the moment ever comes.

Third, honestly, it was fun to build. And it fits the core idea: your phone screen is more useful than you think.

v1.3.0: Spotlight is live on both platforms

v1.3.0 is live on both iOS and Android. The headlining feature is Spotlight, a non-emergency crowd-finding tool that lets you light your screen in one of four distinct colours so your group can locate you without triggering an emergency signal.

Spotlight uses four colours that don't overlap with the emergency set: Cyan, Indigo, Magenta, and Orange. They're solid, non-flashing screens, visually completely distinct from an emergency signal. The idea is simple: agree with your group before you go in, "I'm Magenta," and if you get separated, hold it up.

It's a small feature but a meaningful one. Not every crowd problem is an emergency. Sometimes you just can't find your friends.

v1.2.0: iPad and iPod touch support is here

v1.2.0 is out, and the main addition is iPad and iPod touch support. A full-screen emergency signal on an iPad is genuinely striking. If anything, a larger screen is more visible at distance.

This one had been on the list since launch. The original build was iPhone-only because, in March, Apple reviewed it on an iPad mini and the layout didn't fit, so the quickest route to launch was to restrict installation to phones. v1.2.0 adapts the layout to work correctly across all Apple device sizes, with the same core functionality on every device.

The App Store listing is updated. iPod touch support is a nice bonus; there are more of them out there than you might expect.

v1.1.0: the button order argument, resolved

v1.1.0 is live. This was the release that settled the button order question, renamed Crowd Crushing to Crowd Pressure, and added colour blindness frequency differentiation.

The button order debate (which signal should come first) took longer than I'd like to admit. The final answer is Red, Yellow, Green, Blue. Red (Personal Safety) leads because it represents the highest-urgency emergency. The sequence reads as a gradient from most to least acute. Blue (Water Please) is last because it's a welfare signal, not an emergency.

The renaming from Crowd Crushing to Crowd Pressure was a deliberate tonal shift. "Crushing" is accurate but conjures images of the absolute worst outcomes, and it can read as hyperbolic in contexts where the situation is serious but not yet critical. "Pressure" is still accurate, still urgent, but doesn't carry the same weight of fatality that might cause someone to hesitate.

The colour blindness frequencies were genuinely important to get right. Each emergency signal now flashes at its own speed as well as in its own colour: Green slowest, Yellow faster, Red fastest. So the signals can be told apart even without being able to tell the colours apart. Water Please stays a calm, static screen.

v1.0.3 on iOS

A meaningful update to the iOS build. Water Please was redesigned as a calm, non-flashing static screen, reflecting that it is a welfare request rather than an emergency. A brief responsible use guide was added to the first launch of the app, appearing once and never again. A feature flags system was also introduced internally to allow features to be toggled without requiring a full release.

v1.0.2 on Android

A small but important fix to the Android build. A broken URL was identified and corrected. Nothing visible to most users, but the kind of thing that matters when someone is trying to share the app at an event.

iOS v1.0.1: the share / QR modal

Getting MobileFlare into more hands at live events was always the priority. It is most valuable when the people around you know what the colours mean.

v1.0.1 adds a share modal with built-in QR codes linking directly to the App Store and Google Play. Hold your phone up, let someone scan it, done.

This shipped first on iOS and landed on Android two days later. Small feature, big impact on the peer-to-peer sharing loop that MobileFlare depends on.

Android is live

MobileFlare is now available on Google Play. Android users, you can download it now.

After the iOS release in March, the Android build was completed, submitted, and approved. The comments on our first TikTok post were full of requests for Android, and this is the answer.

The Android version is functionally identical to iOS. Same signals, same button order, same interface, same no-login, no-data-collection approach. Both are built from the same codebase, so the experience of using it is the same.

The response

The first TikTok post reached around 80,000 views within the first week. For a first ever post with no following, no budget, and no promotion, that was unexpected. The feedback was mostly positive, with a lot of people saying they wished they had known about this at events they had been to.

The comments were also full of requests for Android and EU availability. Both noted, and both now addressed.

We're live on the App Store

MobileFlare is available to download on the App Store. After weeks of building, four rejections, two escalations, and more waiting than felt reasonable, it is out in the world.

I have been trying to think of something meaningful to say about this moment and mostly failing. The honest version is: it exists now. It didn't before. People can download it, and if they ever need it, it will be there.

That's enough for today.

Finally, approved

After what seemed like an eternity, the app was approved with no further changes. The waiting was over. Time to share it with the world.

Rejection number 4

It was almost as if the reviewer was viewing a cached version of the website, or simply wasn't looking. Guideline 3.1.1 was still flagged as the issue. I raised an escalation to have it looked at properly.

Rejection number 3

Despite my previous explanations, I removed the Donate button from the app, and the Donate page from the website. I still don't understand the interpretation of the guidelines, but I just needed to get the app out there.

Whilst the app was in review, sombr's concert at Brixton was in the news. You can search for this to see what happened. The app could have helped in this situation by drawing the attention of the stewards instead of sombr having to stop the performance. Frustrating, and it just highlighted the need for such an app.

Rejection number 2

I had hoped to accept tips and donations through the website to support development and cover costs of the app. It seems the Apple reviewer did not like this, as they interpreted it as unlocking features by means other than App Store payments. In my response, I explained that these were not payments to unlock any additional features, and they must have misunderstood. It was also via a website rather than the app, so surely couldn't be linked. I re-submitted.

Rejection number 1

Though I had designed the app to work only on mobile devices, and assigned it to just iPhone hardware, the app was reviewed by Apple using an iPad mini, and the display didn't quite accommodate the design. Two options: redesign for iPads, or figure out how to exclude installation on iPads. I found the setting to not allow installation unless the device is a phone, so it was time to rebuild and re-submit.

First submission

This was my very first submission to the Apple App Store, so another steep learning curve. Various different interfaces and pieces of information to provide, not necessarily in a flow of steps, more jumping back and forth. Now to wait.

Work begins

On an eBay-sourced used MacBook with a smashed screen, connected to an external monitor, I started work on the basics. The iOS store was the first target, so I downloaded Xcode and got started. Several iterations, modifications to button layouts, flash functionality, button press delays, usage optimisation.

I got up to speed with the iPhone Simulator, how fun to have a virtual iPhone and iPad on your desktop to play with, and eventually had a working proof of concept.

Apple Developer account

Application for the Apple Developer account was placed. This is a whole other story, with lots of lessons learned along the way. Maybe I rushed things a little, but it's done now, and thankfully I won't have to go through the process again.

I never realised how much was involved in setting this up, and ensuring it is done in the correct way. I'd never heard of a D-U-N-S number before, but now I'm very familiar!

Research begins

The thoughts which had been in my head could be contained no longer. I started researching if there was an existing method for raising an alarm at a well-populated event, in a noisy environment. I could find nothing even remotely close.

At the same time, I researched the media to find there were dozens of occasions where artists had stopped performances so that staff and stewards could locate, and tend to crowd members in distress. These stoppages received a lot of coverage, much on TikTok and Instagram, with some being headline news in national traditional press.

The idea

MobileFlare started with a simple question: if something went wrong at a live event right now, how would anyone nearby know? Standing in crowds at concerts across the UK, watching performances stop for crowd safety concerns and stewards struggle to locate people in distress, the answer was clearly: they wouldn't.

Your phone screen is the brightest object on your person. That is all MobileFlare needed to be. A colour-coded full-screen signal, visible above a crowd, that tells the people around you exactly what kind of help you need.