[Solved] iOS apps distributed to the App store crash

ARAkasaka · January 18, 2024, 12:49pm

Problem

After distributing a UE5 iOS app using Photorealistic 3D Tiles to the App Store or TestFlight, the app crashes immediately after launching.
It works fine with local builds (same build configuration as when distributed).
It also works fine in a project that excludes Photorealistic 3D Tiles and only has Cesium SunSky.
Could you give me some advice?

Crash logs

App crashes on CesiumAsync::CachingAssetAccessor::get

Project details

Sample project with only Photorealistic 3D tiles placed in the Blank template project.
I referred to this tutorial.
https://cesium.com/learn/unreal/unreal-photorealistic-3d-tiles/

Hardware & Software details

macOS Sonoma 14.2.1
iPhone 14 iOS 17.2.1
Xcode 15.2
UE 5.3.2
Cesium for unreal 2.2.0

janine · January 19, 2024, 3:33pm

Hi @ARAkasaka,

Sorry that your app is having trouble. I’m not sure why Google Photorealistic 3D Tiles would work in a local build but not from the app store. This behavior is happening on the exact same device, correct?

To help us troubleshoot, can you test how your app functions with Cesium World Terrain (instead of Google’s data)? That may help us infer what’s happening here.

ARAkasaka · January 20, 2024, 1:40am

Hi @janine thanks for your response.

This behavior is happening on the exact same device, correct?

Yes, same device (iPhone14, iOS17).

To help us troubleshoot, can you test how your app functions with Cesium World Terrain (instead of Google’s data)?

Even in the case of the app that includes only Cesium World Terrain, similarly, only the distributed app crashed after launching.

ARAkasaka · January 23, 2024, 1:52pm

I resolved this issue by forcing FMallocAnsi usage on iOS platform.

if (Target.Platform == UnrealTargetPlatform.IOS)
{
    GlobalDefinitions.Add("FORCE_ANSI_ALLOCATOR=1");
}

https://alyamkin.artstation.com/blog/9VEQ/ue4-ios-and-pointer-being-freed-was-not-allocated

janine · January 23, 2024, 3:33pm

Glad you were able to figure it out @ARAkasaka! Unfortunately, our team isn’t familiar with deploying to the app store, so the fix wasn’t immediately apparent. Thank you for letting us know about the solution!

Kevin_Ring · February 10, 2025, 8:17am

Just an update on the best workaround here… FORCE_ANSI_ALLOCATOR may not work well in the latest UE versions, and even if it does it may have unintended consequences (such as a reduction in performance).

Instead, I now recommend that you make a change to a script in the Xcode project. If you open Intermediate/ProjectFiles/[project name] (IOS).xcodeproj/project.pbxproj, you’ll see a section like this:

		ED01E0DF7686EEC1CE350CF9 /* Generate dsym for archive, and strip */ = {
			isa = PBXShellScriptBuildPhase;
			buildActionMask = 2147483647;
			files = (
			);
			inputPaths = (
				"\"$(CONFIGURATION_BUILD_DIR)/$(EXECUTABLE_PATH)\"",
			);
			name = "Generate dsym for archive, and strip";
			outputPaths = (
				"\"$(DWARF_DSYM_FOLDER_PATH)/$(DWARF_DSYM_FILE_NAME)\"",
			);
			runOnlyForDeploymentPostprocessing = 1;
			shellPath = /bin/sh;
			shellScript = "set -e\n\n# Run the wrapper dsym generator\n\"${UE_ENGINE_DIR}/Build/BatchFiles/Mac/GenerateUniversalDSYM.sh\" \"${CONFIGURATION_BUILD_DIR}/${EXECUTABLE_PATH}\" \"${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}\"\nstrip -no_code_signature_warning -x -S -D \"${CONFIGURATION_BUILD_DIR}/${EXECUTABLE_PATH}\"\n\n# Remove any unused architectures from dylibs in the .app (param1) that don't match the executable (param2). Also error if a dylib is missing arches\n\"${UE_ENGINE_DIR}/Build/BatchFiles/Mac/ThinApp.sh\" \"${CONFIGURATION_BUILD_DIR}/${CONTENTS_FOLDER_PATH}\" \"${CONFIGURATION_BUILD_DIR}/${EXECUTABLE_PATH}\"";
		};

