Decoding the 'Add to Home Screen' Prompt: Why Users Ignore It and Kryton's Framework for Compelling Installation

The 'Add to Home Screen' (A2HS) prompt is one of the most underutilized features in progressive web apps. Most users dismiss it within seconds—not because they don't want shortcuts, but because the prompt arrives at the wrong moment, lacks context, or feels intrusive. This guide breaks down the psychological and technical reasons behind prompt fatigue, then presents Kryton's framework for designing installation prompts that users actually want to engage with.

We cover the decision points developers face, compare three common prompting strategies (browser-native, custom in-app, and deferred), and provide a structured comparison table to help you choose. You'll also learn implementation steps, common pitfalls that kill conversion, and answers to frequent questions about timing, engagement, and user control.

1. The Decision Frame: Who Must Choose and By When

The A2HS prompt forces a split-second decision on the user: install this app to your home screen, or ignore it. That decision is shaped by context, trust, and perceived value—not by the prompt's technical correctness. As a developer or product owner, you are not the one making the choice; you are the architect of the conditions under which the user decides.

Who is making the decision?

Every visitor who meets the browser's installability criteria—typically a combination of a service worker, a manifest file, and some engagement signals—will eventually see some form of prompt. But the users who matter most are those who have already demonstrated intent: repeat visitors, users who have spent more than a few minutes on your app, or those who have completed a key action (like making a purchase or saving a setting). These users have already invested time; they are the ones most likely to appreciate a shortcut.

The decision also involves stakeholders within your team. Product managers must decide whether to use the browser's native prompt (which is simple but inflexible) or build a custom in-app prompt (which offers control but requires development effort). Marketing teams may want to track installation events, while engineering teams worry about cross-browser compatibility. The timeline for this decision is often tied to a launch or feature release: you need to have your prompting strategy in place before you start driving traffic to your PWA.

By when must you decide? Ideally, before your PWA goes live. Changing the prompt behavior after launch is possible, but it can confuse users who have already seen—and dismissed—one version. If you are retrofitting an existing PWA, the best time to revise your prompt strategy is during a major update or when you introduce new features that benefit from offline access or home screen placement.

2. The Option Landscape: Three Approaches to Prompting

There is no single 'right' way to prompt for installation. The three most common approaches each come with distinct trade-offs in control, user experience, and implementation complexity.

Approach 1: Browser-Native Prompt

This is the default: the browser triggers a mini-infobar or dialog when it detects that your PWA meets installability criteria. The prompt is standardized, requires no custom code beyond the service worker and manifest, and users are familiar with its appearance. However, you have almost no control over when it appears—the browser decides based on its own heuristics, which may not align with your user's context. Many users dismiss it reflexively because it feels like a generic notification rather than a helpful suggestion.

Approach 2: Custom In-App Prompt

You build your own UI—a banner, a slide-in panel, or a modal—that you trigger based on your own logic. This gives you full control over timing, messaging, and design. You can wait until the user has completed a meaningful action, then present a prompt that explains exactly why installation benefits them (e.g., 'Save this page for offline reading'). The downside: more development work, potential for inconsistency across browsers, and the risk of annoying users if you prompt too aggressively.

Approach 3: Deferred Prompt (Progressive Engagement)

This hybrid approach uses the browser's native prompt but defers its appearance until you explicitly call it from your own code. You listen for the beforeinstallprompt event, prevent the default browser behavior, and store the event object. Later, when you decide the moment is right (e.g., after a user's third visit or after they bookmark a page), you trigger the stored event to show the native prompt. This gives you timing control without building a custom UI from scratch. It is a pragmatic middle ground that many teams adopt.

Which approach should you choose?

We recommend starting with the deferred prompt for most projects: it balances control with simplicity. If you have the resources and a clear user journey, a custom in-app prompt can yield higher conversion rates because you can tailor the message. The browser-native prompt alone is rarely the best choice unless you are prototyping or have very low traffic.

3. Comparison Criteria: How to Evaluate Your Prompt Strategy

Choosing a prompting approach is not a one-size-fits-all decision. You need to evaluate options against criteria that matter for your specific app and audience. Here are the key factors to consider.

User Engagement Level

