“eskimo”

If you had discovered this before the deadline, you could’ve withdrawn and re-submitted. See this thread. Now that the deadline is passed, I don’t see any good path forward for you )-: 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 in-depth 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

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth 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

See my response on your other thread. 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 in-depth 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

The no policy, cannot allow apps outside /Applications log entry is a red herring. It’s being emitted by the code that determines the current activation policy. The log entry indicates that there is no policy, and thus the default policy applies, which means that the container app must be in the Applications folder. Notably, the code that logs this is a function that isn’t passed any information about your app, and thus it’s literally impossible for it to change behaviour based on whether your app is or isn’t in the Applications folder. This is normal. The next log entry, client connection invalidated, is more of a concern. It suggests that sysextd was using XPC to talk to some helper service and that helper service went away. I’ve seen issues like that before, where the structure of your sysex causes a helper service to crash (well, trap). See this thread, starting at this post, but also see this thread. And also check for any NE-related crash reports. Share and Enjoy — Quinn “The Eskimo!” @ Develop

Oh, one other thing. I’ve corrected a typo in this thread’s title. The original title said “Network expansion”, which was kinda confusing )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’ve just learnt about a bug similar to this for iOS 26.4b2 (FB22056740). It’s not clear as to whether this is the same issue so, if you’re having a problem on macOS 26.4 beta, I definitely encourage you to file a bug about it. And if you do file a bug, please post the bug number here, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='877556022, mbisque, /thread/816956?answerId=877556022#877556022, /profile/mbisque'] I am unable to revoke existing Developer ID Installer Certificates. [/quote] Right. Revoking a Developer ID certificate is a big deal because its stops existing products from running. You should only do that if the key is compromised. Quoting The Care and Feeding of Developer ID If you believe that your private key has been compromised, follow the instructions in the Compromised Certificates section of Developer > Support > Certificates. I don’t believe that’s the case here. So you have two choices. The one I recommend is that you manually recover the private key associated with one or more of your Developer ID certificates, which will give you a signing identity that you can use to sign your software. The Care and Feeding of Developer ID explains various strategies for this. And once you do that, intentionally back up the signing identity so that you don’t run into this problem again in the future. The Care and

Thanks for all the extra info. I have a couple of comments. [quote='877572022, dolfs, /thread/816619?answerId=877572022#877572022, /profile/dolfs'] I cleaned everything out manually. [/quote] How exactly? I try to avoid testing this stuff on my development machine because the constant build / run / debug cycle exposes edge cases that are rarely seen on normal user machines. I explain my standard approach for this sort of testing in Testing a Notarised Product. It’s discussing a different technology, but the general approach will work here. IMPORTANT Most VM apps don’t virtualise Wi-Fi, so you won’t be able to test the Core WLAN side of this. But you can test the Core Location side, and I think that’s what’s key here. [quote='877571022, dolfs, /thread/816619?answerId=877571022#877571022, /profile/dolfs'] Agent requests location authorization [/quote] Have you tried requesting location authorisation from the container app? That should work because the app is just a normal GUI application. And I’m hoping that th

9labs wrote: FB22063824 Thank you! I’ve asked the relevant team about the state of this and I’ll reply here when I learn more. ps 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. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This isn’t the first time I’ve seen reports of this. See this thread. Unfortunately something I failed to drive that thread to a conclusion )-: so I’m going to use your thread to continue the issue. In that thread I suggested that the developer tweak their filter to return .allow(), purely as a diagnostic test to see whether the problem is fundamental to content filters or something specific to the filter working on the SMB stream. They indicated that it’s the latter. Do you concur? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m sorry I missed your reply [1]. The came up today in a different thread and I encourage you to bounce over there. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] The DevForums platform has ongoing issues with notifying folks of updates on threads. A few months back we fixed one of the more serious issues. However, this thread was before then, so it’s possible that I missed the update because of that. It’s also possible that I fumbled something myself )-:

If you go to Developer > Account > Identifiers and filter on Media IDs, what do you see? For reference, this is what I see with my individual test team: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='817086021, StonedStudio, /thread/817086, /profile/StonedStudio'] the types are now being assigned correctly. [/quote] I’m glad to hear that you got this sorted out. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com