In-App Rating Dialog API
Ask your users for a Google Play review: trigger a native "Rate this app" dialog from your web app via rateapp:// or let WebViewGold show it automatically.
Positive Google Play reviews are one of the most powerful growth drivers for your app. The In-App Rating Dialog API of WebViewGold lets you ask your users for a rating at exactly the right moment — for example, right after a successful purchase or after they completed a task in your web app.
Option 1: Trigger the rating dialog manually from your web app
Call the following URL from an HTML link or from JavaScript to show a native "Rate this app" dialog:
<a href="rateapp://">Enjoying the app? Rate us!</a>
window.location.href = "rateapp://";
If the user confirms the dialog, the Google Play page of your app opens so they can leave a review. For this to work, set RATE_MY_APP_URL in Config.java to the Google Play URL of your app:
public static final String RATE_MY_APP_URL = "https://play.google.com/store/apps/details?id=com.yourcompany.yourapp";
Note: If RATE_MY_APP_URL is empty, rateapp:// calls are ignored. The title and message of the dialog can be customized via the rate_title and rate_message entries in strings.xml.
Option 2: Let WebViewGold ask automatically
WebViewGold can also show a "Rate this app" prompt automatically after the user has used your app for a while. Configure this behavior in Config.java:
SHOW_RATE_DIALOG— set totrueto enable the automatic rating prompt (orfalseto disable it).RATE_DAYS_UNTIL_PROMPT— minimum number of days after installation before the prompt is displayed.RATE_LAUNCHES_UNTIL_PROMPT— minimum number of app launches before the prompt is displayed.
Typical Use Cases:
- Ask for a review right after a positive interaction (completed order, level up, successful booking).
- Show your own custom "Do you like the app?" flow on your website first, and only send happy users to
rateapp://.
SDK-style implementation notes
Treat this feature as a native capability exposed to your web layer: keep your production website or PWA as the source of truth, then use the documented WebViewGold configuration flags, URL commands, and JavaScript bridge calls to opt in to native Android behavior only where it adds value. This approach keeps your codebase maintainable because the same web application can serve browsers, WebViewGold for Android, and the other WebViewGold platforms with minimal conditional logic.
For reliable results, prefer HTTPS endpoints, stable route names, explicit success/error states in your UI, and small JavaScript helper functions that wrap native calls. For example, a web app built with jQuery Mobile, Lovable, Base44, Bolt, WordPress, Bubble, a custom React/Vue/Angular stack, or static HTML can expose a single button or event handler that triggers the native WebViewGold API while still showing a graceful browser fallback.
- Recommended integration pattern: detect the app context, call the WebViewGold API, then update your web UI after the native callback or route change.
- Testing checklist: validate the feature on a real device or packaged build, verify permissions and store review text, and confirm that browser-only users still receive a useful fallback.
- SEO benefit: keep feature pages, route titles, and structured content indexable on your website while WebViewGold delivers the native app shell for Android users.