Frontend & Mobile Engineering · Remote Since Forever

Asking For Notification Permission: The Second Time Is the Wrong Time

2026-07-14T11:00:00+02:00

I work on a B2C health app where notifications aren't a growth channel, they're half the product. The user sets a sleep goal, the app reminds them to wind down before bedtime. They pick a protocol with a daily action, the app nudges them to do it. Without notification permission all of that just doesn't exist for the user, they set goals in onboarding and then nothing ever follows up on them.

Our first onboarding didn't treat the permission with that much respect. We did it the way most apps do, at some point in the flow we called the API, the iOS dialog popped up with no context, and the user had to decide on the spot why an app they installed five minutes ago wants to send them things. Predictably, a lot of them tapped "Don't Allow".

We assumed we could ask again later, once the user had seen enough of the app to change their mind. That assumption was wrong, and it's the reason this post exists. On iOS the native prompt is a one-shot, once the user says no, calling requestPermissionsAsync() again just returns "denied" without showing anything. The only recovery is the user going to Settings, Notifications, Your App and flipping the switch by hand, and very few people who decline ever do that.

So every "Don't Allow" was a permanent opt-out from a core part of the product, which made the decline rate the most expensive metric in the whole onboarding.

Let me show you what we did instead, the screen we put in front of the prompt, the hook that guards the request, and what we're still measuring.

What the iOS docs don't tell you

The native prompt is a one-shot, that part is documented. What isn't documented as prominently is when it becomes a one-shot. It's not the first time you call requestPermissionsAsync(), it's the first time the user sees it. Once they've seen the prompt and declined, you can't show it again from your app code.

You can detect the state with getPermissionsAsync():

import * as Notifications from "expo-notifications";

const { status } = await Notifications.getPermissionsAsync();
// "granted" | "denied" | "undetermined"

"undetermined" is the only state where calling requestPermissionsAsync() will actually show the system prompt. "denied" means the user already saw it and said no, and your only recovery is the Settings deep link. "granted" means you're clear to send notifications.

The whole pattern in this post is built on one rule: never call request while the status is undetermined unless you're confident the user will say yes.

Timing: a lesson from game design

Mobile games solved this years ago. A well-designed game never asks for notification permission on first launch, it waits until you've finished the first level, earned your first reward, or started a building that takes an hour to complete. At that moment the notification has an obvious job, "we'll tell you when it's done", and the player has already felt the value, so the ask answers a question they actually have.

The worst time to ask is before the user has experienced anything, at that point the permission prompt is a cost with no visible benefit and "Don't Allow" is the rational answer. The best time is right after a moment of value, when the notification is clearly in service of something the user just chose.

That's why our screen sits where it does in the onboarding. The user has already entered their name, picked their goals and invested a few minutes in the flow, so the notification ask is framed as the thing that makes those goals happen. Same principle as the game asking after the first level, earn the moment first, then ask.

The screen we show before the prompt

The screen we shipped is one step in the onboarding flow, right after the user has entered their name, picked their goals and invested a few minutes in the flow. It's deliberately simple, a title, a short description and two buttons:

<NotificationExplainerScreen
  title="Stay on track"
  description="We'll send you gentle reminders for your daily habits, lab result updates the moment they're ready, and progress milestones worth celebrating. One nudge at the right time, never spam. You're in control, turn off or customize every notification type anytime in Settings."
  primaryAction={{
    label: "Turn on notifications",
    onPress: requestNotificationPermission,
  }}
  secondaryAction={{ label: "Skip for now", onPress: advanceOnboarding }}
/>

Every line of that copy is doing a job, and most of the jobs come straight from game design.

"Gentle reminders for your daily habits" names the concrete thing the user just set up, the goals from two screens ago, so the notification is in service of something they chose. "Progress milestones worth celebrating" is the reward loop, games learned a long time ago that people say yes to notifications about wins, a level completed, a streak kept, much more readily than to notifications about obligations. "Lab result updates the moment they're ready" gives the notification an obvious job, the same way a game asks for permission when your building has an hour left, we'll tell you when it's done.

