@Media Engineer FB16464516 has been filed.

@Media Engineer Yes, rotationCoordinator is an instance variable in the class which is an actor. Therefore it will get deallocated off the main thread(on actor's serial queue). But it happens the same way in AVCam sample code (where AVCaptureVideoPreviewLayer is used). We don't see this issue in AVCam sample code even though rotationCoordinator gets deallocated on the actor's serial queue. I shall submit a bug soon.

Ok I was able to fix it by running the method on main thread, marking all these properties inside the actor with @MainActor, grabbed a copy of AVCaptureDevice and used it in the main thread. Not sure if it is 100% correct as AVCaptureDevice is not sendable.

Thanks for the answer, but to move these operations to main thread, I will need to move off AVCaptureDevice to main thread (out of the actor context). How do I solve it?

Hello @DTS Engineer Thanks for the answer. I have gone ahead and filed two enhancements suggestions.

Hello Argun, thanks for the response. Well the issue is its not documented anywhere that these statuses can not be checked on the main thread. I will try pushing them to background thread. But what about checking (AVAudioSession.sharedInstance().category == .playback) giving error Hangs - Interprocess communication on the main thread can cause non-deterministic delays. ?

Only solution is to undo all stitchable kernels and go back to extern "C" kernels. Irritating and involves too much work if you have hundreds of Kernels.

But I have gestures on separate views in this case, I don't know how to adapt this solution.

That requires modifying hundreds of CI kernel methods, not a good workaround.

VPP users ARE facing issues I can confirm.

I have recently migrated to freemium model and can confirm that I am only getting build version (not app version). So I have set the build version to a high number like 11 and it works. Original purchase date also seems to be working, though I am getting some 2013 users but my app has been around since 2012. My own device through which I bought the app reports 2018, which seems correct.

I think it is best to avoid using originalAppversion and instead use originalPurchaseDate.

Did you find an answer to this?

Hello @App Store Commerce Engineer Can you please confirm whether AppTransaction.originalAppVersion field will be present for users who purchased the app previously using VPP? Or is this field only present for normal purchases only?

I believe originalAppVersion should be present in the AppTransaction, no matter the type of purchase. Only Apple Engineers can verify this, but I can only know once I push my update in the coming few weeks.