Thank you very much for your reply.
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:
@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.
- (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.
