Popping Sound

Application is using AVAudioSessionCategoryPlayAndRecord category and How are you doing this? The audio system should not be allowing PlayAndRecord to directly activate in a background app. But AVAudioSessionCategoryOptionAllowBluetoothHFP Option is not defined in AVAudioSessionCategoryOptions What do you mean? It's right here. Is there any option to use as alternative of AVAudioSessionCategoryOptionAllowBluetooth option? No, but that's because AVAudioSessionCategoryOptionAllowBluetooth and AVAudioSessionCategoryOptionAllowBluetoothHFP are exactly the same thing. From AVAudioSessionTypes.h, after you remove the availability markings: /// Deprecated - please see ``AVAudioSessionCategoryOptionAllowBluetoothHFP`` AVAudioSessionCategoryOptionAllowBluetooth = 0x4, ... /// - Other categories: /// AllowBluetoothHFP defaults to false and cannot be changed. Enabling Bluetooth for input in /// these categories is not allowed. AVAudioSessionCategoryOptionAllowBluetoothHFP = 0x4, In other words, AVAudioSessionCa

The way this is written makes it sound like there will be a call to... Yes, and I'm actually not sure where that documentation entry actually came from, as it doesn't actually make very much sense (r.165622059). The header doc is a bit more clear: Disable implicitly starting access of the ephemeral security-scoped resource during resolution. Instead, call -[NSURL startAccessingSecurityScopedResource] on the returned URL when ready to use the resource. Not applicable to security-scoped bookmarks. The key word there is ephemeral. On macOS, there is infrastructure in place such that if an app makes a normal bookmark and gives it to another app, that other app has access to the file it JUST received without any additional action. That mechanism is what ephemeral and implicit refer to. That system is better described in NSURLBookmarkCreationWithoutImplicitSecurityScope: Bookmarks that you create without security scope automatically carry implicit ephemeral security scope. This security scope is valid unti

You can interleave encrypted and unencrypted segments without DISCONTINUITY tags (assuming there is continuity otherwise) by using EXT-X-KEY to specify the encryption (or not) of the init / media segments. A brief audio dropout across the transition is a known issue. Please file an enhancement request if that creates a problem for your application.

The general rule for networking in the background on iOS is that everything works as long as your process is running. Once your process gets suspended, you start running into edge cases. TN2277 Networking and Multitasking talks about this idea, although it’s somewhat out of date. Specifically, I now talk about connections being defuncted rather than using the older socket resource reclaim terminology, because Network framework supports a user-space networking stack that doesn’t involve sockets. However, it sounds like you’re using BSD Sockets directly, in which case TN2277 is still as relevant as it ever was. Specifically: [quote='808351021, RiteshV, /thread/808351, /profile/RiteshV'] we attempt to establish a DTLS handshake over our existing socket [/quote] It’s likely that this socket was defuncted when your app was suspended in the background, and thus the issue isn’t with DTLS per se, but rather with networking proper. If you open a network connection in this situation, does that work? Share and

Did a bit more browsing and found the answer as of June '25: No, process attribution is not supported yet. I will pop up a enhancement request. For posterity: The reason why process attribution is a good feature is to help support workflows for isolated filesystems like the spk/spfs project: https://github.com/spkenv/spk The Software Platform FileSystem (SPFS) is a tool for isolating, capturing and distributing software runtime environments. In many ways, what it provides is like a lightweight container combined with the functionality of git. SPFS delivers some of the benefits of a container runtime without creating too much isolation from the host environment.

My issues might even be better solved with FSActivateOptionSyntax, but I don't know where to find the docs for it. Or how to propably use it. Yeah, that's probably meant to be used for your situation. I think you're supposed to be able to provide a path then you can get a security-scoped URL that you can use to access that specific path while sandboxed. I briefly looked at that a while ago but I don't think most of the Info.plist keys are documented right now. Most of the documentation right now is just scouring the forums or Apple's open-source FSKit extensions for examples (or, if you're lucky, replies to your feedbacks), which isn't too great. My (untested, could be wrong) assumption was that if you were to set something like shortOptions abc:d: Then on the command line you'd be able to pass options like -a or -b, while -c=arg and -d=arg both take additional arguments. I never needed it for my own extension though so I didn't look too hard, but the forums post you listed suggests that the ability to get a

ps: in the right-click menu of mac - Share - Airdrop pop-up

I'm seeing the same problems in a project. Managed to characterize the issue narrowly enough to report it via Feedback Assistant, since I'm not sure it's been reported yet (FB21197208). Seems to be two main issues to me: Physics simulation stops moving objects during collisions when their velocity is still high enough that it looks quite unnatural (relative velocity around 2.0 or less). Even with everything set such that the collision should produce 100% elasticity, it doesn't. Effect is worse with a box-shaped collider, but still happens with sphere-shaped colliders. Combination of the two means repeated collisions will eventually lead to objects stopping, regardless of the 100% elasticity. Note: I haven't tried the scaling workaround yet, but it sounds like that might just be putting off the issue (more collisions needed to lose enough energy to stop), and I'm starting to think implementing my own movement system would be better (I don't actually need mass/inertia and other true-to-physics behavior