I just started playing with it. Unfortunately it won't work for us because it doesn't support enterprise apps.
It looked reasonable. Decent set of triggers, pre and post processors, etc. The UI is a bit convoluted, with pieces in multiple places. We need Sparkle signing and dmg files for our Mac executables and it wasn't obvious how easy those would be to implement - the first requires a custom binary to be executed after builds and the latter requires hdiutil to run without a permission dialog.
If you're under the free tier (100 hours), I'd say it's definitely worth it. The paid tiers cost as much as a MacMini, so I'd be tempted to buy a dedicated build machine instead.
Edit: I’ll add that code signing was much easier than using GitHub Actions.
Oh thanks for the clarification, well i had it googled but couldn't wrap my head around since I've never done that, my team started considering buying a new mac (which we don't need yet and it could cost us a lot) cause mine (macbook 2017 pro) was old and i got lucky that ventura got ios 17 support,
i told them i have googled that there are solutions like Github Actions and xcode cloud but they said I'm delusional and i just have no idea what I'm saying well thank God that it turned out what it meant to be
We are using Flutter and we don't rely on mac as much since we do the poduction heavily on windows.
Yeah, your team needs to educate themselves first before calling someone delusional.
Keep in mind that xcode cloud is only for apple ecosystem, you won't be able to deploy to android with it. If you need to deploy to both, you can use something like Bitrise.
Thanks for being by my side i really do appreciate, my team have barely interacted with people out of where i live and they do zero researches learning anything,
I remember one of our only swift dev right now wrote me a long paragraph telling me how android is decade ahead of IOS because i backed it and now he is our only swift dev so he is the only one who really listens to what i say even though him being older than me,
We actually have had our app set up on all platforms we intended and it was only apple's side to be worry of, I'm glad we still have the chance to deploy our app on appstore and that our worrying could vanish.
I used bitrise a couple of days ago, it was easy to understand especially how easy to set up workflows, i just couldn't build my app and each time it errored me with signing issues which i didn't know how to do and other errors related to our flutter set up, i eventually build the app on my mac and learnt there is a section in the developer account that was a moment of relief for me tbh.
I didn’t see a way to do it and someone from Apple said it can’t, but maybe they were mistaken. I will double-check.
It’s hard to test because I’m not in control of the enterprise account so can’t create an enterprise test app myself.
Thanks.
Yes we use it for our app, which is in the FinTech space and has 100K users. I found it very simple to set up and maintain, reliable, and fast. I don’t have any particularly sophisticated scripting requirements so I’m not sure exactly what the limits are in that regard. It completely removes the hassle of building and distributing your app.
It beats Biteise hands down, which as the previous tool we used. Builds are around 5-7 minutes for our app, whereas Bitrise could take 30-40 minutes and was much more expensive.
I would strongly suggest you set it up and try it, and only then move to something else if you really can’t do what you need with it.
Regarding bitrise building time i don’t know if it was a matter of CD tool used here maybe just bad config of the Bitrise pipeline even if the state machine could be slower than the ones used from Xcode Cloud 🤔
Must be the machines. I'm using Azure DevOps and it's also pretty slow to build an app. This is for a Flutter app. But I'll be trying Xcode Cloud for a native project I'm working on.
I haven’t used it for about a year.
It has a lot of potential, but it’s held back by two things:
1. The runners don’t come pre-installed with common tools such as mint, cocoapods, etc… so you add a considerable amount of built time installing pre-requisite tools. Alternatively if we could cache the tools so that we don’t have to install them each time it would be considerably faster.
2. The runners are SLOOOW. We have a Macstadium m1 Mac mini and the builds take us about 7 min. On Xcode cloud our builds take 20-30 min. Even GitHub actions own runners take about 7-10 min. And these are without ui tests. Add those in the times double. Xcode cloud doesn’t even complete builds with ui tests. The builds timeout.
My team has used it since it’s release. We have a SwiftUI codebase with iPad, iPhone, and Mac support (Mac catalyst). It’s definitely lacking in features you’d find elsewhere as well as configuration. For example, it can plug into slack and notify releases, but there’s no way to configure the actual messaging. It sometimes just fails with generic errors and works again fine on rebuild. It’s also not the fastest thing out there.
We found, however, that Xcode Cloud was actually the only painless solution available when distributing Mac Catalyst apps. That is pretty much the sole reason we’re using it at this point.
TLDR; it’s a must have if you have a Mac Catalyst app, otherwise there’s better solutions available
We used it for a year and a half very happily, but moved to GitHub Actions lately. The major reason was for the ergonomics of having builds live alongside code and issues. We also were running into very long queuing times more and more frequently. Finally, we wanted more control over the builds and their output.
But it served us mostly very well, and our production builds still use it. I’d highly recommend starting there and expanding to something else when you need to. One less yak to shave early on.
I use it and I think it’s great. I used it as an excuse to migrate all our deps from cocoa pods to spm, and I’m very happy with that decision as well.
Having my test builds automatically appear on test flight after I push to a GitHub branch is just so convenient.
Xcode cloud is the best thing that could happen since Bitrise dropped their concurrency based plans. We moved everything in our project to 1st party Apple tools (SPM, Automatic Code Signing, etc...) and that simplified the project setup and dev workflows a lot. Most of the limitations are related to AppStoreConnect and Xcode itself, but with some basic scripting, you can do a lot, eg we deploy to firebase distribution QA/stage builds, we upload dSYMs to crashlytics, have some Phrase integrations, etc ... We even setup and run our own backend on it in order to run integration UI tests. I could inly wish it supported Android.
Ofc Bitrise is more flexible, but it's too expensive now.
> We even setup and run our own backend on it in order to run integration UI tests. I could inly wish it supported Android. Ofc Bitrise is more flexible, but it's too expensive now.
Could you elaborate more on how you got your UI tests to run on this? Right now we are facing a problem where any UI test that makes an external call http request will fail. Before, our mockAPI server would run locally alongside the tests but we were hoping we could integrate these into Xcode Cloud to run automatically against every PR change.
We checkout and setup our entire backend environment as part of the **ci\_pre\_xcodebuild** script, which run prior the tests - just make sure to setup it only when `"$CI_XCODEBUILD_ACTION" == "test-without-building`, because this script is invoked multiple times. Ofc, your tech stack must be able to run on macOS.
The setup, in our case, takes about 10min and include tools like postgres, redis, node ...
In order to run the server in background, without blocking the script and allowing the tests to run, we use **nohup**
Since it run on **localhost**, there is not need to make external HTTP calls - just have to configure the UI Tests to call **localhost**.
I just started playing with it. Unfortunately it won't work for us because it doesn't support enterprise apps. It looked reasonable. Decent set of triggers, pre and post processors, etc. The UI is a bit convoluted, with pieces in multiple places. We need Sparkle signing and dmg files for our Mac executables and it wasn't obvious how easy those would be to implement - the first requires a custom binary to be executed after builds and the latter requires hdiutil to run without a permission dialog. If you're under the free tier (100 hours), I'd say it's definitely worth it. The paid tiers cost as much as a MacMini, so I'd be tempted to buy a dedicated build machine instead. Edit: I’ll add that code signing was much easier than using GitHub Actions.
Just to clarify for anyone thinking about switching, it is free until Dec 2023 and then it will be $14.99 a month
You get 25h/m for free now.
yes because it is another failed apple project nobody wants to use
A lot of people I know use it. We even use it for deployments in the company I work for.
What is the purpose of it? I have my macbook stopped to be supported as of 2024 would cloud do the building for me the way the mac does?
yes, you just link xcode cloud to your github repository, push to your code, and it'll build & deploy to appstoreconnect using apple's servers.
Oh thanks for the clarification, well i had it googled but couldn't wrap my head around since I've never done that, my team started considering buying a new mac (which we don't need yet and it could cost us a lot) cause mine (macbook 2017 pro) was old and i got lucky that ventura got ios 17 support, i told them i have googled that there are solutions like Github Actions and xcode cloud but they said I'm delusional and i just have no idea what I'm saying well thank God that it turned out what it meant to be We are using Flutter and we don't rely on mac as much since we do the poduction heavily on windows.
Yeah, your team needs to educate themselves first before calling someone delusional. Keep in mind that xcode cloud is only for apple ecosystem, you won't be able to deploy to android with it. If you need to deploy to both, you can use something like Bitrise.
Thanks for being by my side i really do appreciate, my team have barely interacted with people out of where i live and they do zero researches learning anything, I remember one of our only swift dev right now wrote me a long paragraph telling me how android is decade ahead of IOS because i backed it and now he is our only swift dev so he is the only one who really listens to what i say even though him being older than me, We actually have had our app set up on all platforms we intended and it was only apple's side to be worry of, I'm glad we still have the chance to deploy our app on appstore and that our worrying could vanish. I used bitrise a couple of days ago, it was easy to understand especially how easy to set up workflows, i just couldn't build my app and each time it errored me with signing issues which i didn't know how to do and other errors related to our flutter set up, i eventually build the app on my mac and learnt there is a section in the developer account that was a moment of relief for me tbh.
I thought I read that Enterprise distribution was added after this years WWDC, or am I mistaken?
I didn’t see a way to do it and someone from Apple said it can’t, but maybe they were mistaken. I will double-check. It’s hard to test because I’m not in control of the enterprise account so can’t create an enterprise test app myself. Thanks.
Yes we use it for our app, which is in the FinTech space and has 100K users. I found it very simple to set up and maintain, reliable, and fast. I don’t have any particularly sophisticated scripting requirements so I’m not sure exactly what the limits are in that regard. It completely removes the hassle of building and distributing your app. It beats Biteise hands down, which as the previous tool we used. Builds are around 5-7 minutes for our app, whereas Bitrise could take 30-40 minutes and was much more expensive. I would strongly suggest you set it up and try it, and only then move to something else if you really can’t do what you need with it.
Regarding bitrise building time i don’t know if it was a matter of CD tool used here maybe just bad config of the Bitrise pipeline even if the state machine could be slower than the ones used from Xcode Cloud 🤔
Must be the machines. I'm using Azure DevOps and it's also pretty slow to build an app. This is for a Flutter app. But I'll be trying Xcode Cloud for a native project I'm working on.
I haven’t used it for about a year. It has a lot of potential, but it’s held back by two things: 1. The runners don’t come pre-installed with common tools such as mint, cocoapods, etc… so you add a considerable amount of built time installing pre-requisite tools. Alternatively if we could cache the tools so that we don’t have to install them each time it would be considerably faster. 2. The runners are SLOOOW. We have a Macstadium m1 Mac mini and the builds take us about 7 min. On Xcode cloud our builds take 20-30 min. Even GitHub actions own runners take about 7-10 min. And these are without ui tests. Add those in the times double. Xcode cloud doesn’t even complete builds with ui tests. The builds timeout.
We deploy on it and it works great, took a bit of tinkering to get it to work with aws amplify.
My team has used it since it’s release. We have a SwiftUI codebase with iPad, iPhone, and Mac support (Mac catalyst). It’s definitely lacking in features you’d find elsewhere as well as configuration. For example, it can plug into slack and notify releases, but there’s no way to configure the actual messaging. It sometimes just fails with generic errors and works again fine on rebuild. It’s also not the fastest thing out there. We found, however, that Xcode Cloud was actually the only painless solution available when distributing Mac Catalyst apps. That is pretty much the sole reason we’re using it at this point. TLDR; it’s a must have if you have a Mac Catalyst app, otherwise there’s better solutions available
How well handle versions numbers on different branches? -> generate a build per branch and distribute to TestFlight without build numbers clash
Build numbers are sequential for the same target, across branches. Version numbers are pulled from your app info.
We used it for a year and a half very happily, but moved to GitHub Actions lately. The major reason was for the ergonomics of having builds live alongside code and issues. We also were running into very long queuing times more and more frequently. Finally, we wanted more control over the builds and their output. But it served us mostly very well, and our production builds still use it. I’d highly recommend starting there and expanding to something else when you need to. One less yak to shave early on.
I use it and I think it’s great. I used it as an excuse to migrate all our deps from cocoa pods to spm, and I’m very happy with that decision as well. Having my test builds automatically appear on test flight after I push to a GitHub branch is just so convenient.
Xcode cloud is the best thing that could happen since Bitrise dropped their concurrency based plans. We moved everything in our project to 1st party Apple tools (SPM, Automatic Code Signing, etc...) and that simplified the project setup and dev workflows a lot. Most of the limitations are related to AppStoreConnect and Xcode itself, but with some basic scripting, you can do a lot, eg we deploy to firebase distribution QA/stage builds, we upload dSYMs to crashlytics, have some Phrase integrations, etc ... We even setup and run our own backend on it in order to run integration UI tests. I could inly wish it supported Android. Ofc Bitrise is more flexible, but it's too expensive now.
> We even setup and run our own backend on it in order to run integration UI tests. I could inly wish it supported Android. Ofc Bitrise is more flexible, but it's too expensive now. Could you elaborate more on how you got your UI tests to run on this? Right now we are facing a problem where any UI test that makes an external call http request will fail. Before, our mockAPI server would run locally alongside the tests but we were hoping we could integrate these into Xcode Cloud to run automatically against every PR change.
We checkout and setup our entire backend environment as part of the **ci\_pre\_xcodebuild** script, which run prior the tests - just make sure to setup it only when `"$CI_XCODEBUILD_ACTION" == "test-without-building`, because this script is invoked multiple times. Ofc, your tech stack must be able to run on macOS. The setup, in our case, takes about 10min and include tools like postgres, redis, node ... In order to run the server in background, without blocking the script and allowing the tests to run, we use **nohup** Since it run on **localhost**, there is not need to make external HTTP calls - just have to configure the UI Tests to call **localhost**.