“eskimo”

[quote='816646021, yyzzcc, /thread/816646, /profile/yyzzcc'] Who or how can I find out what going on with it. [/quote] The canonical escalation path for entitlement requests is Apple > Developer > Contact Us > Development and Technical > Entitlements. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='877236022, Lancelotbronner, /thread/816736?answerId=877236022#877236022, /profile/Lancelotbronner'] now there's a target for the XPC service [/quote] Right. XPC doesn’t let you establish a connection between arbitrary processes. Rather, the process advertising the named XPC endpoint must be known to the system. I talk about this a bunch in XPC and App-to-App Communication; see XPC Resources for a link to that. Note that this only affects the connection direction. XPC connections are bidirectional, so the communication direction can go the other way, or in fact go both ways. XPC Resources has a link to another post that discusses that. [quote='877236022, Lancelotbronner, /thread/816736?answerId=877236022#877236022, /profile/Lancelotbronner'] I have an issue with MTLSharedTextureHandle not being Encodable [/quote] It conforms to NSSecureCoding, indicating that it’s intended to be sent across an NSXPCConnection rather than the newer XPCSession. AFAICT there’s no generic way to transfer such an object via

I chatted with my Core Bluetooth colleague about this, and we’re not entirely sure how the failure you’re seeing can be caused by your execution context. Which isn’t to say that it’s not the case, just that the connection isn’t obvious. I usually debug problems like this in small steps. For example, in your case: I would build my agent as an app, with a menu bar and everything. I’d run that from the Finder (or Xcode) and see if Bluetooth behaves in that case. I’d then set it to run as a launchd agent, but still with the menu bar. And re-test Bluetooth. If that works, you know that the launchd agent context isn’t the cause of your issue. Finally, I’d then switch it to run without a menu bar by setting LSUIElement. And re-test Bluetooth again. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='877143022, Pushpak-Ambadkar123, /thread/815498?answerId=877143022#877143022, /profile/Pushpak-Ambadkar123'] prevents access to specific URLs by blocking any websites included in a predefined block list across all browsers installed on an iOS device. [/quote] URL filter is a good option there. Most iOS web browsers [1] are based on the built-in WebKit and thus honour URL filter restrictions without any additional work on the browser’s part [1]. [quote='877143022, Pushpak-Ambadkar123, /thread/815498?answerId=877143022#877143022, /profile/Pushpak-Ambadkar123'] and eventually browser shows error including organization name. [/quote] To reiterate, that’s not something supported by URL filter out of the box, and I encourage you to file an enhancement request for that feature. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] This isn’t the case on macOS, where it’s common for web browsers to not use WebKit (and also not

[quote='877058022, crewshin, /thread/816045?answerId=877058022#877058022, /profile/crewshin'] the option in Xcode is all I need? [/quote] Correct [1]. [quote='877058022, crewshin, /thread/816045?answerId=877058022#877058022, /profile/crewshin'] there is another issue on my side that I need to track down. [/quote] I have a bunch of helpful links in Network Extension Resources. Specifically, check out Debugging a Network Extension Provider. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Assuming that: You’re creating one you’re part of a paid developer team. See Developer Account Help > Reference > Supported capabilities (iOS). You’re creating a packet tunnel provider. You’re not concerned with MDM deployment.

[quote='877124022, rbmanian75, /thread/815676?answerId=877124022#877124022, /profile/rbmanian75'] The bug still exist in Tahoe 26.4 Beta 2 also. [/quote] Yep. That gels with my understanding )-: However, please do continue testing with new beta releases as we seed them. [quote='877124022, rbmanian75, /thread/815676?answerId=877124022#877124022, /profile/rbmanian75'] They are asking me to find another workaround. [/quote] I can’t see any better way to work around this in an App Store app, where all the components are necessarily sandboxed. I recommend that you continue to explore App Review options. See here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='877059022, 9labs, /thread/816046?answerId=877059022#877059022, /profile/9labs'] I’ve filed a support request through the Developer Support channel. [/quote] Cool. But just to reiterate the point I made above, I’d appreciate you filing a bug about this and posting the bug number here. Oh, and apropos that, lemme tag in @noyna and @froglike6 Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='877018022, vishalsehgal, /thread/815465?answerId=877018022#877018022, /profile/vishalsehgal'] We wanted to reduce the kernel overhead of assembling bytes that receiveMessage(completion:) does. [/quote] I have two things to note about this. First, there’s no guarantee that your network connections are being run by the kernel. Our platforms have a user-space networking stack and Network framework will choose that over the in-kernel stack in many common cases. Second, I’m concerned about this concept of “assembling bytes”. In general, UDP datagrams shouldn’t be fragmented and thus there’s no assembling of data at all. A packet arrives, it contains the full UDP datagram, and the content of that datagram is delivered to you. If you’re building something that does fragment UDP datagrams — that is, it sends datagrams that are larger than the path MTU and thus are subject to IP fragmentation — then it’d be better to work on not doing that rather than trying to worry about optimising this path. Moreover, even