And "you're in control, turn off or customize anytime in Settings" lowers the perceived cost of saying yes. Good games always let you toggle notification types individually, and telling the user up front that they keep that control makes "Turn on notifications" feel reversible instead of a commitment.

Then there's "Skip for now", and this one needs explaining because it looks like a mistake. It isn't. Skipping our screen costs nothing, the permission status stays undetermined, so we can ask again later at a better moment, after the user's first completed habit or their first lab result. Declining the OS prompt costs everything, it burns the one-shot permanently. So the skip button is there on purpose, we'd much rather collect a cheap "not now" on our own screen than push an unsure user into an expensive, irreversible "Don't Allow" on Apple's.

The hook

The screen calls a single hook on continue:

// hooks/useNotificationSetup.ts — abridged
import * as Notifications from "expo-notifications";

export function useNotificationSetup() {
  const requestNotificationPermission = useCallback(async () => {
    const current = await Notifications.getPermissionsAsync();

    if (current.status === "granted") {
      // Already on. Skip the prompt; advance the onboarding.
      return "granted";
    }

    if (current.status === "denied") {
      // Already declined. Show the "open Settings" sheet instead of the prompt.
      showSettingsSheet();
      return "denied";
    }

    // status === "undetermined" — the one case where the prompt will actually fire.
    const result = await Notifications.requestPermissionsAsync({
      ios: {
        allowAlert: true,
        allowBadge: true,
        allowSound: true,
        allowAnnouncements: false,
      },
    });

    if (result.status === "granted") {
      await registerForPushToken();
    }

    return result.status;
  }, []);

  return { requestNotificationPermission };
}

Three guards in three lines. "Granted" skips the prompt entirely, "denied" opens the Settings deep-link sheet so the user can recover, and "undetermined" is the only path that calls the OS request.

Asking for the four iOS flags explicitly is worth doing. We didn't enable allowAnnouncements, that's the Siri "read this aloud through AirPods" permission and the product doesn't need it. Asking for permissions you don't need just nudges the user toward decline.

The Settings sheet, for the users who already said no

We show a separate small sheet for users whose status is already "denied":

<BottomSheet
  title="Notifications are off"
  body="You said no the first time, which is fine. The only way to turn them on now is in your phone's Settings."
  primaryAction={{
    label: "Open Settings",
    onPress: () => Linking.openSettings(),
  }}
  secondaryAction={{ label: "Maybe later", onPress: dismiss }}
/>

The copy matters here. "You said no the first time, which is fine" respects the user's earlier choice, and "the only way to turn them on now is in your phone's Settings" is the honest mechanic, not a sales pitch. The share of declined users who open Settings from this sheet is meaningfully higher than the share who responded to the previous "Notifications are off, enable them" banner inside the app shell.

The measurement

We're tracking three numbers, weekly.

Our screen's tap rate. What share of users who land on our screen tap "Turn on notifications".

Permission grant rate after the CTA. Of the users who tap our CTA, how many then tap "Allow" on the system prompt that follows.

Net grant rate. Our screen's tap rate times the system-prompt grant rate. The lift over the bare system-prompt baseline is the metric the product team watches, and on this product it's meaningful, meaningful enough that showing our own screen first is now the model for every new permission ask, not just notifications.

What I would tell another engineer setting this up

Never call requestPermissionsAsync without checking the status first. The one-shot rule on iOS is unforgiving, the three-branch guard is one of those patterns where the lines you don't call matter more than the ones you do.
Write the screen copy around concrete, positive jobs. Habit reminders the user just set up, lab results the moment they're ready, milestones worth celebrating. Specific and rewarding beats "stay engaged with the app", the same reason game notifications lead with wins, not obligations.
Let users skip your screen, never let them skip into the OS prompt. A "Skip for now" on your own screen is cheap, the status stays undetermined and you can ask again at a better moment. A "Don't Allow" on the system prompt is permanent. Design the screen so the unsure user takes the cheap no.
Settings deep link for the declined cohort. Most users who declined the first time won't come back, some will, so make the recovery a one-tap path.
Ask for the iOS flags you actually need. allowAnnouncements isn't free, every permission you ask for raises the bar to "yes".

