“eskimo”

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

Well, that’s interesting. I asked about this internally and, yeah, this is supposed to work as documented but, for Reasons™ (r. 86443002), it does not. I’d appreciate you filing a bug about this. Once you’re done, reply here with the bug number and I’ll inject that into the internal conversation I’m having about this issue. Unfortunately I don’t see a good workaround for this. One of the primary justifications for this to work as documented is because, without that, there’s no way to achieve the goal you’re trying to achieve )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='907908022, HirohikoKihara, /thread/846474?answerId=907908022#907908022, /profile/HirohikoKihara'] Or do you expect Installer Plugins to stay supported once this bug is fixed? [/quote] So there are two separate questions here: Are installer plug-ins supported? Is this the best choice for you? My general advice on the latter is that creating an installer plug-in is a bunch of extra work and I would only recommend that if there’s no other way to achieve your goal. So, if your plug-in only exists to allow the user to choose between installation options, and you can get that same behaviour via the package itself, then, yeah, I’d ditch the installer plug-in. But that’s nothing to do with the first question. AFAIK we’ve not announced that installer plug-ins are going away. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='907715022, marucello, /thread/849002?answerId=907715022#907715022, /profile/marucello'] Would you recommend completely uninstalling Intego/NetBarrier and rebooting the host before repeating the signing test? [/quote] Yes. To be clear, I’ve no specific evidence that this is the issue, just that it helps isolate the problem. We have one machine (your main Mac) that exhibits the issue and another machine (your test VM) that doesn’t, so we want to bring those closer together to converge on the cause. Another approach that might help would be to install this software on your test VM. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='907701022, rbmanian75, /thread/836569?answerId=907701022#907701022, /profile/rbmanian75'] Bug Number : FB25030938 [/quote] Thanks. So my Bug Reporting: How and Why? post has a bunch of hints and tips on the bug reporting process, and I want to call out a couple here: If you’re a developer, it’s better to file a bug under Developer Technologies & Resources rather than, say, under macOS. It’s vital that you attach a sysdiagnose log, ideally one that was recorded on the affected Mac shortly after reproducing the problem. Regarding that last point, I noticed your bug has no such log and so it’ll likely get bounced back asking for one. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I can’t help you here. Questions 1 and 2 are about The Future™, and that’s not something we can discuss here on the forums. See tip 3 in Quinn’s Top Ten DevForums Tips. Question 3 is technically in scope but it’s not something I care to wade in on. My focus here on the forums is on helping developers create products for Apple platforms, and I can’t see any way to use these APIs in such a product, that is, with any hope of long-term compatibility. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

So I want to maintain a list of these kinds of issues you’ve reported, primarily just for my own bookkeeping. Here’s a start: FB25031577 from macos 27 - EDOM error from setsockopt() for SO_LINGER socket option for values greater than 32767 FB25031051 and FB25031272 from macos 27 - unexpected/new errno from BSD socket connect() when pending connections exceed backlog FB25019064 from Out-of-band data returned by recv() and read() on socket bound to non-loopback address even when SO_OOBINLINE is disabled FB12128351 from UDP socket bind with ephemeral port on macos results in OS allocating a already bound/in-use port Lemme know if there’s anything I missed. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com Revision History 2026-09-06 Added FB12128351. 2026-09-05 First posted.

[quote='849448021, the-sarge, /thread/849448, /profile/the-sarge'] I filed FB25058707 [/quote] Thanks. That’s definitely the right path for this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I don’t see any way that your code could’ve provoked this issue. Given that, it’s not really something I want to wade in to here on the forums, where the primary focus is helping developers with code-level issue. So, my advice here is that you report this via Feedback Assistant. 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

Has anyone filed a bug about this? I mean, in the last few years, after PhilB reported that things were working back in 2022-10. If so, what was the bug number? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Oh, hey, you started two new threads about this. I think this one captures the issue better, but Kevin and I have already started answering on the other one, so it’s probably best if we continue over there. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This is one of a class of problems related to the way that Swift concurrency treats methods with callback from Objective-C. Swift is expecting the callback to be delivered on the main actor. That’s not the defined semantics of the sendMessage(_:replyHandler:errorHandler:) method, and hence you end up trapping inside the Swift runtime. My general advice on this front is to switch to the Swift async function variant of the method. However, that won’t work in this case; Swift doesn’t create an async function variant of this method because it’s not sure which callback is the correct completion handler. Given that, your best option is to mark the callback closures as sendable: session.sendMessage( …, replyHandler: { @Sendable reply in … }, errorHandler: { @Sendable error in … } ) This tells the compiler that the callbacks are safe to call from any context, and thus it won’t insert its main actor check. IMPORTANT The real fix for this problem would be for Apple to annotate the Watch Connectivity framework headers s

[quote='849369021, vm_install_notes, /thread/849369, /profile/vm_install_notes'] a host-only connection succeeded outside the command sandbox. [/quote] I’d like to clarify what you mean by this. Specifically, what is this “command sandbox”? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The other way to slice this would be for Apple to relax the Personal Team provisioning limitations on the Mac [1]. I’m pretty sure I’ve discussed that idea before on the forums, but I wasn’t able to track down the link. Anyway, OC_s, if you’d like to see Apple change its Personal Team policy for macOS, I encourage you to file an enhancement request along those lines And 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 [1] For more about those limitations, see Developer > Support > Choosing a Membership.

[quote='849259021, Auxentis, /thread/849259, /profile/Auxentis'] I have read that first submissions may be held for in-depth analysis … [/quote] Right. That’s very likely to be the case here. I’ve included a copy of my standard spiel about this below. Given that I missed your post last Friday, I suspect that this has cleared already. If it’s not cleared by Wednesday, please reply back here and I’ll dig deeper. 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.