There seem to be very few reports of this problem. But I'm seeing it today on my Mac Studio M4 Max running Sequoia 15.6 and the latest build of Transporter v1.3.4 (13410). "Can't authorize your user at this time." "Unable to process authenticateWithProvider request at this time due to a general error (1020)" ALSO seeing "The server returned an invalid response. This may indicate that a network proxy is interfering with communication, or that Apple servers are having issues. Please try your request again later. Status Code: 502 (bad gateway)" This has got to be something broken on Apple's end. Does anyone happen to know a work around? BTW I've used Transporter for years. Last time I used it was June 3rd of this year.

@tlowe & @calin - I had the exact same experience as @adwazime. When this was happening to me I filed a DTS ticket. Then a day or two later the problem seemed to magically fix itself. Good luck!

Quick update: I saw that there's a tiny little + icon next to the Minimum Deployment popup menu. Clicking it allowed me to manually enter "10.13" as the minimum target. I was able to build a Mac app and run it on my crusty old Intel iMac. So I guess all is well.

This is really easy for me to reproduce on an Intel Mac running Sonoma 14.6.1 and Xcode 15.4: Create a new default macOS app in Xcode using a Xib interface and Objective C Run the default macOS app Click the Help menu bar (note that the Search text field menu item is active) "Error when clicking on TextField..." appears in Xcode's log I just filed Feedback FB14860396 (and I referenced this thread).

Hey Everyone, I just wanted to post an Update: On 3/7, we checked the Notarization history on our Primary dev account. We noticed that all the apps we had submitted for Notarization over the previous 10 days had been changed from “In Progress” and were now all marked as “Rejected”. Since we hadn’t heard any official word from DTS, we decided to wait before trying anything. On 3/8, we still hadn’t received any news from DTS. But we decided to “risk it” and submitted an app for Notarization. It worked! We tried a few more submits, and everything went through just fine. As of this morning (3/12), we still haven’t heard anything official from DTS. But Notarization seems to be working for both our Primary account, as well as the Secondary dev account we created last week. So… I guess it’s all good now…? :) Quinn, I don't know if you were able able to do any "prodding" behind the scenes, but thanks (as always) for your help and expert advice here on the forums:)

We're at 9 days and counting, with every zip or dmg sent to notarytool being stuck "In Progress". This must be some kind of record. I went so far as to create a second paid Developer Account just to be able to notarize apps, while our main Dev account gets fixed. Nope. Those apps are all stuck "In Progress" also... We've notarized literally dozens and dozens of apps since mid-2022 using both altool and notarytool. Sometimes it takes a while (20-30 minutes). But we've never had a problem anywhere near this bad. I did finally get a reply from Dev Support late yesterday. I sent them all the info I could think of. But unfortunately it's been crickets ever since. Just FYI in case anyone was wondering.

Thank you for the reply Quinn. It's been over 2 1/2 days now, and we're still stuck at "In Progress". I'm thinking I'll wait a few more hours to see if it clears up, and then file a support incident if it doesn't ¯_(ツ)_/¯

This is TRULY aggravating. The several different apps we've submitted via Notarytool for the past 36 hours are all stuck "In Progress". The most recent one is a test app that's just 2.7 MB in size. -------------------------------------------------- createdDate: 2024-02-28T14:34:27.130Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxxxxxxxxxxxx.zip status: In Progress -------------------------------------------------- createdDate: 2024-02-27T16:51:40.287Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.zip status: In Progress -------------------------------------------------- createdDate: 2024-02-27T16:41:12.532Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xx.zip status: In Progress -------------------------------------------------- createdDate: 2024-02-27T16:33:43.991Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.zip status: In Progress -------------------------------------------------- createdDate: 2024-02-27T16:12:52.728Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxxxxxxxx.zip status: In Progress -------------------------------------------------- createdDate: 2024-02-27T13:42:42.377Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxxxxxxxxxxxxxxxxxx.zip status: In Progress -------------------------------------------------- createdDate: 2024-02-26T23:21:11.236Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxxxxxxxxxxxxxxxxxx.zip status: In Progress -------------------------------------------------- createdDate: 2024-02-26T21:35:51.813Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxxxxxxxxxxxxxxxxx.dmg status: Accepted

I just tried this with Xcode 15.2 and a Clean build. The same thing is happening. The frameworks that Xcode compiles and links at project Build time are left untouched. However, all pre-built Frameworks that my app links to get Merged into the app's binary. While I don't think anything bad is happening because of this, I'd prefer to have complete control over my build chain. Is there any way to disable this behavior?

If it’s an app you could avoid this problem by: Siging your app. Notarising your app. Stapling to your app. Wrapping it in a disk image. Signing, notarising, and stapling your disk image, or not, as you see fit. Yup, that's exactly what we do. We'll just keep on doing that. Thanks Quinn.

Unfortunately I can't seem to use xattr -w com.apple.quarantine "..." /Volumes/path/to/my/mounted/dmg/myapp.app to trigger Gatekeeper. Xattr doesn't like that our DMG's are all re-only. Sigh. I think I may need to stick with hdiutil and just continue with our existing two-pass Notarizing system.

Quinn - Yes, using "open" works:) However we're actually mounting the dmg from within our app, and doing an "hdiutil attach -nobrowse -noautoopen" to keep it off the Desktop. From there we copy the app inside using NSFileManager. Basically, we're trying not to bother our users about it:) So sticking with hdiutil is important. Paradigm777 - Wow, that's crazy that someone asked practically the same (very esoteric!) question on Codermite just a few hours after I posted it here. I haven't tried manually setting the Quarantine flag as suggested in that post. It looks like using xattr to do this is a bit tricky, however I think I'll give it a try just to see what happens. But question back to Quinn: How "safe" would it be to manually set the Qurantine flag, in an attempt to trigger Gatekeeper's "ticket ingestion"? Without going into too many gory details, the reason I'm looking into this is that our systems currently do a two-pass Notarization: App first, build the dmg, then Notarize the dmg. It'd be nice if we could skip the first Notarization step and just stick with Notarizing the dmg. But we could certainly just stick with a two-pass Notarization system and call it a day:)

Hadn't tried Sandbox testing in a while and it's DOA for me again. Just got done filing feedback FB1014100.

It appears that it's finally fixed (at least for me) on macOS 12.2. YMMV.

FWIW, my account is still busted. Anyone else? I haven't been able to test any build since before Thanksgiving, which has basically prevented me from posting new apps or updates. I filed Feedback as well as a DTS incident. They got back to me and asked for some logs, which I provided. Since then: crickets. With the holidays now here, I doubt this will be fixed before January.