AI case studies
The iOS app for the same service was the main battleground, holding the majority of members. Even so, notifications were even more quietly silent than on Android — the previous-generation notification route had been completely cut off. Following Field Report ⑥ (the Android instalment), this time we cover the sticking points specific to iOS and, common to both operating systems, how we modernised notifications without touching the old server.
A failure nobody can notice is exactly the one worth killing first.
Most users were on iOS. And on iOS, notifications were dead.
Like the Android app, the iOS app was a native shell displaying an existing web service — a WebView wrapper plus notifications. Sending relied on a previous-generation mechanism, and delivery stopped the moment that route became unusable. Because most users were here, the impact was at its largest. Moving this onto a modern delivery platform was the biggest return of the project.
The iOS blockers were all things that only appear on a real device.
With iOS, the problems were mainly ones that a simulator or a code review cannot reveal — they only surface on real hardware.
The shell was rebuilt in Swift; the contents and the members stayed put.
An AI agent rebuilt the iOS app on a current native stack (Swift + WKWebView + the current notification platform). We ran everything from generating the project skeleton to checking it on real hardware, confirming it worked in a device build from a Mac. The contents being displayed (the existing web service) and the member asset of roughly 14,000 registered devices are carried over unchanged.
| Item | Before | After the rebuild |
|---|---|---|
| Notification route | Previous-generation notification scheme (discontinued — cannot send) | Current delivery platform + new-scheme authentication key |
| App shell | An old-generation native implementation | Regenerated with Swift + WKWebView |
| Screens (contents) | Displays the existing web service | Continues unchanged (member assets preserved) |
| Real-device defects | Garbled Japanese text and similar | Fonts, badges and generation gaps handled individually |
We modernised the old server without replacing it.
The crux common to both operating systems was the sending server. It runs on a very old runtime, so the current official tooling will not run on it as is. We therefore implemented the signature processing required for authentication ourselves and connected to the current delivery platform. Without replacing the whole server, we moved only the notifications onto a modern scheme.
The sending side was also rebuilt as an independent delivery service separated from the shared platform, so that recipients can be chosen and messages sent from an admin screen.
Even a mobile app written off as broken can be returned to current operation with a single rebuild: rebuild the shell, carry over the keys and the member assets, and modernise the old server. If you have an app you have given up on as untouchable, start by talking to us about analysing what actually exists.
* This article generalises a real project to the extent that no company or service can be identified. Figures are approximate, based on measurements as of August 2026. Duration and scope of work vary with the structure of the app.