Highlights of new technologies introduced at WWDC 2021 | Hacker News Reader

Highlights of new technologies introduced at WWDC 2021

developer.apple.com

171 pointsAustin_Conlon131 comments

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)?

Their offering is for upstarts who don’t have any existing devops infrastructure

> 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

Does it matter? As long as you can run gcc/Python/node/whatever you can always build software for macOS.

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

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

https://eclecticlight.co/2020/11/25/macos-has-checked-app-si...

How about launching those applications totally privately — no network requests at all?

Spoiler: `sudo spctl --master-disable`. Luckily we're still allowed root on ARM Macs for now :)

Yes, I know. My argument is that they don't want to use it that way, not that they can't.

I don't think it's possible to know who wants what or who even contributes to such a decision today, much less who will in the future.

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

But then why make iPads so insanely, ridiculously powerful?!

To run a simulator on it

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.

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.

This feature is most likely just a wrapped version of buddybuild, which Apple acquired in 2020.

> You can't integrate it with your existing CI/CD

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?

Well past a certain scale you almost certainly have infrastructure that isn’t an iOS app.

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?

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

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.

> Xcode Cloud requires you to push your repository to their servers

What do you mean? It says it supports BitBucket, GitHub and GitLab.

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:

https://developer.apple.com/documentation/xcode/configuring-...

> This step is necessary because Xcode Cloud uses your personal SCM account to monitor the Git repository for changes.

From that point on, Xcode Cloud polls/monitors the repo for changes, but it does so in a way that doesn't integrate with CI/CD.

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.

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

Agreed and this has been true forever.

The incredible amount of work that has to go into https://github.com/fastlane/fastlane/releases always impresses 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.

Which is how a large majority of native apps on iOS are developed.

Not everyone needs 100 team members for a messaging app.

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.

Most of those already have their own in-house solution,

https://uk.pcmag.com/gallery/130620/the-best-iphone-apps-for...

I'm not sure what you're saying with that link. Can you clarify?

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 target demographic of Apple is developers using Swift, Objective-C and native OS APIs directly.

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.

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?

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.

Then you have two problems...

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.

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.

Swift is currently reference counted, which is more or less GC but worse because it’s not tracing/cycle-detecting.

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.

How is RC deallocation deterministic?

Besides which I don't want to have to keep track of weak references, at that point I would rather just have a full ownership model: https://github.com/apple/swift/blob/main/docs/OwnershipManif...

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.

Sure but that's nothing like deterministic destruction, where I can tell you the order that things will be deallocated just from looking at a block.

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.

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.

No langserver? SourceKit LSP has been around for a while now: https://github.com/apple/sourcekit-lsp

Yes, async/await will be terrific. It's been a long time coming though; I've been expecting it 'real soon now' for over 3 years: https://gist.github.com/lattner/429b9070918248274f25b714dcfc...

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?

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.

async/await are trivial to understand and use.

Anything Rx beyond the simplest of examples? Nope.

Rx is very powerful and can be difficult to understand at first, especially if you haven't done a lot of programming in functional languages before.

I'm not trying to argue about that though - I just want to know under what set of circumstances I should prefer async/await over Rx and vice versa.

I wondered the same thing actually. After I read about async await I thought “Well, what’s the point in Combine then?”

It’s your choice - you want Rx - you do Rx. Everyone gets something.

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.

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

love Swift, largely agree with most comments here and feel like async fills a big hole.

> when Apple says “jump” you jump.

just not with the betas

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.

A common trait to any multi-paradigm language, I fail to see the problem.

In fact, you could state the same complaints against Turbo Pascal on the MS-DOS days.

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.

Interesting argument, do you have any links to said discussions on this topic?

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

Appreciate it!

> Automatically build, test, and distribute your apps with Xcode Cloud to verify changes and create high-quality apps.

I'll still count this as "called it" since 2020 disrupted every timeline :) https://news.ycombinator.com/item?id=21942520

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.

Would need to see exactly what new hardware has been announced at WWDC.

For example, it would make sense to announce new CPU architectures like Intel and M1 since the transition heavily affects developers.

But incremental improvements to existing hardware, not so much.

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.

2012: The original 15" MacBook Pro

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.

M1 air was not announced at wwdc2020, it was announced in November 2020.

https://www.apple.com/newsroom/2020/11/apple-unleashes-m1/

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!

(Extra embarrassing because I own an M1 Air…)

I think they used to announce new devices at WWDC until a few years ago when they switched to a holiday release schedule.

There really isn't a pattern. Basically if they have a pro Mac ready to go or something that needs developers to prepare, they'll announce it at WWDC.

2021: nothing

2020: M1 Macs

2019: Mac Pro

2018: nothing

2017: iMac Pro, HomePod

2016: nothing

2015: nothing

2014: nothing

