If you are referring to the behavior where the app shows a blank or white screen after being left idle for several hours (typically 5–9 hours) and then reopened, please note that this has already been forwarded as a feature improvement request. We have shared this feedback with our technical team for consideration in future updates.

However, if this issue was occurring frequently without the app being left idle for long periods, that would not be expected behavior.

In that case, we recommend reaching out to our support team directly through the dedicated support channels with details about your app and the steps to reproduce the issue. Our team will be happy to investigate and assist you further.

naomi778:

WooCommerce store into a native iOS app

Hey Naomi,

From what you’ve described, the performance drop is most likely related to the external execution environment and background resource usage, rather than the AppMySite app itself. Tools like executors or automation environments that run intensive background processes can significantly affect CPU, memory, and GPU allocation on the device, which may lead to frame rate drops or delays in data synchronization.

It’s also important to note that AppMySite apps rely on the device’s available resources and the operating system’s background process management. When another high-resource tool is running simultaneously, iOS may throttle performance for foreground or background processes to maintain overall system stability.

We hope this helps clarify the behavior you are seeing, and we appreciate you taking the time to thoroughly test your app.

If you run into any specific issues with your app, please feel free to reach out to our support team directly through the dedicated support channels, and we will be happy to assist you further.

Unlike traditionally coded apps, our no-code platform does not generate keystore details in a sharable format. These details are embedded within the app build process and are not accessible separately.

Additionally, since AppMySite is not an open-source platform, we are unable to share the source code or the associated .jks / keystore file, as it contains sensitive build data used during the app generation process.

I’m currently using a delta exec tool to run some local UI automation scripts to test how my app handles rapid-fire checkout sequences and push notification triggers. The logic for these tests is based on the automation workflows in this delta blox fruit guide, which I adapted to see if my app’s memory management could handle high-velocity events. However, I’ve noticed that whenever the delta exec tool is active in the background, the app’s frame rate drops significantly, and the “Real-Time Sync” with my WordPress site starts to lag.

Has anyone else here tried using a delta exec tool or similar external execution environments to stress-test their AppMySite builds? I’m trying to figure out if the performance hit is due to how the iOS sandbox handles the executor’s background processes or if I need to optimize my app’s “Image Cache” settings to free up some RAM. I really want to ensure a smooth experience for my power users who might have other background tools running, but right now, the app seems to struggle with the extra overhead. Does anyone have tips for maintaining app stability when these types of high-resource tools are active?

I am planning to migrate my Android app to another development environment, and I need my Keystore details to update the existing app on Google Play.

Could you please provide me with the following information for my app (App ID: 585611)?

• Keystore file (.jks or .keystore)

• Keystore password

• Key alias

• Key alias password

Thank you, Daisuke

I’ve actually had this exact same problem. Users were getting blank white screens and buttons on startup, which only fixed itself if they completely closed and restarted the app.

It got to the point where I just unpublished it—it’s way too hard to explain that workaround to every single user. AppMySite is an awesome platform overall, but it would be amazing if you could add a feature to force-close or reload the app automatically to prevent this.

fgtv:

Thank you for your reply and for the clarity in your explanation about how mobile operating systems handle background apps. I understand that resource management varies depending on the operating system and device, and I agree that there are multiple factors involved.

However, I would like to point out that I have tested numerous apps under similar conditions, and none of them exhibit this kind of blocking or crashing behavior when reopening the app after several hours in the background. It’s true that the issue doesn’t occur if I fully close the app before reopening it, but from a user experience standpoint, most users typically do not do this.

For this reason, it would be very valuable if you could consider exploring and implementing improvements in this area, so that the app’s behavior remains stable and user-friendly even after long periods of inactivity. I’m confident that this would significantly enhance the experience for all users of the platform.

Thank you for your attention and for the ongoing dialogue focused on improving the product.

@fgtv
Thank you for your thoughtful response and for sharing your testing experience in detail. We truly appreciate the time you’ve taken to explain the situation and provide constructive feedback.

We have noted your suggestion as a feature improvement request and have passed it along to our technical team for consideration in future updates. Feedback like yours helps us better understand real user scenarios and identify areas where the platform can continue to improve.

Thank you again for your valuable feedback and for contributing to the community discussion. We appreciate your input and your continued support of the platform.

However, I would like to point out that I have tested numerous apps under similar conditions, and none of them exhibit this kind of blocking or crashing behavior when reopening the app after several hours in the background. It’s true that the issue doesn’t occur if I fully close the app before reopening it, but from a user experience standpoint, most users typically do not do this.

