RFDs #0005

The best possible kitchen clock

Picture this: you're cooking something new, hands covered in flour, and the smell of simmering sauce fills the air. You glance at the recipe and need to set a timer. If you’re staying in the kitchen, a simple physical clock works great—reliable and easy to use.

But what if you need to step away? Maybe the sauce needs to simmer for hours, or the oven timer isn’t loud enough to hear from another room. That’s when a timer on your phone comes in handy.

When implementing this feature, our main goal was to make creating this alarm in your phone as close as "one tap" as possible. We identified and evaluated three primary options:

  1. Browser-based timers; Enhanced using web push notifications
  2. Custom apps Leveraging native push notifications and APIs
  3. Native alerts

Choosing the best option depends on balancing reliability, user convenience, and technical complexity.

Why push notifications are critical

As long as your app or website is in the foreground, everything works smoothly. Creating a reliable timer is straightforward, and you can easily access APIs to play sounds or make the phone vibrate. The real challenge arises when the user’s focus shifts elsewhere.

Imagine this: the screen turns off, the phone goes into low-power mode, or the user switches to another app. Suddenly, your app’s ability to deliver a timely notification is severely limited. This is where the rabbit hole begins. Push notifications become your lifeline, but they are constrained by multiple layers of restrictions—battery optimizations, connectivity issues, and device settings.

In these edge cases, failing to alert the user at the right moment can have serious consequences. While turning off the stove is ultimately your responsibility, we shouldn’t build a system on a fundamentally flawed method.

Why Reliable Push Notifications Are Hard (web or not)

Phones should make setting and receiving alerts simple, but many things can go wrong—especially if you’re considering implementing time-critical alerts you’d trust your Christmas dinner to. These are all important factors to consider when building a seamless and reliable experience:

  • Do Not Disturb (DND): Alerts might stay silent unless special settings are used. These settings can change over time, and users may not notice.
  • App Lifecycle: Your app might not be running when the alert needs to go off.
  • Limited Resources: Phones in low-power mode, without signal, or in airplane mode can prevent push notifications from being delivered.
  • Muted Devices: If the phone is silenced or headphones are connected, alerts may be missed.
  • Accessibility Needs: Features like voiceover or vibration patterns must be considered.

Some of these issues can be worked around. For example, Apple’s Priority Notifications can bypass DND, but getting approval for this during the App Store review is not always easy. Android offers more flexibility but introduces its own challenges.

This is a solved problem; Use Native Alerts

After testing different ideas, I relized that native alerts of the clock app are just better. They have unique integrations with the OS that are impossible to replicate. They avoid many problems with push notifications and provide a smoother, more reliable experience.

  • Reliability: They aren’t affected by browser limitations or push notification issues like low-power mode or airplane mode.
  • Seamless Integration: They leverage the phone’s built-in systems, ensuring consistent behavior across different situations.
  • User Trust: Users are familiar with native alerts, making them more intuitive and dependable.
  • Accessibility: They integrate with the device’s accessibility settings, like voiceover and vibration patterns.
  • Bypassing DND: Native alerts always bypass Do Not Disturb settings, ensuring critical alerts are received without any additional setup.

The challenge becomes... How do I create a native alert in the clock app when a user clicks a link on a website? Each platform has its own caveats, but it is certainly possible.

Apple Devices: Shortcuts

Apple doesn’t let apps set alarms directly in the Clock app, as there is no official API for this functionality. However, there is a workaround we can exploit.

You can easily create an Apple shortcut that creates a timer for a given time.

Then the challenge is to invoke this shortcut from a web page. Fortunately, there is a solution: you can create a URL like this:

shortcuts://run-shortcut?name=forkclub-start-timer&input=120

When you click that link on an Apple device, the shortcut will be invoked.

This method has a few trade-offs:

  1. Setup: Users must install the shortcut themselves. While we can simplify this, it adds some friction.
  2. Fragility: The shortcut name must match exactly what we expect. Clear documentation is essential to troubleshoot these cases.
  3. Updates: Changing the shortcut later requires manual updates by users. Hopefully, this won’t be needed often!

Once it’s set up, though, it works very well. With just one tap, you can create a timer in the Clock app!

Android: It's complicated

While Android supports the AlarmClock.ACTION_SET_TIMER intent, using it reliably isn’t easy. The main issue is that it’s not part of the BROWSEABLE category within most clock apps, which means intents triggered through URLs like intent:// don’t always work.

Adding to the confusion, every phone manufacturer’s Clock app behaves differently. Some support the intent, some don’t, and others use different names for the same feature.

The best solution? Build a custom "fork.club" Android app with its own BROWSEABLE intent i.e:

intent://timer/#Intent;scheme=forkclub;...

This app can act as a bridge to trigger ACTION_SET_TIMER on behalf of the user. It’s a lot of work, but it ensures a smooth and reliable experience fairly similar to the apple one.

Conclusion

Timers are more than just tools for tracking time—they make cooking easier, whether you’re in the kitchen or not. Physical clocks are classic and reliable, but phone alerts add flexibility when done right.

We'll split users based ont their platform (Apple and Android initially).

For Apple users we'll:

  1. Ask the user to install a Shortcut.
  2. Store the fact that the Shortcut was installed in some semi-persistent storage in the device (probably localstorage)

For Android users we'll:

  1. Ask them to install an app from Google Play
  2. Store the fact that the App was installed
  3. Configure the Android intent, so that we provide a fallback url if the itent isn't resolved.

Yes, we have spent weeks prototyping and investigating all this just to make the experience of clicking a Boil for 30 minutes link as exceptional as it can be. But oh boy, was it worth it!

Author: Jorge Bastida
Published: January 1, 2025
RFD: #0005

If you'd like to discuss this RFD, share your thoughts, or simply chat about it, feel free to reach out to me - To stay up to date with the project's development, you can follow me on X