The important part is buried on the shellScript line and looks like this:

strip -no_code_signature_warning -D \"${CONFIGURATION_BUILD_DIR}/${EXECUTABLE_PATH}\"

Change it to this:

strip -no_code_signature_warning -x -S -D \"${CONFIGURATION_BUILD_DIR}/${EXECUTABLE_PATH}\"

In other words, add the -x -S options to the strip command.

Now, if you archive / deploy your game again, you should no longer see the crash. You might need to edit a source file to force it to produce a new binary and re-run this script.

The reason for the crash is that UnrealBuildTool is (incorrectly, in my opinion) stripping operator new and operator delete symbols from the packaged binary. This means that code inside your game executable will use Unreal’s custom memory allocator, but code outside your game executable will use the default allocator. Specifically, any allocations in the C++ standard library that do not get inlined will use the default allocator. The crash is caused by allocating memory with Unreal’s custom allocator and then freeing it with the default allocator. It’s easy to trigger this by constructing something as simple as a std::string.

By adding these command-line arguments to strip, we tell it to only strip debug and local symbols. Global symbols like operator new / delete are left intact, ensuring that the std::string constructor and destructor, as well as all similar memory allocations, go through Unreal’s custom allocator.

More details of the problem here for anyone interested:

github.com/CesiumGS/cesium-unreal

Game packaged as an ipa crashes at startup on iOS

opened 08:32AM - 07 Feb 25 UTC

kring

bug