For this reason, it would be very valuable if you could consider exploring and implementing improvements in this area, so that the app’s behavior remains stable and user-friendly even after long periods of inactivity. I’m confident that this would significantly enhance the experience for all users of the platform.

Thank you for your attention and for the ongoing dialogue focused on improving the product.

Thank you for your question.

At the moment, AppMySite does not support preventing users from taking screenshots within the app, including on specific pages. This type of functionality typically requires native-level controls on individual screens, which is not currently available within the AppMySite platform.

That said, we understand that this can be an important requirement for apps dealing with sensitive information or protected content. We have noted your request and will add this feature to our product roadmap for consideration in future updates.

We truly appreciate you sharing your use case, as feedback like this helps our team identify features that can benefit the broader community.

If you have any other questions or suggestions, feel free to share them here.

Thank you for taking the time to share your feedback. We truly understand your concern regarding response times and appreciate you bringing this up.

We would like to clarify that the community forum is primarily intended as a public space where users can interact with one another, share experiences, ideas, and potential solutions. As mentioned on the Community Introduction page, while the AppMySite team does occasionally monitor discussions here, responses from our team on the community are not guaranteed.

If you require official assistance or support for a specific issue, we strongly recommend reaching out to our dedicated support team directly through your AppMySite account. This ensures that your request is logged in our support system and reviewed by the appropriate team so it can be properly investigated and addressed.

Our support team is specifically assigned to handle customer queries and provide assistance through the official support channels, which allows us to track, prioritize, and resolve issues more efficiently.

We truly value your feedback and your patience, and we encourage you to submit any support-related concerns through the in-account support channel so our team can assist you as quickly as possible.

Thank you again for being a part of the community and for sharing your thoughts.

Considering the slow response time effort, and the further delay of addressing the contrast settings in iOS 26, it will be awhile before there’s a solution to this…so that means any users (me or anyone else for that matter) experiencing this issue will be impacted for months.

I wonder if other users feel ignored.

If you felt this was such a low priority that it didn’t warrant a response for a full billing cycle, you should at least let people know where the support request stands in the stack of priorities. If other extenuating circumstances affect your response time…please let us know.

if you don’t have the human resources to respond, you might want to reach out to some of the “power users” in the forum and work out a plan to have them assist. Prompt support responses could help improve customer satisfaction.

I sincerely look forward to seeing the ability to choose legacy settings and to drastic improvements in support response times.

KC

Hopefully your issue has been resolved by now. Sometimes temporary connectivity issues can occur, which may get resolved automatically after some time.

However, if the problem is still persisting, we recommend reaching out to our support team directly by raising a support ticket so that our team can check your app configuration and connectivity in detail.

Once the ticket is raised, our team will be able to investigate the issue promptly and assist you further.

Thank you!

Thank you for bringing this to our attention.

The error message “No path provides a match between the URL and the requested method.” usually indicates that the API endpoint being called is not available or the request being sent does not match the expected method on the server side.

Since features like shopping cart, login, and signup depend on the proper communication between the app and your website APIs, this issue may be related to the website configuration, plugin setup, or API accessibility.

To help us investigate this further, we kindly request you to please raise a support ticket with us and share the following details:

• The app ID and app name
• A screenshot of the error
• The steps you are following when the issue occurs

Once we receive these details, our team will review the configuration and assist you in identifying the cause of the issue.

We look forward to helping you resolve this as soon as possible.

After reviewing your concern, we would like to clarify that the behavior you are experiencing is currently the expected behavior of the AppMySite platform.

At the moment, the “Open in external browser” option is available only for links configured using the WebView link type. This means the option will work for external URLs added through WebView.

However, this option does not apply to internal app content, such as:

• App Pages

• WordPress posts or pages

• Menu items generated from your WordPress menu

These sections are designed to load within the app experience, and opening them externally would effectively redirect users to your website outside the app, which is why this functionality is not supported for those content types.

If you would like certain links to open outside the app, the recommended approach is to add those links as WebView items and enable the “Open in external browser” option for them.

If you continue facing issues with the WordPress menu sync not refreshing, please reach out to our Support team and they would assist you further.

Thank you again for your patience and understanding.

Currently, the AppMySite platform does not have a native option to display post view counts or interaction metrics within the app.

If you would like to show view counts for your posts (for both new and existing posts), you can implement this on the WordPress side using a plugin that tracks and displays post views on your website.

Once the view count is visible on the website pages, the same information will automatically appear in the app as well, since the app loads the content from your site (for example, when pages are displayed through WebView).