2013: Trashcan Mac Pro

2012: MacBook Pro 15" (first retina Mac)

2011: nothing

2010: iPhone 4

Considering the fate of the Trashcan Mac Pro, HomePod, and iMac Pro.... maybe it's OK that they didn't introduce any new hardware at WWDC this year !!

That being said, the iPhone 4, Retina MacBook Pro, and M1 were transformative - nothing was the same afterward.

(Probably not coincidentally, they also all required major software revisions!)

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.

Apple Silicon is big breaking change for compatibility so it's natural to be announced at WWDC. They just announced DevKit at the time.

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.

I expect they're just not quite done with the new 16" MBP, and are saving its reveal for Christmas season.

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.

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.

The year is still young.

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.

Also Apple's patent info is useless source to predict new product despite it's official. But leak from Xcode binary is pretty trustworthy.

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.

WWDC's are about 50/50 on whether they announce new hardware or not.

Likewise, hope to see one released this summer, and one worthy of replacing my 2015 15"ers

The real disappointment is the iPad. They didn’t announce that they were lifting the 5gb limitation which renders 8 and 16GB of RAM pointless.

That’s before we mention how overpowered they are and not introducing even the future possibility of actually pro apps at the developer conference.

I like the Foundation/Markdown/AttributedString addition - i’ve seen so many bad implementations at my work copied from around SO and such https://developer.apple.com/documentation/foundation/attribu...

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?

there's a session tomorrow on TextKit2 - maybe that has what you need?

https://developer.apple.com/videos/play/wwdc2021/10061/

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.

https://en.wikipedia.org/wiki/Sherlock_(software)

> Most of us will embrace these changes but it will leave a bunch of point-solution vendors in the dust eventually.

They fired a lot of shots at a lot of people tonight. I, for one, am very excited.

> It felt like a big Sherlock keynote…

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

I could name a few:

- 3rd party AirPlay receiver apps (you can stream to Macs with new macOS)

- Universal Control looks very Synergy-like (I don't know of an iOS alternative, but surely nobody is going to try compete with Apple now)

- Xcode Cloud - arguably competition to rent-a-mac services like MacStadium

- SharePlay probably will replace SyncTube for a lot of folks

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.

To be fair, it's both because you can't really run a CI for Xcode builds on anything besides Mac hardware.

> arguably competition to rent-a-mac services like MacStadium

More like Corellium since Apple tried to buy them, failed, then tried to lawyer them to death, with the DMCA claim afaik still undecided:

https://twitter.com/mdowd/status/1193299900408090624

https://arstechnica.com/tech-policy/2019/08/apple-sues-virtu...

And I just bought a license for AirServer last week

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

Zoom has a few features that are incredibly useful/needed for some people (e.g. breakout rooms) and afaik FaceTime doesn't have them.

It will require some major effort from apple to overtake it, it's not just being cross platform

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.

sure, but there's plenty of videoconferencing software who still don't support it.

And there's more! Dial-in, guest access, persistent rooms with/without password, organization-level restrictions, automatic recording, cloud upload of videos etc..

It's not a technical problem for Apple to do everything Zoom does, but it'd be a massive product shift to try to it.

It looks like Apple will have a native package tracking widget (at least for iPad), which will kill likely other package tracking apps.

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!

> Maybe their developers were actually more efficient being WFH

Definitely! You can't come up with something like that in the office, literally impossible.

No pencilkit improvements :(

Getting pencilkit and a webview to work properly together has been an impossible task.

I haven't been able to find a way to draw on a WKWebView, while synchronizing both scrolling and zooming of the pencilkit and WkWebView.

:( there's so much potential there that I just can't extract.

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.

Hmm I'll give this a try. Do you have this open-source so I can take a look?

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.

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?

Yeah, they have sever side Swift (https://swift.org/server/)

The basics, to put it on a nice way.

It is as useful as Objective-C with clang on non Apple platforms.

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.

Craig’s enthusiasm in the keynote is contagious. Makes me really excited for the changes this year!

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?

No new Apple Silicon 16" MacBook Pro announcement made me sad. Continuing to wait.

Maybe they are affected by the parts shortage.

Me too. My 2016 16'' MBP really needs replacing, and I'll be damned if I will work on a 13'' for the next couple of years.

No monitor?

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 hope the game developers hurry up and wake up. Basically my entire game library still has zero M1-compatible versions.

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.

HKverifiableclinicalrecord is SMART Health Card support for vaccine passports.

https://developer.apple.com/documentation/healthkit/

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.

> Enabling social interactions

Impressively versatile wording

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?

Not everyone can get the vaccine though, a small number of people are allergic to the ingredients as one example.

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.

The question I have is why didn’t people hold this opinion before COVID-19?

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.

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.

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?

Reply on news.ycombinator.com