How often do users return? For a utility app that users open daily (like a weather or note-taking app), a prompt on the second or third visit may be appropriate. For a content site that users visit sporadically, you might wait longer or trigger the prompt after a high-value action like reading an article to the end. The more engaged the user, the earlier you can prompt without feeling pushy.

Context of Use

Are users on a slow connection? Do they frequently switch between devices? If your app provides offline functionality, the prompt should highlight that benefit. If the app is primarily used on desktop, the home screen prompt may be less relevant (since desktop PWAs can be installed via the address bar). Consider the device and environment: mobile users are more likely to appreciate a home screen shortcut than desktop users who already have bookmarks.

Brand Trust and Design Consistency

A custom prompt that matches your app's design language feels more trustworthy than a generic browser dialog. If your app has a strong brand, a custom prompt reinforces that identity. On the other hand, if your app is new or has low recognition, the browser's native prompt may carry more authority because users associate it with the browser's security.

Technical Overhead

How much development time can you allocate? The browser-native prompt requires almost no code. The deferred prompt adds a few event listeners and state management. A custom in-app prompt may require a designer, front-end development, and testing across multiple browsers. Factor in maintenance: browsers may change their prompt behavior over time, and custom prompts need to keep pace.

Measurement and Analytics

Can you track installation events? With the native prompt, you can listen for the appinstalled event, but you have limited insight into why users declined. Custom prompts allow you to log dismissals, time spent on the prompt, and even A/B test different messages. If data-driven optimization is important to you, a custom or deferred approach gives you more levers to pull.

4. Trade-offs Table: Comparing Prompt Strategies

The table below summarizes the key trade-offs between the three approaches. Use it as a quick reference when discussing with your team.

No single approach wins across all criteria. The deferred prompt is a strong default because it offers timing control with low effort. Custom in-app prompts are worth the investment if your app has high engagement and you have the resources to design and test. The browser-native prompt alone is best reserved for quick experiments or apps where installation is not a primary goal.

When not to use each approach

Avoid the browser-native prompt if your app has a complex user journey where timing matters—for example, a multi-step checkout flow where an interruption could cause abandonment. Avoid the deferred prompt if you need to completely control the visual experience (e.g., for a branded game or media app). Avoid custom in-app prompts if your team cannot commit to ongoing testing and iteration; a poorly designed custom prompt can hurt trust more than a native one.

5. Implementation Path: From Decision to Deployment

Once you have chosen an approach, the next step is to implement it carefully. Here is a practical path that works for most teams.

Step 1: Ensure technical prerequisites

Before any prompt can appear, your PWA must meet the installability criteria: a valid web app manifest with correct icons, a service worker that handles fetch events, and a secure context (HTTPS). Verify these with Lighthouse or the browser's developer tools. Without these, no prompt will fire, regardless of your strategy.

Step 2: Listen for the beforeinstallprompt event

Even if you plan to use a custom prompt, always listen for the beforeinstallprompt event. This event signals that the browser considers your app installable. In your event handler, call preventDefault() to suppress the default prompt, and store the event object for later use. This is the foundation of both deferred and custom approaches.

Step 3: Define your trigger conditions

Decide when to show the prompt. Common triggers include: after a user has completed a key action (e.g., submitting a form), after a certain number of page views (e.g., 3 visits), after a time threshold (e.g., 5 minutes of engagement), or when the user attempts to leave the page (exit intent). Choose one or two triggers that align with your user's moment of highest perceived value.

Step 4: Build or configure the prompt UI

For a deferred prompt, you simply call storedEvent.prompt() at the right moment. For a custom prompt, design a UI element that explains the benefit clearly. Use action-oriented language: 'Add to Home Screen for quick access' is better than 'Install this app'. Include a dismiss option that is easy to find—users who feel trapped are unlikely to convert.

Step 5: Handle the user's choice

Listen for the userChoice promise that resolves after the user accepts or dismisses the prompt. Log the outcome for analytics. If the user accepts, you may want to show a confirmation or redirect them to the installed app. If they dismiss, consider whether to show the prompt again later (be careful not to be annoying—once per session is usually enough).

Step 6: Test across browsers and devices

