Web access is a core workflow#
Responders can sign in, review incidents, acknowledge, and resolve through the customer-hosted Web application. Use the deployment's HTTPS origin and trusted certificate chain. Browser-based response does not require APNs, FCM, or a public cloud service.
iOS and Android apps#
AckNexa has native iOS and Android apps. Both list incidents with live updates, acknowledge and resolve through the API, show your on-call shifts and cover requests, your team and your notification history, and open the incident when you tap a page. An action is shown as successful only after the API confirms it. Session tokens are stored per server: in the iOS Keychain, and encrypted with the Android Keystore.
On Android, P1 pages use a separate alarm channel that can show a full-screen notification when the phone allows it; other pages use a high-importance channel.
How the apps are distributed#
For release 1.0.0-rc.1 neither app is published in the App Store or Google Play. The operator builds them from source: the iOS app with Xcode and their own Apple developer account (TestFlight can distribute it to a pilot group), and the Android app with Android Studio or Gradle, their own Firebase project and their own signing key. Signing, device trust and real-device testing are deployment responsibilities.
How pages reach a phone#
| Path | What the server needs | Connectivity |
|---|---|---|
| iOS, self-built app | The customer's own APNs key (APNS_* settings or Apple push under Notification Providers). | Outbound to Apple; the phone also needs Apple connectivity. |
| Android, self-built app | The customer's own Firebase service account for FCM HTTP v1 (FCM_SERVICE_ACCOUNT_FILE, optional FCM_PROJECT_ID, or the organization's FCM settings). Pages are high-priority data messages. | Outbound to Google; the phone also needs Google connectivity. |
| Push relay | A relay credential (PUSH_RELAY_URL, PUSH_RELAY_CREDENTIAL) for the store-distribution model, where the relay operator holds the APNs key or FCM account. | Outbound HTTPS from the worker to the relay only. |
Through the relay, the worker sends only an incident reference: the notification and incident IDs, the incident number and severity, the device token, and the server's address and name. No alert title, service name or body text leaves the customer network; the app fetches the details from the server itself. Each relay credential is pinned to the deployment's own server address or addresses, and the relay refuses a push that names any other origin, so one installation cannot label pushes as another. An organization uses either the relay or its own APNs key, not both. The relay model is intended for store-distributed apps, which are not published for this release.
Several servers on one phone#
Each app keeps one signed-in account per server address. A push names the server it came from, and tapping it switches to the matching account; a push from a server the phone is not signed in to says so and pre-fills the sign-in screen.
Inside a private network#
- Devices need a route to the private API, directly or through the customer's approved VPN.
- Private DNS and the private CA must work on the device, not just on servers.
- APNs and FCM require connectivity to Apple and Google. An isolated device cannot receive pushes merely because the API is reachable.
- A lost network connection during ACK is not a successful response. Reconnect and refresh to verify the server state.