“eskimo”

[quote='889315022, Pushpak-Ambadkar123, /thread/827166?answerId=889315022#889315022, /profile/Pushpak-Ambadkar123'] any update [/quote] Not really. I have a reminder to come back to this, but that’ll likely be after WWDC. Both myself and the person I’m talking with are buried in WWDC preparation right now. Alternatively, you could ask this in the Networking Q&A during WWDC. It’s likely that the relevant folks will be there. See the link on Developer > WWDC26 > Schedule > Forums. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='889313022, Fushj, /thread/783701?answerId=889313022#889313022, /profile/Fushj'] From crash log, the reason of crash is caused by CFRelease(NULL). [/quote] Right, but that doesn’t tell you much. A memory management crash indicates that some code has done something wrong with the heap. The challenge is that the heap is one giant piece of shared mutable state. So there’s no guarantee that the code that crashed is in any way related to the code that has the bug. It certainly could be, but it could also be an innocent victim of some other code’s problem. As you’ve noted, the value being released is the return result from RPSampleBufferUtilities_CreateSampleBufferFromIOSurface. So is that bug that: -captureHandlerWithSample:timingData: should be checking for NULL? Or that RPSampleBufferUtilities_CreateSampleBufferFromIOSurface shouldn’t be returning NULL? It’s hard to say without understanding that the design contract between those two subsystems. And if the design is such that RPSampleBufferUtilities_Creat

My answer on Bojie_Lv’s recent thread about this has a little more context to this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='828136021, vince-zheng, /thread/828136, /profile/vince-zheng'] We found that some devices which originally supported Wi-Fi Aware may suddenly report that Wi-Fi Aware is not supported. [/quote] I can’t imagine that being anything other than a bug. [quote='828136021, vince-zheng, /thread/828136, /profile/vince-zheng'] The only known way to recover so far is to erase all content and settings / factory reset the device. [/quote] Yikes! I believe you’ve filed a bug report about this already (FB22866996), so thanks for that. I had a look at your bug and it’s definitely with the right folks. Based on the diagnostics you posted here, it sounds like you have access to an affected device. If so, have a read of Filing a Wi-Fi Bug Report to see if there’s anything you can do to improve your bug report. Also, it wasn’t clear whether you’ve tried to reset the device’s network settings (Settings > General > Transfer or Reset iPhone > Reset > Reset Network Settings). If not, you could try that. But: If yo

[quote='828110021, ShaddamIV, /thread/828110, /profile/ShaddamIV'] When we uninstall and reinstall an app, it should work as it did [/quote] I understand your position here, but that’s never been true on the Mac [1]. When you delete an app on macOS, the system doesn’t delete the app’s container [2]. That’s because the app container might contain vital user data, and there’s no way for macOS to know if the user has another copy of the app elsewhere on their system, or perhaps on an external hard drive that’s not connected right now. Given that reality, there are a couple of things you can do here. The first is to ask one of your affected users to remove the app and then delete the app’s container. You’ll find that in ~/Library/Containers. My advice is that you work through the process yourself, so that you can figured out the exact instructions, and then send those instructions to one of your affected users, just to see if this helps. IMPORTANT The user-visible name of your app’s container is likely different

I discussed your issue with various folks here at Apple — from both Xcode and the Developer website teams — and the conclusion is that this is a bug. We are already looking into fix it, but I’d appreciate your filing your own bug report. That’ll help in a couple of ways: It gives us a way to track the work. Our bugs system will notify you when the issue is fixed. Please post your bug number, and I’ll pass that along to the relevant folks. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi, eskimo, I met the same crash. It may RPScreenRecorder inner crash. From crash log, the reason of crash is caused by CFRelease(NULL). Triggered by Thread: 39 Application Specific Information: *** CFRelease() called with NULL *** Thread 39 Crashed: 0 CoreFoundation 0x185cde1f4 CFRelease.cold.1 + 16 1 CoreFoundation 0x185b36dc4 CFRelease + 132 2 ReplayKit 0x23b16f770 __56-[RPScreenRecorder captureHandlerWithSample:timingData:]_block_invoke + 148 3 libdispatch.dylib 0x1bd502adc _dispatch_call_block_and_release + 32 4 libdispatch.dylib 0x1bd51c7ec _dispatch_client_callout + 16 5 libdispatch.dylib 0x1bd50b468 _dispatch_lane_serial_drain + 740 6 libdispatch.dylib 0x1bd50bf44 _dispatch_lane_invoke + 388 7 libdispatch.dylib 0x1bd5163ec _dispatch_root_queue_drain_deferred_wlh + 292 8 libdispatch.dylib 0x1bd515ce4 _dispatch_workloop_worker_thread + 692 9 libsystem_pthread.dylib 0x1e097b3b8 _pthread_wqthread + 292 10 libsystem_pthread.dylib 0x1e097a8c0 start_wqthread + 8 See assembly below, the result of RPS

