Issues with Cesium in UE5.4 on iOS

I’m having issues with Cesium on iOS across multiple version of UE and the CesiumForUnreal plugin.

This seems to be related to:
https://community.cesium.com/t/solved-ios-apps-distributed-to-the-app-store-crash/29401

There appears to be a few different issues, but they all seem to be related and are hard for me to separate and test properly.

UE5.2 w/ fix - CesiumPlugin 2.10 = works fine as long has I have the fix from the above.
UE5.2 w/o fix - CesiumPlugin 2.10 = builds and runs on device on iOS 17.
UE5.2 w/ fix - CesiumPlugin 2.11 = Unreal Editor (on my Mac) won’t launch and throws a msg that the CesiumRuntime module was built for a different engine version (i downloaded this from the Epic Launcher)

UE5.3 w/ fix - CesiumPlugin any = fails to build app because of a UE issue with the “fix” (more on that below)
UE5.3 w/o fix - CesiumPlugin 2.10 = app builds and will run until I attempt to load a level that has a Cesium actor, and then it crashes. (same as UE5.2 w/o fix)
UE5.3 w/o fix - CesiumPlugin 2.11 = app builds but crashes as soon as I launch even though the initial level has no Cesium actors in it.

UE5.4 w/ fix - CesiumPlugin all = fails to build app because of a UE issue with the “fix” (more on that below)
UE5.4 w/o fix - CesiumPlugin 2.10 = app builds and will run until I attempt to load a level that has a Cesium actor, and then it crashes
UE5.4 w/o fix - CesiumPlugin 2.11 = app builds but crashes as soon as I launch even though the initial level has no Cesium actors in it.

I am doing this testing in the 3rd Person template project.
All Unreal Editor versions are from the Launcher (no custom builds) running on Mac M1

Mac OS 13.7 - M1 MacBookPro
Xcode 15.2.0
iOS: 17.5.1 - iPad Pro 11-inch 4th gen (M2)
UE 5.2.1
UE 5.3.2
UE 5.4.4
Cesium for Unreal 2.11 & 2.10. (i have not tested all versions prior to 2.10 but in some that i have tested i see consistent results with 2.10)

I have not tested UE 5.5.1 or CesiumForUnreal 2.12

As i mentioned above the “fix” listed in the referenced post seems to have broken in UE5.3 & 5.4. I found a UDN post about this here:
https://udn.unrealengine.com/s/question/0D5QP00000OGa550AD/forceansiallocator-causes-issues-with-the-eigen-library
Looks like it was fixed in UE5.5. But that doesn’t really help me unless i want to do a custom engine build, which i’d prefer to not do.

At this point i’ve tried quite a few different things.
At the end of the day i’m trying to upgrade my UE5.2 project to UE5.4 and i can’t seem to do that without dropping the Cesium featrure.

Does anyone have Cesium working in iOS using 5.4?

thx-e

Hi @Eric_Carney,

Sorry that there have been problems with building to iOS :frowning: When the app fails to build, are any errors that are printed in the log? If there’s anything more you can say about those “few different issues,” that would help too. Thank you!

Thanks for taking a look at this.

A few notes since my initial post.
UE 5.4.4
Cesium 2.12
Mac OS 13.7
Xcode 15.2
iOS 17.5.1
I am testing in the FirstPerson C++ template.
I have the Cesium plugin loaded but i do not have any Cesium actors in my level.

I’ve discovered that if you use the QuickLaunch in UE to launch the app directly to your attatched iOS device then the app launches and runs just fine.

If i Archive and Distribute from Xcode then the app crashes on launch. This is the process for creating apps for the Apple App Store.

—Steps—
Launch UE5.4.4 from the Epic Launcher
At the Open Project screen select Games > FirstPerson > C++ / mobile
Once the project is open
In Project Settings > iOS fill in a Bundle Name
In Project Settings > Xcode Project fill in your Apple Developer Account ID & Bundle ID
From the Tools menu selct Build Xcode Project or Refresh Xcode Project
From the Platforms menu select iOS > Package Project
Once that is done then launch the Xcode (iOS) project that should be in your UE project dir.
In Xcode make sure the FirstPerson game is selected and from the Product menu select Archive. This will run for a bit and should be successful.
When done it should open the Organizer window. Select Archives and you should see archive you just created.
Select he archive you just created and click Distribute App, then select Debugging. This will allow you to write out an iOS IPA file to you Mac.
Then Drag-n-Drop that IPA onto your iOS device via the Finder.
The app should install on your IOS device.
Tap the app icon on your iOS device to launch
You should see the UE launch screen for a split second and then the app will crash.

Link to console output when running the test app on my device:
https://www.dropbox.com/scl/fi/q4heqnvl7x1d5637bigki/cesium-UE5.4-crashlog.txt?rlkey=mp1i9xmqyz7eoaxar1ouce0wa&st=1jikp1dd&dl=0

It’s still on my To Do list to dig into iOS problems, which I’ll do as soon as I can. But I looked at your log, and saw this:

default 09:08:48.831662+0000 ReportCrash ASI found [libsystem_malloc.dylib] (sensitive) 'firstPerson5p4-IOS-Shipping(3332,0x2068efec0) malloc: *** error for object 0x302630060: pointer being freed was not allocated

That’s not a lot to go on, because there’s no call stack. Do you know if it’s possible to run a debug build / get a more complete crash call stack from the iOS device? That might enable us to zero in on the problem pretty quickly.

Ok, I was able to do some more testing on this and have some new info.

As i mentioned before, if you use Quick Launch from Unreal to your device then it does not crash on launch. I also tried launching to my device directly from Xcode. This did not crash on launch.

