Basis Failed to Transcode on iOS 17

I have a site that has been live and running fine for the last 11 days:

Built, tested, and running perfectly on PC, Mac, iOS, Android.
I have an older iPhone 11 and today I upgraded to iOS 17. Now my site will not load on my phone and the errors are basis files failing to transcode (both chrome and safari)

Tried running out of the editor and I get the same issue.

Using engine ver 1.65.3

Is there a newer version I can be using? Please help as 90% of our traffic is mobile and more than half of that is iOS.

Screenshots attached.

Hi @derek9nine,

I don’t have an iPhone iOS 17 to check right now, but this is indeed quite important if Basis fails to load. Pinging the PlayCanvas team @will @mvaligursky @slimbuck

Thanks for the help @Leonidas

I just found this issue:

going to attempt the workaround suggested

After looking at the bug I realized they are working w/ the engine source, and we have been working out of the editor.
Need an editor based solution so I can deploy a fix.

1 Like

Just to make sure I’m not going crazy, the engine examples PlayCanvas Examples
as posted by @mvaligursky in the open issue fails to transcode on my phone.
Star-Lord, however, doesn’t throw any errors.

EDIT: Tried rolling back the engine version in the editor and still get transcode errors (both last patch and last minor) so it likely wasn’t something recently introduced.

Hi @derek9nine,

We believe this is a regression in iOS 17. I reported the bug a month ago, but there haven’t been any updates:



By the way, we’re investigating and looking for possible workarounds.
The issues can be reproduced both on iOS 17, but also on MacOS Safari 17.


Follow up. @mvaligursky @slimbuck

I grabbed the source from tag 1.65.3 and forced the basis handler to manually compile using the fallback script (line 58 of src/framework/handlers/basis.js). This solves the iOS 17 issue and everything seems to be good across all devices.

Is there going to be a performance hit by not using the wasm when transcoding the textures? That would be my biggest concern, but I do need to get a fix out the door ASAP

There’s likely going to be a perf hit, but how that will affect your project you might need to test - as that depends on compression type / texture sizes / counts. It might be ok as a workaround.

We have some existing workaround for safari 15.4 - perhaps you can temporarily apply your workaround for 17.0 only, so it will only affect small number of people.

1 Like

Real quick question on that check, is the ua variable a string so if I check if it includes “17.” and “17_” it should cover all versions for 17 for the time being yeah? Or do I need to test against specific versions of the OS?

yeah I’d go with “17.” and “17_”

1 Like

If anyone stumbles upon this pre-WebKit fix and needs a solution, here’s what I did:

  • Downloaded the source for the version of the engine we are using (1.65.3 for me)
  • Opened up src/framework/handlers/basis.js
  • Changed the code to not use the wasm on iOS 17
  • Rebuilt the engine
  • Replaced the min.js in my project
1 Like

I’ve submitted Handle ios 17 basis wasm regression by slimbuck · Pull Request #5657 · playcanvas/engine · GitHub which should deal with this issue.

@derek9nine if you have any time to test this fix on your assets I’d be very grateful.



@slimbuck Will be testing this morning.
Thanks again for the quick responses and help with a work around! Y’all rock

1 Like

@slimbuck Is this fix dependent upon any other engine changes? Because we’ve been using 1.65.3 I took your code change and applied it to my local basis-worker.js and rebuilt the engine after removing my iOS 17 check from the previous workaround

I am getting a different error now evaluating S[b-1].buffer

Hi @derek9nine, any chance you can send me the texture(s) causing the issue then I can investigate locally?

@slimbuck Trying to figure out the best way to accomplish that right now
We have 30+ textures using basis and the assets that throw errors never finish loading asset wise so my loading screens stay up the whole time

The errors now don’t log the failed asset because it is syntax as opposed to console.error. Will dig into it a bit more tomorrow and try to figure it out

Searching the engine source for S[b-1].buffer gets me nothing
Searching project code for the same gets me nothing. Wondering now if it is from a different wasm and the fix affected it. Not really sure how that would be possible if the same number of mips are being used

I think that S[b-1] is the code you took from the fix PR … just renamed by the bundler.

1 Like

Makes sense. Does the bundler also strip out console logging?

I don’t think so, console. code should stay.

1 Like

Just to let you know. We are getting this on iOS 17 too. Will this be fixed in the engine anytime soon? Thanks