“eskimo”

[quote='905631022, DTS Engineer, /thread/845853?answerId=905631022#905631022'] I’ve made a note to fix this. [/quote] And it’s back! Thanks again for letting me know. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

So are you seeing this issue on just one Mac? Or across a wide range of them? My standard test for this stuff is pretty much what I outline in Testing a Notarised Product, that is, use a VM to test and then retest on a (virtual) Mac that’s never seen my product before. If you do that, do you see the problem? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='906055022, christophe.calmejane, /thread/841958?answerId=906055022#906055022, /profile/christophe.calmejane'] it will eat all the AVTP-C frames [/quote] Did you file a bug about that? If so, what was the bug number? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='906056022, floorish, /thread/845853?answerId=906056022#906056022, /profile/floorish'] The API has been deprecated since macOS 11, not 10.6. [/quote] Indeed. Sorry for the confusion. I’ve gone back and corrected my previous post. [quote='906056022, floorish, /thread/845853?answerId=906056022#906056022, /profile/floorish'] You seem to imply that this XPC connection is not always allowed? [/quote] At a technical level, sandboxed apps are allowed to make IPC connections via an app group, regardless of whether the other end of the IPC connection is sandboxed or not. That’s what’s expected (per that doc you found) and it matches my experience. [quote='906045022, Etresoft, /thread/845853?answerId=906045022#906045022, /profile/Etresoft'] I could not get a sandboxed app to talk directly to a non-sandboxed launch agent [/quote] I’m not sure why you had problems with this, but I’ve done this myself and it worked for me. I’ve also seen other developers take advantage of it. I’m happy to help either you or flooris

I don’t think there’s much for me to say here. FB24828992 and FB24791716 look like bugs that need to be investigated by the relevant engineering teams. Thanks for filing them. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='906069022, PERockwell, /thread/847185?answerId=906069022#906069022, /profile/PERockwell'] I can confirm that Xcode 27 on macOS 26.6.2 works fine. [/quote] OK. That’d explain why I didn’t see it. After responding yesterday I asked about this issue internally. It seems that it’s a known thing. When Xcode runs a program in this way there’s a limit to the maximum line length. Hence the error you’re seeing, where --env=XYZ is being truncated to just --en. Unfortunately I don’t see a good way to get back to exactly the behaviour you were used to. An easy, albeit hackish, alternative is to slightly tweak your code to connect stdio to a known pseudo TTY: int fd0 = open(/dev/ttys001, O_RDONLY); assert(fd0 >= 0); int fd1 = open(/dev/ttys001, O_WRONLY); assert(fd0 >= 0); int fd2 = open(/dev/ttys001, O_WRONLY); assert(fd0 >= 0); dup2(fd0, STDIN_FILENO); dup2(fd1, STDOUT_FILENO); dup2(fd2, STDERR_FILENO); You then have to wedge that Terminal window in a sleep call so that your program has full control ove

Yep. That’s matches my reading of the current state of these bugs (specifically FB23265799). )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='906020022, IHadToChooseAUserNameAndIdidntWantTo, /thread/847102?answerId=906020022#906020022, /profile/IHadToChooseAUserNameAndIdidntWantTo'] It's not really my question. [/quote] OK. But the rest of your reply doesn’t contain a question either [1]. Sorry to be so strict, but you have to remember that my mandate here is to help developers create products that use Apple’s APIs and tools, so I kinda need to know what developer-facing issue you’re trying to solve. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] At least not by the standard DTS metric of Are there any question marks? (-:

I expect that this will work, but I can’t do this: [quote='847405021, Pavel, /thread/847405, /profile/Pavel'] could you please confirm if the specific PDF-handling subset of CoreGraphics … is completely session-independent, memory-safe, and daemon-safe … ? [/quote] The problem here is one of layering. Because these APIs exist within Core Graphics it easy for them to become accidentally bound to the window server [1]. So, even if that’s not the case right now, it’s hard for us to guarantee that the implementation won’t change in the future. But there’s a trade-off here. There is no lower-level PDF API, so the alternatives are to use CG or bring your own PDF library. Unless your product already has such a thing, the latter will add a constant maintenance burden. So, you have to trade off between that and the potential risk of an urgent, and complex, update if CG breaks on you. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [

[quote='847432021, sasa707, /thread/847432, /profile/sasa707'] Feedback Assistant report: FB24876147. [/quote] Filing a bug about this a good first step. However, for the bug to be actionable we’ll likely need a sysdiagnose log taken on an affected device shortly after reproducing the problem. Are you in touch with a customer who can get that for you? If so, they can either use Feedback Assistant to file their own bug, which will include the sysdiagnose log, or send the log to you so that you can attach it. I have lots of hints and tips about filing bugs in Bug Reporting: How and Why? As to what’s actually causing this, it’s looks like NECP [1] is denying your app access to Wi-Fi. This is is rare outside of China because only iPhones bought in China have the option to disable access to Wi-Fi. So, if something goes wrong with that feature then it’ll most likely show up in China. One common cause of problems like this is build UUID issues. NECP relies on the main executable UUID internally, and if the device ha

The symptoms you’ve described usually correlate with a failed upload. When you initiate a notary submission, the notary service allocates a request and then waits for the binary to be delivered. It’ll wait for about 12-ish hours, after which it assumes that the binary is never coming and deletes the request. The weird part about this is the Intel versus Apple silicon difference. I can’t think of any reason why that’d affect this behaviour. Regardless, the path forward is the same: Run notarytool manually using the --verbose flag and then: Check for any errors reported by the tool. See what it says about the upload progress. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for those clarifications. If you use the recipient team to create a new profile for the app, does it list previous-application-identifiers in its entitlements allowlist? For information on how to dump the entitlement allow in a profile, see TN3125 Inside Code Signing: Provisioning Profiles. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

So I suspect that there’s something environmental in play here. If this were affecting everyone using Xcode 26.6 on macOS 26.6.2 the world would be alight with reports like this. Have you tried this on more than one Mac? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='905635022, floorish, /thread/845853?answerId=905635022#905635022, /profile/floorish'] If I did it incorrectly please let me know. [/quote] Nah, I suspect I was ‘holding it wrong’ at my end. I re-ran my queries today and got sensible results. However, those results didn’t shed any light on this problem. I unpacked your sysdiagnose log and then ran a query against the system log snapshot within that: % log show --debug --info --last 15m --predicate category == 'violation' AND composedMessage MATCHES 'Sandbox: FontRequest.*deny.*' and NOT (composedMessage CONTAINS 'vfs') system_logs.logarchive Note I suppress log entries containing vfs because there’s a lot of them and I believe that they’re just noise. I only see entries like this: type: error time: 2026-09-17 12:17:17.945576 +0200 process: kernel subsystem: com.apple.sandbox.reporting category: violation message: Sandbox: FontRequest(1055) deny(1) iokit-open-user-client AppleNVMeEANUC and I don’t believe that they’re relevant to this issue. I was hopin

[quote='905838022, sunil.jakhar, /thread/844277?answerId=905838022#905838022, /profile/sunil.jakhar'] Any update on it as we are also facing this issue. [/quote] In the two weeks since vdsoti filed their bug? No. If this is causing problems for you, I encourage you to file your own bug about it. IMPORTANT If file a bug about this, make sure to include a sysdiagnose log taken on the affected device immediately after reproducing the problem. That’s critical to us making forward progress on this. And if you do file a bug, 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