[quote='889279022, pascalgnaedinger, /thread/803339?answerId=889279022#889279022, /profile/pascalgnaedinger'] Just checking in whether this is still on your radar [/quote] The only thing on my radar right now is WWDC O-: But seriously, in cases like this, where working code has broken, DTS doesn’t investigate the regression ourselves [1]; that’s the responsibility of the framework’s engineering team. Our input is usually limited to: Helping you file an actionable bug Looking for a workaround This problem is easily reproducible, you don’t need help with the first point, which leaves the second. And, yeah, that’s unlikely to be happen. As I mentioned above, we’re been trying to get Multipeer Connectivity officially deprecated for years now. That makes it hard to justify spending a bunch of time looking into a regression in the framework, especially as… [checks calendar] it’s less than 7 work days to WWDC. Sorry. [quote='889279022, pascalgnaedinger, /thread/803339?answerId=889279022#889279022, /profile/pascalgna

macOS doesn’t currently support Wi-Fi Aware. Normally I’d suggest you file an enhancement request for such support, but in this case I can assure you that the Wi-Fi Aware team fully understands the desire for this. [quote='827887021, Bojie_Lv, /thread/827887, /profile/Bojie_Lv'] As shown in the image [/quote] Yep. Lemme explain why you’re seeing what you’re seeing. Mac Catalyst is a technology that allows anyone with an iOS app to create an equivalent macOS app. To make that job easier, most iOS-only frameworks are available to Mac Catalyst. However, that doesn’t mean that the framework will do anything useful. Wi-Fi Aware already has an API to determine whether the current device is supported, namely the wifiAware feature, and if you query that on the Mac then’ll you’ll find that it’s not present. Keep in mind that the Wi-Fi Aware framework itself has to be present on macOS because we support the iOS Apps on Mac feature, where users can run existing iOS app binaries on their Apple silicon Mac. If the Wi-Fi A

There’s two parts to this Your inability to access a specific release. The general problem of getting arbitrary restore images. Regarding the first, you wrote [quote='889212022, nathan-pierce-veertu, /thread/827856?answerId=889212022#889212022, /profile/nathan-pierce-veertu'] Opened FB22869718 [/quote] Thanks. That’s definitely the right path forward for this. Regarding the second issue, hmmm… AFAIK there’s no documented way to get arbitrary restore images from Apple. VZMacOSRestoreImage has two options: You can get the latest supported image from the latestSupported property (or, equivalently, the fetchLatestSupported(completionHandler:) method). You can pass a URL in to load(from:completionHandler:). There’s no API to get a list of supported images and, regarding that second choice, AFAIK there’s no documented list of URLs you can pass in. Now, there are lots of techniques to uncover those URLs but AFAIK none of them are documented as being supported by Apple. (If I’ve missed something, please reply back he

[quote='827787021, HaiPro, /thread/827787, /profile/HaiPro'] Open support case: 102900780153 [/quote] That’s a DevPrograms case number, so you’re already on the right path here. For anyone else who stumbles across this thread, this isn’t an issue we can help you with on the forums. Rather, you need to seek help via official channels. For the details, see this post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='827782021, vovkas, /thread/827782, /profile/vovkas'] case 102887849530 [/quote] That’s a DevPrograms case number, so you’re already on the right path here. For anyone else who stumbles across this thread, this isn’t an issue we can help you with on the forums. Rather, you need to seek help via official channels. For the details, see this post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m skeptical that there’s a good way to do this, but I have one suggestion for you… Starting a transparent proxy should close all flows. This was a deliberate design choice to handle cases like yours, where an upcoming proxy wants to make sure that it sees all traffic [1]. An app proxy, and hence a transparent proxy, can stop itself by calling its cancelProxyWithError(_:) method. So, if you can find a way to convince your transparent proxy to start again, you’ll have your solution. And that’s where things get tricky. It’s possible that an on-demand rule might help with that. However, this isn’t something I’ve played around with. IMPORTANT You mentioned a bunch of “undocumented” stuff. You have to be careful here. There’s a difference between: Stuff that’s in the SDK but documentation is lacking Stuff that’s not in the SDK Stuff in the second category is not undocumented; rather, it’s an implementation detail. Those can change at any time and it’s not something you should build a product on. But if you bump i

[quote='889138022, pde5i, /thread/824472?answerId=889138022#889138022, /profile/pde5i'] This broke for me in 26.5. [/quote] Well, that’s not good. However, it seems unrelated to the original issue on this thread because: That issue was specific to streams. The original poster, m.gansrigler, reports that 26.5 fixes it. Given that, I recommend that you file your own bug about the issue you’re seeing. Make sure to follow the instructions for reporting Handoff problems that I referenced upthread. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

As Albert suggested, there are a variety of different tools that you can reach for here. I have links to a lot of them in iOS Background Execution Limits. I also recommend that you have a read of Moving to Fewer, Larger Transfers. I suspect you might be able to make some headway by combining approaches: Use a URLSession background session for your large attachments. Use a continued processing task to complete your sync when the user moves the app to the background. And if that doesn’t pan out — for example, because the user cancels the task — use a background processing task to complete the sync overnight. This isn’t a trivial exercise and I suspect that you’ll need to tweak things to match the real world circumstances encountered by your app. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com