⬡ Dev Tools/2026-06-16Intermediate

Notifications You Can Finish Without Opening the App — Interactive Notification Actions for Rork Apps

Those buttons and text fields that appear when you long-press a notification. Here is how to implement interactive notification actions in a Rork-built Expo app for an experience that completes without launching, including the background-execution pitfalls.

Rork⁴⁹⁸ Notifications³ Expo¹³⁹ Notification Actions UX Design⁹ React Native²⁰¹

✦ Premium Article

When I started sending a "word for today" notification in a wellness app, something occurred to me. The user taps the notification, opens the app, reads the message, and closes it again. They were launching the entire app for nothing more than that. If it's just to read, wouldn't it be kinder to let it complete inside the notification itself? That thought is what led me to interactive notification actions.

Interactive notification actions are the buttons and text-input fields that appear when you long-press (or swipe down on) a notification. It's the mechanism behind a "Done / Later" button on a reminder, or a reply field on a message. Because the user can finish the action right there without opening the app, the number of steps drops dramatically.

Rork tends to generate the basic code for sending and receiving notifications, but often not the action definitions or background handling. Here is the design for adding this to an Expo (React Native) app, drawn from my experience as an indie developer shipping apps on the App Store and Google Play.

Define actions grouped into "categories"

Notification actions aren't defined as loose individual buttons; they're grouped into a unit called a "category." For example, you bundle "Done" and "Remind in 1 hour" into a "reminder" category, then specify that category when you send the notification.

In Expo you define them with setNotificationCategoryAsync from expo-notifications.

// notificationCategories.ts — register once at app launch
import * as Notifications from "expo-notifications";
 
export async function registerCategories() {
  await Notifications.setNotificationCategoryAsync("reminder", [
    {
      identifier: "complete",
      buttonTitle: "Done",
      options: { opensAppToForeground: false }, // handle in background, no launch
    },
    {
      identifier: "snooze",
      buttonTitle: "Remind in 1 hour",
      options: { opensAppToForeground: false },
    },
  ]);
 
  await Notifications.setNotificationCategoryAsync("daily_word", [
    {
      identifier: "reply",
      buttonTitle: "Write a reflection",
      textInput: {
        submitButtonTitle: "Send",
        placeholder: "A word about how you feel…",
      },
      options: { opensAppToForeground: true }, // save in-app after input
    },
  ]);
}

The value of opensAppToForeground is the crux of this design. Set it to false and the work runs without bringing the app to the front; set it to true and the app opens after the action. The basic split: false for instant work like a "Done" button, true for work like text input that you'll want to show a screen for afterward.

On the sending side, specify the matching category ID in categoryIdentifier.

await Notifications.scheduleNotificationAsync({
  content: {
    title: "Time to water",
    body: "Give your houseplant a drink",
    categoryIdentifier: "reminder", // the category defined above
  },
  trigger: { hour: 9, minute: 0, repeats: true },
});

Receive the action and branch the handling

The result of a button press arrives via addNotificationResponseReceivedListener. Which action was pressed is in actionIdentifier, and the text-input contents are in userText.

// notificationHandler.ts
import * as Notifications from "expo-notifications";
 
export function listenForActions() {
  return Notifications.addNotificationResponseReceivedListener(async (res) => {
    const action = res.actionIdentifier;
    const data = res.notification.request.content.data;
 
    if (action === "complete") {
      await markReminderDone(data.reminderId);
    } else if (action === "snooze") {
      await Notifications.scheduleNotificationAsync({
        content: { title: "Reminder", body: data.body, categoryIdentifier: "reminder" },
        trigger: { seconds: 3600 },
      });
    } else if (action === "reply") {
      await saveReflection(res.userText ?? ""); // text input arrives in userText
    }
  });
}

Watch out: actionIdentifier also carries OS-reserved special values. A plain tap on the notification body delivers Notifications.DEFAULT_ACTION_IDENTIFIER. If you forget to branch — handling only your own actions and routing the default tap to normal navigation — body taps go unresponsive. I shipped exactly that bug once: "tapping the notification normally does nothing."

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦Defining button and text-input actions grouped by category

✦Handling the OS execution-time limit when completing work in the background without launching

✦The action-design criteria that kept my notification opt-in rate from dropping — with measured results

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

The pitfall of the background execution-time limit

Actions with opensAppToForeground: false are handled in the background without opening the app. Convenient — but here lurks an easily-missed trap: the OS execution-time limit.

On iOS, the grace given to this kind of short background execution is limited (roughly seconds to a few tens of seconds). Run heavy work including network calls inside the listener and the OS may kill the process before it finishes, leaving the work half-done. I once tried to do full server sync behind the "Done" button, the sync failed in a low-signal spot, and I created an inconsistency: done locally, not reflected on the server.

The guiding principle: inside a background action, reliably finish only the local state update, and merely enqueue the server sync into a pending queue. The actual send happens in bulk on the next app launch or when a background task runs.

async function markReminderDone(id: string) {
  // 1) Commit local state first (this reliably finishes)
  await db.update("reminders", id, { done: true, doneAt: Date.now() });
  // 2) Just enqueue the server sync (send it later)
  await enqueueSync({ type: "reminder_done", id });
  // Don't wait on the network here, to avoid burning the background grace
}

The experience of "the moment you press the action, the appearance changes" is covered by the local update alone, and sync reliability is covered separately by the queue and retries. Keep that separation in mind and the behavior stays stable regardless of signal conditions.

How to prioritize which actions to add

When designing a category, I personally follow a priority order. Rather than adding buttons indiscriminately, I re-question "is this really needed?" in this sequence:

First, provide one action that completes the notification's main purpose in a single tap (for a reminder, "Done"). When this works from right after onboarding, the experiential value of the notification clearly rises.
Add one escape action that lets the user defer the main purpose ("Later," "in 1 hour"). The reassurance of being able to defer helps retention by keeping people from turning notifications off.
Add nothing beyond that. A third action tends to add "cognitive load that makes you think" more than it lifts the continuation rate — that's my judgment from experience.

Pruning by this priority converges naturally on a binary like "Done / Later." I recommend starting from that binary.

Where to draw the line to protect opt-in rates

Finally, a word on an operational call. More actions means more convenience, but if the notification itself starts to feel "noisy," users turn notification permission off. Once it's off, getting them to turn it back on is extremely hard.

The line I hold: at most two actions per notification. The buttons actually visible on an iOS lock screen or banner are limited, and more choices make it a "notification that makes you think," raising the psychological load. Narrowing to a binary almost anyone can press reflexively — "Done / Later" — is what ended up being used most.

After adopting this, "clear it with Done without opening the app" came to dominate reminder-type notifications, and the wasted round trips from notification to app launch visibly dropped. The opt-in rate didn't fall — it ticked up slightly. When a notification shifts from "something that summons you" to "something that's handled on the spot," its value to the user changes. I hope it offers one design option to anyone building wellness or utility apps solo, as I do.

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.