My use-case is a framework that utilises #if os(...) because some symbols are not available across all platforms (e.g. views that inherit from UIView vs NSView). The @available parsing is useful, thank you for clarifying how that works. I will file a feedback with a more complete example.

This is explicitly not supported: You can’t send messages from a containing iOS app to your web extension’s JavaScript scripts. https://developer.apple.com/documentation/safariservices/safari_web_extensions/messaging_between_the_app_and_javascript_in_a_safari_web_extension

To extend in to the safe area you can use min-height: -webkit-fill-available;. Note that this will also extened in to the notch when in landscape so you may want to use the safe-area-inset-* env variables, e.g. padding-left: env(safe-area-inset-left);

At some point in the beta cycle this seems to have been improved and icons are now tinted and scaled correctly. The sizes I'm using are: 19px (iPad and iPhone menu 1x) 24px (iPad address bar 1x) 38px (iPad and iPhone menu 2x) 48px (iPad address bar 2x) 57px (iPad and iPhone menu 3x) 72px (iPad address bar 3x)

@Polyphonic This is a simplified example to be able to ask the question, rather than asking "here's my architecture, is it safe?" My use case is an object that has a public API that includes private(set) properties (where @Published comes in useful), internally the values may be updated from any thread, and Sendable conformance is required because the object is passed to an actor. Are you implying "this could create incorrect values" or does the unsafe nature of this extend to "this is unsafe and may crash"? I am aiming for correctness, but it would be interesting to know why if this isn't safe and why my naive test doesn't crash. Is there a scenario that can be created where this would crash? I've seen others using @Published properties with @MainThread, which I would guess makes this safe, but it doesn't fix the correctness side of things. e.g. reading the value, checking the value, then writing the value is not a single atomic operation. For this I think locks/private queues would be suitable, but that's out of scope for this discussion.

I'm just checking to see if there was ever a resolution to this? I'm seeing this in the crashes too, up to the latest iOS version. It's a very small percentage of users that are seeing this but it's enough (e.g. > 0 😊) to want to fix it. From the crash reports this is only happening when the app is in the foreground. The app does use a background URLSession but the requests are only made when the app is active. From the state of the other threads this looks to happen just after the app is brought to the foreground. This isn't something we've been able to recreate while debugging or without a debugger (in case we're hitting some restriction that is disabled when debugging). It's rare enough that there's no clear cause. We see a few different exceptions causing this, e.g. EXC_BAD_ACCESS (SIGSEGV); KERN_INVALID_ADDRESS at 0x00004a54c4966330 -> 0x00000054c4966330 (possible pointer authentication failure), EXC_BAD_ACCESS (SIGSEGV);KERN_INVALID_ADDRESS at 0x000000006874616e, and EXC_BREAKPOINT (SIGTRAP). I can redact and provide some Apple crash reports if it would be of some use, but they are effectively the same as the one above.

Sure thing, I've attached 2. When locally symbolicated I can see that thread 12 is code that we run in response to UIApplication.willEnterForegroundNotification (after a DispatchQueue.async call). This is what makes me think this is happening not long after the app enters the foreground. 2024-03-10_11-38-08.1768_+0000-afc91c3bf93f7d7cb4850b234a8dc92bff5c3f2a.crash The next crash has a different exception type. Thread 21 is the code run in response to UIApplication.willEnterForegroundNotification. 2024-03-10_20-55-20.4938_+0100-6350826a04fd7a72170f3f9502c7040522c08d2e.crash Thanks Quinn!

I didn't even notice we're both called Joseph -- we are 2 different people so I can see that could be confusing 😄 The only other interesting thing I've noticed is that we sometimes get a call to URLSessionTaskDelegate.urlSession(_:task:didCompleteWithError:) with a task that has a description we're not expecting. We set the taskDescription to a file URL's absoluteString and then try to create the URL again with URL.init(string:), but that will fail. Unfortunately I don't have an example of what we actually get (e.g. taskDescription could have been corrupted in some way) but it might be a clue to the underlying problem. We've never seen this during debugging, which is our primary use of the app. If we ever find a way to recreate this I will get a sysdiagnose. We have been thinking about opening a DTS for this. It sounds like there's not much more that could be looked at so this might not be worth it?

Thank you for your support on this Quinn. I just so happened to run in to the scenario where the taskDescription is nil this morning. Just before it I see the following logged (this looks to be by iOS): Task <39EBDA50-1653-4B16-B5FC-FBC1CDE9B130>.<462> finished with error [-1000] Error Domain=NSURLErrorDomain Code=-1000 "bad URL" UserInfo={_kCFStreamErrorCodeKey=22, _NSURLErrorFailingURLSessionTaskErrorKey=BackgroundUploadTask <39EBDA50-1653-4B16-B5FC-FBC1CDE9B130>.<462>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "BackgroundUploadTask <39EBDA50-1653-4B16-B5FC-FBC1CDE9B130>.<462>", "LocalUploadTask <39EBDA50-1653-4B16-B5FC-FBC1CDE9B130>.<462>" ), NSLocalizedDescription=bad URL, _kCFStreamErrorDomainKey=1, NSErrorFailingURLStringKey=https://my-subdomain.on.company.com/event/pack, NSErrorFailingURLKey=https://my-subdomain.on.company.com/event/pack} This is the same error passed in to URLSessionTaskDelegate.urlSession(_:task:didCompleteWithError:). I can't see anything wrong with this URL though. The value of task.currentRequest?.url?.absoluteString is https://my-subdomain.on.company.com/event/pack so URL at least thinks it's valid. Until I can recreate the actual crash I don't know if this scenario is a red herring or not. In an attempt to provide as much as I can here I've already attached the output of p task. p task.txt