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.
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.