Option A: Convert Your Private Account to a Company Account (or open fresh one)

– If you already have a private Google Play developer account, you can switch it to a company

account.

– This is useful if you plan to publish apps under a business name.

– Make sure your business details (address, tax ID, etc.) are ready before making the change.

Option B: Test With a Group of Testers

– Before going public, it’s smart to test the app with a closed group.

– Invite friends, colleagues, or external testers to try your app and give feedback.

– You can manage testers via Google Play Console (Closed Testing or Internal Testing tracks).

Option C: Use Fiverr for Affordable Testing Service

1. Sign up using our Fiverr link: https://www.jocapps.com/partner-network/fiverr-pro-voucher

2. Once signed up, search on Fiverr for: “Play Store tester”, set your maximum budget to 10 USD

or 10 EUR and you will see many affordable testers available which allow you to quickly get real- world feedback without overspending:

The post How to Get 12 or 20 Google Play Store Testers easily appeared first on WebViewGold Support Center.

Starting November 1st, 2025, all new apps and updates targeting Android 15 (API level 35) and higher must support 16 KB memory page sizes on 64-bit devices.

This change comes as Android devices evolve to include more RAM and optimize performance. By switching from 4 KBto 16 KB memory pages, devices benefit from:

• Faster app launches (up to 30% in some cases)

• Lower power usage during startup (~4.5% less)

• Quicker camera launches (4–6% faster)

• Faster device boot times (~8% improvement)

WebViewGold for Android: Already Compliant (If You’re on the Latest Version)

The latest version of WebViewGold for Android is already 100% compliant with this new Google Play requirement.

However, older versions (e.g., from May 2025 or earlier) may not meet this requirement. If you’re unsure whether your app is affected, you can:

• Check the Google Play Console warning messages for your project.

• Use the APK Analyzer in Android Studio to see if any native alignment issues are reported.

Should You Update?

Since WebViewGold is an app template (not a traditional software framework), updating requires some manual work. Our recommendation:

• Update only if you need compliance (e.g., for apps targeting Android 15+ after Nov 1, 2025) or want new features.

• Otherwise, you can safely skip updates not relevant to your app.

You can always check what’s new in our changelogs:

• WebViewGold for Android changelog

• WebViewGold for iOS changelog

How to Update WebViewGold Safely

If you decide to update to the latest version, here’s the easiest approach:

On iOS

• Replace the Config.swift file with your existing one.

• Refill any new variables introduced in the update.

On Android

• Replace your existing Config.java and relevant parts of MainActivity.java.

• Copy over your icons, strings.xml, and colors.xml files.

• Watch out for new variables in Config.java that may need to be configured.

General Tips

• Keep the same Bundle ID / Package Name.

• Increase your app’s version number (required for Play Store updates).

• Use Git or version control tools (GitHub, GitLab, etc.) to compare changes between versions and merge safely.

Conclusion

If you’re running the latest WebViewGold for Android, your app is already future-proof for the new 16 KB page size requirement.

If you’re on an older version, we recommend upgrading only if:

• You plan to update your app on Google Play after November 1, 2025, or

• You need new features or fixes from the latest release.

Stay ahead of Play Store requirements with WebViewGold — your fastest path from website to Android app.

Check out the latest WebViewGold for Android

The post Is Your WebViewGold App Ready for Google Play’s 16 KB Requirement? appeared first on WebViewGold Support Center.

With WebViewGold, you can easily convert your web content into native iOS and Android apps without any programming knowledge. By incorporating Pushwoosh, a leading platform for push notifications and marketing automation, you can add sophisticated notification features. This allows you to keep your users informed, engage them with your app, and ensure they keep coming back.

Why Integrate Pushwoosh into Your WebViewGold App?

Push notifications are a critical factor for the success of a mobile app. The Pushwoosh integration enables you to leverage effective strategies to grow your business:

