Seems that once the event is added the attendee appears, so this is definitely a bug.

Your summary does not cover all the edge cases I’m aware of. I’m not going to post all those details here because a) I just don’t have time to test them all, b) the expected behaviour has always been that described in Matt’s post, and any variance from that is, from Apple’s perspective, a bug. While I understand why technically this might be undesirable and difficult, from a product perspective Apple has been pushing standalone apps for the Watch now, and some use cases are just impossible without hacks like polling or a companion iPhone app, such as messaging applications. I was curious if things like Facebook Messenger stopped working but then realized it uses the classic iPhone connection to function. Is there any alternative besides polling for this kind of need (to be able to receive a message asynchronously), or is the suggestion that this kind of use requires an iPhone application to handle all the network?

@eskimo thanks for the reply. I see the point, but this is a very big problem: this feature was documented as supported and worked perfectly fine. This fix has two problems: applications that were published and approved by Apple (which I assumed vetted every SDK API call in the code) are now broken with no easy fix besides implementing polling (my case, which is much worse for the user than a proper WebSockets connection); and the error it reports is completely misleading, instead indicating the device isn’t connected to the internet. I’ve seen some other evidence of people facing problems with this on libraries such as Firebase, which is used by a lot of companies.

@meaton can you clarify why my app was approved and ran perfectly fine from watchOS 7 until 8.7 using WebSockets? My entire app foundation was built relying on that functionality which only stopped working on watchOS 9, and the documentation for NSURLSessionWebSocketTask still lists watchOS as supported. Now my app stopped working for users that upgraded and I’ll have to spend a lot of work to reengineer my application to use a polling mechanism instead.

Update: it seems they have resolved the issue on watchOS 7 beta 6 that was just released. My app is now opening fine.

Same issue on a Watch-only app: Exception Type:	EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note:	EXC_CORPSE_NOTIFY Termination Reason: Namespace WATCHKIT, Code 0x1 Triggered by Thread:	0

Submitted feedback FB8523784 (TestFlight installed watchOS App crashes on launch) with sysdiagnose and one of the crash reports for my app. Hope this helps solve the issue.