Thanks for the reply Quinn:) Unfortunately I can't try going from Work to Home, as my home Mac is my work Mac (and vice-versa). So instead this morning I first tried restarting my Google Fiber and UniFi equipmenent, hoping that it might help. But unfortunately I ran into the Stapling timeout again. The only thing that seems to help is when I Restart my M4 Studio. After a Restart, Stapling worked fine. I did the same thing (Restarted) after Stapling timed out on me last week, and it temporarily fixed the problem. It's pretty anecdotal I know. So... 🤷

Yup! You're right as always Quinn... it's the Hardened Runtime. Although I do seem to have HR enabled all the time in my Target. Maybe something about building for Debug or Profiling disables it...? Regardless, disabling it not only got DYLD_PRINT_LIBRARIES working, it also got the LSEnvironment flags in my Info.plist to work as well. Thanks:)

Update: After some trial-n-error with my builds, this looks like it has something to do Deployment Postprocessing (which I think is enabled for Archive builds). But I still don't understand why my Test app Archive build (which should have Deployment Postprocessing on) seems to be okay with adding Environment Variables in Terminal.

Ignore my Dropbox post. I set something up in Github instead. I hope this helps someone:) https://github.com/psulak/Tahoe-Sequoia-Hybrid-Icon

My test projects for anyone who wants to try this madness. Requires installing Xcode 26.0.1. Follow the 2 Read Me files included. At some point I may clean this up and post it on Github. But Dropbox will have to do in a pinch: https://www.dropbox.com/scl/fo/pyqw2s06pzc4gacdrysmf/AHp6Bqy7dzfGZz34jOoG6F0?rlkey=cziky74r2hwxfo9m4gpd6fpif&st=8z7au8wn&dl=0 If someone comes up with a cleaner way to do this, please share with the whole class:)

@Steve4442 Quick FYI: I actually have the 2 different icons working now (Liquid Glass Icon Composer .icon appears in Tahoe, and my current Legacy .icns appears in Sequoia). It's a huge mess to do, but it is possible. In my case I had to: Generate a Legacy .icns via Terminal (instead of using an Asset Catalog in Xcode) Install Xcode 26.0.1 Create a simple test app with a Shell Script that runs actool to build the Asset.car file. Build my test app with Xcode 26.0.1 Copy the resulting Assets.car and the Terminal-built .icns, into my Xcode 24.3 production project. Tweak my Xcode 24.3 production project's Info.plist and build. Final app displays two different icons: LG in Tahoe, Legacy in Sequoia. To give you an idea of how messy this is, I had to follow much of John Siracusa's advice from here: https://mjtsai.com/blog/2025/08/08/separate-icons-for-macos-tahoe-vs-earlier/ If anyone really wants to go through this major hassle, I can try to write up instructions here. But it'll take me a while to write up the process and I'm not sure when I'll have the time to do that.

Thanks @Steve4442. I figured you'd be the one to respond:) Ok, so dumb follow-up question: If I ditch Asset Catalog and use Icon Composer exclusively, is there a way to generate an icon such that the Liquid Glass effect is On for Tahoe, but Off for Sequoia and earlier? In other words, have an Icon Composer Layered icon which automatically renders "flat" in Sequoia, but "glassy" in Tahoe? I'm about 98% sure I can't, but I figured I'd ask in case I missed something really obvious.

Does anyone have an update about this for Xcode 26.3/26.4? I'm finally getting around to updating my app's icon with Icon Composer and Liquid Glass for Tahoe. But now my app looks very out of place in Sequoia and earlier. I figured it'd be easy to just keep my old icon along side my new Tahoe icon so my app looks "correct" under both new and Legacy OS's. But I cannot for the life of me get this to work, and it's maddening. I've wasted well over half a day on this problem. Is there a known solution? Surely there must be a way, as the very latest builds of both Safari and Chrome have different icons in Sequoia and Tahoe.

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 ¯_(ツ)_/¯