• Increase Engagement: Keep users active by sending scheduled or triggered campaigns. Announce a flash sale, share breaking news, or remind users of a special event—right when it matters most.
• Onboard New Users: Create a welcome series with automated push notifications and in-app messages. Guide new users through your app’s key features to improve understanding and increase activation rates.
• Gather Valuable Feedback: Want to know what your users think? Use push notifications to send surveys and gather direct feedback. You can use these insights for product development and to improve the user experience.
• Increase Customer Retention & Prevent Churn: Identify users who are becoming less active and automatically send them a personalized re-engagement message to win them back before they uninstall the app.

Exclusive Offer for WebViewGold & Pushwoosh Users

To celebrate this partnership, we have a special offer for you!

• For WebViewGold Users: Get two free months of Pushwoosh to discover its full potential.
• For Pushwoosh Users: Secure a free license upgrade for WebViewGold.

To take advantage of this offer, simply send your WebViewGold License Code and your Pushwoosh App Code to pushwoosh-love@webviewgold.com.

Setting Up Pushwoosh in Your WebViewGold App

Integrating Pushwoosh is straightforward. You just need to enable the feature and add your unique Pushwoosh IDs to the configuration files.

Developer assistance needed: You may need support from your development team to complete this setup. Please share this guide with them.

Important Prerequisite: Pushwoosh Account Setup

Before you begin, you must have an active Pushwoosh account. There, you will need to:

1. Set up your application in the Pushwoosh dashboard.
2. Configure the required platforms (APNs for iOS, FCM for Android).
3. Upload the necessary certificates and credentials (e.g., your .p12 certificate for iOS).

Please follow the official Pushwoosh documentation to complete this crucial first step. The integration in WebViewGold will only work once your app is fully configured on the Pushwoosh website.

Integration Steps for Android

Here’s how to enable Pushwoosh in your WebViewGold Android app:

1. Open your project in Android Studio and navigate to the file: app/src/main/java/your/package/name/Config.java.
2. Find the following line: public static final boolean PUSHWOOSH_ENABLED = false; …and change it to true:public static final boolean PUSHWOOSH_ENABLED = true;
3. Next, open the app/src/main/res/values/strings.xml file and replace the placeholder values with your actual Pushwoosh App ID.
4. Finally, open the app/src/main/AndroidManifest.xml file and replace the placeholder with your Pushwoosh FCM Sender ID.

That’s it! Your Android app is now configured to receive push notifications.

Integration Steps for iOS

Here’s how to enable Pushwoosh in your WebViewGold iOS app:

1. Open your project in Xcode and find the Config.swift file.
2. Find the following line: static let kPushwooshEnable = false …and change it to true: static let kPushwooshEnable = true
3. Next, open the Info.plist file.
4. Find the key Pushwoosh_APPID and replace the placeholder string with your actual Pushwoosh Application ID.

Congratulations! Your iOS app is now ready for Pushwoosh.

You’re All Set!

After completing these simple steps, your WebViewGold app will be fully integrated with Pushwoosh. You can now log into your Pushwoosh dashboard to create segments, build campaigns, and send powerful push notifications to your users.

If you have any questions, feel free to contact our support team at any time.

The post How to integrate Pushwoosh in WebView-based iOS and Android apps? appeared first on WebViewGold Support Center.

TL;DR (the quick fix)

1. Host a tiny index.html somewhere that’s not behind your problematic CDN (or use a different CDN).

2. That index.html immediately redirects to your real site (which is on the CDN).

3. Point your app’s WebView at the new index.html instead of your main domain.

This extra “hop” often bypasses CDN heuristics that block first loads from WebViews.

Why this works

Many CDNs and WAFs score requests with heuristics (e.g., unusual User-Agents, missing cookies, iframes/embeds, in-app browsers). A clean first request to a neutral host can:

• Set initial cookies/headers cleanly,

• Avoid tripping bot rules on the first navigation,

• Land the user on your real site immediately after.

If your CDN challenge happens only on first paint, this simple redirect hop can get you past the white-screen wall.

Step 1 — Create a minimal index.html on a neutral host

