I’m having a frustrating problem with Apple devices. The crux of the problem started last week. I ran a test of a finished project on an iPad Air 3 running 13.1.2 using both Chrome and Safari - both worked beautifully.
I then upgraded to the latest 13.1.3 version and the project’s preloader was sluggish and appeared to keep stalling. Once the project was loaded it seemed slower and the sound was out of sync or overlapping.
It still worked perfectly on all desktop browser tests and on Android. I’ve tried running it from different servers, resetting & updating the router and resetting the iPad.
I’ve passed it to clients who are running the same OS and are hitting the same problem.
I ran some Google searches and was surprised to see many issues regarding iOS 13 but none of the suggestions helped.
I decided that as it was the preloader, I would run some test on the project as other simpler projects are still running.
I created a blank project and simply loaded all the old resources into the project and published. Same issue.
There are about 300 file at 30mb. So I decided to try the test again but with 300 new small audio files. It ran quicker because the size was only 5mb but it was still really slow compared to loading it on any other device.
I don’t know what Apple has done, but if Atomi has anything that might help, it would be really appreciated.
It’s loads on a wireless Android in under 10s. The iPad was still going after two minutes. I then checked YouTube and the video loads and plays quickly and Google’s speed test was reporting a 48Mb connection.
In our tests, it takes about 1.5 minutes to load your project on iPads with older iOS.
But after upgrading to iOS 13.1.3, it takes about 5-6 minutes, sometimes it hangs.
I thinks it’s related to inherent performance issues of browsers on iOS devices. Now they get worse with the latest iOS version.
You can try creating a custom preloader, handle its Start and Item Complete events as the follows to see if it helps:
function onLoadStarted(doc, e) {
// customize preloader 'load' method:
// wait a time before loading next items so that browser can do other stuffs
if (!this.orgLoadMethod) {
this.orgLoadMethod = this.load;
this.load = function(items) {
var loader = this;
setTimeout(function() {
loader.orgLoadMethod(items);
}, 10); // wait for 10ms, for example
};
}
}
function onLoadItemCompleted(doc, e) {
var loadedItem = e.iData;
// item is loaded, call cancel to free some memory, not sure if it affects caching
if (loadedItem && loadedItem.cancel)
loadedItem.cancel();
}
That makes a huge difference. The ipad version is now usable again.
It does appear to have had the knock on effect that when scenes are loaded with an image at the start of the timeline - there is a slight delay before it is viable whereas before the image was loaded with the scene.
I can resolve this by using a fade in for the images if necessary.
A couple of things I did notice when testing some more over the weekend:
It didn’t require that many sound files for the issue to become noticeable - at around 30 audio file - there was a delay starting to occur.
It seems to only be audio files? I tried with 300+ images and they loaded smoothly. If this is the case, I was wondering if it was possible to only use the delay above on the audio?
Creating a custom preloader causes a missing preloader.css file. I added one manually for now.
Again, thanks for the excellent support - a working iPad version is a must for these projects.
I don’t have this issue, but I think it’s not the knock-on effect of the customized loader. Maybe the browser limits the cache size so the image is not cached but fetched again from the server. Or there’s too many elements on the scene that make image rendering a bit slower. Using a fade in is a good workaround.
Unfortunately, it’s not possible to set the delay for audio only.
It just shows an error on the browser console but doesn’t affect the content. We’ll fix it in the next update.