Embracing Improvements

2024-01-04T02:24:41+01:00

Some of my coworker might remember that few years ago I was strongly against Tailwind CSS in one of our project.

The reason was that our design system wasn’t rigid enough for us to be able to use Tailwind, and that we ended writing new css class for each of our deviations.

The choice between,

<div class="my-element flex items-center bg-white"/>
.my-element {
  margin-left: 34px;
}
// or
.my-element {
  margin-left: 34px;
  @apply flex items-center bg-white;
}

and

<div class="my-element"/>
.my-element {
  margin-left: 34px;
  display: flex;
  align-items: center;
  background: white;
}

was obvious that if we ended up with a lot of deviation by creating our own class, let’s just stick with raw CSS.

We were using scoped CSS at that time, so we dont really care about name colission. If the choice was between the disciplined name of BEM and Tailwind, we’d probably go with Tailwind and just bear the pain of deviations.

Tailwind was still on its early days that time, it was slow to use, and there was no support for arbitrary values using square brackets. I kept pushing my team to stop using Tailwind, let’s stick with CSS as we don’t have a consistent design system.

But fast forward, Tailwind improved a lot. There was an improvements going on with Tailwind. JIT is a thing, compile speed was better, extending the configuration has become easier, and the support for arbitrary values allowed us to have an escape hatch without maintaining another CSS file.

So I decided to embrace Tailwind and starts advocating to use it for new projects. Even when the designer decided to nudge that margin into 171px, we’d have no problem as we can just m-[171px]

Where Tailwind Shine

Tailwind shines when we have a consistent design system and that the designer properly plan their design tokens and enforcing discipline. This way, developer can model their Tailwind configuration to match the design principles.

When thing goes south, deviating is just two keystrokes away (or 14 if you use m-[1234567890px]).

When there’s an improvements, we should embrace it. A lot of developers got too fixated by certain technologies that they missed good things happening at the other side of the fence.

However, it does not mean that we got the green pass to just use everything in our project. I experienced it first hand in an open source project where they implement all of the possible tooling without considering how it’d impact the performance and development flow. I stopped contributing when the package.json dependencies reached 60 or something — for a website that just show data from a database without any user inputs.

Remember, it’s always about the product, the team, and the workflow. It’s the technology that should adapt with those, not the other way around.

Building a one page landing page using React, Tailwind, Gatsby, SCSS, React Router, Redux, SQL in JS, and Web Assembly? Enjoy the 1 minute build time I guess?

The Logic of Position Reordering

2020-06-18T11:00:00+02:00

Reordering things seems to be something trivial. We do it almost every day, we sort our tasks, we sort our priorities — we move around that card on our Kanban board.

I mean, what could go wrong right?

The Cascading Reordering

Imagine you have an array of letters, and you want to reposition some element to another position.

const list = ['A', 'B', 'C', 'D']

We want to move 'C' to be the first element.

['C', 'A', 'B', 'D']

Now, let's say we need to keep track of each element's position. So it would be like:

C: 0
A: 1
B: 2
D: 3

Compare the order above, with the original state of the data below:

A: 0
B: 1
C: 2
D: 3

Notice what just happened?

The position of all elements except 'D' changed, we just moved 'C' to the beginning of the array, a very simple operation; but affected the array greatly. We can model it as:

function affected(startPos, targetPos) {
  if (targetPos > startPos) { // Forward
    return [startPos ... targetPos] // Anything in between needs to be shifted backward
  }
  if (targetPos < startPos) { // Backward
    return [startPos ... targetPos] // Anything in between needs to be shifted forward
  }
}

