[Solved] iOS apps distributed to the App store crash

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.

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

[Solved] iOS apps distributed to the App store crash

Related topics