Xcode Cloud, to me, tells me how Apple doesn't understand building tools for developers in 2021. (Their internal tooling notwithstanding.) Contrary to the other major cloud providers and the tooling they offer...
Xcode Cloud requires you to push your repository to their servers, and you have to configure the "Workflows" via their desktop application. No configuration as code, no shell scripts you can run from your existing CI/CD, no ability to trigger a build remotely or push code to them on demand. You can't even synchronously wait on a build to finish - you have to set up a web server and listen for a webhook! You can't integrate it with your existing CI/CD - whether that's GitHub Actions, GitLab pipelines, etc.
In other words, their build tooling does not integrate with any devops infrastructure that exists in the world.
It's like they asked devops engineers what the state of the art is (declarative configuration, scriptable builds) and said, "we'll not be doing that, thank you very much."
Why oh why couldn't they have taken a page out of Google Cloud Build or Azure build and allowed me to "build" a Dockerfile using a local CLI command in their cloud? Or AWS CodeBuild and let me push code or a tarfile to a storage bucket (or pipe it to a CLI command)?
> Xcode Cloud requires you to push your repository to their servers […] You can't even synchronously wait on a build to finish - you have to set up a web server and listen for a webhook!
It's interesting how the outcomes of Apple's engineering decisions are coincidentally indistinguishable from an attack on general-purpose computing itself. I wonder how many more years it will be until they stop shipping me a compiler entirely (never worry about confusing Xcode updates again!!) and make Xcode Cloud the only way to write software for iOS devices and M1 Macs. LLVM's licensing means I'm not even entitled to the changes necessary to support their custom hardware.
https://boingboing.net/2012/08/23/civilwar.html
> I wonder how many more years it will be until they stop shipping me a compiler entirely.
Probably never, especially with respect to Macs. I am beginning to feel like the cranky contrarian around here for continuing to argue that macOS will never be locked down to the degree iOS is, but I'm going to continue to argue it. You will always be able to develop locally on your Mac, always be able to get to a shell, always be able to install third-party apps without going through the App Store.[1]
But, Xcode Cloud (I nearly typed "Xcloud," hmm) might eventually become what they use as a solution to allow Xcode on the iPad. That would allow them to stick with their "iPads are app consoles" philosophy, even if it might be bending it a little.
[1] With the asterisk that I firmly believe there's a new OS that will replace both iOS and macOS down the road, and I'm not willing to make any strongly-worded predictions about its security model. Yet.
As I understand it, Apple's current answer to not having Xcode on the iPad is that you can now develop full apps in Swift Playgrounds and submit them directly to the app store.
It's an interesting approach - turning an educational/prototyping environment into something that you can theoretically do real work with.
Not sure why we don't have Final Cut and Logic on the iPad though - it's certainly powerful enough.
That's kind of the unanswered question, yeah. I think the other answer of "to run a simulator" isn't impossible -- the M1 has virtualization capability of some sort on it, IIRC, which might let Apple create a fully sandboxed environment for development in a future release. (I know that goes against App Store policies, but Apple can change those policies at any time, and of course can give themselves an exception at any time.)
The other, and maybe more likely, answer, though is consumer applications that could use it. On HN we tend to think about development tools when we think of "software that needs lots of power," but there's image, video and audio editing, real time effects processing, animation, all of that.
> You will always be able to develop locally on your Mac, always be able to get to a shell, always be able to install third-party apps without going through the App Store.
The infrastructure to grant/deny use of specific applications to individual users has existed in macOS for years if they wanted to use it that way. Their server just currently gives the same answer to all requests for the same signature.
I can't definitively know, sure, but I can make guesses based on what I see, and what I see so far continues to match my model of how Apple thinks about Macs vs. iPads, even as Apple passes by obvious inflection points for changing things up if they wanted to (e.g., the shift to Apple Silicon, the macOS redesign in Big Sur).
In the future, though, we run into the footnote in my original comment that I said I'm not willing to make any strongly-worded predictions about yet. I'm still not. :)
I think you’re lost in a team with a king’s share budget; this sounds fantastic to me, if they pull it off. CI system that doesn’t require me to put in a week of work at the beginning of every project, a few days to maintain as the months go on? And it is part of the ‘value proposition’ of what I’m already having to pay for in our shop?
This is all true, but I don't think that they are positioning this "Xcode Cloud" as an all-purpose continuous integration platform. It's really only for folks building iOS/macOS apps using standard templates and workflows. An opinionated, convenient, zero-configuration toolchain that automatically integrates with the rest of the ecosystem does sound like it would simplify project management for many developers, while folks who needs something more advanced can always use more flexible third-party tools.
I agree that the preview of Xcode build looks it is very tightly integrated with Xcode
>Xcode Cloud requires you to push your repository to their servers, and you have to configure the "Workflows" via their desktop application.
The code still lives with your preferred Git hosting provider. Xcode Cloud copies/clones the code just like any conventional CI. Once the build is done, Apple claims to remote/delete any copy of it.
> No configuration as code, no shell scripts you can run from your existing CI/CD, no ability to trigger a build remotely or push code to them on demand. You can't even synchronously wait on a build to finish - you have to set up a web server and listen for a webhook! You can't integrate it with your existing CI/CD - whether that's GitHub Actions, GitLab pipelines, etc.
I will reserve my comments about inter-op till they release their API and I get to play with it.
Xcode Cloud seems to be a blessing for iOS developers who don't have exposure to CI/CD systems. And that includes most iOS developers. And also it will be a blessing for companies since hiring good CI/CD engineers for iOS is really hard.
My personal view is, Xcode cloud does a lot of things what fastlane was doing using Apples Cloud infrastructure.
Isn't that the point? It _is_ your new CI/CD. If you don't want it, don't use it. I don't really see why any team would go all in on Xcode Cloud and keep their old CI infrastructure around - why split responsibilities between platforms?
I think it is the other way around, most shops I work with would be more than happy with such tooling, they don't want to pay for DevOps experts nor deal with stuff like TerraForm or ARM Templates.
Apple is coming from the IDE as main tool, as they always have done since Mac Classic.
I don't think this is actually true, but maybe I misunderstood the SOTU presentation. My understanding was that there were APIs exposed, and that Apple won't be hosting git repos themselves? Correct me if I'm wrong here...
Biggest problem with iOS in CI is limited build primitives, some providers have macOS options, macstadium is a thing, Anka helps but it’s all so hard! Waaay harder than building stuff on Linux. Apple can wave it away but making it harder means iOS CI is going to be behind forever.
They had a chance to try and help close that gap and even charge for it, I’d rather not have to setup macstadium, configure Anka controller and pull 20gb+ images.. just solve my problem for me..
APIs and authentication is ever changing all because Apple refuse to embrace modern devops. They have this idea that apps are produced by lone devs in their bedrooms and the process is designed for them.
Sure, there are loads of independent developers and that's great and tooling should work for them.
The majority of the top 100 native iOS apps are developed by teams of people working together. Apple unnecessarily makes it difficult for that group, which creates a barrier to entry for more sophisticated app development which is bad for the ecosystem.
The top 100 are those classical 100 people team for a message app kind of companies, hardly the target market of this feature, they already have their DevOps pipeline using Terraform with K8s on Kata Containers, and immutable builds that scale across the cluster.
Right, which is the point of the post I originally replied to and also my point. They cannot use that DevOps pipeline to build iOS apps, sign iOS apps or deploy to the Apple App Store.
Shopify detailed the hoops they had to jump through a few years back (https://shopify.engineering/scaling-ios-ci-with-anka) where they specifically say that CI for iOS has to be done entirely differently to the rest of their infrastructure:
It’s the only piece of infrastructure at Shopify that doesn’t run on top of Linux. We can leverage the same Google Cloud infrastructure we already use in production for our Android build nodes. Unfortunately, Cloud providers such as Amazon Web Services (AWS) and Google Cloud Platform (GCP) don’t provide infrastructure that can run macOS.
You benefit from using these tools almost immediately when you're >1 developer and that's where XCode Cloud may be helpful, the 1-5 developer team size. But you're still in trouble if you are using something like React Native/Flutter/Kotlin to build iOS and Android apps and don't want to maintain separate CI processes.
The desktop application supports you giving the app your credentials to BitBucket, GitHub, and GitLab, whereby it then uses your credentials (it uses your username and password instead of an API key or SSH key??????). See the docs here:
Xcode Cloud requires you to push your repository to their servers, and you have to configure the "Workflows" via their desktop application. No configuration as code, no shell scripts you can run from your existing CI/CD, no ability to trigger a build remotely or push code to them on demand. You can't even synchronously wait on a build to finish - you have to set up a web server and listen for a webhook! You can't integrate it with your existing CI/CD - whether that's GitHub Actions, GitLab pipelines, etc.
In other words, their build tooling does not integrate with any devops infrastructure that exists in the world.
It's like they asked devops engineers what the state of the art is (declarative configuration, scriptable builds) and said, "we'll not be doing that, thank you very much."
Why oh why couldn't they have taken a page out of Google Cloud Build or Azure build and allowed me to "build" a Dockerfile using a local CLI command in their cloud? Or AWS CodeBuild and let me push code or a tarfile to a storage bucket (or pipe it to a CLI command)?