[quote='877072022, T3ch5uppor7, /thread/816344?answerId=877072022#877072022, /profile/T3ch5uppor7'] Any way we can delete this duplicated thread? [/quote] Yes and no. See here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='816636021, khanhndvn, /thread/816636, /profile/khanhndvn'] Dear Apple Carrier Relations [/quote] The Apple Developer Forums are not the right channel to contact these folks. Rather, our focus is on the APIs in Apple’s various platform SDKs. You’ll have to escalated this via your carrier contact at Apple [1]. And to head off the inevitable follow-up question, I don’t have a contact to give you; as far as I know Apple’s carrier folks don’t have a general-purpose contact point. If you’re working as an MVNO, you might be able to make some progress by talking to your ‘parent’ carrier (or carriers). Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] The name has changed over the years, but at some point in the past it was indeed Carrier Relations. Last I checked it was Apple Device Certification, but it’s been a while.

On recent versions of macOS a program needs the Location privilege (from System Settings > Privacy & Security) to access SSID information. It should be feasible for a launchd agent to get that — unlike, say, a launchd daemon — but it’s not without its challenges. My usual advice here is: Install the from a container app using SMAppService. This ensures that the system understands the relationship between the app and the agent. Request the Location privilege in the container app. In the agent, confirm that you have the Location privilege before attempting to do anything with Core WLAN. There’s a new-fangled way to do this but I tend to rely on the old ways. I’ve run through this process for other privileges and it works a treat. However, the Location privilege is kinda weird — it’s not managed by the standard TCC infrastructure — so I’m not 100% sure this will work in that case. But give it a whirl and lemme know how you get along. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Sup

Coming at this from the perspective of the C API, the equivalent of writeDirectoryContents(archiveFrom:path:keySet:selectUsing:flags:threadCount:) is the combination of AAPathListCreateWithDirectoryContents and AAArchiveStreamWritePathList. And to write a single file you can create the path list with AAPathListCreateWithPath. The Swift API combines these two into a single step, so there’s no Swift equivalent of AAPathListCreateWithPath. However, it’s not clear whether you need that. If you put a file in a directory and then point writeDirectoryContents(…) at that directory, you end up with an archive that contains just that file. For example, with this hierarchy: /Users/ quinn/ Test/ somefile.text passing /Users/quinn/Test to writeDirectoryContents(…) I end up with this: % aa list -v -i output.aar Operation: list worker threads: 14 verbosity level: 1 input file: output.aar entry types: bcdfhlmps D PAT= UID=502 GID=20 MOD=00755 FLG=0x00000000 CTM=1663853978.872477459 MTM=1771930096.106661813 F PAT=somefile.tex

Someone pinged me about this via a different channel so I thought I’d post an update here. [quote='661920022, SerusMac, /thread/673322?answerId=661920022#661920022, /profile/SerusMac'] I confirm that we use NETransparentProxyProvider and return FALSE from the callback. [/quote] Right. This a key test. A transparent proxy should be… well… transparent when you always return false from your handle-new-flow method. If you’re having compatibility problems with your transparent proxy, this is a great diagnostic test: Tweak your code to always return false and see if the problem persists. If so, it’s not your proxy’s fault, pretty much by definition. Anyway, I just took a look at FB9002173 and it didn’t result in a fix. However, a different developer filed their bug about this, FB13053446, and it’s carrying the torch forward. Having said that, I’ve no meaningful information to share about FB13053446. It’s still subject to investigation. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ A

@KayleeSC , Please take another run at submitting your app. I just checked on FB19582905 and there’s signs of movement there [1]. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Our bugs system should officially notify you of this soon, but I figured you’d appreciate a heads up as soon as possible.

[quote='876924022, GangOrca, /thread/816179?answerId=876924022#876924022, /profile/GangOrca'] please correct if not true [/quote] That’s right. Oh, except the bit about the exact 5 second timeout, which is an implementation detail rather than part of an API contract. Our watchdog timeouts have changed in the past and could well change again in the future. [quote='876924022, GangOrca, /thread/816179?answerId=876924022#876924022, /profile/GangOrca'] The duration of the timer is expected to be in milliseconds [/quote] Blocking the main thread for milliseconds is not ideal, because it can cause hitches [1] in the UI, but it’s not going to cause the serious problems that you get if you block if for multiple seconds. But note my comment about the iOS app lifecycle. I regularly see folks try to run cleanup code like this on app termination, only to discover that app termination is rare on iOS. And if you have to structure your app to work properly in the iOS case, then what’s the point of writing a bunch of code tha