Introduction

If window.onbeforeunload is not working on iPad, the short answer is that iPad browsers, especially Safari, do not reliably support the full desktop beforeunload experience. Even where the event fires in some situations, browsers on iOS heavily restrict or ignore custom unload prompts.

That means you should not build important data-protection logic around onbeforeunload on iPad. The better approach is to auto-save state and respond to lifecycle signals such as visibilitychange or pagehide instead of expecting a confirmation dialog to always appear.

Why onbeforeunload Is Unreliable on iPad

On desktop browsers, beforeunload has traditionally been used to warn users about unsaved changes. On mobile browsers, and particularly on iOS, the browser lifecycle is more aggressive about suspending, navigating, or discarding pages without offering the same hooks or confirmation UX.

So even if this pattern works on a desktop browser:

window.onbeforeunload = function () {
  return 'You have unsaved changes.';
};

it may do nothing useful on iPad Safari.

Modern browsers also ignore custom message text and often suppress the prompt entirely unless there was a recent user gesture and a strong enough reason to show it.

Do Not Depend on an Unload Prompt for Safety

The real problem is usually not "how do I force the dialog to appear" but "how do I avoid losing user work when the dialog does not appear." That changes the solution.

If users can type into a form or edit data, the robust answer is auto-save.

A simple pattern is to persist draft state while the user is typing:

1const input = document.querySelector('#draft');
2
3input.addEventListener('input', () => {
4  localStorage.setItem('draft-value', input.value);
5});
6
7const saved = localStorage.getItem('draft-value');
8if (saved !== null) {
9  input.value = saved;
10}

That protects the user even if the browser kills the page with no unload warning at all.

Use Better Lifecycle Events

If you need to send analytics, flush state, or mark a page as hidden, visibilitychange and pagehide are usually more realistic signals on mobile:

1document.addEventListener('visibilitychange', () => {
2  if (document.visibilityState === 'hidden') {
3    console.log('Page is being hidden');
4  }
5});
6
7window.addEventListener('pagehide', () => {
8  console.log('Page is being unloaded or cached');
9});

These events are still not a guarantee for every possible mobile lifecycle edge case, but they align much better with how modern mobile browsers behave than beforeunload does.

Think in Terms of Resilience, Not Blocking

On iPad, users may:

• switch apps abruptly
• swipe away browser tabs
• navigate with gestures
• trigger page suspension without a traditional unload flow

Because of that, resilient design matters more than exit confirmation. Save early, restore drafts, and keep server state current if the data is important.

If your app is form-heavy, debounce background saves instead of waiting for one big final save during unload.

When beforeunload Still Helps

You can still attach a handler if you want desktop browsers to warn users. Just do not assume the same protection exists on iPad:

1window.addEventListener('beforeunload', event => {
2  if (hasUnsavedChanges()) {
3    event.preventDefault();
4    event.returnValue = '';
5  }
6});

This keeps desktop behavior while your mobile strategy relies on autosave and recovery.

Common Pitfalls

• Expecting iPad Safari to behave like desktop browsers for beforeunload dialogs.
• Relying on custom prompt text, which modern browsers often ignore.
• Deferring all persistence until unload instead of saving progressively.
• Treating beforeunload as a guaranteed signal in mobile web apps.

Summary

• 'window.onbeforeunload is not reliable on iPad, especially for confirmation dialogs.'
• iOS browsers restrict or suppress unload prompts much more aggressively than desktop browsers.
• Use autosave plus visibilitychange or pagehide for practical mobile resilience.
• Keep beforeunload only as a best-effort enhancement for desktop behavior.
• Design for recovery from abrupt page loss instead of assuming a warning dialog will protect the user.