“eskimo”

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. You wrote: The type of bytes is [UInt8]. OK. What’s your deployment target here? The reason I ask is that I can think of two ways to approach this problem: Manually allocate the memory. Engage with Swift’s recently-introduced Span type. The issue with Span is that it’s really bleeding edge. For example, the span property requires appleOS 26 or later. Thus, if you need to support earlier systems there’s no point looking at Span, and that means you have to copy the properties. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='898921022, Himindu, /thread/789461?answerId=898921022#898921022, /profile/Himindu'] This suggests that the issue reported for iOS 18 may still be present in iOS 26. [/quote] Hmmmm, no. When we investigated veerasivaraman’s primary issue, FB18502752, we determined that the local network privacy prompt wasn’t showing because the address they’re accessing wasn’t on a local network. Which is representative of my general experience with local network privacy on modern versions of iOS. It seems to work pretty much as explained in TN3179 Understanding local network privacy. IMPORTANT This isn’t to say that I think local network privacy works perfectly. We continue to find problems with it, especially on macOS. However, the majority of problem reports I see from iOS are misunderstandings of how it actually works. Regarding step 3, does your accessory contain a DHCP server? If so, does its DHCP response list the accessory’s IP address as a DNS server. If so, local network privacy doesn’t apply. Quoting TN3179:

[quote='898842022, RomanKisil, /thread/814226?answerId=898842022#898842022, /profile/RomanKisil'] Basically disabling SIP and removing these two files [/quote] Right. That’s just resetting the local network privacy state, albeit in an unsupported fashion. Unfortunately it doesn’t tell us anything about what went wrong. [quote='898842022, RomanKisil, /thread/814226?answerId=898842022#898842022, /profile/RomanKisil'] I have made a Feedback Assistant submission to this: FB23981410 [/quote] Thanks. Unfortunately there’s no sysdiagnose log attached to that, which serious limits our ability to investigate. And you’ve reset local network privacy, so there’s no point adding a sysdiagnose log now. So, if you see this again in the future, please trigger a sysdiagnose log immediately, and then file a new bug report with that. See our Bug Reporting > Profiles and Logs for more about sysdiagnose logs. ControlAV, It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this an

Hmmm, this is tricky. It’s clear from the crash report that dyld has trapped (dyld4::halt(…)). Tracking down the source of that failure is tricky because the crash report hasn’t captured the message that’s passed in. However, some disassembly reveals that it’s probably coming from here. Unfortunately it’s hard to trace further from that point. Taking a step back, I’m not sure that this line of enquiry is actually gonna be fruitful. Earlier I posted two questions: Why is shared cache region memory map failing? Why is the simulator’s dynamic linker crashing when that happens? The dynamic linker is no longer crashing, it’s trapping, and that’s a reasonable thing for it to be doing in a case like this. And that brings us back to the first point. To recap: On macOS 26… There’s an intermittent issue where things start failing in the simulator. Which goes away when you reset the simulated device. With a log entry that mentions vm_shared_region_start_address. That log entry is coming out of the kernel (see here), so

[quote='898736022, Etresoft, /thread/838682?answerId=898736022#898736022, /profile/Etresoft'] Couldn't it simply be embedded for real? [/quote] I believe it is: % vmmap lldb | grep Python | head -n 1 … /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/Python3 However: It’s not clear whether simply removing the Python executable would be enough to satisfy Catalin_e10’s security audit. It’s likely that Python is used by other parts of the developer tools. I was using LLDB as an example, not as a complete list of all such dependencies. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

That seems like a pretty reason enhancement request, and I encourage you to file it as such. 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

The Settings > General > VPN & Device Management thing is a red herring. If you build and run an app via Xcode’s standard Product > Run command, nothing shows up there [1]. That’s because the provisioning profile is embedded within the app itself, and it’s automatically trusted by virtue of it being a development profile that includes your specific device’s provisioning UDID. As to why you’re see this failure, it’s hard to say without more details of the failure. Try this: Using Xcode, create a new test project from the built-in iOS > App template. Make sure you team is selected in Signing & Capabilities. Select your device as the run destination. Choose Product > Build. Assuming it builds, choose Product > Run. What do you see? Also, what version of Xcode is this? And what version of macOS? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] It is relevant in other scenarios, most notably In-House

I’ve responded on your specific thread, but the answer is basically the same as my answer to sranjan: This isn’t something we can help you with on the forums. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I don’t think there’s any reasonable way to achieve this specific goal )-: Recent versions of macOS have become increasingly strict about app and group container protection, as explained in the WWDC talks linked to by Trusted Execution Resources. This is just a further refinement of that overall goal. IMO the correct long-term fix for this is for Apple to support app extensions based screen savers. If that happened, this problem would go away because you could store these preferences in an app group container that’s available both the screen saver appex and its container app. However, there’s no sign of that happening )-: If you’d like to see that happen in the future, I encourage you to file an enhancement request describing this problem and any other problems you see caused by the legacy screen saver architecture. And please post your bug number, just for the record. As to what you can do about this today, lemme start with question: How was your installer app previously writing this property list? Share and

[quote='839144021, veer_dutta07, /thread/839144, /profile/veer_dutta07'] this … would result in NWConnection holding a strong reference to the DispatchQueue object. [/quote] Correct. [quote='839144021, veer_dutta07, /thread/839144, /profile/veer_dutta07'] whether the pending callbacks are ultimately executed depends on whether the application has kept the queue alive? [/quote] That’s never the case. The connection will maintain the strong reference until it’s completely done with the queue. You can break this up into two cases: Completion handlers Event handlers For completion handlers the connection is required to call all completion handlers once and only once. It’s not safe to simple drop them. And the completion handlers must run on the connection’s queue. Thus, the connection must retain its strong reference to the queue until all completion handlers have returned. For event handlers — state update handlers and so on — my advice is that you set the handler property to nil before calling cancel(). This is

This isn’t something we can help you with here 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

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for additional analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays. For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Based on a machine translation of your post (sadly I don’t read Chinese)-: I think that you created an English language version of this question in a different thread. I’ll reply over there. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for additional analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays. For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I see you started a new thread for this, and I plan to respond there. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com