A developer writing on dev.to has published an investigation arguing that a multi-device push-notification rollout cannot be judged complete by inspecting the new API alone. The post, attributed to the author's own testing of a project called SquadNote, compares the old and new tRPC routers against the old and new logout callers, and concludes that the server schema and the deletion scope used by every caller are separate conditions that must both be satisfied.
The underlying change, per the post, lets a server store multiple push tokens per user. The updated API upserts by token, so registering an iOS token and then an Android token preserves both registrations. Before the change, registering a previously unregistered token also removed the user's existing tokens, so registering iOS and then Android left only the later registration in the database.
The compatibility problem is that the updated API retains unregisterAllPushTokens. The author states that the mobile change must also reach clients so that an ordinary logout removes only that installation's tokens. Having an adequate server schema, the post argues, is not the same as having every caller use the new deletion scope.
Disposable copies of a local libSQL database of the same type were connected to the actual before-and-after tRPC routers by the author, in order to test the combinations. A synthetic authenticated user first registered an iOS value and then an Android value; per the post, these were test strings, not real Expo Push Tokens. One of two deletions was then selected by the comparison: the device-specific deletion of the new caller, or the all-device deletion of the old caller.
The author is explicit that this exercised API calls, not an end-to-end run of the application UI and network. Their assertions were matched by all four cases. The old server cannot be made to retain both destinations by adopting only the new logout method, and both registrations are still removed by the new server if all-device deletion is called.
One case deserves attention because a final count alone would mislead. In the old-server-plus-device-deletion combination, the count reaches zero because registering Android had already removed the iOS row; device-specific deletion did not itself remove the iOS registration. The author recommends inspecting both the post-registration and post-logout states rather than only the final count.
The post also addresses whether updating the server restores registrations that were previously deleted. It does not. The test registered iOS again after logout and confirmed the row existed, but the author attributes that to another registration call with the required input, not to the server update reconstructing deleted rows.
From this, the author proposes a verification sequence: the new code is distributed; it is downloaded and applied by the target device; registration is executed by the device; the required destinations are confirmed to exist on the server; and logout is then verified to preserve the other device. The post labels this a proposed sequence and states that the rollout stage of actual user devices was not collected by the investigation. The author therefore does not claim that every user updated or that all registrations were restored.
A second thread takes Expo runtime versions as its subject. According to the post, the specification directs teams to ship the Web/API side first and afterward roll out compatible changes to iOS and Android, and it notes that the two platforms' targeted builds carry differing native dependency configurations. The author cites Expo's runtime-version documentation, which holds that an update must be compatible with the native code baked into a build, and contends that stamping the same identifier onto both platforms by hand does not erase those native differences.
A rollout record, the author suggests, could link the applied update, the registration outcome, each platform's build and runtimeVersion, and the API commit. According to the post, delivery settings were not changed, and successful distribution was not inferred from local tests.
On test coverage, four additional cases passing alongside eight existing registration, deletion and sending tests are reported by the post, for twelve successful tests. Node.js v24.15.0 and Vitest 4.1.4 formed the environment, using in-memory libSQL and the actual router code, with external HTTP for notification sending mocked. Circle-hub at 0cda1e8 and the parent of change ad0a669 are the source versions cited, with tests run locally on September 11, 2026.
The author lists what these checks do not cover: permissions on physical devices, delivery after Expo accepts a message, OS notification presentation, and recovery from offline operation. The post also says no OTA update or notification to a physical device was sent.
At the inspected revision, the original specification's physical-device checklist is described as unchecked. That checklist asks for updates to be applied on both platforms, for receipt on both devices, and for receipt only on the remaining device once one logs out. The author's point is that a documented procedure is not evidence it was executed.
For developers and freelancers maintaining mobile apps with push notifications, the practical takeaway is editorial interpretation: a passing server test suite and a matching runtimeVersion string are weak signals of a finished migration. The post's matrix suggests auditing which logout path each shipped client actually calls, and recording per-platform build and update state alongside registration outcomes.
The tradeoffs are real. Retaining unregisterAllPushTokens for compatibility keeps older clients working but leaves a deletion path that wipes every device, so the safety of the rollout depends on client distribution rather than server behavior. The author's proposed verification sequence is more rigorous but requires device-level receipt checks that local tests cannot substitute for.
What remains unknown is substantial. The evidence is a single author's account of local tests on synthetic token strings, with no physical-device verification, no data on actual user device rollout stages, and no confirmation that all registrations were restored. The post does not establish that any production deployment reached completion, and its conclusions should be read as the author's claims rather than independently verified findings.