It means anything between the start position and target position or vice versa, needs to be updated.

Now imagine we have 1M records, and we reposition the last item to be the first, it would cascade the updates resulting in 1M updates just for one reposition.

Now I don't understand why on earth someone would want a drag-and-drop reordering feature on 1M records.

The Squeezing Reordering

Instead of cascading other elements into a new position, what if the relocated element squeezed itself so it fits into the new position?

Now we need to change the phrasing of the command. We no longer say, "Move X into Y". But we say, "Move X between Y and Z". So the final position of the element would be between Y and Z positions.

X.pos = (Y.pos + Z.pos) / 2

Zero Zero

Say we have a list that looks like below, and we want to move C to be the first element. Wait, "move 'C' between 'what' and 'A'?" —

A: 0
B: 1
C: 2
D: 3

Let's welcome our first edge cases (pun intended). In Squeezing Reordering, position zero is special and should not be assigned to any element. If we say "move 'C' between the 'very beginning (zero)' and 'A'" and apply the formula above. It would result in:

X.pos = (0 + 0) / 2
-> 0

Now both 'C' and 'A' are in position 0, which means they occupy the same space. Congratulations, we just made our own particle collider!

Starts From One

Now let's update our data to be:

A: 1
B: 2
C: 3
D: 4

Say the same command "move 'C' between the 'very beginning (zero)' and 'A'" — then we would have:

C.pos = (0 + 1) / 2
-> 0.5

Then our data would look like this:

C: 0.5
A: 1
B: 2
D: 4

Notice that the 'A', 'B', and 'D' positions didn't change. But the 'C' position is squeezed in between the beginning and 'A'.

Not Indexed Here

Now, in a programming language that uses an index to maintain the order of an array; it is unlikely that the drag and drop operation used our phrasing for the command, it is more likely that it will say something like "Move 'C' from index 2 to index 0" — it would make sense if we code it as below right?

Y = list[targetIndex - 1]
Z = list[targetIndex]
X.pos = (Y.pos + Z.pos) / 2

However, the element before index 0 is nothing.

?: ? [?]
A: 1 [0]
B: 2 [1]
C: 3 [2]
D: 4 [3]

So we need to check if our target points to a non-existent element, we set it to 0. Also consider the other side of the edge, when the target points beyond the array bounds, we set it to the array length + 1.

Y = list[targetIndex - 1] // Points to nothing
Z = list[targetIndex] // Points to 'A'
yPos = Y ? Y.pos : 0 // Lower out of bounds
zPos = Z ? Z.pos : list.length + 1 // Upper out of bounds
X.pos = (yPos + zPos) / 2
-> yPos = 0, zPos = 1
-> X.pos = (0 + 1) / 2
-> 0.5

Now we get the same result as our paraphrased command:

C: 0.5
A: 1
B: 2
D: 3

Now let's say we got another command "Move C from index 0 to index 1", we should be able to reuse our algorithm above right?

Y = list[targetIndex - 1] // Points to 'C'
Z = list[targetIndex] // Points to 'A'
yPos = Y ? Y.pos : 0
zPos = Z ? Z.pos : list.length + 1
X.pos = (yPos + zPos) / 2
-> yPos = 0.5, zPos = 1
-> X.pos = (0.5 + 1) / 2
-> 0.75

This is the result:

C: 0.75
A: 1
B: 2
D: 3

Wait, we were told to "Move 'C' from index 0 to index 1" right? Why is it still at index 0?

Direction Matters

In the case of Cascading Reordering, we detect the direction of the movement to find which elements are going to be affected. We can use this direction information to calculate the target index of a Squeezing Reordering.

Say, we run the same command "Move 'C' from index 0 to index 1" using the previous data:

C: 0.5
A: 1
B: 2
D: 3

With a slightly modified algorithm that considers the direction of the reordering:

if (targetIndex < startIndex) { // 1 < 0 = false
  Y = list[targetIndex - 1];
  Z = list[targetIndex];
} else { // Because the direction is forward
  Y = list[targetIndex]; // Points to 'A'
  Z = list[targetIndex + 1]; // Points to 'B'
}
X.pos = (yPos + zPos) / 2
-> yPos = 1, zPos = 2
-> X.pos = (1 + 2) / 2
-> 1.5

Now our data looks like:

A: 1
C: 1.5
B: 2
D: 3

Order Distancing

Due to this "virus" called decimals (and how infectious it is once you keep dividing and dividing), and the complexities of floating-point arithmetic; we can modify the distance between each element by an order of magnitude.

Instead of a small interval such as:

A: 1
B: 2
C: 3
D: 4

We can use:

A: 1000
B: 2000
C: 3000
D: 4000

Now when we run the command "Move 'C' from index 2 to 0" — we get:

C: 500
A: 1000
B: 2000
D: 4000

Conclusion

Both cascading and squeezing method works, it is just a matter of which trade-offs we want to make. When the database system that manages the position data is blazingly fast, cascading the position is not a big deal; or when the floating-point arithmetic implementation is eerily accurate, we can keep dividing it till infinity.

Feel free to share if you have any feedback on this article, or maybe you have a different approach to position reordering.

Creating a Shared and Cached Fetch Request

2020-06-08T11:00:00+02:00

There are cases when you have multiple components that display the same data from the same source. If every component that requests the data needs to fetch it from the source, you would end up with too many fetch requests; thus consuming many of the user network resources.

Typically, this can be solved by requesting the data only once on the parent component and then passing down the data to the components that might need it. However, now you have to responsibly manage the state of the data on the parent component and pass it around.

What if we could reuse the same code, that it is written like every component is requesting the data, but the data was actually shared and cached instead of fetching it every time from the source?

The concept is simple, wrap the fetch call into a function that handles sharing fetch state and cache expiration.

// Simulate network call
function fetch(url: string): Promise<{ expired: boolean; url: string }> {
  console.log(`NETWORK CALL (${url})`);
  const randomDelay = Math.round(Math.random() * 1000 + 100);
  return new Promise((res, rej) => {
    setTimeout(
      () =>
        res({
          expired: true,
          url
        }),
      randomDelay
    );
  });
}

// To wrap the fetch function into a cached and shared version
function cached<T>(
  fn: (...args: any[]) => Promise<T>,
  expire: number,
  args: any[]
): () => Promise<T> {
  let cache: any = null;
  let promise: Promise<T> | null = null;
  let fetcher: Promise<T | void> | null = null;
  return () => {
    // If the network call is processing, we reuse the promise
    if (fetcher && promise) {
      return promise;
    }
    // We store the promise that wraps the caching and network call
    // so we can reuse it later in case the network call hasn't finished
    promise = new Promise((res, rej) => {
      // Automatically resolve to cache when it is available
      if (cache) {
        res(cache);
        return;
      }
      // Store the fetcher so we know that the network call is still
      // processing
      fetcher = fn.apply(null, args).then(value => {
        cache = value;
        res(cache);
        // Clear the reusable promise and mark network call finished
        fetcher = null;
        promise = null;
      });
      // Clear the cache once its expired
      setTimeout(() => (cache = null), expire);
    });
    return promise;
  };
}

// Store the shared and cached version of fetch
// Components that accesses the shared data should use this
const f1 = cached(fetch, 100, ["https://api.example.com/subcription-expired"]);

f1().then(v => console.log(`${v.url} - ${v.expired}`));
f1().then(v => console.log(`${v.url} - ${v.expired}`));

You can play with this example on CodeSandbox.

Another Approach

What do you think about this approach? Do you have a better alternative or addition to this implementation? Feel free to share your thoughts!

I remember using saga patterns that handle this kind of issue, but adding a whole saga pattern seems like an overkill for my small project.