25 hours of Xcode Cloud now included with the Apple Developer Program | Hacker News Reader

25 hours of Xcode Cloud now included with the Apple Developer Program

developer.apple.com

81 pointsCharlesW65 comments

This is actually pretty awesome. I've been using Xcode Cloud to build and submit builds for my apps since it was first announced during WWDC 2021. As an indie developer, it definitely helps a lot to not have to spend absurd amount of $ on third party services and also frees my time to do other things.

As a solo developer, I haven't found any use for Xcode Cloud. I just build my app on my laptop and submit to App Store. It just takes few minutes. How would Xcode Cloud make things easier?

Of course, it could automatically build and test my app after every commit to VCS, but I build and test the app on my laptop anyway to see how it works, so I don't see any benefit.

>I just build my app on my laptop and submit to App Store.

I wonder how much longer that will be the case. Looking at the trends for pretty much all software I'd be surprised if Xcode doesn't end up completely in the cloud.

Their need to sell future (high-end) machines to developers should keep that from happening. Microsoft OTOH, may do it.

It is obviously for those who want to have CI approach.

You can build and deploy websites and services manually as well, however a lot of people choose to have CI/CD systems instead.

Right, but would you want a separate CI platform just for iOS? Maybe if you were only developing iOS and macOS apps it would be attractive. I'm also not convinced Apple will continue to support or how much Apple churn it will introduce.

It also doesn't have a proper web interface and Xcode is already one of my least favourite tools, so I'm not keen on the prospect of relying on it even more than I already do.

> Right, but would you want a separate CI platform just for iOS

You already don't have a choice. The iOS build tooling only runs on MacOS. So your current options are:

1. Run all of your CI infra on MacOS (literal insanity)

2. Have dedicated mac minis just for building iOS apps (waste of $$$ and additional maintenance hassle)

3. Use a build cloud (somehow even more expensive than option 2)

What I meant by platform is GitLab/GitHub/Teamcity/etc. You can at least use the same CI platform for all your builds, you "just" need some macOS runners/build agents to do iOS builds. Xcode cloud is another platform that basically nothing integrates with - an additional shit option to add to the existing pile of shit options.

I'll take the opposite position. A few weeks ago, I migrated my CI/CD pipelines from GitHub Actions to Google Cloud Build, which was a meaningful improvement for me. But I left my mobile pipelines on GitHub Actions due to the lack of MacOS environments in GCB.

I have not yet looked into the details, but this new Xcode Cloud free tier might be a godsend for me. GitHub Actions sucks, and their on-demand MacOS runners are crazy expensive. This will let me flip over to Xcode Cloud for Apple builds, save the $0.16/min I spend on GitHub Actions MacOS runners, and probably have a much better experience overall. The web stack gets built on GCB and deployed to GCP, and the mobile apps would get built on Xcode cloud and deployed to the App Store.

> separate CI platform just for iOS?

What else is there? For web things I already have some GitHub actions taking care of the work.

Github Actions totally has MacOS runners: https://docs.github.com/en/actions/using-github-hosted-runne...

Integration with TestFlight and AppStore submissions is the key. No need to manually set the build version. And no need to go through the steps on uploading the app. And I have all my personal apps on TestFlight and install them on my Mac via TestFlight, to make sure they are uptodate, I also have scheduled build every week to submit to internal testing on TestFlight.

Yup this mostly. After a "git push", Xcode Cloud takes care of building and submitting the test flight build. Even if it's just a couple of minutes, it quickly adds up (and also helps with context switch).

good for you to choose that cloud-only world - when it is no longer a choice, others have a real problem.

never tried xcode cloud, but judging by the overall quality and attention granted to apple developer tools, i wouldn’t touch it with a 10 foot pole.

Just the brand « xcode » itself is so damaged..

What's wrong with Apple developer tools?

Every now and then something annoying will happen, like the Simulator sucking all the resources for no apparent reason, Xcode crashing/declining to compile some SwiftUI View because the code is too complex and the download size of Xcode used to be gargantuan but all these are really annoyances and nothing catastrophic. Definitely not case of not paying attention to details, on the contrary - Xcode does lot's of small things to increase developer comfort, which IMHO is about paying attention to details.