So, this functionality would need to be implemented and managed through your website configuration, and the app will reflect those changes accordingly.

Hope this helps!

Thank you for sharing the detailed explanation of your setup and concerns. We understand how important this functionality is for your app roadmap.

We checked your case and can confirm that your concern was already escalated to our technical team for a deeper review. Based on their analysis, here is the clarification regarding the behavior you are observing.

Currently, in AppMySite:

• Firebase Authentication is used only for social login when Native Login is enabled (for example, Google login through the native authentication flow).

• Manual login via WebView or WordPress login forms is authenticated directly through WordPress, not through Firebase.

Since your app is currently using WebView-based login and native login is not enabled, the authentication happens entirely on the WordPress side. Because of this, Firebase does not receive or record these login events, and therefore users will not appear in Firebase Authentication → Users.

Root Cause
Firebase records users only when social login is performed through the native login flow. Manual login through WordPress or WebView does not create or register users in Firebase Authentication.

Recommended Approach

• Enable Native Login in your app.

• Use Social Login (e.g., Google) through the native authentication flow so that users are authenticated via Firebase and recorded there.

• If you continue using WordPress manual login through WebView, Firebase user tracking will not occur, as the authentication is handled entirely by WordPress.

If you are still facing any issues or need help configuring this setup, please feel free to reach out to our support team directly by raising a support ticket. Our team will be happy to review your configuration and guide you further to resolve the issue.

Thank you for sharing the details of the issue you are encountering while enabling push notifications for your iOS app.

In this setup, there are two app identifiers involved, and the configuration needs to be done carefully:

• The main app identifier (used for your app build) should have Push Notifications capability enabled.

• The secondary identifier that is used specifically for creating the notification provisioning profile should not have any capabilities enabled. It should remain blank without enabling Push Notifications or any other capability.

If the capabilities are enabled on the secondary identifier, it may lead to the provisioning profile error you are currently seeing.

If you are still facing the issue after verifying these settings, we recommend raising a support ticket with us. Our team can review your Apple Developer account configurations and guide you further to resolve the issue.

We will be happy to assist you with the setup.

Thank you for bringing this up and for sharing the details you’re seeing in the preview.

After a thorough technical analysis, we can confirm that the behavior you are observing is not caused by an issue in the application code.

With recent iOS updates (including iOS 26), Apple has strengthened automatic contrast and readability adjustments within system UI components such as UITabBar. These system-level adjustments can modify how tab bar items (icons and text) are rendered in order to maintain sufficient contrast and accessibility.

In your current configuration:

• Selected text/icon color: Green

• Unselected text/icon color: White

• Tab bar background: Darker blue shade

Since the unselected color and the background fall within a similar tonal range, iOS may automatically apply contrast adjustments to improve readability. Because of this, the unselected elements may appear darker (sometimes close to black) instead of the configured shade.

This behavior is controlled by iOS system rendering and accessibility logic, and the OS may override certain color combinations to maintain visual clarity.

Recommended approach

To minimize these automatic adjustments, we recommend using stronger contrast between the tab bar elements, for example:

• Tab bar background: Lighter shade

• Selected color: Green (this is fine)

• Unselected color: Black

Using clearly distinguishable colors helps reduce the likelihood of system-level contrast modifications.

Upcoming enhancement

To provide more flexibility, we are also working on an enhancement in the App Builder that will allow customers to choose between:

• Standard system appearance (Apple’s default behavior), and

• A legacy-style tab bar configuration for more controlled color behavior.

This improvement is currently under development and will be launched in the future.

We appreciate you highlighting this here, as feedback like this helps us continue improving the platform.

To comply with the Play Store policy in cases like this, you can configure the links to open outside the app in the device’s native browser instead of loading within the in-app WebView.

This can be done using the “Open in external browser” option available in the WebView settings.

Please follow these steps:

1. Go to Navigation → Bottom Bar (or the section where the WebView is added in your app menu).

2. Select the WebView item you want to modify.

3. Enable the toggle for “Open in external browser.”

4. Click Save.

5. Rebuild the app so the changes reflect in the live version.

   

Once this option is enabled, the selected links will open in the device’s native browser instead of inside the app, which helps ensure better compliance with Play Store policies when external pages may contain purchase options.

This feature has already been launched, so you can now decide which WebView links in your app menu or bottom bar should open externally.

Hope this helps! If you need any further clarification, feel free to share more details here and the community will be happy to assist.

However, it’s important to clarify that keeping a mobile app open in the background for extended periods such as 8–9 hours for testing purposes is generally not considered a supported usage scenario on mobile platforms.

