“testflight the requested app is not avaliable”

在 iOS26 系统中 出现了不同的日志 感觉是一类问题 [com.jd.jinrong::com.jd.jinrong.JDJRWidget:Attributes type: JRDingPanActivityAttributes:CC68BF7B-0B52-474B-8DB5-EA9939717315] reload: failed during processing. [w:fix-412.00-h:dyn-64.00-160.00-cr:23.5-s:1.0.fam:medium]: ChronoCore.PlatterContentError(code: Returned timeline could not be accepted, targetIdentifer: [com.jd.jinrong::com.jd.jinrong.JDJRWidget:Attributes type: JRDingPanActivityAttributes:CC68BF7B-0B52-474B-8DB5-EA9939717315], contentIdentifer: [w:fix-412.00-h:dyn-64.00-160.00-cr:23.5-s:1.0.fam:medium], destinationURL: nil, underlyingError: Optional(Error Domain=NSCocoaErrorDomain Code=4 无法将“CC68BF7B-0B52-474B-8DB5-EA9939717315-w/fix-412.00-h/dyn-64.00-160.00-cr/23.5-s/1.0.fam/medium.activity-archive”移到“activities”，因为前者不存在，或包含后者的文件夹不存在。 UserInfo={NSSourceFilePathErrorKey=/var/mobile/tmp/com.apple.chrono/NSIRD_chronod_OmSpXo/CC68BF7B-0B52-474B-8DB5-EA9939717315-w:fix-412.00-h:dyn-64.00-160.00-cr:23.5-s:1.0.fam:medium.activity-archive, NSUserStringVari<…> 更

Any ETA of when this can be fixed, please? Because of that issue, Dash cannot parse the full documentation either, which is slowing me down considerably. Thanks for your work!

@App Review Hello, how long should i expect to be waiting more... there is still no status update on the issue, my app is still stuck in waiting for review and it entered the over 50 days mark... please review it already, it is on production, but i have a crucial update for the backend on it that must be accepted..... thanks

[quote='882249022, vishalsehgal, /thread/815465?answerId=882249022#882249022, /profile/vishalsehgal'] In case error remains nil, can I still receive Data as null? [/quote] Yes. That indicates an EOF. As I mentioned earlier, the doc comments are the best source of truth for this stuff. Quoting the doc comment for nw_connection_receive_completion_t from : The content may be NULL in two cases: The receive context (logical message) is now complete, and the callback is only delivering the completed event The connection encountered an error and there is no data to deliver. Note that the content may be non-NULL even in the case of an error if there was some data received before the error was encountered. The caller should process all content it receives, and not necessarily ignore data in case of errors. I don’t think this can happen with UDP because UDP doesn’t support the concept of EOF. [quote='882249022, vishalsehgal, /thread/815465?answerId=882249022#882249022, /profile/vishalsehgal'] Is there

[quote='882281022, Pavel, /thread/820632?answerId=882281022#882281022, /profile/Pavel'] [outside of MDM] is there any programmatic way to influence which proxy receives the flow first? [/quote] No. And, in practice, the order you get is very much an implementation detail, one that changes from Mac to Mac and OS release to OS release. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='882312022, dopey, /thread/820940?answerId=882312022#882312022, /profile/dopey'] We are actually seeing seeing this happen in practice. [/quote] OK. [quote='882312022, dopey, /thread/820940?answerId=882312022#882312022, /profile/dopey'] it's not deterministic. [/quote] Right. It’s hard to say what’s going on without more logging, but the most likely cause is a memory pressure exit, and that’s very non-deterministic. [quote='882312022, dopey, /thread/820940?answerId=882312022#882312022, /profile/dopey'] I will open a bug and post the bug number. [/quote] Much appreciated. Ideally this would include a sysdiagnose log taken: On a device with extra CryptoTokenKit logging enabled (see below) Shortly after seeing the problem But that might be hard to get, so you should feel free to file a bug with only your ‘kill ctkd’ step as evidence. On the logging front, our Bug Reporting > Profiles and Logs only has a CryptoTokenKit profile for iOS. However, you can install that profile on macOS, and I think

[quote='882274022, Davidbaraff2, /thread/820572?answerId=882274022#882274022, /profile/Davidbaraff2'] Do you know of any off the shelf VPNs that can be configured in the way you describe? [/quote] No. But my expertise is in VPN APIs, not VPN products. [quote='882274022, Davidbaraff2, /thread/820572?answerId=882274022#882274022, /profile/Davidbaraff2'] If you could point me [at code to] open sockets that will only use cellular [/quote] To start you off: Extra-ordinary Networking > Network Interface Techniques > Binding to an Interface explains how to bind a socket to a specific interface. Extra-ordinary Networking > Network Interface APIs > Network Interface Type explains how to identify the WWAN interface. [quote='882274022, Davidbaraff2, /thread/820572?answerId=882274022#882274022, /profile/Davidbaraff2'] We have total control of our local network. [/quote] So what happens if you don’t deploy a DHCP server on that network? I would expect that you’ll still be able to communicate

Hi Quinn, Following up on your earlier advice about using NEAppProxyUDPFlowHandling and the async readDatagrams / writeDatagrams API. I’ve updated my DNS proxy as follows: I now implement NEAppProxyUDPFlowHandling and handle DNS over UDP via the async API. For each flow, I store the Network.NWEndpoint that comes from readDatagrams() and then pass that same endpoint back into writeDatagrams. I no longer use NWHostEndpoint / NetworkExtension.NWEndpoint anywhere in this path. Relevant code (stripped down): private func readFirstDatagrams(from udpFlow: NEAppProxyUDPFlow, into flow: Flow, channel: Channel) { Task { let (pairs, error) = await udpFlow.readDatagrams() if let error = error { // handle error... return } guard let pairs = pairs, !pairs.isEmpty else { // retry... return } let (firstData, firstEndpoint) = pairs[0] let size = firstData.count MainLogger.shared.log(message: UDP recv (pairs.count) datagrams, first size=(size) from=(firstEndpoint) type=(type(of: firstEndpoint)) ) // Force a hostPort e

[quote='821109021, JTechHyd, /thread/821109, /profile/JTechHyd'] Are there known issues with aggressive optimization (-O) affecting … ? [/quote] Yes. If you’re using a C-based language it’s very easy to rely on undefined behavior, and the exact behaviour you get can change based on the optimisation level, the compiler version, the OS version, and so on. This is true in safer languages as well, but it’s less common. For example, Swift is generally safer than C but there are still sources of undefined behaviour, including unsafe pointers [1] and concurrency [2]. Is sounds like you’re building this third-party library from source. Is that right? If so, you can dig into the library to see if you can isolate the cause of the problem. This is no different from tackling a hard-to-debug problems in your own code. You can use both build-time tools (like the Clang static analyser) and runtime tools (like the standard memory debugging tools). It’s also possible for problems like this to be caused by bugs in the

[quote='821027021, Pavel, /thread/821027, /profile/Pavel'] For debugging purposes, I am trying to run the daemon's executable directly from the terminal [/quote] This won’t work. For your launchd daemon to work correctly, it must be started by launchd. I explain why that’s the case in XPC and App-to-App Communication. My general advice for debugging a launchd daemon is: Structure your code so that you can do most of your debugging in unit tests, rather than in your daemon. That’ll make your life much easier. To unit test your XPC code, use the technique in TN3113 Testing and debugging XPC code with an anonymous listener. To debug integration issues: Using LLDB’s --wait-for option to attach to the daemon shortly after it starts. There’s a similar option in Xcode, under Debug > Attach to Process by PID or Name. Or if you absolutely need to debug from the first instruction, add the WaitForDebugger property to your launchd property list. See the launchd.plist man page for details. [quote='821

froglike6, It’s not clear whether your response was addressed to me or Skygreed. If it’s for me, be aware that my comment above was purely administrative. Skygreed added a reply to your thread, so I wanted to make sure that anyone finding this thread was aware of their thread. As to the technical aspects of this issue, and similarly for Skygreed’s issue, I’m not the right person to address that. I don’t have any in-depth experience with HID stuff. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com