What do you think it can happen if you let Xcode cloud access your online git repo and compile the project on their machines? What should I be worried about?

Never used Xcode as anything other than a dependency for other dev stuff and in that case it's huge, takes ages to install, doesn't clean itself after installation and easily fills 50-100 gigabytes with useless "simulators" that has no relevance for most.

> doesn't clean itself after installation and easily fills 50-100 gigabytes with useless "simulators" that no one seems to understand why is needed for most devs.

Not the case anymore, Go to Settings->General->Storage in macOS where you can manage the storage space. If you tap on the "i" next to the "Developer", you will be given option to delete caches, indexes, iOS device support(which can be huge).

Perform a sacred voodoo dance (you need to find its instructions somewhere under the sea, the map of the location is hidden in the highest mountains, you need to ask a big foot of its whereabouts). It’s very aesthetically pleasing though, if you’ll ever find it. Welcome to the wonder— Apple land.

Nothing sacred or secret, its under the menu where you manage your storage.

I was just mocking the way Apple hides some things in their interface, e.g. their ‘Search this page’

https://news.ycombinator.com/item?id=38625718

Interesting, based on this comment, I deleted ~20GB of simulators (~/Library/Developer/CoreSimulator). Thanks for that!

I can recommend the app GrandPerspective to find files like these sitting around.

Try build your swift packages with vscode, you'll thank me later. Integration with spm is so bad i could only find the path problem i had with vscode. Xcode would show me completely obscure message, probably because it was trying to do something smart that only partially worked.

Xcode is utter crap. It's sluggish, its window and history management is nonsense, it crashes every day, every new version brings its new batch of weird build errors.

Honestly i can't believe this company owns the whole stack down to the hardware and manages to release such a poor product.

There’s this hate for Xcode that I see popping up every once in a while, often times by non-native devs.

I honestly don’t get it. I’ve tried everything under the sun and Xcode is by far my favorite IDE.

It’s intuitive, fast and is getting more and more QoL improvements that are much appreciated.

Is it annoying at times? Yeah sure, there are some running jokes between me and a bunch of other indie devs, but it’s mostly in jest.

I can’t recall the last time I ran into an actual issue that ate up my time and was a showstopper.

Perhaps it’s a matter of preference, because the no 1 suggestion by the haters, VSC, is something I personally hate. Unintuitive as hell and yet another addition to the Electron Hall of Shame.

There was a time period when Xcode was truly awful: incredibly slow, crashed often, the syntax highlighter kept crashing so you’d be editing code with no syntax coloring forget autocompletion or diagnostics. I’m glad AppCode existed at this point because it was basically unusable.

I believe this dark point was when Swift came out, up to 2.0 or 3.0. They definitely rushed it and I believe rushed a lot of other features into Xcode.

But otherwise, Xcode in the early days was great, and Xcode today is great. I suspect most of the haters are remembering the bad times. Or maybe they have an old computer, and Apple software is known for being slow on older devices (“planned obsolescence”, I think Apple just adds bloat to their software when they develop faster hardware because they don’t notice). Or maybe they are complaining because Xcode is ridiculously large (it requires like 40GB free space to install) and does weird stuff when installing, there are probably issues you can run into with certain system configurations (particularly with, again, older systems). Or maybe we’re spoiled by good IDEs (even VSCode is fast despite being Electron, I still prefer JetBrains and AppCode).

The thing is if you're in the mobile world you don't have a choice.

If I could at least get the behemoth of xcode and supporting tools of my machine for an affordable price that would be a win

for what it's worth, you could very well build all your swift packages with vscode. The swift plugin is really good, and integration with swift-format makes it a really nice development experience.

That’s 25 hours a month which is going to be plenty to get new developers hooked on this.

I don’t really get why Apple’s pushing this (other than a cash grab). You can already submit builds to TestFlight/the App Store with GitHub actions.

