Background: The app embeds an in-app game feature ("Game Hub" / Fallinmoji) that is written in Java against libGDX and cross-compiled to native code for iOS using RoboVM (via ./gradlew :ios:robovmInstall). The build produces BWIOSGdx.xcframework, which is linked and embedded into the main iOS target.
What we confirmed in the framework itself: The .xcframework does contain two genuinely separate Mach-O slices — one tagged LC_BUILD_VERSION platform=IOS (device) and one tagged platform=IOS SIMULATOR (arm64 simulator), so at the packaging level Xcode sees a proper simulator slice. Despite that, the framework does not run correctly under the Simulator, so our build script deliberately skips building/linking it entirely for iphonesimulator runs ("libGDX is device-only") and the feature is device-only in practice.
Root cause (working theory): RoboVM AOT-compiles JVM bytecode into native ARM64 machine code and relies on hand-written runtime scaffolding (trampolines, dynamic method dispatch, JIT-adjacent code generation) that predates Apple Silicon simulators. That scaffolding appears to assume the calling conventions/execution environment of a physical device and does not behave correctly when executed inside the Simulator's process (which runs under different memory-protection/JIT and code-signing rules than a device). The result is that even though a correctly-tagged simulator slice exists, code compiled by RoboVM's toolchain does not execute reliably there — RoboVM itself has been effectively unmaintained since ~2017 and was never updated for Apple's current arm64 Simulator runtime.
Impact: We cannot build/run/debug the Game Hub feature (and by extension, sometimes the whole app when this framework is force-included) in the Simulator, which blocks fast local iteration, CI-based UI testing, and any workflow that depends on Simulator rather than a provisioned physical device.
Ask for Apple: Is this a known/expected limitation of running JIT-adjacent or non-Apple-toolchain-compiled native code (e.g., from RoboVM or similar Java→native cross-compilers) inside the iOS Simulator on Apple Silicon, versus on a physical device? Is there a supported mechanism (entitlement, code-signing flag, JIT-related capability) that would let such a framework execute correctly under Simulator, or is Simulator execution of dynamically-generated/trampoline-based native code from third-party toolchains fundamentally unsupported?