Hi everyone, I'm trying to understand something for analytics purpose. We see a large number of transactions coming in Transaction.update that don't initiate from our app's paywalls. When using AppStore.sync, does this send any restored transactions in Transaction.update? Or does it simply update what currentEntitlements will return. In other words, when I validate a transaction coming from Transaction.update, and the reason is .purchase, is it always a new purchase, or can it be an old purchase which is replayed? If the answer to the above question is yes, how can we distinguish actual purchases from restored transactions when verifying a transaction? Thanks! Bruno

Hello, I'm trying to address the following crash from an old Objective-C code. Crashed: com.apple.main-thread 0 libobjc.A.dylib 0x88e8 object_isClass + 16 1 Foundation 0x1d748 KVO_IS_RETAINING_ALL_OBSERVERS_OF_THIS_OBJECT_IF_IT_CRASHES_AN_OBSERVER_WAS_OVERRELEASED_OR_SMASHED + 48 2 Foundation 0x2be10 -[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:maybeNewValuesDict:usingBlock:] + 284 3 Foundation 0x21c5c -[NSObject(NSKeyValueObservingPrivate) _changeValueForKey:key:key:usingBlock:] + 72 4 Foundation 0x2daf8 _NSSetBoolValueAndNotify + 316 5 SDKCore 0x47854 __45-[CameraSession processPhoto:orientation:]_block_invoke_3 + 239 (CameraSession.m:239) 6 libdispatch.dylib 0x2914 _dispatch_call_block_and_release + 32 7 libdispatch.dylib 0x4660 _dispatch_client_callout + 20 8 libdispatch.dylib 0x12b60 _dispatch_main_queue_callback_4CF + 944 9 CoreFoundation 0x51cd4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 10 CoreFoundation 0xbeac __CFRunLoopRun + 2540 11 CoreFoundation 0x1f3b8 CFRunLoopRunSpecific + 600 12 GraphicsServices 0x138c GSEventRunModal + 164 13 UIKitCore 0x5196a8 -[UIApplication _run] + 1100 14 UIKitCore 0x2987f4 UIApplicationMain + 2092 15 MyApp 0x79bc main + 11 (main.swift:11) 16 ??? 0x102161a24 (Missing) The crash is due to setting takingPhoto to NO in - (void)processPhoto:(AVCapturePhoto *)photo orientation:(UIDeviceOrientation)orientation. From what I understand, the crash would be caused by a released observer receiving the notification, but I don't see how it's possible given the following code (this is an excerpt with relevant parts). @implementation CameraSession @synthesize takingPhoto = _takingPhoto; - (void)dealloc { [self _cleanupObservers]; } - (instancetype)init { self = [super init]; if (self) { [self _setupObservers]; } return self; } - (void)setTakingPhoto:(BOOL)takingPhoto { if (!takingPhoto) { [self.triggerDecider reset]; } _takingPhoto = takingPhoto; } - (BOOL)isTakingPhoto { return _takingPhoto; } - (void)takePhoto { if (self.isTakingPhoto) { return; } self.takingPhoto = YES; // … [self.capturePhotoOutput capturePhotoWithSettings:[self buildCapturePhotoSettings] delegate:self]; } - (void)processPhoto:(AVCapturePhoto *)photo orientation:(UIDeviceOrientation)orientation { dispatch_async(self.captureSessionQueue, ^{ [self.delegate cameraSessionDidSnapPhoto:self]; [self.cameraCaptureHandler processPhoto:photo orientation:orientation onSuccess:^(Scan *scan) { dispatch_async(dispatch_get_main_queue(), ^{ self.takingPhoto = NO; [self.delegate cameraSession:self didGenerateScan:scan]; }); } failure:^(NSError *error) { self.takingPhoto = NO; [self.delegate cameraSession:self didFailToSnapPhotoWithError:error]; }]; }); } #pragma mark - KVO - (void)_setupObservers { [self addObserver:self forKeyPath:@"takingPhoto" options:NSKeyValueObservingOptionInitial|NSKeyValueObservingOptionNew context:CameraSessionKVOContext]; [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(captureSessionRuntimeError:) name:AVCaptureSessionRuntimeErrorNotification object:self.captureSession]; [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(captureSessionDidStartRunning:) name:AVCaptureSessionDidStartRunningNotification object:self.captureSession]; [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(captureSessionDidStopRunning:) name:AVCaptureSessionDidStopRunningNotification object:self.captureSession]; [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(captureSessionWasInterrupted:) name:AVCaptureSessionWasInterruptedNotification object:self.captureSession]; [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(captureSessionInterruptionEnded:) name:AVCaptureSessionInterruptionEndedNotification object:self.captureSession]; [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(applicationDidEnterBackground) name:UIApplicationDidEnterBackgroundNotification object:nil]; [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(applicationWillEnterForeground) name:UIApplicationWillEnterForegroundNotification object:nil]; } - (void)_cleanupObservers { [self removeObserver:self forKeyPath:@"takingPhoto" context:CameraSessionKVOContext]; [[NSNotificationCenter defaultCenter] removeObserver:self]; } - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSString *,id> *)change context:(void *)context { if (context == CameraSessionKVOContext) { if (object == self && [keyPath isEqualToString:@"takingPhoto"]) { // While taking the photo, stop processing video frames // ... } } else { [super observeValueForKeyPath:keyPath ofObject:object change:change context:context]; } } @end Am I missing something here? Thanks! Bruno

