Popping Sound

@DTS Engineer @JanosKranczler Because of this issue, I am not able to hear any audio for the call in my app after performing 7th step mentioned in the reproducing steps.

Whether this entitlement is assigned on a single app or your team account would depend on the entitlement team's evaluation of your use case at the time you have made the request. This would be determined on a case by case basis, and the information you received at the time you made the request and received the entitlement would have explained your usage limitations. Best would be to contact the entitlement team and inquire about the state of your entitlement assignments. White-labelled apps could be different, depending on what you exactly mean by white-labeled. If the apps are being published by your clients directly, they will need tp apply and acquire the entitlement separately. In any case, this sounds like you would be better off contacting the entitlements team and inquire. On the technical side, you could be encountering some other issue, like a build problem not configuring the extension correctly, the extension not being launched, or crashing, etc. Using the Console app and filtering on you

In my practice dealing with CallKit, I came to the conclusion that changing CXProvider configuration during a call is a bad idea. Sometimes this was causing providerDidReset being called, and the first call got dropped. Can you confirm or deny my observation? That's hard to say. On its own, I wouldn't expect it to be an issue or, more specifically, it's much more likely to trigger a pending failure than it is to create one. As background context, the primary cause of providerDidReset is mediaserverd itself crashing, not normal system behavior. I'm sure there are cases where a call to setConfiguration was the direct trigger, but that doesn't mean that NOT calling setConfiguration would have prevented the crash. It's also possible/likely that setConfiguration DID actually cause providerDidReset... because the media system was already in a bad state, and the setConfiguration call is what caused callservicesd to detect a problem. However, having said all that... Do you suggest calling setConfiguration even if the

First off, one other question I should have asked earlier— what does the crash log you're getting from the SIGKILL actually show? Is it just random state (whatever your app happened to be doing at the time)? Or does it show a pattern, particularly anything tied to your app’s own quit cycle? One possibility that I didn't cover here is that your app IS getting 'quit', but something is going wrong and stalling things long enough that the system kills you. I see, so quit AppleEvent is kinda like the Windows WM_QUIT message. Yes, except WM_QUIT is like the 'quit', since the AppleEvent came first. Yes, AppleEvents are that old. We definitely will file a bug. Bug number? In the meantime, the documentation for Sudden Termination says it's for shutdown. Unfortunately, the phrasing in our documentation is using trickier wording that it really should. Here's what it actually says: macOS 10.6 and later includes a mechanism that allows the system to log out or shut down more quickly by, whenever possible, killing applicat

It can be reproduced in AS's lab, Mac M4 crashed after running ATTO Burn-in in 20~40 minutes. And there is an error report pop up on Mac M4 host.

[quote='868820022, AppDevVa , /thread/809565?answerId=868820022#868820022, /profile/AppDevVa+'] Could you please confirm this understanding? [/quote] That sounds right. Peer-to-peer Wi-Fi works in all of the following scenarios: If both devices are on the same infrastructure Wi-Fi network. If the two devices are on different infrastructure Wi-Fi networks. If neither device is on an infrastructure Wi-Fi network. Any combination of the above. But, yeah, I recommend that you create a tiny prototype and test this in your specific environment, because it certainly sounds weirder than most (-: [quote='868820022, AppDevVa , /thread/809565?answerId=868820022#868820022, /profile/AppDevVa+'] would a WebSocket-based connection be sufficient compared to a peer-to-peer Wi-Fi solution? [/quote] That question doesn’t make sense. Peer-to-peer Wi-Fi supports TCP connections [1] and WebSocket runs over TCP. So these don’t stand in opposition. You can use WebSocket over any TCP connection. If you set up a TCP

The user can put you into exactly the same state using Force Quit as will crashing. The standard solution here is for the child to monitor the parent and self-terminate if the parent dies. We already implemented that. The problem is that, in the case of user force-quitting, the user inflicted that upon themselves so the the app quit unexpectedly message is nothing out of ordinary, but if a simple app update also prompts the app quit unexpectedly that doesn't sound very good.

I just checked it and it seems like Numbers implemented in HTML or something. I get the same long delay with a bunch of messages about networking, non-existent processes, WebProcessProxy, and WebPageProxy. Then I finally get a failure message DID FAIL LOADING QLWeb2DisplayBundle and the preview appears. But my app doesn't have networking. If I enable outgoing client, then the preview appears more or less instantly. The preview still isn't correct. Instead of being a large icon, it's the upper left portion of the content. QLThumbnailGenerator sounds like an interesting idea.

Thanks for your explanation of how you got to where you are. My natural inclination here is to use a UIApplication background task with an expiration handler. It sounds like you’re already doing most of that. If you simply delete the preflight code and rely on your expiration handler, does that work in practice? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi @MadGM, This sounds like a bug to me. I also tried and can reproduce the same issue. Can you file a feedback report at https://feedbackassistant.apple.com with a sample project and respond here with the FB number? Interestingly, I did notice that the resizability is available with the automatic window style, although the image is obscured. I did not find a workaround, but if I do I will respond back here.

I'd need to dig through our code to be sure of all the details; however, this is what's mostly likely going on: Now this is where things go wrong. On macOS 15, our app seems to be gracefully terminating (we attached it with lldb, and it shows that our app returns with 0 when we click Continue“), which is fine. This is likely the classic macOS app lifecycle, which involves your app receiving an AppleEvent and then choosing to exit. Strictly speaking, your app wasn't terminated— the system asked it to quit, and it eventually chose to exit (it wasn't not required to). However, for macOS 26, though, it seems that TestFlight just directly SIGKILLs our app. This sounds like the sudden app termination lifecycle, as described here. In that approach, your app is responsible for telling the system when it can't be killed, and the system is allowed to terminate your app any other time. The link above has the full details on that. However... (indicated by lldb), which means that all of our app's child processes

Thank you for your response. However, the situation may still need further attention. The latest build (2.1.5) has just been rejected, and I have already submitted a detailed reply through App Store Connect. The rejection appears to be due to a misunderstanding of the app’s core functionality. The app’s design is centered around on-device audio practice using the user’s own imported materials. The optional sample audio and the optional on-device AI model are downloaded only when the user explicitly requests them, and they can be removed at any time. There is no dynamic server-driven content or remote app behavior. I am preparing a full clarification and will post it here shortly. Thank you again for your time and attention.

Sounds like either it's not working right or the documentation needs to be updated to explain how to get it working. 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.