A campus safety app is judged on what happens after somebody taps the button.

What a campus notification is required to do

Federal rules are specific here, and they are worth reading before designing any screen. An institution must have procedures to immediately notify the campus community upon the confirmation of a significant emergency or dangerous situation involving an immediate threat to the health or safety of students or employees occurring on the campus. The word doing the work is confirmation. Somebody has to establish that the thing is real, and that step belongs in the product.

The rule then describes the process in four parts, and each one is a screen. Confirm that there is a significant emergency or dangerous situation. Determine the appropriate segment or segments of the campus community to receive a notification. Determine the content of the notification. Initiate the notification system. A campus security app that begins at part four, with a free text box and a send button, has skipped three quarters of the job.

There is an exception to design for as well. The institution acts without delay unless issuing a notification would, in the professional judgment of responsible authorities, compromise efforts to assist a victim or to contain, respond to or otherwise mitigate the emergency. That is a human decision with a reason behind it. The reason should be captured in the same record as the alert, because it is the thing anyone will ask about afterwards.

Timely warnings are a separate duty and deserve a separate flow. They cover reported crimes the institution considers a threat to students and employees, they withhold victims' names and other identifying information, and they aim to help prevent similar crimes. On top of that, emergency procedures have to be tested at least annually, announced or unannounced, with each test documented: a description of the exercise, the date, the time and whether it was announced. Build the test mode and that log at the start, not the week before the review.

34 CFR 668.46, timely warning, emergency notification and annual testing

An alert reaches installs, not people

The roster is not the audience. An app reaches a phone only if the person installed it, opened it, allowed notifications and did not later turn them off. Every one of those steps loses people, and none of the losses show up in an enrolment figure. If the plan says the app notifies the campus community, the plan rests on a fraction of that community, and nothing tells you which fraction.

This is why campus alerting is almost always several channels fired together: text messages to the numbers in the student record, email, desktop takeover, outdoor speakers. The app is not the channel that guarantees arrival. It is the channel that can carry a map, an instruction, a photo and a follow up. Treat it as the richest channel rather than the only one and most of the design arguments go away.

Measure the real number and keep measuring it. Installs with notifications enabled, broken out by group, refreshed every term, is a metric somebody should own by name. At a forty percent install rate the app is a useful supplement. The same app described to a board as campus coverage is a problem waiting for a bad night.

The receiving end needs its own answer too. Confirming an incident, dispatching a patrol and closing the case is not the same job as tapping a button while walking home, and that view has far more in common with a first responder app than with anything in a student's pocket. Two apps, or one app with two honestly different modes, but never one screen pretending to serve both.

Getting an alert onto a phone that is on silent

A normal push obeys the phone. Silent mode, Do Not Disturb, a focus, a scheduled summary: any of them can hold the message until later, which is precisely what you do not want from an emergency alert app for campus. Apple has one exception for this case. Critical alerts ignore the mute switch and Do Not Disturb, and the system plays the sound regardless of those settings, with a custom sound and volume if you set one.

The catch sits in the same documentation. Critical alerts require a special entitlement issued by Apple. You request it, you explain the use, and you may not get it. Design so that a refusal is survivable, because an alerting plan that only works with the entitlement has a single point of failure you do not control.

One question comes up on every small build: can you reach every installed device at once without paying for a notification platform. Here is what we could confirm. In a Newly build, push notifications are connected from a card inside the chat, the notification service is created for your project, and there is no separate account to sign up for at that step. What the documentation describes from there is a test send and a view of recent sends, not a documented control for broadcasting to every installed device. Reaching a real iPhone also needs your own Apple Developer account and a build people have actually installed. We could not verify an audience ceiling or a volume limit on the service behind that card, so confirm both before planning around a campus of thousands.

The layer underneath goes deeper than this page does: device tokens, batching, a phone that has been offline for a week, and the per request limits on a single send. If you are building an alert that has to arrive now, that is where the real work is, because the gap between one second and four minutes lives entirely in it.

Apple, UNAuthorizationOptions criticalAlert

What the app does on the days nothing happens

An app installed only for an emergency is an app that gets deleted in week three. The features that keep it on the phone are ordinary ones: shuttle times, a walk home request, a report of a broken light or a blocked exit, lost property, an anonymous tip form that goes where tips actually go. None of them are exciting. They are the reason the alert feature has anybody to alert.

The escort timer is the one that earns its place. Someone sets a destination and an expected arrival, and if they do not check in, whoever is on duty is told. The product is in the failure modes, not the happy path. What happens with no signal in a stairwell. What happens when the battery dies. Who is called, in what order, and how long each step waits. How a false alarm is cancelled without embarrassment, because an escort tool that is awkward to cancel stops being used.

Big nights are a different problem again. Orientation, move in weekend and game days bring thousands of people onto campus who are in no directory at all, which is closer to an event check in app than to daily operations. Decide early whether visitors are in scope, because the answer changes the sign in, the data you hold and the channels you need.