eskimo

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

I have a standard spiel about such In Progress delays (see the end of this post) but 8 days is way longer than I’d expect. If you post the UUID of the earliest stuck request and its creation date, I’ll do some digging. You can get this info using the history subcommand. For example: % xcrun notarytool history …credentials… Successfully received submission history. history -------------------------------------------------- createdDate: 2025-10-29T08:04:07.376Z id: f45200c2-8495-4763-acd8-73262625832c name: Test812163.zip status: Accepted -------------------------------------------------- … and so on … 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.

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

I’m glad to hear that this got resolved quickly. If you’re looking for more context about this, Notarisation Resources 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

Thanks for filing FB21348415. It’s definitely prompted some interesting discussions internally. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I don’t have anything concrete to share here. This issue is caused by the combination of multiple things, as explained upthread, and it’s not clear that a change in the iOS client is the best way to resolve it. Conversations are ongoing. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='811359021, -Refracted-, /thread/811359, /profile/-Refracted-'] My project requires the on-device apple intelligence models [/quote] We recently updated Developer > Swift Student Challenge > Eligibility > Terms and Conditions to cover this. It now says: On-device Apple Intelligence frameworks … may be used. Submissions will be judged offline. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

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. Could you … double-check my case manually? I actually did that before the winter holiday and word from the notary team (as of 15 Dec) is that your team (Team ID 2________L) is not blocked by this Team is not yet configured for notarization and had successful notarisations earlier in December. At this point there’s nothing more I can do here. DevForums is not the right place to provide help with this, because this is about your account, which is a private thing, and DevForums is intrinsically public. If you continue to have problems, you need to escalate it again to DevPrograms. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

What Albert said but, before you do that, there’s one thing I’d like you to check: Make sure that the target team is an Organization team [1]. The most common cause for problems like this is that the target team is an Individual team. This works for App Store Connect but not for the Apple Developer Program. See the note at the top of the Permissions in App Store Connect section of Developer > Program Roles. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Or In-House (Enterprise) team.

Oh, one more thing. That dispatch_sync call being made by XProtect is doing some one-time initialisation. That initialisation has to be done on the main thread. So, you might be able to work around this by forcing that initialisation to run on the main thread in advance of all this secondary thread work. An easy way to do that would be to use NSAppleScript to run a trivial script from the main thread as part of your app init sequence. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for attaching a sysdiagnose log to your bug (FB21334477). I took a look at the enclosed spin dump and I see this: Thread 0x222f6b 180 samples (216-395) priority 31 (base 31) cpu time 0.016s (43.3M cycles, 111.3M in… 180 thread_start + 8 (libsystem_pthread.dylib + 7080) [0x19ea8cba8] 180 _pthread_start + 136 (libsystem_pthread.dylib + 27656) [0x19ea91c08] 180 ??? (XojoFramework + 1309844) [0x10569bc94] 180 ??? (XojoFramework + 2624740) [0x1057dcce4] … redacted … 180 -[NSAppleScript compileAndReturnError:] + 136 (Foundation + 9808488) [0x1a0c7da68] 180 OSACompile + 52 (OpenScripting + 78068) [0x1bffa30f4] 180 SecurityPolicyTestDescriptor + 152 (OpenScripting + 8836) [0x1bff92284] 180 _SecurityPolicyTest(char const*, void const*, unsigned long) + 332 (OpenScripting + 8472) … 180 InterpreterSecurity_ScanBuffer + 112 (libInterpreterSecurity.dylib + 4868) [0x298e39304] 180 -[InterpreterSecurity scanData:withSourceURL:] + 164 (libInterpreterSecurity.dylib + 3… 180 -[XProtectScan beginAnalysisWithFeedback:] +

OK. That first bug (FB19631435) got lost in the system, but the second one (FB19734992) has found its way to the right folks. Given that, I’ve asked for the first to be marked as a dup of the second. Regarding FB19734992, I don’t have any info to share on that front. kunal_a, If this is significantly affecting your product’s customers, I recommend that you update your bug with a description of that impact. Also, it’d help if you associated the bug with your team, as explained in Bug Reporting: How and Why? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='871291022, AbsurdFish, /thread/811481?answerId=871291022#871291022, /profile/AbsurdFish'] Revoke and regenerate the Installer certificate? [/quote] Do not do that. Developer ID signing identities are precious. See The Care and Feeding of Developer ID for a lot more background on that issue. [quote='871291022, AbsurdFish, /thread/811481?answerId=871291022#871291022, /profile/AbsurdFish'] Download and install intermediate certificates? [/quote] Yes. The majority of unable to build chain to self-signed root problems are caused by a missing intermediate. I talk about this in detail in Fixing an untrusted code signing certificate. Its focus is on code-signing certificates, but the same logic applies to installer-signing certificates as well. Note It’s perfectly feasible for your Developer ID Application and Developer ID Installer certificates to be issued via different intermediates, and that would explain the behaviour you’re seeing here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technica

Looking at the code you posted, the only way [1] that preferences can be nil at line 15 is if your decoded object code fails. You didn’t show that code, so it’s hard to tell what’s going on there. It sounds like you can reproduce this reasonably reliably. Given that, you can debug this using logging. I have general advice on that topic in Testing and Debugging Code Running in the Background. IMPORTANT It’s time to stop using NSLog habitually. Rather, use print(…) for transient debugging and Logger for debugging that you want to keep in your codebase (or for cases like this, where you need to debug without Xcode being attached). Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Well, not the only way. You could be dealing with an issue that’s outside of the scope of the Objective-C / Swift execution models, like a memory corruption problem. However, let’s rule out the easy things first (-:

[quote='811956021, FIRF, /thread/811956, /profile/FIRF'] the device … is incorrectly labeled as an “iPod” (it is actually my MacBook Air) [/quote] Yeah, that’s so weird. I’ve actually seen folks hit this before. It isn’t something you can fix yourself. I recommend that you reach out to our Developer Programs team via Apple > Developer > Contact Us. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com