The loading screen never disappears

This is usually caused by a JavaScript error that happens before o3h.Instance.ready() is called, preventing
execution from reaching that line.

• Check that your web server can be accessed from your device
  • Copy the address you entered and paste it directly into Safari on the device and see if it loads
• Check for JavaScript parsing errors
  • Immediately after you load the module, attach the Safari inspector from your desktop to the device and check for errors in the console.
    The "Delayed Load" function should be useful here.
  • Alternately, load the html page directly in your desktop browser and check for console errors here.
    If you have a syntax error it may show up here during parsing.

A pink screen shows between the loading screen and the module

This screen was added to the SDK specifically to warn you if your module load sequence is incorrect.
If you see even a flash of it while starting your module, please review your module's initialization sequence and ensure o3h.Instance.ready() is being called only when your module is fully loaded and rendering.

The pink screen should also not be seen at any point while running the module, as it means there is nothing rendering in that area. Ensure that something is being rendered over the entire screen at all times either with the webview or a module component.

There are a few things you can try to debug a pink screen:

• Recognize that local loading vs loading live will be different because resources are fetched from AWS
• All splash screen assets need to be loaded before firing ready. Consider using a preloader script or an event such as window.onload.
• You can debug preloading by enabling the network conditioner in the Developer settings on your iPhone.
• Make sure all asynchronous operations are being resolved properly to avoid race conditions. Documentation on promises can be found here. Documentation on async/await can be found here.

Note that you may see the pink screen momentarily while the module is closing after exiting it. This is normal.

Memory leaks

A difficult topic to address, but there is one error that has popped up a few times that could signify it. If the Module starts lagging and eventually crashes, preceded by the following error, it's possible there is a memory leak somewhere. Generally to address issues like this, you should try to gradually isolate the suspicious code and see if it's possible to resolve.

❗️

Failed to load resource: The operation couldn't be completed. (WKErrorDomain error 1.).

Before debugging for a potential memory leak, make sure to enable the memory profiler in the Timelines tab, hit Done, and then hit the red record button on the left.

If you have a potential memory leak, the module's memory should go up without going back down, which can signify a memory leak.

There isn't a single suggestion for how to address these issues, but an article such as the following could help.

Recent issues

The following issues are timely and related to recent updates of our SDK, browser engines or specific game engines. We've suggested temporary workarounds until the issues are resolved.

Phaser: "The operation is insecure"

We've received reports that you may get the following error when trying to load ImageAsset objects as a texture in Phaser.

❗️

Unhandled Promise Rejection: Security Error: The operation is insecure.

One workaround you can try is downloading the image and then creating a locally trusted object to load into Phaser.

image.src =  await window.fetch(await asset.getImageUrl()).then(r => r.blob()).then(blob => URL.createObjectURL(blob));

Another potential fix is setting the crossOrigin of the texture image to anonymous.

this.app.loader.getHandler("texture").crossOrigin = "anonymous"; // https://photonstorm.github.io/phaser-ce/Phaser.Loader.html#crossOrigin