Both iOS and Android manage apps very aggressively when they remain idle in the background for long durations. During this time, several things can happen at the operating system level, such as:

• The app may be automatically terminated by the system to free memory.

• The app may remain suspended in the background.

• When reopened after a long idle period, the app may restore partially or behave unexpectedly due to OS-level memory and lifecycle management.

This behavior is part of standard mobile OS design and does not necessarily indicate a problem with the app framework itself.

In practical day-to-day usage, when users return to an app after long inactivity, the system typically reloads or refreshes the application state. For the most stable experience, our recommendation is to close (kill) the app completely and relaunch it fresh before using it again if it has remained inactive for many hours.

Additionally, the behavior you described can sometimes be influenced by other factors such as:

• WebView caching behavior

• Device storage availability

• Individual device settings or battery optimization rules

• Device-specific memory management

Since these variables differ across devices and environments, the experience may vary from one user to another.

We appreciate you raising this here, as discussions like this help clarify platform behaviors for everyone in the community.

I haven’t been able to fix it: I’ve tried many options and, to rule out my website/server or any external content, I even created a custom app with no links to any website, using only the platform’s features. Even so, when the app stays idle or in the background for a while (hours), when coming back it gets stuck (sometimes showing a white screen).

Based on these tests, it seems more related to the app’s lifecycle and how the WebView is restored when returning from the background, rather than the content being loaded.

Please let us know if you’ve been able to resolve it.

I’m experiencing exactly the same behavior in my application.

In my case, the app works normally during active use. The issue appears when I leave it in the background for several hours (for example, 4–9 hours or more) and then open it again.

When returning to the app:

• The interface is visually displayed, but the bottom bar colors change unexpectedly.

• Some links stop working.

• The bottom bar buttons (generated by the platform itself) do not respond.

• In some cases, the screen turns completely white before crashing.

I have also received reports from users on both iOS and Android experiencing the same behavior, so this is clearly not limited to a single device.

It is important to note that the application is not native; it operates as a WebView that first loads the AppMySite environment and then renders the web pages. When even the bottom bar created by the platform itself becomes unresponsive, it is difficult to attribute the issue solely to the client’s server. Suggesting that this is only a server-side problem shifts responsibility away from the app framework.

Support has indicated that it might be an issue with my server and suggested that users simply force-close the app and reopen it when it happens. However, this does not seem to be an appropriate solution from a user experience perspective, especially considering that the behavior occurs after several hours of inactivity — which is completely normal in real-world mobile app usage.

If I had known this kind of instability could occur under normal usage conditions, I would not have contracted the service.

Based on the observed pattern, this appears more consistent with a WebView restoration issue after being suspended in the background rather than a server or content-related failure.

I am sharing this because it clearly does not seem to be an isolated case and may require a deeper review of how the app lifecycle is being handled.

Please let me know if you’ve managed to resolve it.

I’m facing a critical issue with the login system, and I need a clear technical explanation and solution.

Here is my setup and problem in detail:

• I am using AppMySite mainly as a wrapper / framework to publish a mobile app.

• The app loads a mobile-only WebView page from my WordPress site.

• Google Login popup appears correctly (account chooser screen).

• After selecting a Google account, the user is successfully registered/logged in inside WordPress (wp_users).

• However, no user is created in Firebase Authentication.

Important points:

• Firebase project is fully configured.

• SHA1 & SHA256 fingerprints are added.

• Google Sign-In is enabled in Firebase Authentication.

• Service accounts are configured.

• Firebase Cloud Messaging is already working.

• The app is correctly linked to Firebase.

Despite all of this:

• Firebase Authentication → Users remains empty.

• Login events are not reflected in Firebase at all.

• Firebase cannot recognize authenticated users, which breaks:

  • User-based notifications

  • Future subscriptions

  • Premium/free user logic

From my understanding:

• AppMySite Google Login authenticates users directly with WordPress, not via Firebase SDK.

• This means Firebase is never notified that a login occurred.

My questions:

1. Does AppMySite Google Login use Firebase Authentication internally, or is it completely separate?

2. If it does NOT use Firebase Auth, is there any supported way to:

   • Sync authenticated users with Firebase?

   • Or trigger Firebase Auth after successful login?

3. Is it possible to fully disable AppMySite’s login and use a custom Firebase-based login instead (Google / Apple / Phone OTP) without breaking the app?

4. Are there plans to support Firebase-first authentication flows?

This issue blocks my entire roadmap, because I need:

• Firebase as the single source of truth for authentication

• WordPress users to be created after Firebase login, not the opposite

