Frida 17.19.0: iOS 27 fixes and arm64 instrumentation improvements

What happened on 2026-09-25

At 12:07 UTC on 2026-09-25, Frida published 17.19.0 on GitHub, and the project's news page posted 'Frida 17.19.0 Released' the same day. The release post lists the following. A PlayStation 5 backend was added. The barebone backend gained Android emulator support, better Linux kernel symbol discovery, and WinNT support extended to arm64. On Darwin, an iOS 27 injection leak that could leave roughly 40 MB of agent data behind after each attach was fixed, and memory-protection handling was improved. The fruity component fixed RSD port discovery on macOS 27. Gum improved arm64 relocation and function-prologue handling, including cases where X16 and X17 are both in use. Interceptor now tracks the C stack associated with each frame. There were also fixes for resource cleanup after Linux injection and for Windows unwinding through Interceptor trampolines. This entry describes these changes only at release-note level.

What it means for defenders

For developers protecting their own apps, the timing is the main lesson. Issues related to iOS 27 and macOS 27 were fixed soon after those systems shipped. The assumption that a new OS version will temporarily break dynamic analysis tools holds only briefly and should never appear in a protection promise. The arm64 prologue and relocation improvements also mean that client-side detection relying on details such as an unusual function entry sequence will erode as the tooling iterates. Client-side detection still has value, since it raises cost and produces signals. The threat model should nonetheless assume that a process running on a user's device can be observed and modified. Critical decisions, such as granting entitlements, confirming payments and making risk calls, must be settled by the server.

Checks to run on your own builds

First, after major releases of dynamic analysis tools, rerun your existing security test plan on test devices you control, and record which client-side checks still work and which no longer do. Second, go through critical business operations one by one and confirm each has server-side validation, so a modified client cannot gain privileges on its own. Third, report client-side detection results as telemetry for server-side risk decisions, rather than letting them make the only blocking decision locally. Fourth, when describing your protection to others, avoid absolute claims such as 'cannot be debugged' or 'cannot be injected'.

Your checklist

• Rerun your security test plan on your own devices after major tool releases
• Confirm every critical operation has final server-side validation
• Use client-side detection as telemetry, not the sole blocking decision