Popping Sound

Is this expected behavior on iOS? Yes. And is there any way to make non-critical notifications play at the same maximum loudness as critical alerts? No. I describe what is happening below, but by design, the audio session configuration that's being used cannot be configured or activated by any application. As to why... However, I’ve noticed that non-critical notifications still play quieter than critical alerts under these conditions. Critical alerts with volume: 1.0 sound noticeably louder than standard notifications, even though the Ringtone and Alerts slider is already set to maximum. And I couldn't find any documentation for this behavior anywhere. I'm not sure we ever documented it formally, but the behavior here has actually been true forever“. It’s just easy to overlook unless you know what you're looking for. The key clue here is that if you compare the max volume of a standard PlayAndRecord audio session with the maximum volume of a CallKit call, you'll find exactly the sam

I tested this behavior in WhatsApp, and it seems to work correctly there. Does it work correctly in Speakerbox? Speakerbox is effectively our reference implementation for CallKit, so that's the first question I'll nearly always ask. Critically, if it DOESN'T have happen in Speakerbox, then the issue is being caused by something your app is doing. Continuing with the assumption that Speakerbox works correctly... I’m developing a VoIP app that uses Linphone and CallKit. Everything works as expected until the user enables the speaker on the native CallKit screen. After that, all subsequent calls start with the speaker already on. Even if I call AVAudioSession.sharedInstance().overrideOutputAudioPort(.none), I can't really tell you exactly what the problem might be, however, what generally causes these kind of audio issues are the complicated interactions between a number of different factors: The audio system has a rigid but poorly documented set of rules about exactly what changes you can make

Sounds good. Here is the crash report: com.myCompany.myDaemon-2025-09-15-081339.txt

What would we do without you Quinn! Thanks for the explanation, it sounds like the most plausible scenario. Filed FB20224875. Might have to change focus to a different project for now or get really crafty for a workaround...

Hello - There are no known conditions or scenarios where the server notification for the initial In-App Purchase of a new subscription (with notificationType=SUBSCRIBED and subtype=INITIAL_BUY) would not be sent. Since it sounds like you missed only one such notification (and presumably successfully received many other INITIAL_BUY notifications), ensure that your server is responding to the notifications as documented here: https://developer.apple.com/documentation/appstoreservernotifications/responding-to-app-store-server-notifications. Retry notifications are sent as documented on that page. Use the Get Notification History endpoint to verify that a specific server notification was sent for a given Transaction ID: https://developer.apple.com/documentation/appstoreserverapi/get-notification-history. If you cannot find an expected notification using the endpoint above, please reply back with more details - including the Transaction ID(s) and date(s) - and we will investigate further. Thank you.

Did you wait some time to make sure the error didn't pop up? It might take a minute or two. Try inserting a record then re-running and waiting a few minutes. Yeah, I've tried waiting until seeing the new record being synchronized across my devices, and haven't seen the issue. NSKeyedUnarchiveFromData is the default transformer and comes to play when you use a Core Data / SwiftData transformable attribute without explicitly specifying a transformer. Unless you are using a transformable attribute, it shouldn't be engaged. My best guess is that your CloudKit schema / data contains something that needs a transformer (due to your historical changes?), and that triggers the error when NSPersistentCloudKitContainer tries to synchronize the data from the server to your device. If that is the case, consider cleaning up the schema and data on the CloudKit server. Assuming you are on the CloudKit development environment, you can remove the existing schema and data by resetting the environment, and then re-creat

First off, here: Here's my current personality dictionary. With this dictionary, the driver crashes, presumably in its init. One thing I strongly recommend during early bring-up is that your driver should do as LITTLE as possible. Basically, you can log data... and nothing else. I might not even call super. The problem here is that until you've got a foundation that works in the most BASIC sense (doesn't crash), you'll end up wasting time looking at what you THINK is the problem without actually knowing what's wrong. In any case, this is wrong: IOClass IOSCSIPeripheralDeviceType00 And should be: IOClass IOUserSCSIPeripheralDeviceType00 IOSCSIPeripheralDeviceType00 is the base class driver for mass storage devices. What you want is IOUserSCSIPeripheralDeviceType00, which is the DEXT support driver for SCSIPeripheralDriverKit. In more concrete terms, in the kernel IOUserSCSIPeripheralDeviceType00 is a subclass of IOSCSIPeripheralDeviceType00 which includes a bunch of additional callout hooks which call out to y