Xcode Cloud Subscriptions Now Available
Apple (Hacker News, MacRumors):
Xcode Cloud, the continuous integration and delivery service built into Xcode, accelerates the development and delivery of high-quality apps. Get started by configuring a workflow in Xcode and receive 25 compute hours per month at no cost until the end of 2023. And now, Account Holders can subscribe for more compute hours in the Apple Developer app.
A compute hour is an hour of time used to execute a specific task in the cloud, such as building an app or running automated tests. For example, running 5 tests of 12 minutes each equals one compute hour. Xcode Cloud runs tests in parallel with other actions, such as analyzing, archiving, and building, so you’ll get results quickly.
After next year, the 25 hours/month plan will cost $14.99. I don’t have much sense for how much one compute hour gets you in practical terms. Hopefully it’s by CPU rather than by core, but I don’t know what CPU it uses. Right now, the full build/analyze/test suite for all my apps, takes about 40 minutes on an i9 MacBook Pro. The most attractive part of Xcode Cloud is the ability to test on different configurations without having to manage them yourself, but of course then you multiply the compute hours by the number of configurations.
I’ll probably sit this one out, not because of the price but because I’m not sure the benefits are worth the hassle. Xcode Bots looked great but was so frustrating and buggy that I wish I’d never touched it. It was just an incredible waste of time to have it keep breaking and require restarting the server Mac or deleting and reconfiguring the bots.
Jenkins has a rougher interface and is a pain to set up, but once it’s working it stays working. You have to manage the Mac and Xcode versions, though—in addition to Java and Jenkins—and make sure it doesn’t fill up your whole SSD with workfiles.
I decommissioned the Mac that I had been running Jenkins on because of a swollen battery and never got around to setting it up on the replacement server Mac. So far I haven’t really missed it. What were all the stats and graphs and status e-mails really doing for me? Right now, I just have a secondary Mac within arm’s reach and a script that does a git pull and analyzes/tests everything. Since this is the backup Mac that I need to maintain anyway, there’s no extra admin burden for the Mac or privacy concerns with putting my repo in the cloud. The difference is that I invoke the script manually a few times per day rather than having Xcode/Jenkins run automatically after every commit. If something breaks, I can look at it directly on that Mac.
Previously:
- Xcode 14 Announced
- Official macOS Hosting and Amazon EC2
- GitHub Actions CI/CD in Beta
- Branches and Continuous Integration
- Apple Acquires Buddybuild
- Using Xcode Bots
- Setting up Jenkins for Github and Xcode
Update (2022-09-14): Marcin Krzyzanowski:
Xcode Cloud is so annoying. None of these errors is an actual error. 🤷♀️
First is the SwiftPM package bug.
The second is just bananas.
imagine a world where Xcode Cloud uses the same Xcode we do. because this is only Xcode Cloud error, not local Xcode builds.
Update (2024-05-01): David Heinemeier Hansson:
So we’re going to drop the remote runners and just bring continuous integration back to developer machines at 37signals.
It’s remarkable how big of a leap multi-core developer machines have taken over the last five-to-seven years or so. Running all these checks and validations in a reasonable time on a local machine would have been unthinkable not too long ago. But the 14900K has over 20 cores, the M3 Max has 16, and even a lowly M2 MacBook has 8. They’re all capable of doing a tremendous amount of parallelized work that would have seem fantastical to do locally in the mid 2010s.