Prompt behavior varies between Chrome, Edge, Samsung Internet, and other browsers. Test on both mobile and desktop. Some browsers may not support the beforeinstallprompt event at all (e.g., Firefox on iOS). Have a fallback: if the event never fires, you can still offer a manual install instruction (e.g., 'Open in browser menu and select Add to Home Screen').

6. Risks of Getting It Wrong: Common Mistakes That Kill Conversion

Even with a solid strategy, small mistakes can undermine your installation rates. Here are the most common pitfalls we see in practice.

Mistake 1: Prompting too early

Showing the prompt on the first visit is almost always a mistake. The user has no context, no trust, and no reason to commit. They will dismiss it, and many browsers will not show the prompt again for that user. Result: you lose the opportunity forever. Always wait for at least some engagement signal.

Mistake 2: Using vague or technical language

Phrases like 'Install this web app' or 'Add to home screen' assume the user knows what those terms mean. Instead, describe the benefit: 'Get faster access with one tap' or 'Save this page for offline reading'. Test your copy with non-technical users to ensure it resonates.

Mistake 3: Ignoring the dismiss action

If your custom prompt has a tiny 'X' button or no clear way to dismiss it, users will feel trapped. They may close the entire tab to escape. Make the dismiss action obvious and generous—a large 'Not now' button works better than a subtle close icon.

Mistake 4: Not tracking outcomes

Without analytics, you cannot improve. Track how many users see the prompt, how many accept, and how many dismiss. Also track downstream behavior: do users who install engage more? If not, your prompt may be attracting the wrong audience. Use this data to iterate on timing and messaging.

Mistake 5: Over-prompting

Showing the prompt every session or after every action is a fast track to user annoyance. Set a reasonable frequency cap—once per user, or once every few sessions. Respect the user's previous dismissal: if they said no, wait a significant number of visits before asking again (if at all).

Mistake 6: Forgetting the 'why'

Users need a reason to install. If your PWA does not offer offline functionality, push notifications, or a faster load experience, the home screen shortcut adds little value. Before investing in prompt optimization, make sure your PWA actually delivers a better experience than the website. Otherwise, you are asking users to clutter their home screen for no benefit.

7. Mini-FAQ: Common Questions About A2HS Prompts

Can I show the prompt on iOS?

iOS Safari does not support the beforeinstallprompt event. The only way to prompt iOS users is through a custom banner that instructs them to use the Share menu and 'Add to Home Screen'. This is a manual process and has lower conversion rates. Consider it a secondary channel and focus your optimization efforts on Android and desktop Chrome.

How many times can I show the prompt?

There is no hard limit, but best practice is to show it no more than once per session, and to respect a user's dismissal for at least a few sessions. Some browsers (like Chrome) will not show the native prompt again once dismissed, so if you use the deferred approach, you can control the frequency yourself. A reasonable pattern: show on the 3rd visit, then again on the 10th visit if dismissed, then stop.

Does the prompt affect SEO?

No, the A2HS prompt is a client-side feature and does not impact search engine rankings. However, the underlying PWA requirements (service worker, manifest) can improve performance and user experience, which indirectly benefits SEO. The prompt itself is neutral.

What if the user has already installed the app?

You can detect installation by listening for the appinstalled event or by checking if the app is running in standalone mode (via matchMedia('(display-mode: standalone)')). Once installed, hide the prompt. Showing it again would be confusing and annoying.

Should I prompt on desktop?

Desktop users can install PWAs, but the behavior is less common. The prompt may appear in the address bar or as a small icon. If your PWA offers value on desktop (e.g., offline document editing), it is worth prompting, but manage expectations: conversion rates are typically lower than on mobile.

Can I A/B test different prompt designs?

Yes, especially with custom prompts. You can test different copy, colors, timing, and placement. Use analytics to measure which variant yields higher acceptance rates. Just be careful not to confuse users with too many variations—test one variable at a time.

Now that you understand the landscape, the criteria, and the implementation steps, it is time to audit your own PWA. Review your current prompt behavior, identify which mistakes you might be making, and choose a strategy that respects your users' context. Start with the deferred approach if you are unsure—it is low-risk and gives you room to iterate. Then measure, learn, and refine. The goal is not to maximize installs at any cost, but to offer a genuine shortcut to users who already value your app.