I would really appreciate a clear technical answer, not a generic setup guide, because all standard configurations are already done.

Looking forward to your response.

Best regards,

and i have paid for max service and support team did not solve or contact me

How can we address this?

This feature does NOT work on iphone. I’ve tested it several times. It works in the preview, but NOT on an actual device. I’m on an iphone 16, iOS 18.6.2. Are there exceptions or limitations as to which iOS this works for? Is there any documentation to read on this?

I’m only seeing the ability to choose “open in external browser” with WebView as the link type. This does not work for links such as Pages > Home.

I’ve tried to investigate what happens if I choose to sync with my Wordpress menu, but when toggling on that feature, it doesn’t load/refresh….so I cannot test it to see if those menu items load in an external browser. Please advise.

UPDATE: I’ve just seen the ability in the header (see Navigation > turn on Header Menu) to have the three vertical dot menu which pops up the options including “open in external browser”. Would it be possible to trigger a menu of this type for each link? It would also be helpful to have some control over this popup were permitted in the builder to edit menu options and colors (similar to the options available to style the header).

Thank you for addressing this in the app. Very much appreciated.

If you now nagivate to any of your web links, under the link you’ll see an option called “Open in external brower”. If you toggle this on, your app users will be redirected to the default browser of the device, where that particular link will open.

It should be live in a couple of weeks.

Naturaw:

Would love the ability to hot link, for example a sale on a product so when they click on popup notification it opens the app to that product, or, if i want to hotlink from an ad or from a url, like a password reset success.

@milkrow We’re upgrading our product roadmap. Its expected to go live in a couple of weeks.

This issue typically occurs when the email address used to log in to the Shopify store is different from the email address used in your AppMySite account.

Here’s how the flow works:

• When you install the AppMySite Shopify app, Shopify passes the store owner’s email address to us.
• If there is no existing AppMySite account associated with that Shopify email address, our system automatically creates a new AppMySite account using the Shopify email and redirects you to the app creation flow.

To resolve this, please ensure that the same email address is used for both your Shopify store owner/admin account, and your AppMySite app builder account.

If you are currently using different email addresses, we recommend updating the email address on the AppMySite app builder to match the one used on your Shopify store, and then repeating the verification process.

If aligning the email addresses does not resolve the issue, please reach out to our support team, from within your AppMySite account.

I’m having an issue verifying my Shopify connection in AppMySite and I couldn’t get past the Verify step. I’d really appreciate any help.

Here are the exact steps I’m following:

1. In Settings, I select Shopify App and enter my website URL, then save.

2. I go to Connectivity → Connect to Shopify.

3. I click Verify (top right).

4. This opens the Shopify login page. I log in successfully.

5. Shopify then redirects me to the app installation screen, where I install the AppMySite Shopify app and grant all permissions.

6. After installation, Shopify opens the AppMySite app inside Shopify, but it automatically creates/logs me into a new AppMySite user.

7. I log out from that newly created AppMySite user and log back in with my original AppMySite account.

8. However, when I return to AppMySite, the connection is still not verified.

I’ve tried repeating the process multiple times, but the verification never completes.

Has anyone faced this issue before?
Is there a specific account that must remain logged in during verification, or am I missing an extra step?

Thanks in advance for your help!

Have you been able to prevent users from taking screenshots in AppMySite created apps? We have a web-to-app app for our customers on iOS and Android but want to prevent them from screenshotting specific pages. This is a feature available in natively built iOS and Android apps (on password pages etc) but not sure of this is an AppMySite feature. I haven’t been able to find anything online. Thanks for your help.

The app usually works fine, but sometimes if I leave it in the background for a few hours and then open it again, the whole interface turns white (icons too) and it crashes.

It’s happened to me on a few Samsung phones already. I reached out to support but didn’t get much help.

Has anyone else run into this? Any tips on how to fix it?

Thanks!

the connectivity from yesterday afternoon totally failed, but before it works well.

Please help to check as soon as possible.

Thank you for reaching out, and welcome to the AppMySite community!

Yes, you can absolutely convert your existing website into a PWA using AppMySite. To achieve this, you’ll need to use our Custom App solution.

Our Custom App solution allows you to build your app from scratch using customizable elements like image galleries, external links, and custom code. It’s one of our most versatile products that lets you create apps with both native and WebView content.

You can create a custom app on our portal, map your existing website pages within the app, and from there, you’ll be able to generate a PWA based on the custom app you build. Along with your website’s pages, you can also generate and blend native pages to create a more impactful and engaging PWA.

You can click on the link below to learn more:
Custom Apps