Xcode Cloud is a CI/CD setup for compiling and signing Mac and iOS apps. It is not a web or remote development environment like some other companies offer.
Because it can be triggered by pushes into git, you could make changes to existing code from an iPad or PC and get it built. But you can’t (realistically) do anything that requires Xcode such as adding new things to your project or messing with xib files.
This is probably a controversial opinion, but it feels like Apple is trying to lock developers in to a single path of constantly upgrading hardware and getting more and more specialized in the skills required in the Apple ecosystem.
Not just developers who try to do it for a living, but the demographic that used to be called power users (and before that: hackers): the enthusiasts that install things and dig deeper and make tools for themselves and maybe make tools for others or even transition to being career developers.
It’s the developers who build the moat around the walled gardens of mobile, and enthusiasts who bring in the people in their lives. I think Apple knows this and intentionally builds new APIs (while depreciating old ones) just so they can force devs to upgrade their OS’ which in turn forces them to upgrade to the next generation of restrictive hardware and lead them further down the garden path.
I have no insight in to the workings of Apple. I only see what they show to the public. I’m comfortable being wrong about this, but I don’t think I am.
Not a controversional opinion at all but instead very obvious, and for a long time now.
At least macOS is a UNIX under the hood these days (unlike MacOS 9), which provides some 'cross-platform synergies', but looking at where Apple has been taking these UNIX roots with iOS that was probably just a lucky accident. Enjoy it while it lasts (on macOS at least) ;)
Had BeOS been acquired instead of the NeXT reverse acquisition, Apple's history would have been much different, and most likely there wouldn't be any UNIX desktops to chose from (as I doubt Desktop Linux would have been any different in such alternative universe).
>This is probably a controversial opinion, but it feels like Apple is trying to lock developers in to a single path of constantly upgrading hardware and getting more and more specialized in the skills required in the Apple ecosystem.
That has literally been Apple’s business model since the 80s.
This is an internal NeXT video from 1991 with Steve Jobs explaining their product strategy. The more things change, the more they stay the same. https://www.youtube.com/watch?v=KRBIH0CA7ZU
It is so funny to see people that only came to OS X, because they couldn't bother to support Linux and BSD OEMs, always being surprised by the Apple developer culture (the ones actually developing for the platform since its inception).
There isn't an Xcode for iOS, but there is an increasingly capable iOS development environment for iOS, and I expect that this cloud offering is intended to eventually complement that well.
Much of the stuff that Xcode Cloud does is automation that's ~easy with a terminal and some scripting and that many developers end up doing on their Macs, but that is hard to do in the limited computing environment that iOS offers – things like packaging apps for TestFlight with the right signing keys, compressing images, etc. By moving those processes to automation running in the cloud, Apple are making iOS development on iOS more feasible.
You mean, there is (1) first-party children's sandbox that is being provided by Apple's good graces and private entitlements, written in their own language and only allowing you to publish applications to their heavily taxed storefront?
Yeah. Sounds like Apple is starting to get serious about their developer market, huh?
I didn't say it was for everyone, or a general purpose development environment.
iOS developers have been asking to be able to do iOS development on iOS for a long time, and that's exactly what Apple are delivering. It's certainly not just a children's sandbox either.
> It's certainly not just a children's sandbox either.
It might as well be, it's not like you'd be making any apps that Apple doesn't directly profit off of. Pretty much as interesting as Nintendo's Toy-Con Garage.
I can't think of a good reason Apple would want to support developers who want to publish in their (very) walled garden but aren't willing to purchase at least one macOS device. There are services which provide virtual Macs, this isn't meant to be one of them.
It's a CI/CD, not an IDE. If you want to automatically test your code on all devices in a dozen configs on multiple OS versions, you're going to need to buy some fairly expensive hardware and host it yourself, which is not exactly where the industry is going at the moment with it's "yay cloud" movement.
> I can't think of a good reason Apple would want to support developers who want to publish in their (very) walled garden but aren't willing to purchase at least one macOS device.
Those devs aren't going to purchase Apple hardware whether Apple sells them cheeseburgers or not, so its more profitable for Apple to sell them cheeseburgers.
You can, in fact, write an app and publish it to Apple's App Store with it, all from an iPad. I have no idea how much actual uptake this has seen, since I think the capability only came out at the start of the year?
This is probably fixed now, but around the days of Swift versions 1-3, Playgrounds were straight up broken. Very basic programs would segfault the compiler. I feel bad for any kids who may have been introduced to programming that way.
Very simple programs would segfault the compiler in 1-3 as well. You'd most often notice this as your syntax highlighting went away for a period of time.
Playgrounds is mostly a local running environment if I am right ?
If you teach a class, having a CI build and run the programs, potentially taking screenshots for you to review later could be a pretty good use case, especially for remote home work.
"Xcode Cloud is a continuous integration and delivery service built into Xcode and designed expressly for Apple developers."
This is a (presumably well-integrated) alternative to CircleCI. There's nothing about this particular product that would make it even remotely relevant for a middle school programming curriculum.
At any rate, what you're asking for already exists — Swift Playgrounds has been around for years, it's specifically tailored for learners, is kid-friendly, and already lets you take the whole journey from your first line of code to publishing on the App Store.
> I can't think of a good reason Apple would want to support developers who want to publish in their (very) walled garden but aren't willing to purchase at least one macOS device
Xcode explicitly supports running external command-line tools in a full-permission, unjailed shell; which is entirely contrary to the iPadOS permission model.
Apple's approach seems to be to use Swift packages as an alternative project type that can be shared across iPads and Macs and, most importantly, do not require support for running binaries outside of an app container.
How this evolves over time depends on Apple's opinions about their operating systems. If they were to basically hand people what amounts to a manufacturer-sanctioned jailbreak, then they could port Xcode to UIKit with all the functionality it has on MacOS, save for the lack of AppKit support. Alternatively, and more likely, what they'll do is add new app extension types to do Xcode-like things in Swift Playgrounds. So if you need to, say, use Rust code in your app; you'd literally download a Rust compiler from the App Store to do that.
Or they could do nothing and be satisfied with the hobbyist-grade, Swift-only programming environment they already ship.
Swift Playgrounds on iOS supports building apps and submitting them to the App Store. It seems like a 'trivial' extension to add in support for XCode Cloud to Swift Playgrounds.
A14/M1 and higher all have the hardware for virtualization, nothing is fused off for "devices". iOS and iPadOS don't ship Hypervisor.framework but the kernel still recognizes the entitlements for using it. Apple will never sign provisioning profiles with those entitlements, of course; but on at least one particular OS version with a jailbreak you could set up hardware virtualization. See https://worthdoingbadly.com/hv/
The main problem is purely just Apple not seeing a use case for virtualization on a touchscreen. They need to let go of at least one Strongly Held Belief.
"[author] has been using Xcode Cloud to compile and deploy my rcmd app switcher (https://lowtechguys.com/rcmd) for the past few months, and it’s been a great experience.
I liked that with a single “git push” I could compile, archive, deploy to TestFlight, and send for beta review. I even pushed a fix from my iPhone using Working Copy one time while I was on a train.
These are the pricing plans for those interested:
- 25 compute hours/month: Free*
- 100 compute hours/month: $49.99/month
- 250 compute hours/month: $99.99/month
- 1000 compute hours/month: $399.99/month
* Free through December 2023, then $14.99/month if you choose to subscribe at that time. "
This is interesting, because a month never contains more than 744 hours, so even if you owned your own hardware, you couldn't beat Apple's compute power with only one machine.
Isn't this a little like saying "Don't pay for Github, just buy a server rack"? My point being, A Mac mini != Xcode Cloud. There are other services that Xcode Cloud offers beyond a roll your own Mac mini solution. Just like how Github offers more services than a roll your own home server offers.
Managing the difference between a home server and a cloud service.
I used to manage some rack-mount servers for a garage startup. That meant dealing with:
- power (including UPS and remote power strips)
- network (LAN, router, ISP, DNS)
- server hardware
- server BIOS (i.e. pls reboot after power failure)
- OS and software updates
- user admin
- backups
And living 500 miles away from the server room taught me how many things can go wrong when I'm away, and what it takes to even monitor that. Can't easily conclude it wasn't worth, since these were multi-purpose and the equivalent capacity on EC2 would've cost a ton, but doing all that just for Xcode builds would've been silly.
Closer to the topic, I also used to just manage a remote Mac mini server. It was also not automatic. Even had both disks in my RAID1 set fail over time.
Many of those things are included in the Hetnzer contract though. They have service technicians that can perform any physical operation for you remotely. Just open a ticket.
Been hosting bare metal with them for ages and it has been very pleasant.
Will Hetzner install Linux on it for me and fix all the problems when they come up? If not, there's zero reason to purchase one of these for any professional purposes aside from iOS/MacOS CICD.
I'm confused, if you're running an M2 Mac, you're probably going to be running Asahi Linux. (Not really sure there is any other option :P)
That would be set up on the first day with the simple asahilinux she'll script, and then theres essentially nothing else needed after that.
We've just set up our CI in it (set it up as a Gitlab runner), it seems to work fine. To add more complexity, it isn't even a native iOS app but Nativescript. I think we use it to make the Android builds as well.
For $475/month, I hope you're able to use it for more than just iOS builds.
I know I'm too hobbyist- and small-business-minded for lots of folks on HN, but that monthly fee is a mind-boggling non-starter for me. I know that cloud services are never the cheapest option and I don't want to come off as a skinflint, but AWS' Mac pricing is just absurd. Two months' rental pays for the machine outright (three, if you upgrade the RAM or storage). I wouldn't leap into running a public-facing service on a machine parked in the back corner of an office somewhere, but it's not a big deal if your CI/CD machine goes offline for a few minutes if power or data connectivity stumbles.
I've worked for a startup where we begged the IT folks to just buy us an M1 Mac Mini to stuff in the closet somewhere, or at least sign us up for Mac Stadium or something, but it was borderline impossible to convince them to do that.
Talking to DevOps folks to spin up two dedicated instances on AWS? I had access within 10 minutes.
I think you must have misread GP's comment. They said "for comparison", and I think you read "let's pop the champagne". I for one found the comparison appropriate and interesting.
Whoever flagged my adjacent comment, “applaud” means praise. I applaud the person who downvoted my bad joke. I was sincerely agreeing with the downvote of my own comment, not objecting to the downvote. I will however object to being moderated for agreeing with being moderated.
I’ve been developing with Xcode since at least 2005 and I still have, for some reason, never gotten used to this. It’s only autocorrect that saves me, I always instinctively type it with a capital C. Weird.
Apple took the first steps to an AWS competitor in 2010 when it started working on phone CPUs.
Apple is very unlikely to build a “general cloud” offering. This is built and sold on differentiated services (eg BigQuery, Lambda, Kinesis), not on undifferentiated compute units (ie Apple Silicon even if it is slightly cheaper for the raw hardware).
Meanwhile, every time a developer uses local inference with CoreML, that competes directly with AWS’ revenue.
Apple’s “cloud” offering will be hosted in people’s pockets, powered by electricity consumers pay for, and hardware that Apple sells for a fat profit. And they will keep empowering developers to move more compute over to “the client”.
I think that IF they were to do any kind of cloud offering, it would be services for apps - storage like Firebase, push notifications, analytics, in-app purchase management, that kind of thing.
My guess, they’ll contract this out to a player like Cloudflare (like with iCloud relay).
e.g. I can see Apple building a framework for “isomorphic” Apps. Where the front end in SwiftUI and backend in SwiftStateful (a hypothetical framework for permissions/auth and connecting to cloud databases) compiled and deployed to CF Workers or some other edge deployed service.
I think they might even take this one step further and make some future version of MacStudio+WiFi that downloads and executes CFs Workers. If they went this route, it’s unclear if they’d need or want a partner like CF just to deploy and cache the workers.
Disclaimer: I have an investment in Cloudflare. I have no real idea about anything really.
Apple Silicon is so much more efficient on the desktop, and an AWS competitor might make it worthwhile to consider using aarm64 containers end-to-end. That would be amazing.
I'm not sure what I'm missing, but don't most cloud providers have ARM instances these days? We've been running most of our stuff on Graviton processors on AWS for some time now and it is a nice cost savings.
It’s not just a matter of ISA, Apple’s CPUs are significantly more performant in a number of ways compared to other ARM CPUs on the market at the moment.
The pricing is in compute hours, which means that their app-integrated CI/CD offering directly competes with offerings that require you to purchase your own retail-rate AWS EC2 &co compute hours.
That sort of raises the question: What does Xcode Cloud run on?
You would assume macOS as the operating system, but is that manageable at that scale? Maybe it runs on Linux and cross-compiles? Apple do run their own data-centers, which I assume all run Linux. If there was some headless macOS version and data-center wide management framework for it, I suspect that we would have heard about it. If the Xcode Cloud runs on macOS, does that mean that Apple have some rack mounted servers based on the M1/M2 processors?
Folks at e.g. MacStadium has been managing Mac minis (running macOS) at scale for a very long time. AWS also entered the space ~2 years ago. Of course Apple can do it themselves, and more efficiently.
> You would assume macOS as the operating system, but is that manageable at that scale?
Sure, it's a unix system. You can go far with SSHing into a machine and running some commands. Also, they only very recently discontinued MacOS Server (https://support.apple.com/en-us/HT208312)
Hardware-wise, it's either a battery of Mac Minis or Mac Pros, or maybe they've made custom hardware so they can put Apple hardware in a blade server form factor.
Darwin is headless. But maybe they're running asahi, although I doubt it. To run nodes, you don't actually need a complete distribution..
All the cloud providers create custom rack servers and even silicon, so why wouldn't they have rack mounted Mx boards? Also, the Mx gives you a lot of power for per watt. Perfect use case of a DC.
They have built a few datacenters around the globe.
They’re spending 10B between 2018 and 2023 to build datacenters in the US.
They’ve been a big customer on all cloud platforms (learning). The last contract with aws is worth at least 1.5b (300m/year but growing since 2018) and ends in about 1.5 year.
Seems like a good place to save billions, and make some more by offering cloud services on efficient systems.
And they've been hiring a lot of infra people since 2020
> Xcode Cloud is a continuous integration and delivery service built into Xcode and designed expressly for Apple developers. It accelerates the development and delivery of high-quality apps by bringing together cloud-based tools that help you build apps, run automated tests in parallel, deliver apps to testers, and view and manage user feedback.
This requires xcode, which requires a Mac as far as I know.
Why would you? I'm of the opinion that instead of trying to fight the system you should work with it, take the path of least resistance, and work on the best solution for the problem.
Tangentially related, in my opinion, native apps built in the tooling offered by the phone's manufacturer (xcode or android studio) will always be superior - to the end-user - than any cross-platform compromise. I'll admit that e.g. react native may have a better developer experience, but you don't build apps for the developers, right?
Xcode cloud requires you let Apple handle code signing automatically so you don’t have to do it locally, although obviously you still have to have a paid account. Additionally as others have mentioned this can push things to TestFlight for you.
If only. Apple's licensing terms require you to keep the instance for at least 24 hours[0].
[0] On the Scaleway checkout for the Mac Mini M1, at the bottom: "As required by Apple License, you must keep this Instance for at least 24 hours. You will be able to delete it only after 24 hours.".
I do wonder how they're implementing this. Are they also building Mac Mini farms or are they making exemptions from their ToS for themselves like so often to get around that and be able to run their service more efficiently than their competitors?
It feels like something that may or should be prevented by some laws.
Is it really an exemption from the ToS for them to run their own operating system on other hardware?
For one thing, it would still be "Apple-branded hardware" if Apple just puts an Apple sticker on it, so would literally be compliant with the same ToS they offer to everyone, but even if it wasn't based on that technicality, they reserve all other rights to their IP, so I don't see any logical or legal reason why they couldn't either make a version of Xcode that ran on an alternate OS or run macOS on other hardware.
>or are they making exemptions from their ToS for themselves
Err, allowing it to your self, is not an "exception from their ToS". The ToS, any ToS, only applies to third parties you provide a service/product to. You're free to do whatever you want with it yourself (within the general law of the land).
It's the same reason someone can't "violate" GPL by giving their own code, they wrote themselves, under a closed license as well, or even stop providing new versions under GPL altogether...
It is pretty telling that they've deliberately made devs unable to build Apple software on non-Apple hardware, though. I've already ground my Apple tree axe down to nothing and quit being an iOS app developer; fed up with their antics.
I mean they definitely can (and do) enter in to legal agreements with “themselves”. Many companies do, especially when it comes to licensing (even Subway does it).
It’s one of the most common methods for shifting income to other countries where the taxes are lower.
On the surface, yes. That’s exactly why it’s legal. However, from another perspective it’s the same company.
Let’s take the Apple example:
Apple created Apple Sales International and Apple Operations Europe as companies that own the intellectual property that Apple uses to create it’s products.
They did this because when they make 1B profit on 10B sales (let’s pretend for the sake of easy math), they would normally have to pay tax on that 1B but instead they can say “Our agreement with Apple Sales International and Apple Operations Europe state that we must pay “them” 1B in licensing fees for these sales. As you can see, we have no more money left to tax.”. Since Apple Sales International and Apple Operations Europe are subject to different tax laws they can pay little to no tax at all.
Now: Are those separate legal companies? Yes. But when it comes down to it, are they all the company we think of when we say Apple? I would say yes.
Really good question, I think someone will get their hands dirty and find a way to see on which hardware it’s running. Maybe through time correlation, that 2 test are running on the same hardware and reverse the power of the Hardware.
They have public documentation[1] about running macOS in a VM, so maybe they’ve let that go?
The parts of their ToS you are alluding to mostly talks about it being against ToS to run macOS on non-Apple hardware and since Apple makes chips now it’s very possible that the entire Xcloud service is running on Apple hardware.
My understanding is Apple uses Linux a lot internally for server stuff. Wouldn’t surprise me one bit if it was just Linux machines running LLVM and their other tools.
Perhaps the stuff runs on MacOS in VMs for the best compatibility, but I’m not sure that’s strictly necessary.
The iPhone apps where already cross-compiled from AMD64, before the switch to the Apple Silicon. It might not take that much to do the compilation on an Linux server, regardless of the underlying hardware.
There is something weird about a company that makes it's own hardware and operating system using something completely different in their datacenters. However I don't think that macOS have the tooling required to large scale installation required for something like this.
If you’re going to complain that Xcode Cloud is unreliable, it’s probably best not to suggest GitHub Actions as an alternative, it doesn’t have the best track record for reliability itself.
Businesses? I'm thinking it's something a team of developers would use. There are a ton of project on GitHub that uses various CI/CD tools to build package, rather than letting a random developer build an distribute a new release. Similarly a company might want to use this to test, build and release software. Checking that patches and updates from any number of developers can be merged and verify that all tests still passes.
If I understand it correctly, it would also mean that use Xcode Cloud to release an application into the App Store. Then no single developer needs access to submit new versions.
Say you have a 6 or more developer team working on an app. Do you really want everyone to be able to create production builds? Or do you really want to rely on one guy having the production certificates?
What if you've outsourced your app development; do you really want random developers spread across the world from having the ability to make production builds?
Anyway, there's more authorative sources on the internet about "why CI" than some guy (me) in a comment section.
Shouldn’t folks on iOS at least be able to access XCode Cloud