Hello, I'm investigating a crash where keyWindow is nil when I don't expect it to be nil. I would like to understand when this can happen. Indeed,I could make a fix by guarding for nil values, but this would lead to an invalid state. Context We want to return quickly from application(didFinishLaunchingWithOptions:), so: We set a view controller as a splash screen rootViewController => we mark the window with makeKeyAndVisible(). We queue initializations asynchronously on the main queue. => Basically, while the app is initializing starting, we're displaying a splash screen view controller. When the app is done initializing, it needs to present the actual UI. A last asynchronous task on the main queue does this. We get keyWindow from UIApplication to set the new view controller with the actual UI. That's where we assume that it shouldn't be nil and force-unwrap it, but alas, in some instances it's nil. Misc This crash only happens when app built with Xcode 13.x, running on iOS 15. I cannot reproduce this bug, and it has fairly little occurrence. (100s over 100000 of sessions) I also attached a sample crash Questions Given that I made the window "key and visible" in step 1, what could cause the window to stop becoming "key". What would be the correct way to get the window to set the new root view controller ? I don't really want to guard against a nil value because then it means that I wouldn't be able to set my new rootViewController and the app would be stuck on the launch screen. 2021-12-01_18-16-29.7629_-0700-9b5855582b13262f154acae64dd3140ad49c84f3.crash Thanks a lot! Bruno

Hello,We are having a systematic crash of the lldb-rpc-server when debugging our project, so we are unable to use the debugger. The crash is as follow:https://gist.github.com/bvirlet/89ecb0388c659932f5b572fa0d79e4f5I have submitted a crash report to Apple (FB7671116) but in the meantime I would be interested in a possible workaround.The problem is present for several developers, on different machines.Thanks!Bruno

I'm fighting with the following error NSCocoaErrorDomain 513 reported by a very small number of users (~ 0.01%):Unable to create directory at path /var/mobile/Containers/Data/Application/EBE2C5D8-5AEC-4D62-9393-B19CAD598FE5/Documents/documents/FF2F88FB-2C07-4FA3-988E-58AD5C21F659/9A02F8A0-74EB-4ED6-81B6-4F40653856D3. Error: Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “9A02F8A0-74EB-4ED6-81B6-4F40653856D3” in the folder “FF2F88FB-2C07-4FA3-988E-58AD5C21F659”." UserInfo={ NSFilePath=/var/mobile/Containers/Data/Application/EBE2C5D8-5AEC-4D62-9393-B19CAD598FE5/Documents/documents/FF2F88FB-2C07-4FA3-988E-58AD5C21F659/9A02F8A0-74EB-4ED6-81B6-4F40653856D3, NSUnderlyingError=0x15e09de00 { Error Domain=NSPOSIXErrorDomain Code=13 "Permission denied" } }This error means that the directory cannot be created because of a permission error. That's where I'm lost as the only reason I can see would be if I'm creating a file outside of my app's sandbox.The code generating this error:NSArray* paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES); NSString* documentsDirectory = [paths objectAtIndex:0]; NSString *directory = [documentsDirectory stringByAppendingPathComponent:documentsPathAndUUIDs]; NSError *error = nil; if (![[NSFileManager defaultManager] createDirectoryAtPath:directory withIntermediateDirectories:YES attributes:nil error:&error]) { NSError(@"Unable to create directory at path %@. Error: %@", directory, error); }A couple things worth noting:This path isn't saved, it's regenerated every time, so it's not as if the app container had changed between installs;The users seem to have available disk space;This affects at least iOS 9 (I don't have enough reports to know if it also affects iOS 10)Would anyone have a hint of why this could happen?