Mentioned on the community forum here: https://community.cesium.com/t/solved-ios…-apps-distributed-to-the-app-store-crash/29401 https://community.cesium.com/t/issues-with-cesium-in-ue5-4-on-ios/37756/3 Packaging a game and running it on an iPhone from Xcode works fine. But if we create an "archive" (ipa) and then run that on the device, it crashes very quickly after showing the splash screen. The immediate cause of the crash is that a std::string's destructor is called, and the memory it holds was not allocated by the standard `operator new`. That's because it was allocated from Cesium3DTileset.cpp, which, being compiled in the usual Unreal way, overrides `operator new` with its own custom allocator. The fundamental problem is that the `basic_string` constructor that gets called is found in our Unreal game, so it uses Unreal's custom allocator, while the `basic_string` destructor is found in `libc++.dylib`, so it uses the standard allocator. > Rant: this is why overriding operator new and delete is a terrible idea. Think you can get better performance with a custom allocator? Well, ok, I'm skeptical that that's true if it's a general purpose allocator, but go ahead if you want to try. But call your custom allocator explicitly from your code. Overriding the global new and delete makes it pretty much impossible for dynamically-allocated objects to cross .dll/.so/.dylib boundaries. Which maybe doesn't sound _too_ bad, until you consider that "objects" includes std::string, and ".dll/.so/.dylib" includes libc++.so/.dylib. It's pretty much just dumb luck that this works on other platforms where the C++ standard library is dynamically linked. I spent a lot of time trying to understand why the constructor/destructor end up coming from two different places. Based on stepping through the disassembly with the xcode debugger (with the app running on the iPhone), I can see: * Neither the constructor not the destructor are inlined. Both are actual function calls. * The constructor implementation is found in our app binary. * The destructor implementation is found in libc++.dylib. Why does this happen? Well, in Apple's libc++ (taken from iOS SDK v18.2), the relevant std::string constructor is declared/defined like this: ``` template <__enable_if_t<__is_allocator<_Allocator>::value, int> = 0> _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 basic_string(const _CharT* __s) { // ... } ``` The destructor looks like this: ``` inline _LIBCPP_CONSTEXPR_SINCE_CXX20 ~basic_string() { // ... } ``` So the constructor has `_LIBCPP_HIDE_FROM_ABI`. Among other things, that adds the `__exclude_from_explicit_instantiation__` attribute. Here's the clang docs on what that means: https://clang.llvm.org/docs/AttributeReference.html#exclude-from-explicit-instantiation Long story short, methods marked with this attribute will be implicitly instantiated in every translation unit (cpp file) where they're used. Never will an implementation from libc++.dylib be used. That's consistent with what I'm seeing. Why? I have no idea! Meanwhile, the destructor is declared `inline`. Well, it's not getting inlined. If it were, there wouldn't be a problem, because both the constructor and destructor would then use Unreal's allocator. But no, it's not inlined, despite that fact that it's declared inline. That's a little odd, but not shocking. For one thing, I reckon that `inline` here doesn't actually do anything at all, because the method implementation is found inside the class definition in this case, which implies `inline`. And second, `inline` is doesn't actually mean inline, cause C++ is like that. See here: https://en.cppreference.com/w/cpp/language/inline > The original intent of the inline keyword was to serve as an indicator to the optimizer that [inline substitution of a function](https://en.wikipedia.org/wiki/inline_expansion) is preferred over function call, that is, instead of executing the function call CPU instruction to transfer control to the function body, a copy of the function body is executed without generating the call. This avoids overhead created by the function call (passing the arguments and retrieving the result) but it may result in a larger executable as the code for the function has to be repeated multiple times. > > Since inline substitution is unobservable in the standard semantics, compilers are free to use inline substitution for any function that's not marked inline, and are free to generate function calls to any function marked inline. Those optimization choices do not change the rules regarding multiple definitions and shared statics listed above. So clang isn't necessarily doing anything wrong by not inlining the destructor. 🤷 Alright, so the compiler is doing what it should, and it's easy to see why that causes a crash. The problem is either in Unreal Engine or in libc++, or in any case the interaction between the two of them. What can we do about it? Well, one solution is to tell Unreal not to use a custom allocator. This is done by defining `FORCE_ANSI_ALLOCATOR=1`. That reportedly worked in older versions of Unreal Engine, but not in newer ones (I haven't tried myself). It's not surprising that there would be problems when compiling the plugin and app with the ANSI allocator and the rest of Unreal Engine with its own allocator. Perhaps compiling all of Unreal Engine with ANSI would work, but that's a drastic step for people that just want to package their game for iOS. I'm low on other ideas. Perhaps there are some compiler flag tweaks that would cause that destructor to get inlined. But even if we found such a solution, it feels precarious. Or go the other way, and construct all of our strings with a custom STL allocator that is guaranteed not to use Unreal's custom new/delete functions. But the allocator is part of std::string's type, so we'd basically have to specify it everywhere in cesium-native's public API. Can we statically-link the C++ runtime library on iOS? What other possibilities am I missing?

I’m going to report this to Epic as a bug, but this workaround should work well in the meantime.

Eric_Carney · February 19, 2025, 6:10pm

Thanks so much for this.

I have tested this in UE5.4 with Cesium for Unreal 2.10 & 2.13 and in both cases, this fix worked for me.
I have removed the “FORCE_ANSI_ALLOCATOR” fix as it does not seem to work in 5.4

thanks
eric

Topic		Replies	Views
App crashes with Google Map Tiles on iOS16 Cesium for Unreal	10	294	December 23, 2024
Cesium for Unreal seems crash on iOS Cesium for Unreal	6	109	June 12, 2024
Crash with Google Photorealistic 3D Tiles - fix now available for UE 5.1 - 5.5 Cesium for Unreal	9	183	February 24, 2025
Packaged Application Crashing Cesium for Unreal	5	212	January 4, 2024
Issues with Cesium in UE5.4 on iOS Cesium for Unreal	9	105	February 19, 2025

[Solved] iOS apps distributed to the App store crash

Problem

Crash logs

Project details

Hardware & Software details

Related topics