Post

Replies

Boosts

Views

Activity

Reply to Rosetta Terminal on Mac OS Ventura
I tried what @freightmike suggested, but when launching the resulting copy, I get an error that the app is damaged and can't be opened because the file was downloaded on an unknown date. It wants me to trash it, but can't even trash it for me and instead requires me to manually delete it. If you have overcome this, I'm all ears. Otherwise, I'm going to have to take @davfre's approach and use a 3rd party terminal to support both native and Rosetta mode terminals.
Nov ’22
Reply to When will Xcode Cloud use Apple Silicon machines for running workflows?
Thanks for your interest here, Quinn. Our interest lies in the fact that we have a third-party dependency that generates code for specific platforms. Up until recently that dependency was only building for x86_64 simulators alongside arm64 devices. With their recent update, they now produce an xcframework, which includes the simulator binaries for the platform on which it was built. They don't have an easy way (yet) to cross-complie and include both simulator platforms (x86_64 and arm64 iphonesimulator) alongside the arm64 iphoneos binary. We could invest in figuring this out, but with the signaling from Apple that Intel machines will disappear it is less than ideal investment of our time to figure it out. At the moment we can use Xcode Cloud for archiving and submitting builds to TestFlight and the App Store, but not for running our unit test CI process for every pull request. We were hoping to move off our self-hosted GitHub Action runner to use Xcode Cloud exclusively, but until we can figure out the architecture issues for the simulator, we are stuck since our development machines are Apple Silicon.
Oct ’23
Reply to errSecInternalComponent for a specific target
Sorry for the delayed response, I didn't see your feedback until today. I can run the xcodebuild archive command (wrapped in a Makefile) from the terminal window in a screen share session with no problem, but no prompts for password. If I run the same command via SSH, I get the same error I posted before. If I run security unlock-keychain in the SSH session and then re-run the archive command, it works. What I can't figure out now is how to effectively have CI run the same keychain unlocking when the job is run as a GitHub Action workflow given that the security unlock-keychain is interactive on the command line. Is there any way to do the unlock programmatically without having to hard code the password for the account to unlock the keychain?
Jan ’24