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:
As someone preparing to transition from C# to Swift dev, async/await was a big missing piece. I’ll be curious to see how quickly the ecosystem picks it up as I move forward on my journey.
My experience interacting with teams and devs targeting Swift is that when Apple says “jump” you jump.
What do people already using Swift in production think?
I'm trying to figure out where Swift is going. I maintain 3 relatively complex apps in it. When I first started coding on iOS, it was objective C. Objc was a poor mans Smalktalk, and when that didn't scale you did some inline C. Being quite familiar with Smalltalk and C, I was comfortable with this two basic computing models (everything's an object OR pointer/stack machine), I just had to do the Frankenstein dance of knowing when to employ how much of which.
With Swift, I have a hard time getting a feel for what the unifying gestalt of the language is supposed to be. It's a better C! It's objects! It's functional! It's typesafe! It's protocols! It's async! It's closures! It's a better C++! It's modern! It's a systems language! It's a scripting language! It's for UIs! It's actors! It's declarative! It infers things!
I get stuff done with it (obviously) and it's capable, but the effect has not been "it's a bird, it's a plane, it's Superman." It feels like some sort of anime shapeshifter caught in a cycle sometimes. Or a bogart.
I keep hoping these are growing pains, intermediate steps, with a "long game" characteristic of Apple, but I'm not seeing it yet.
Kotlin seems to be following a similar path, just a few steps behind in some places, and a few steps ahead in other.
I worked with Swift extensively for a year and a half, and I absolutely adore the language. I think it does a lot right while avoiding more of rust's complexities (I am a rust n00b, so grain of salt).
The problem with Swift (as of like 1.5 years ago when I stopped using the language daily) was its ecosystem. Swift package manager wasn't really used (at least for iOS apps), there was no real decent ecosystem outside the xcode world (no langserver, some server-side swift abstractions).
I think Swift would really thrive if Apple were to give it some room to breathe in the open source community, but until Swift decouples itself more from Apple's own needs, I couldn't imagine using it for anything other than iOS development.
Two of my favorite languages are Swift and Kotlin. I basically always choose Kotlin, but I would actually like Swift more if it was supported more outside of Apple.
Swift has the benefit of actual value types, no GC, and IME it's much faster. But it only runs on Apple's OS (technically there's support for Linux but people say it isn't good). Kotlin has access to all Java packages and runs on the JVM, and with Kotlin multiplatform JetBrains is trying to make it run on almost anything.
JetBrains will discover the pains of embracing multiple platforms.
Outside Android, Kotlin will always be playing catch-up with platform features, having two ways of doing the same thing for features introduced before the platform went their own way, FFI that only goes one way, the native variant is being redone due to the clever idea of being originally incompatible with JVM memory model, it is officially a way to sell InteliJ licenses.
Every design decision has tradeoffs. RC has its own significant upsides, like deterministic deallocation and a much lower memory floor for preventing world-pauses during tracing.
And possible stack overflow or freezing applications, when a domino effect of reference counting reaching 0 happens, and dealloc functions weren't properly written.
There is a Herb Sutter talk at CppCon about the downsides of reference counting.
Basically the solution to those problems is to make use of hazardous pointers or deferred destructions on background threads, which are a kind of lightweight tracing GC.
I assume the grandparent was talking about how, as soon as the last reference to a refcounted object goes away, the object is deallocated. Pure Swift follows this rule though Objective-C code may not always do this due to things like autorelease pools.
Async await is the mistake of the decade. Not the concept of concurrency but the function coloring approach. See previous discussions for why this is such a bad idea. In short: concurrency belongs on the caller side, not the callee side. Go does it right, most others follow the dark path.
I still don't understand why I'd want to use async/await in a mobile/desktop app over something like Rx (Combine). Is there a good rundown on when to use one or the other?
Yes but my question is more about what tradeoffs should I be looking for to decide which to use. There does not seem to be a simple way to bridge the worlds, so deciding early is probably necessary.
From what I'm gathering I should stick to Rx (Combine) when I have multiple related tasks or want to fire off changes in response to events, whereas async/await is useful for one-off asynchronous tasks like most web requests? I'm really not sure.
also interested in async vs combine, but i’m the other way around - unless you want to fight for rx programming i see Combine being in a very weird place. it looks like existing Foundation stuff will be easy to change to async, and for teammates without rx experience Combine can be a big mental model shift. plus Combine doesn’t compile on Linux, which is a big deterrent for me when thinking about how I might want to approach a Swift command line app.
We build a lot of REST based apps and are very, very excited to transition our internal networking framework to async/await. Currently we use GCD which can lead to a nightmare of closures as well as a lot of ugly indentation.
The @MainActor is nice. It was always bewildering to me that we still had put UI operations on the main thread by hand. I still don't get why we need @MainActor. The compiler should do some sort of flow analysis and do the right thing.
I've been using Swift to build the server-side of NLUDB.com and async/await is the biggest item on my wish list.
Maybe I just haven't learned proper EventLoopFuture-style development style, but you really seem to get stuck callback hell, similar to the early days of NodeJS. It's a bear on code readability.
Re: the sibling comment about Combine -- I've heard great things about Combine but AFAIK it's still part of Apple's platform-specific layer atop Swift so the small group of us using Swift atop Linux can't use it (yet?).
No new 16” MBP announced. No multi display support in the M1 MBA/P. And my 2014 15” MBP has been phased out of supporting Monterey. Personally, this WWDC has been a bust for me. I skipped the 2016-2019 MBP and was hoping for a replacement to be announced. Alas, it was not meant to be.
Well, it is the developer conference — the focus is always on software. Hardware announcements at WWDC are never guaranteed.
I think the next typical time of year they do hardware announcements is fall, like around August, though that doesn't happen every year. And then iPhones are almost always in September.
Well, it is the developer conference — the focus is always on software.
I read on one of the rumor sites that 65% of WWDC keynotes also introduce hardware. I don't know if that's true, but it could indicate why so many people thought new computers were coming today.
2013: The "trashcan" Mac Pro, AirPort TimeCapsule/Etreme
2017: iMac Pro, HomePod
2020: M1 MacBook Air and 2-port 13" MacBook Pro
Hardware announcements do happen at WWDC, but there's no real pattern to it besides, perhaps, having a Mac available that developers would be interested in.
Post-M1 MacBook Pros (and bigger iMacs) are almost certainly around the corner, but presumably they're just not ready now.
You are correct. I was going off someone else's list and didn't double-check that. They announced Apple Silicon at WWDC2020, but didn't actually announce hardware!
I don't know what the actual breakdown is, but since ~iPhone there's almost always if not always been a hardware announcement at WWDC, even if only because the iPhone is a hard schedule and Apple has a limited number of events annually.
Well, developers need a hardware to develop on :). While hardware might not be the focus of the WWDC, the big MB Pro routinely would be refreshed ahead of the WWDC, as this is a very popular hardware for many developers. That they didn't do it this year is especially annoying, as it is still waiting for the transition to ARM. Apple wants to have developers develop for ARM, but only offer the Mini or the Air. They definitely are great machines, but Apple should really hurry to get their higher end offerings transitioned to ARM quickly.
Apple Silicon (M1) was announced at WWDC '20. It's reasonable to believe there would be another major hardware announcement at WWDC '21.
And as a developer who has used 2 monitors for almost 20 years, actual multidisplay support, and not a DisplayLink hack, is a reasonable demand. Even at a developer conference.
But the hardware with M1 in it wasn't announced until the Fall event. So the comment about "new MBP" wouldn't apply. The only reason M1 was announced at WWDC is because it requires work from developers. New MBP doesn't require 6 month lead announcement for developers.
Agree, though I think it'll be shipping well before Christmas (though not in July, as some have speculated... if it were gonna be ready in July, they would have announced it).
I expect the new MBP will have the M2, which should be available in quantity soon. Besides the (presumed) hardware improvements, the M2 will be a marketing-friendly way of differentiating the MBP from the MB and MBA, and persuading people to pay a premium for it.
This is why there’s not much sense to paying attention to the rumour mill. Would you have felt such disappointment had you approached it with a blank slate rather than via shady rumours?
If you do go in for rumours, Mark Gurman and Ming Chi Kuo are pretty much the only two reliable ones. Neither called for macs this wwdc.
I think there is a decent chance of a new 16" being released around the time of Monterey.
Based on the lack of an M1x (just an M1 with more cores) showing up by today, I suspect that it doesn't be exist and probably never existed. At this point Apple will go straight to the M2 (next gen cpu/gpu archtecture).
Because Apple has a very regular release cadence for their A-series SoCs of about 1 year, I don't think we will see the M2 launched until closer to the A15's expected release date of September/October.
They shouldn't need to stockpile the M2 as much as they need to stockpile the A15, so I'm hoping for an August launch.
It's so nice to get APIs designed for Swift, they feel much nicer.
I was expecting a SwiftUI replacement for NSTextView/UITextView that allowed using NSAttributedString(s) (or better yet the new AttributedString), but I can't find anything. Am I missing it?
It felt like a big Sherlock keynote as Apple seems to be expanding into our homes, cars, access systems, cross-platform video, identity verification, ad publishing, email sanctity, internet anonymity and so much more. Maybe their developers were actually more efficient being WFH.
Most of us will embrace these changes but it will leave a bunch of point-solution vendors in the dust eventually. Or they will adapt.
I just watched the 24m Verge edit, and I didn't notice any instances of this.* Are there, say, 3 examples of single-feature companies who will be "Sherlocked"?
(*If I had to stretch, iCloud+ Private Relay could take the place of a VPN for some people.)
Xcode Cloud is the result of Apple's purchase of BuddyBuild from a few years ago. It's more competition to CI services like Circle and Travis (and any others that support Mac builds) than straight up Mac hosting like MacStadium.
if FaceTime really does land on Android and Web I would say it’d be possible that Zoom got Sherlocked today too. given their black eyes around privacy Apple’s offering seems a lot more appealing than Zoom’s imho
i feel like making breakout rooms at this point is not as hard as making FaceTime for web/Android. they can basically pick and chose the features they like at this point.
I think my own app, Unreplied, just got Sherlocked actually. It never had a huge user base but it would let you view unreplied iMessages (as the name implied). On to greener pastures I guess!
Swizzle UIApplication.sendEvent to intercept the pencil touches sent to the WKWebView’s gestures and redirect them to an overlaid, disabled PKCanvasView’s intercepted gestures; call the original gestures’ touchesEnded. Cache the gestures in a weakToWeak NSMapTable for successive events. contentSize, contentOffset, and zoomScale syncing is trivial.
I have it working even without swizzling using custom drawing engines. The issue lies within the dynamic and changing nature of the web and cross-device/size display unless you imagined it as one-off raster drawing.
I've been tracking the Actor implementation in Swift and was wondering if they were going to go full on distributed but so far it looks just to be a localized concurrency model versus distributed.
I could potentially see Swift becoming a competitor to Scala/Akka if they can advance their Actor implementation into more of a distributed system. Apple did hire one of the core Akka maintainers, so the skills are there.
There has been serious talk on the Swift Evolution forums about distributed actors, so this may be something that Apple adds in the next couple of years. They haven’t given a timeframe that I know of. Or a promise that it will definitely happen.
How would that work as a competitor to Akka distributed cluster sharding? That would require swift running on server side instead of scala/java, right?
The changes feel exciting because for the first time in a very long time most of the announced features are coming to MacOS, too.
But so many of them are minor (background blur and noise reduction in Facetime, really?), a catch up to competition (almost anything related to photo and text), or features for features sake (new Safari design).
How many of these will be badly designed, break HIGs and accessibility, (re-)implemented in Catalyst and abandoned a year later?
Good. Plenty of time for other developers to move to Apple Silicon before Apple starts to push them. Probably they will give a product refresh to their current line up with an M2 chip later.
Would rather wait a year for the Apple Silicon ecosystem to mature than to jump all in now and wait for the software bugs to be fixed for a year so I can do my work.
I got the 13 and am really happy with it compared to my 2018 16". I was going to wait but I figure if I sell and upgrade within several months I'm not going to be out by that much.
Not that anyone is officially planning to operate economies, travel, or society on them or anything, as that would be a conspiracy theory. ShazamKit appears to be the foundation for general search for sound. Searching for someones voice can't be far off.
Imagine predicting that we would need to develop countermeasure technologies to retain our privacy.
Everyone who matters to the government already has this information and more. At least with these new HealthKit features we can act on our own information instead of being separated from it.
Also, if I was a business owner, I would 100% want some sort of vaccine verification system if I decided to lift the mask mandate. Why would I want my employees or other customers to get sick when the cure is available for free?
They did. In many places you have to get the proper vaccinations in order to play on a sports team, attend public school, attend college, work with animals, work with children, etc. That's why I don't understand why the COVID-19 vax is a big deal given that we've had vaccine requirements in play since the 50s.
Yea but no business ever checked or cared. You could go in to Wal-Mart with smallpox and nobody would have said a word, let alone required a mask.
I don’t get the Covid-19 anti-vax stuff either (if you go far enough left you end up on the right), but I also don’t get the hysteria around people all of a sudden trying to require vaccines or masks when you didn’t care whatsoever less than two years ago with many other virulent diseases ranging from the flu to streptococcus and others.
I always feel like I’m caught between two groups of crazies. On one hand you have people who didn’t know they were anti-vax until Donald Trump said so (good god…) but then on the other hand you have people who are hell-bent on wearing a mask in conditions far less or at worst just as dangerous as two years ago. Like can everybody chill out?
People will probably calm down about it as the years go on and the new vaccines are proven to be safe and effective. I think it's just the novelty that scares people since there's brand-new tech involved. Compare to vaccines like MMR that have been around for fifty years where even the falsey autism claims couldn't scare most people off because the results speak for themselves.
Which is why it's important to compel everyone that can get the vaccine to do so, so that we can protect the minority of people who have legitimate reasons for not being vaccinated and will always be in danger of being exposed to the virus if community transmission is ongoing. Once enough people in a group are vaccinated, the odds of the virus spreading from host to host go down to minuscule and essentially irrelevant levels.
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)?