A few months ago, my GitHub Actions iOS pipelines were failing ~50% of the time a few minutes into the run because half the MacOS runners didn't yet have XCode 15.01. At $0.16/minute, those pipeline failures cost me a lot of money. And I fully expect that sort of thing to happen again, because the executives making decisions about GitHub Actions seem to be taking their inspiration from the leaning tower of Pisa.

Is there an easy to follow guide for this? We use various templates to run our CI builds and tests in GitHub Actions, but I didn't realize you can push to TF and the store with it.

I’m guessing nobody was using it. I think Figma became successful (apart from being a good product) because it was free, so developers try it in their free time, and bring it into their company

I think the main goal of Xcode Cloud is to offer a first-party, out of the box solution for CI/CD. You'd be surprised how crappy (and expensive) GitHub's experience is when it comes to iOS and macOS builds.

One has to wonder how much of Github's subpar experience for it is down to mac market share not making it worth improving, and Apple's own strangehold on the hardware and "odd" licencing (I know that with AWS due to Apple, you are stuck with a minimum 24 hour allocation, compared to being able to spin up half a dozen Intel/AMD/ARM instances for a few minutes then terminate them and only get build by the second.)

Interesting so another unfair advantage for Apple themselves. AWS and other vendors can't offer per second or minute billing but I assume they're doing it for the 25h of credits.

Well, GitHub is certainly in control of their own platform and a problem entirely done by themselves. For example, not making pre-release Xcode versions available on their images, or by default selecting 1-year-old versions of macOS (and as a result throwing everyone into a side quest just to get started)... and ultimately charging 3x the regular pricing for this is absurd.

> charging 3x the regular pricing for this is absurd

macOS virtualization is pricey by Apple's design. This is not just a GH problem

Surely if Microsoft (this big corp, that happens to own a cloud) wanted to find a way for GitHub to offer a pleasant experience, they would have.

Arguably, they've done the best they can do without partnering with Apple directly. Are you suggesting that they should invest in hacking MacOS to improve the customer experience?

> happens to own a cloud

macOS hardware or virtualization is beaucoup bucks in every cloud. As I said, this is not just a GitHub (or Microsoft) problem.

I didn't know you could virtualize macos.

The license restricts you to only virtualize macOS on Mac hardware, and only 2 VMs per physical machine.

CI for Mac and iOS is a disaster. We manage builds and deploys for multiple languages, platforms and cloud providers in our CI system, the _last_ thing we want is another platform to check for Mac builds.

Well that's your choice of course. I like Xcode Cloud because it knows what I expect for building an app and gets the job done. I don't like systems that need me to fiddle with infinite number of config files before they can do anything useful for me.

That's fair. I think the problem for me is that there's no in between. We use buildkite, and _everything_ goes through buildkite. We compile native desktop apps, monolithic Kotlin web backends, deploy clients to multiple different app store like platforms, servers to AWS, and the workflow is the same. Click new build, wait, fill in the form.

That's just not an option for mac or iOS in the same way it is for Windows.

They've done very to promote it. No educational material, no community... just a handful of announcements.

Besides that, most companies already have CI pipelines in place for all their apps. Why would their switch?

There's a jarring in-IDE ad, which feels unusual for Apple

Rejoice, for the gods have decided to be generous.

Average iOS app build takes 30-45 minutes. You typically make 1-3 PRs a day, each of which need to be built. Let's say 3 PRs + 1 build after merging. That gives you about a week of usage every month so you'll still need dedicated build hardware or pay for their overpriced cloud.

Thanks, Apple! Now go make your build tooling cross platform so we can just run it on a linux vm like everything else, and maybe stop gouging the people who are providing value for your platform?

Never going to happen. Apple has been fighting any efforts that attempt to support building for iOS on non-Mac hardware.

I don't know why it matters so much, but it seems to matter to them. I doubt the little extra money they made back then from selling to developers would have mattered to them?

But like all tech giants, Apple is now refocusing on services rather than software and devices, so perhaps forcing all Apple developers into their build service is part of that effort.

It matters for them because their business strategy is utter and complete lock-in. If you don't want to submit to the apple religion they want you to gtfo.