But, as mentioned, if I do a proper deployment build and use Archive in Xcode and deploy to my device then it crashes on launch.

Also, as I posted originally, the Cesium 2.10 plugin works, but the Cesium 2.11 and 2.12 do not.

As the issue doesn’t happen in test builds I’m finding it diffecult to get a proper crash call stack. I was able to get these:

https://www.dropbox.com/scl/fi/9f08c4faymb45qa3u4s1b/CesiumCrash.txt?rlkey=3iu2iik44n8dyalyz4keyip0y&st=4hr0m47a&dl=0

https://www.dropbox.com/scl/fi/uk2ycp077e5ixa8yq9685/firstPerson5p4-IOS-Shipping-2025-01-28-143413.ips?rlkey=pn6epdp1bw2dhqmsz1ib2fl5c&st=vwpdfum1&dl=0

thx-e

Thanks for the update, Eric. The call stack you shared is interesting, because it appears that a simple malloc is failing, without anything Unreal or Cesium related nearby. It’s safe to say either we or Epic (it’s probably us) are doing “something” wrong, but it’s hard to say what it might be.

I still plan to dig into this deeper, but am so far sadly waiting on some prerequisites in order to actually be able to do this (don’t get me started ranting about how the Apple Developer Program is required even to deploy to your own device).

Ok, I think I’ve made some progress! First, I can reproduce the problem you’re seeing. I can run the Cesium for Unreal Samples project just fine on an iPhone if I launch it with Product → Run in Xcode. But if I create an archive, copy it to the device, and run that, it crashes immediately after the splash screen.

It was shockingly difficult to get a decent call stack for the crash, but I finally did. I had to create a DebugGame build and make sure it was set up to produce a dSYM file, of course. And then get the IPS file of the crash from the device logs.

I could load the IPS file in Xcode, but it gave me worthless call stacks for reasons I can’t understand. Instead, I had to run it through this random convertFromJSON.swift tool that I found (see last link below). And then run the .crash file it produces through the symbolicatecrash script that comes with xcode (/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/). Can you tell I’m not really an Apple developer and found this whole process infuriating? :slight_smile: Some of the pages I found useful:

In theory you can attach the debugger to an app running on the phone, and that would save a lot of trouble, but that requires the app to stay running for more than a few milliseconds. If there’s a way to attach the debugger to an app at startup, I don’t know what it is. In retrospect, making the app sleep for 30 seconds at startup to give me time to attach might have been a worthwhile approach.

But anyway, here is the call stack:

Thread 9 Crashed:
0    libsystem_kernel.dylib                  0x1e45911d4 __pthread_kill + 8
1    libsystem_pthread.dylib                 0x21c6faef8 pthread_kill + 267
2    libsystem_c.dylib                       0x19bf83ad8 abort + 127
3    libsystem_malloc.dylib                  0x1a4424aa0 malloc_vreport + 895
4    libsystem_malloc.dylib                  0x1a4424710 malloc_report + 63
5    libsystem_malloc.dylib                  0x1a4423ce8 find_zone_and_free + 527
6    libc++.1.dylib                          0x1a478f1b8 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::~basic_string() + 35
7    dev-IOS-DebugGame                       0x10b179324 getCacheDatabase() + 115430180 (CesiumRuntime.cpp:108)
8    dev-IOS-DebugGame                       0x10b1788f4 getAssetAccessor() + 115427572 (CesiumRuntime.cpp:124)
9    dev-IOS-DebugGame                       0x10b0174b0 ACesium3DTileset::LoadTileset() + 113980592 (Cesium3DTileset.cpp:893)
10   dev-IOS-DebugGame                       0x10b020d04 ACesium3DTileset::BeginPlay() + 114019588 (Cesium3DTileset.cpp:736)
11   dev-IOS-DebugGame                       0x10974c850 AActor::DispatchBeginPlay+ 87984208 (bool) + 240
12   dev-IOS-DebugGame                       0x10abd6258 AWorldSettings::NotifyBeginPlay+ 109519448 () + 256
13   dev-IOS-DebugGame                       0x109e582a8 AGameStateBase::HandleBeginPlay+ 95371944 () + 40
14   dev-IOS-DebugGame                       0x10ab13aa0 UWorld::BeginPlay+ 108722848 () + 252
15   dev-IOS-DebugGame                       0x10a9eb414 UEngine::LoadMap+ 107508756 (FWorldContext&, FURL, UPendingNetGame*, FString&) + 6000
16   dev-IOS-DebugGame                       0x10a9e8850 UEngine::Browse+ 107497552 (FWorldContext&, FURL, FString&) + 3688
17   dev-IOS-DebugGame                       0x109e231b8 UGameInstance::StartGameInstance+ 95154616 () + 704
18   dev-IOS-DebugGame                       0x109dfdaac UGameEngine::Start+ 95001260 () + 144
19   dev-IOS-DebugGame                       0x10af678ec FEngineLoop::Init+ 113260780 () + 2648
20   dev-IOS-DebugGame                       0x10af66afc FAppEntry::Init+ 113257212 () + 388
21   dev-IOS-DebugGame                       0x10583cf88 -[IOSAppDelegate MainAppThread:] + 300
22   Foundation                              0x192e7d6c8 __NSThread__start__ + 723
23   libsystem_pthread.dylib                 0x21c6f937c _pthread_start + 135
24   libsystem_pthread.dylib                 0x21c6f4494 thread_start + 7

So the problem is in creating the request cache database. I don’t know exactly why this is going wrong yet, but I hope it’ll be reasonably easy to figure out from here. Probably a bad or unwritable path. I’ll let you know when I have a fix.

I’ve updated this post with a new workaround for this problem:

Please let me know if it works for you!