“eskimo”

It seems like there was a major infrastructure outage yesterday. Based on the posts at the end of this thread (10 pages, wow!) it seems to be resolved. Reply back here if you continue to have problems. 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. [quote='818322021, Chandrashakar, /thread/818322, /profile/Chandrashakar'] Is this the in-depth analysis path … ? [/quote] It certainly looks that way. [quote='818322021, Chandrashakar, /thread/818322, /profile/Chandrashakar'] for new accounts [/quote] It can be triggered by a variety of criteria. [quote='818322021, Chandrashakar, /thread/818322, /profile/Chandrashakar'] Any ETA … ? [/quote] Usually this clears in a few days. If you remain stuck after a week, lemme know by replying here. [quote='818322021, Chandrashakar, /thread/818322, /profile/Chandrashakar'] workaround? [/quote] No. In my ex

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. [quote='818398021, grad13, /thread/818398, /profile/grad13'] Notarization submissions stuck “In Progress” for 5+ days [/quote] In my experience five days is longer than normal for submissions that hit the “in-depth analysis” path. However, it’s not completely unheard of. If you remains stuck after a week, please reply here with: The UUID and creation date of your earliest request. The UUID and creation date of your latest request. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Two bits of administrivia: It looks like nilsn26 started a similar thread on Swift Forums. nilsn26, 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 is for Team ID J________H, right? If you click that Manage button, what do you see? For example, here’s what I see when I do that for my individual test team: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

benihayashi, Let’s discuss this over in your specific thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Based on the above I tried reproducing this with a test project. And lo! it’s trivial to reproduce: I started with Xcode 26.3 without the Metal Toolchain 26.3 component installed. I created a new project from the iOS > App template. In the General tab of the target editor, I removed the Mac (Designed for iPad) destination. And added the Mac (Mac Catalyst) destination. I selected My Mac (Mac Catalyst) as the run destination. I chose Product > Build; the project built without any warning. In Xcode > Settings > Components, I installed the Metal Toolchain 26.3 component. I chose Product > Clean. And then Product > Build. I now see a build warning: ld: warning: search path '/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.7003.10.hJke6J/Metal.xctoolchain/usr/lib/swift/maccatalyst' not found Given the above, I can only conclude that this is a bug. I did some digging and was unable to find any more backstory (for example, I thought that someone might’ve filed this

[quote='878914022, captadoh, /thread/808917?answerId=878914022#878914022, /profile/captadoh'] Could me passing a closure that throws to NetworkListener.run(_:) be the cause of my issues? [/quote] That’s unlikely. I mentioned it purely because it’s one of the various random issues I’ve bumped into during this process. But if you’re worried about this, I recommend that you make your closure non-throwing like so: listener.run { do { … your code here … } catch { … log the error … } } Sadly, I’ve still not made relevant progress on your main issue. I think I need to just bite the bullet and create a minimal test project, rather than try to build something ‘correct’. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='878887022, Nickkk, /thread/817724?answerId=878887022#878887022, /profile/Nickkk'] But the crash report mentions the architexture x86_64, which I don't own myself anymore. [/quote] If you run your app under Rosetta it can still run vmmap against, and I think the reported __TEXT segment size will match what you get on a real Intel Mac. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Cool. I consider this to be a problem with Xcode’s build system, but it’s an understandable one. Xcode knows that your tool depends on this library — because it adds an import of it — but, being a command-line tool, it doesn’t have anywhere to embed the library. It should embed it in the container app, but it’s clearly not doing that. I think it’s worth filing a bug against Xcode about that. And if you do, please post your bug number, just for the record. As to a workaround, there’s a couple of ways to approach that. The first is the obvious one we’ve been discussing here: Add a dummy use of Subprocess within your app. Xcode will embed libswiftCompatibilitySpan.dylib, because it knows that your app needs it, and your tool can pick it up from there The other option is to embed the library explicitly. This is complicated by the fact that the library exists within a toolchain, so it’s not clear how to reference it [1]. For the moment I recommend that you go with the first option. I’m going to talk to some collea

OK. Lemme explain how I’d tackle this and then you can either try it yourself or, if you’ve tried it already, share your experience. I typically test this stuff with a small test project. I set it up to run a request via URLSession and also load a page via a web view. I then run my debugging infrastructure against that test app. If things work there, I can run the same setup against my real app with some confidence that my debugging setup is working. OTOH, if I can’t get the results I expect with my test app, I know that there’s something wrong with my debugging setup. I haven’t tried mitmproxy recently, but the last time I did it worked a treat. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='818269021, anonymousdev332299, /thread/818269, /profile/anonymousdev332299'] is both a Developer ID certificate and Apple notarization required on current macOS versions? [/quote] Yes. Developer ID signing has been required for a long time (10.8?). Notarisation for apps has been required since 10.14. [quote='818269021, anonymousdev332299, /thread/818269, /profile/anonymousdev332299'] Is [ditto] necessary to properly preserve the app bundle structure and extended attributes? [/quote] Yes and no. If you compress with the Finder then extended attributes get sequestered, which is not good. See Extended Attributes and Zip Archives. The ditto tool doesn’t do that by default. However, in an ideal world this wouldn’t matter because your code signature should not depend on extended attributes. If you find that it does, that suggests your have a bundle structure problem. We talk about this more in TN3126 Inside Code Signing: Hashes and Placing content in a bundle. As to what’s actually happening here, it’s hard

I’m not entirely sure what’s going on here, and it’s hard to talk about the specifics without… well… you sharing info about the specifics, like what MyApp is. However, if this is a new App ID then I’ve found that it’s quicker to not try to resolve the underlying issue but instead pick a different App ID. For example, com.automaticduck.My-App. 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