Apple supports development on iPadOS now with swift playgrounds.

This step moves closer to a iPadOS Xcode solution for build, test and distribution. This has minimal demand on the iPad as long as the network connection is good enough.

Business acceptance of iPad is greater then that of Mac.

Looking forward to WWDC2024.

> Average iOS app build takes 30-45 minutes

That seems high to me. Where does that come from?

> You typically make 1-3 PRs a day, each of which need to be built. Let's say 3 PRs + 1 build after merging.

That also seems like a lot, at least for an individual, which is what this seems? (to me) aimed at. I haven’t used it, but 25 hours seems within bounds for reasonable for a month’s usage.

  > That seems high to me. Where does that come from?

it is high (and i agree too high imo), but many apps utilize a lot of 3rd party libraries that take a loooong time to compile (just off the top of my head, various "reactive" frameworks, realm, firebase related libs etc)

you might ask why not deliver binary libs to cut down the time, well that used to be easy with obj-c/c dylibs but swift doesnt have a stable abi outside of apple libs, so every new swift update requires recompilation and swift package manager doesnt have much in the way of caching binaries for dependencies in a ci afaik

Not just compile, but download. In addition to dozens pure-iOS projects (internal apps deployed to users), I have a couple of react-native codebases to support Android. Xcode Cloud spends more time downloading npm packages than anything else including compiling. Unlike other CI tools I’ve used, there is no way to Xcode Cloud to maintain a dirty executor or specify dependencies to skip this step. In addition, downloading dependencies fails so often that CI fails a majority of builds which have to be re-run which consumes more minutes.

I’m currently working with a client to convince them Jenkins on a Mac they own is cheaper and easier, working through the standard headaches of an IT department who supports thousands of iPhones and Windows machines but doesn’t want to support a single digit number of Mac just because Apple fights any attempt at cross-compiling from anything that’s not a Mac.

If you're downloading dependencies on every build then you don't have a repeatable build.

It is extremely high. Typically I’m dealing with less than a minute, occasionally up to 2 and rarely, when I’m dealing with heaps of dependencies perhaps 5, but 30-45 is just crazy.

If you're doing 3 PRs a day, I think it's reasonable to start to pay for CI resources.

> Now go make your build tooling cross platform so we can just run it on a linux vm like everything else

I don't think they need to go as far as this. We already maintain windows CI agents on my team as we build C++ apps with MSVC. But crucially, our builds only take 10 minutes from cache, we don't want to pay for 24 hours usage.

You can run Windows on commodity hardware. You can easily get a Windows VM billed by the minute. macOS is only licensed to run on Apple hardware (and will soon be impossible to run on a commodity x86 machine) and there are licensing restrictions that make macOS VMs on EC2 require a 24-hour minimum bill.

> here are licensing restrictions that make macOS VMs on EC2 require a 24-hour minimum bill.

Yeah, this is the killer. I don't mind paying $1/h for an M1 mac - our builds take about 10 minutes when cached, so paying $0.16 is fine. Even an hour's minimum would be totally fine - paying $60/mo to license it for 2h/day would be perfect. But, we're not paying $1/h with a 24h minimum every day. At that point, a Mac Mini is cheaper on month 1, so I have a mac mini on my desk.

> Average iOS app build takes 30-45 minutes.

That sounds too awful to be true. Roughly how large are these average apps in terms of lines of code? I assume that's Swift rather than Objective-C?

30 minutes build, i assume you mean including running extensive unit tests ? Otherwise 30 min build is insanely large.

building with full optimizations and lots of 3rd party libraries (esp if they are c++ or use lots of swift-generics w/type inference) can indeed take that long caused by lots of inlining, de-virtualization, static specialization, whole module optimization and static linking (or just linking in general)...

a comparable clean build with debug flags (no optimization) might only take a few minutes with incremental builds taking a few seconds or so, i guess thats why its tolerated...

the other thing is ci build pipelines are reaaallly slow so if you made the same build locally on your m1 pro its probably gonna take 1/4 the time as the ci (ime anyways)...many ci's are slow af....

Reply on news.ycombinator.com