I have updated to the latest official release: Xcode 26.5 with iOS 26 Simulator runtime, unfortunately the exact same problem still 100% reproduces only on the iOS Simulator. Important background: The production app uploaded to App Store runs perfectly on all physical iOS devices and Mac Catalyst, no logic error at all. The defect is isolated exclusively to simulator Debug environment. Two concrete problematic code snippets: Case 1: BOOL property overflow from system API @property (nonatomic, assign) BOOL isRunningOnMacOSX; // Assign value from NSProcessInfo self.isRunningOnMacOSX = [NSProcessInfo processInfo].isMacCatalystApp; On simulator, BOOL is signed char, the return value is truncated to a negative number. Since any non-zero value evaluates to true in C if() check, the branch is always incorrectly triggered. Case 2: __block BOOL returns garbage value after dispatch_sync GCD call (BOOL)isConnected { __block BOOL result = NO; dispatch_block_t block = ^{ result = (self->flags & kConnected) ? YES : NO; }; if (dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey)) { block(); } else { dispatch_sync(socketQueue, block); } NSLog(@"Logged result = %d", result); // Prints clean 0 in log return result; // Returns huge negative garbage integer only on simulator } When calling if ([aSocket isConnected]), it incorrectly enters the true branch. My analysis: This stems from inconsistent ABI handling of signed char return value zero-extension between simulator runtime, real ARM device and Mac Catalyst. Even in Xcode 26.5 stable release, the simulator still does not zero out high bits when extending 1-byte signed char to full register in Debug -O0 mode, leading to heap garbage value after cross-thread dispatch_sync. Current temporary workaround: Replace BOOL type with int internally and strictly store only 0 or 1 to bypass all signed char overflow and register extension issues. Could you help confirm whether this simulator ABI discrepancy is a known runtime limitation, or if there is any compiler/build setting to unify the BOOL behavior across simulator and physical devices? Thanks a lot.

Environment: Xcode 16, iOS 18 Simulator, Objective-C, Debug build. Problem: After upgrading to iOS 18 SDK, BOOL values behave abnormally exclusively on the iOS 18 simulator: BOOL properties assigned with system API return values are truncated to negative numbers; __block BOOL variable logged as 0, but the function returns a huge negative integer after dispatch_sync, leading to wrong if condition judgment. All code runs correctly on physical iOS devices and Mac Catalyst. I temporarily fixed it by replacing BOOL type with int to store only 0 and 1. I just want to confirm: what changes in iOS 18 Simulator runtime or Xcode 16 compiler lead to this signed char BOOL overflow/extension issue?

After upgrading to Xcode 16 and iOS 18 SDK, my Objective-C project has serious BOOL value errors only on iOS 18 Simulator. The same code works perfectly on real iPhone devices and Mac Catalyst. When getting BOOL return values from methods or assigning system API results to BOOL properties, it generates unexpected negative large numbers. Since C language treats all non-zero values as true in if() judgment, our business logic is completely broken. Could you please explain what underlying changes in iOS 18 Simulator or Xcode 16 compiler caused this BOOL parsing problem? Thank you.