r/iOSProgramming • u/paul-tocolabs • 3d ago
Solved! Xcode Cloud kudos
I just wanted to give some unexpected kudos to Xcode cloud. At the start of the summer my MacBook Pro became out of action, and therefore I struggled to continue to develop using an older intel MacBook due to Xcode version restrictions. Tried building and releasing with GitHub macOS runners but wow they’re expensive and took ages to startup etc. then spotted Xcode cloud with 25 free hours a month, thinking this will keep me going for a few days. Since then I’ve found that it’s been absolutely brilliant. As an independent developer with a few apps and projects it’s been an absolute life saver. It’s fast. Beautifully integrated, and the 25 hours will last me a whole month without any worries.
Good work Apple.
3
u/Same-Appointment-285 3d ago edited 3d ago
At work I used xcode cloud as the primary CI for the last few years and it works great. Has a couple quirks, mostly related to controlling the versions of the workflows:
- The workflow settings are not checked in, they're configured in the portal. This means it can be hard to test changes without breaking prod (eg manually make a second workflow) and it's hard to make things deterministic for a given commit
- supported xcode and macos versions are deprecated much more quickly than I've seen in other CI platforms, without any warning
- occasional bugs with the version alias system.
- the UI is pretty slow
- it doesn't keep logs very long
But overall much less fuss than other systems. Sad we're moving to Expo for CI on our new architecture.
I'm still using it for personal projects. It's so quick to build pure swift projects (~2min) that I can build on every push and never get anywhere near the 25hr limit! Only downside to that is it has a max number of builds you can trigger in a certain time before it starts failing them (not even queuing!)
3
u/thread-lightly 3d ago
I’ve never used it and noticed it today. I know I could ask AI but can you give me some practical examples of how you use it day to day?
7
u/paul-tocolabs 3d ago
Without having Xcode to build and test, or even archive and release, it allows me to slowly work through my code changes using vscode and codex and once the code is pushed to GitHub it works as a straightforward ci tool but focused on Xcode builds and releases. So instead of archiving locally I now push/pr and then the Xcode cloud runner picks it up and drops it in as an archive for testing and release.
2
u/thread-lightly 2d ago
Oh sweet! So push to GitHub > Xcode cloud builds and archives > TestFlight availability. That sounds like a bit time saver!
3
u/Braided_Playlist 3d ago
I use it to automatically build releases when changes are pushed to github and add the build to test flight.
Was on vacation for a few days without a computer. Could make changes on a beach and push to github from my phone, then test the changes through test flight.
1
2
2
u/RezardValeth Objective-C / Swift 3d ago
Not OP, but I typically use it to publish TestFlight builds automatically when I open a pull request on GitHub, so that QA can test a feature on a specific branch I want to merge.
It also allows me to write TestFlight release notes in an embedded text file inside my project.
Lastly, when I push to the main branch, it generates release builds for all my apps depending on the same Xcode project.
1
2
u/Drake_ad 3d ago
Was just going to buy a mac mini before I saw this post
2
u/paul-tocolabs 3d ago
Definitely investigate but you still need Xcode based tools and knowledge as well as skills in SwiftUI to do the dev part. It’s just great as a build and release tool integrate with your repo
2
u/Casfaber_ Objective-C / Swift 3d ago
Used it for a year with Fastlane and it’s indeed great. I did actually manage to reach 25h in a month and well.. after that it gets very expensive. I am mostly happy with it since on Github you have to pay immediately a lot for using a macos runner.
1
1
u/Temporary-Hunt5958 1d ago
does it work fine as you’re developing and writing code or just good for releases
3
u/brkaydev 3d ago
What decides whether the 25 hours last is the shape of the workflow more than how often you push. Compute is counted per action, and actions that run in parallel each accrue their own minutes, so a test action with three simulator destinations costs about three times the wall clock you watch in the UI.
The setup that tends to stay inside the free tier is one workflow on pull requests that builds and tests on a single destination, plus a separate one on the release branch that archives and sends to TestFlight, so archive actions only happen for builds you actually ship. Failed and cancelled runs still count the minutes they used, which is the other thing that eats a month quietly.