You can use any free/basic static hosting (there are lots of lists and threads out there with options, e.g., https://www.reddit.com/r/software/comments/1i0av3m/whats_the_best_free_hosting_site_for_a_basic_site/). The file should be as empty as possible and perform an instant redirect.

Example index.html

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>Loading…</title>
    <!-- HTML fallback -->
    <meta http-equiv="refresh" content="0; url=https://your-cdn-site.com/" />
    <script>
      // JavaScript redirect (more reliable than meta refresh)
      (function () {
        var target = "https://your-cdn-site.com/?src=webview-hop";
        // Use replace() to avoid back-button loop
        window.location.replace(target);
      })();
    </script>
    <noscript>
      <meta http-equiv="refresh" content="0; url=https://your-cdn-site.com/?src=noscript-hop" />
    </noscript>
    <style>html,body{background:#fff;height:100%;margin:0}</style>
  </head>
  <body></body>
</html>

Tips

• Add a simple query param like ?src=webview-hop so you can see hop traffic in analytics and debug loops.

• Keep it static—no frameworks, no external scripts, no cookies.

Step 2 — Point your WebView to the neutral

index.html

Android (Config.java)

see webviewgold.com/docs/android

iOS (Config.swift)

see webviewgold.com/docs/ios

Step 3 — Test the flow

1. Cold start your app (force-quit first).

2. Confirm the WebView loads the neutral page and then quickly redirects.

3. You should land on your real site (on the CDN) without a white screen.

4. Check your analytics for hits with src=webview-hop.

Troubleshooting & hardening

• Avoid redirect loops:

  If your main site sometimes redirects back to the neutral host, add a rule on the main site: if src=webview-hop is present, do not redirect again.

• HTTP 301/302 vs. JS/meta:

  If you can configure the neutral host to respond with an HTTP 302 to your main site, that’s even cleaner. Otherwise, the JS location.replace() shown above is reliable.

• HTTPS & HSTS:

  Ensure the neutral host supports HTTPS (no mixed content). Some strict CDNs plus HSTS can block downgraded or mixed requests.

• Cookies / SameSite:

  If your main site needs cookies on first load, make sure they’re set with attributes compatible with in-app browsers (e.g., SameSite=None; Secure where appropriate).

• User-Agent tweaks (optional):

  Some CDNs block uncommon User-Agents. A modern mobile UA string can help—test before shipping.

• Error reporting:

  Add console/JS error reporting (e.g., Sentry) to see if the WebView is blocked by CSP, CORS, or script errors that look like “white screen” issues.

When to use this workaround (and when not to)

Use it when:

• You see a white screen only inside WebViews and only on the first load.

• You don’t control CDN rules or can’t get them fixed quickly.

Prefer a CDN fix when possible:

• Whitelist your app’s User-Agent or domain.

• Relax overly strict bot/WAF rules for your origin.

• Check CSP, CORS, and TLS/H2/HTTP3 settings that can confuse embedded browsers.

This “redirect hop” is a pragmatic patch you can deploy fast; long-term, align your CDN/WAF to support in-app browsers properly.

Copy-paste checklist

• Create neutral index.html with instant redirect (JS + meta refresh).

• Host it on a non-problematic origin (no WAF/CDN hurdles).

• Point Android/iOS WebViews to that URL.

• Add a query param (e.g., src=webview-hop) for debugging/analytics.

• Verify no redirect loops; confirm HTTPS everywhere.

• Monitor errors and analytics; iterate as needed.

Bonus: server-side redirect variant

If your neutral host lets you set server rules, a simple 302 is ideal. For example, on Apache:

# .htaccess
Redirect 302 / https://your-cdn-site.com/?src=server-hop

Or on Netlify (_redirects file):

/  https://your-cdn-site.com/:splat  302!

Got stuck or still seeing a white screen? Write to our support, we are happy to help!

The post Fixing “white page” CDN issues in iOS & Android WebViews with a workaround appeared first on WebViewGold Support Center.

Integrating RevenueCat is our recommended approach for handling in-app purchases and subscriptions. It simplifies the process across both iOS and Android, providing a powerful backend to manage transactions, entitlements, and analytics. Here is a step-by-step guide to get you started.

Step 1: Create Your RevenueCat Account

First, you need to create a free account on the RevenueCat website. Follow their setup wizards to add your app, configure your in-app products, and connect to App Store Connect and Google Play Console.

Sign up for RevenueCat here.

Step 2: Configure WebViewGold with Your API Keys

After setting up your project in RevenueCat, you need to add your unique API Key and Project ID to your WebViewGold project. You can find these keys in your RevenueCat dashboard.

For iOS (in Config.swift):


static let revenueCatAPIKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" // Your RevenueCat API Key
static let revenueCatProjectID = "xxxxxxxxx" // Your RevenueCat Project ID


For Android (in Config.java):


public static final String REVENUECAT_API_KEY = "xxxxxxxsxxxxxxxxxxxxxxxxxxxxxxxxxx"; // Your RevenueCat API Key
public static final String REVENUECAT_PROJECT_ID = "xxxxxxx"; // Your RevenueCat Project ID


Step 3: Trigger a Purchase from Your Web Content

To initiate a purchase or subscription, create a link in your HTML using the revenuecat:// URL scheme. This works for both iOS and Android.


<a href="revenuecat://purchase?external_id=user_123&product=sub_30_days">Subscribe Now</a>


Here’s what the parameters mean:

• external_id: This should be your own unique identifier for the user (e.g., their email, username, or a database user ID). This is crucial for tracking purchases for specific users.
• product: This is the Product or Entitlement ID that you defined in your RevenueCat dashboard.

Step 4: Granting Access to Content

The most secure and reliable way to grant access to premium content is by using RevenueCat Webhooks. You can configure a URL on your server to receive real-time notifications from RevenueCat about events like initial purchases, renewals, and cancellations. Your server can then update the user’s access rights in your database automatically.

Please check out our documentation for detailed examples:

iOS: https://www.webviewgold.com/docs/iOS/#inapppurchases
Android: https://www.webviewgold.com/docs/android/#inapppurchases 

For more detailed information, please also refer to the official WebViewGold website.

The post How do I set up RevenueCat for In-App Purchases / In-App Subscriptions in WKWebView (iOS) or WebView (Android)? appeared first on WebViewGold Support Center.

You can configure it in Config.swift of WebViewGold easily

The post How does the native footer in iOS WebView looks like? appeared first on WebViewGold Support Center.

Step 1: Download the Latest WebViewGold Version

• Go to your CodeCanyon Download tab: https://codecanyon.net/downloads

• Click “Download” → “All files & documentation” for WebViewGold (iOS or Android)

• Unzip the downloaded file

Step 2: Use Git/GitHub to Compare Files

If you’re working with version control (highly recommended):

1. Create a GitHub repository:

   • Visit https://github.com

   • Log in and click “New repository”

   • Name it something like webviewgold-ios-custom or webviewgold-android-app

   • Choose Private visibility

    

2. Upload your current (customized) app to the main branch

3. Create a second branch (e.g. original-v5.8) and upload the new WebViewGold files there

4. Use GitHub’s Compare feature to:

   • Identify what changed

   • Manually transfer new/required changes into your working version

    

Step 3: Replace Key Files for Upgrade

On iOS:

• Replace your Config.swift file from the previous version into the new one

• Make sure your Bundle ID stays the same

• Increase the version number and build number

• Reapply customizations like splash screen, colors, icons, etc.

On Android:

• Replace the Config.java file and copy over custom code from your MainActivity.java

• Watch out for any new variables or settings in the updated version and configure them accordingly

• Copy over:

  • res/values/strings.xml (texts)

  • res/values/colors.xml

  • App icons in res/mipmap-*

   

• Keep the same Package Name

• Bump up the version code and version name

Bonus Tip: Use Git Tools

For even smoother handling, use tools like:

• GitHub Desktop

• GitKraken

• Sourcetree

• Or built-in Git support in Visual Studio Code

The post How to use GitHub for smart upgrading of WebViewGold app template? appeared first on WebViewGold Support Center.

TL;DR:

Google Play will require apps to target Android 15 (API level 35) by August 31, 2025. Existing apps must at least target Android 14 (API level 34) to be downloadable on newer devices. WebViewGold is a ready-to-use alternative to ensure compliance easily and quickly—even for replacing existing apps if you have your keystore.

What is Google Play’s Current Target API Level Requirement?

Google Play updates its required API level annually. From August 31, 2025, app developers must ensure their new apps or app updates target Android 15 (API level 35) or higher to be accepted in the Google Play Store.

Existing apps currently published must target Android 14 (API level 34) or higher. If an app targets a lower API level, it risks becoming unavailable for users on Android 15 or newer devices.

Developers can request an extension until November 1, 2025, through the Google Play Console.

Why Does Google Play Regularly Increase its Target API Level?

Google Play’s annual increase ensures apps maintain the highest standards in security, privacy, user experience, and performance. The key benefits include:

• Enhanced Security: Integrates critical security updates.

• Improved Privacy: Adheres to stricter privacy standards and user data protection.

• Better Performance: Leverages newer Android APIs for optimized app performance.

• Device Compatibility: Ensures smooth operation on new hardware and software.

How to Stay Compliant with Google Play’s New API Level Requirement

Compliance involves several critical tasks:

• Third-party SDK Checks: Confirm SDKs support API level 35.

• Target SDK Limitations: Anticipate and test compatibility with private APIs.

• AndroidX Compatibility: Verify AndroidX libraries match your target API.

• Regular Updates: Keep your app updated to the latest stable AndroidX libraries.

To simplify this compliance process, developers can utilize WebViewGold as a ready-made, hassle-free alternative.

How WebViewGold Simplifies API Compliance

WebViewGold is designed specifically to make apps compliant with Google Play’s evolving requirements effortlessly:

• Easy Implementation: Simply insert your URL, no coding required.

• Compliance Guarantee: Fully meets Google Play’s API level requirements, including API 35 for Android 15.

• Replaces Existing Apps: Effortlessly replaces your current apps if you have the original keystore.

• Rapid Deployment: Quick turnaround ensures your app stays visible and downloadable.

Three simple steps to compliance with WebViewGold:

1. Rebuild your app using WebViewGold to instantly target Android 15.

2. Quickly test using WebViewGold’s built-in testing features or actual Android 15 devices.

3. Publish effortlessly to Google Play before the deadline.

How to Comply Without WebViewGold

Without WebViewGold, developers must manually handle:

• Updating their app’s API level and AndroidX compatibility.

• Managing complex behavior

The post Google Play’s Target API Level Requirement: Android 15 (API level 35) appeared first on WebViewGold Support Center.

    Our mobile apps (iOS/Android) are developed using WebViewGold by jocapps GmbH (Germany). These apps display the content of our website using a WebView framework and enrich it with selected native features to improve usability and performance. Accordingly, the same privacy policy and terms of service that apply to our website also apply to our mobile apps. For more information, please visit
    https://www.webviewgold.com/#convert-website-to-app-privacy, or contact us directly.

The post What should we add/modify in our Privacy Policy / Terms & Conditions if we deploy WebView mobile apps? appeared first on WebViewGold Support Center.

Images.xcassets: error: Failed to find a suitable device for the type SimDeviceType

This error is not directly related to WebViewGold itself but is instead caused by an issue within the Xcode Simulator.

Solution:
Simply cleaning the project may not resolve the problem. Follow these steps to quickly fix this issue:

1. Open the Terminal on your Mac.
2. Enter and execute the following command:

sudo killall -9 com.apple.CoreSimulator.CoreSimulatorService

3. After running the command, restart your Simulator or relaunch your project through Xcode.

Alternative Solutions: If the issue persists:

• Restart your Mac entirely.
• Clean your build folder in Xcode:
  • Click on “Product” from the top menu.
  • Hold down the Option key and select “Clean Build Folder”.

These steps typically resolve the issue effectively, allowing you to run WebViewGold apps successfully via the Simulator.

The post Fix Xcode Images.xcassets: error: Failed to find a suitable device for the type SimDeviceType appeared first on WebViewGold Support Center.