Context
This relates to #222 (background action buttons not invoking their callback when the app has been killed, only firing once the app is reopened). We ran into the same underlying limitation and built something to work around it — opening this issue to see if the approach is something you'd be interested in as a contribution, before we polish it into PR form.
The general idea
When a notification action button is set to run in the background, the plugin currently still needs to wake up the app's JS/WebView to actually run the button's callback. If the app has been fully killed, Android (and to a lesser extent iOS) won't reliably let a background receiver spin the app back up just to run some JS — so the action effectively does nothing until the user happens to reopen the app themselves, which is the exact behavior reported in #222.
Trying to force the app/JS to wake up more reliably felt like fighting the OS rather than working with it. So instead, we added an optional, opt-in way for an action button to make its own network call directly from native code — no app or JS involved at all. Practically, this is meant for simple, safe actions like "mark this notification as read," where you don't need the full app to be running, you just need one HTTP request to fire.
A few things we thought were important to get right:
- Fully backward compatible. This is an additional, opt-in field on top of the existing action button setup — nothing about how action buttons work today changes unless you use the new option.
- Security-conscious by default. Since this runs without a live app/user session, we didn't want it reusing a normal login/session token. The intended pattern is a short-lived, single-use token minted by your backend specifically for that one action when the notification is sent — similar in spirit to how an email "unsubscribe" link works. We documented this clearly as intended for low-stakes, reversible actions only, not anything destructive.
- Works the same way on both platforms, accounting for the fact that Android and iOS have pretty different constraints around background execution.
While building this, we also picked up a couple of smaller, related improvements:
- iOS action buttons were previously limited to a fixed set of 3 buttons — we made that flexible to match what Android already supports.
- Some small hardening/typing gaps we noticed along the way.
What we're asking
Would you be open to reviewing a PR (or a few smaller PRs, if that's easier to digest) for this? We have a working implementation on both platforms already. Happy to share more of the technical detail — payload shape, exact API, etc. — either here or in the PR itself, whichever you'd prefer.
Context
This relates to #222 (background action buttons not invoking their callback when the app has been killed, only firing once the app is reopened). We ran into the same underlying limitation and built something to work around it — opening this issue to see if the approach is something you'd be interested in as a contribution, before we polish it into PR form.
The general idea
When a notification action button is set to run in the background, the plugin currently still needs to wake up the app's JS/WebView to actually run the button's callback. If the app has been fully killed, Android (and to a lesser extent iOS) won't reliably let a background receiver spin the app back up just to run some JS — so the action effectively does nothing until the user happens to reopen the app themselves, which is the exact behavior reported in #222.
Trying to force the app/JS to wake up more reliably felt like fighting the OS rather than working with it. So instead, we added an optional, opt-in way for an action button to make its own network call directly from native code — no app or JS involved at all. Practically, this is meant for simple, safe actions like "mark this notification as read," where you don't need the full app to be running, you just need one HTTP request to fire.
A few things we thought were important to get right:
While building this, we also picked up a couple of smaller, related improvements:
What we're asking
Would you be open to reviewing a PR (or a few smaller PRs, if that's easier to digest) for this? We have a working implementation on both platforms already. Happy to share more of the technical detail — payload shape, exact API, etc. — either here or in the PR itself, whichever you'd prefer.