Popping Sound

So, repeatedly calling SCScreenshotManager increments counter accessed your screen and system audio ?

It sounds like you’re looking for an API to configure Personal Hotspot programmatically. There is no such API. If you’re working with Wi-Fi accessories, I have lots of advice in Extra-ordinary Networking > Working with a Wi-Fi Accessory. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Things went long, so you get a Part 1... Is FileManager using cloning behind the scenes? Yes. More specifically, most of our copy APIs are actually built on top of copyfile, and copyfile is what actually handles file cloning. Or more exactly how guaranteed are we it will use it? It basically uses it everywhere it can. That includes both the obvious case of copying within a volume but also includes less obvious cases like copying a hierarchy that includes clone between two APFS volumes. Generally speaking, you should get the same results as what you'd get copying using the Finder*. *The one exception I can think of is copying files within an SMB server which will definitely be slower and which I believe will also bypass cloning. You can read more about that particular issue here. (I know it does, I tried manually cping the resources and it was thousands of times slower.) Just to clarify, I assume you meant manually copying the contents (using open/read/write), not using the cp command? cp also uses copyfile, s

@DTS Engineer , I don't assume that we have correctly identified the problem, But to us it seems like a failed negotiation for TCP SYN, i.e., Apple network framework not doing fallback to a basic TCP SYN. Then it was our idea/hope to get a domain expert from Apple to give their five cents on it. But it sounds like that is not possible before I try that disableECN and so I will try to look into that one day... 🥹 Cheers!

[quote='839507022, st-gab, /thread/783347?answerId=839507022#839507022, /profile/st-gab'] today I tried our automation for Notarization and it worked fine again in expected times [/quote] OK, so things are back to normal again? If so, that makes this sound more like the “in-depth analysis” case. Still, I’ll do some digging, just to confirm. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Sounds like you have tried everything I would try. Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports. Bug Reporting: How and Why? has tips on creating your bug report.

Based on your explanation it sounds like you are working with a project based on React Native technology. While folks here may have suggestions for you, you should consult the support resources offered by the creators of that technology.

Our app uses CallKit with WebRTC to establish VoIP connections. However, on iOS 18.4.1, CallKit no longer triggers: func provider(_ provider: CXProvider, didActivate audioSession: AVAudioSession) We're currently comparing the occurrence rate across different iOS versions to better understand the impact. Could you please help analyze the root cause of this issue? I can't tell you what the exact issue issue is but what typically causes this is that the app itself activated the audio session itself. That can result in one way audio because the system ends up allowing playback activation but blocks recording (since that's what the system actually protects against). Having and active audio session means that CallKit cannot activate the audio session (since you can't activate an active audio session), which then means it doesn't call didActivate. That leads to here: Our app uses CallKit with WebRTC to establish VoIP connections. The biggest issue with using any kind of l

I was wondering if you've had a chance to take a look at FB17497530 yet? I spent an hour or so looking at it today and have a few thoughts. First off, something is clearly happening in the VM system. I don't know what the issue might actually be, but 200+ thread are blocked in vm_page_wait and I didn't find any thread that was showing clear progress in the VM system. How much space is available on the boot volume and is there ANY possibility That it's becoming constrained? Like most modern OSs, the system is going to fail if it actually exhausts available swap. There are systems in place to mitigate that (first by warning the user, then by terminating processes) but there isn't any way to guarantee that will work and it's possible that some nuance of your implementation is bypassing that those protections. Related to that point, what's the content you're actually decompressing? One (or several) large files or a bunch of small ones? The thought that crossed my mind is that it's possible decompressing a very la

That sounds like it could be something else in your app causing a problem. I recommend doing some additional debugging to try to figure out what's going on there. Maybe even making a copy of your app and trying to identify what's causing the error using a process of elimination by turning different parts off.