use the Reply feature for replies. No notifications are sent to watchers if you add a comment. How about changing the window's transparency? See https://developer.apple.com/forums/thread/694837 (I haven't tried this, just kicking ideas around)

Have you considered using hide and unhide on the app instead? If you don't want the user to close the window, you could suppress the appearance of the close button using .windowDismissBehavior(.disabled) in macOS 15 and later.

look at https://developer.apple.com/documentation/photokit instead of Xcode's built-in documentation. It gives you details of the two constituent frameworks, Photos and PhotosUI, for both languages. I can't find documentation for either in Xcode's documentation viewer, for any language.

I'd advise against this, but it depends on exactly what your requirements are. BLE connections are low power because the radio can turn when there is no data to transfer. A "connection" implies that the receiver and transmitter are tightly synchronized, but this synchronization falls apart if you push the connection interval out to 5 minutes. Usually, connection intervals are in the tens or hundreds of milliseconds range. Most types of connections aren't going to be maintained in the background - your app is competing with others for antenna time and energy from the battery. Radio connections are unreliable. You can't expect every transmission to arrive at the receiver intact, so using the phone to log data is likely to be disappointing, unless either: a. you don't care about the occasional missing sample, or b. you buffer samples on the logging device and upload historic data in a batch Lastly, advertising isn't a great way to log data with any temporal precision. The advertising device is usually something with a real time OS and nothing better to do, so it can send advertising packets at regular intervals. The scanning device, however, doesn't know when those advertising packets are being broadcast, so it will generally turn on its receiver at irregular intervals. Even if it were to keep its receiver on permanently, it doesn't know what channel to listen to (advertisements cycles through three different advertising channels). On top of that, you can't fit much data in a regular advertising packet. Extended advertising in BLE 5 allows for more efficient advertising of larger packets, but I don't know how much support for extended advertising is built into iOS and the various phone models. If I were trying to make a data logger, I'd log on the device and have an explicit, user-driven data download procedure from a foreground app. If you're more interested in status than logging, advertising might be an option. If your data requirements are low, and timing isn't critical - e.g. if you're monitoring temperature every 10 minutes, you might be able to leverage iBeacon technology.

can you log in in Safe Mode? (https://support.apple.com/en-gb/guide/mac-help/mh21245/mac) If so, you might be able to access some crash reports and submit them with your bug report (they should be included with sysdiagnose). Inspecting those reports may give you a clue as to what is causing your Mac to crash on login.

works for me too. Xcode 16.2 (16C5032a) or Xcode 16.3 (16E140), macOS Sequoia 15.3.2 (24D81). Is your system preferred language English? I tried changing mine to German for a bit, but did not restart the Mac. It still worked as expected. When you tried it on another Mac, did you copy the app, or build it on the other Mac?

does this work for you - a stroke with a gradient? struct ContentView: View { var body: some View { let backgroundColor = Color(hue: 0.0, saturation: 0.0, brightness: 0.44) let foregroundColor = Color(hue: 0.0, saturation: 0.0, brightness: 0.33) let rimTop = Color(hue: 0.0, saturation: 0.0, brightness: 0.26) let rimBottom = Color(hue: 0.0, saturation: 0.0, brightness: 0.5) let gradient = LinearGradient(stops: [ Gradient.Stop(color: rimTop, location: 0.0), Gradient.Stop(color: rimTop, location: 0.40), Gradient.Stop(color: rimBottom, location: 0.6 ), Gradient.Stop(color: rimBottom, location: 1.0 ) ], startPoint: .top, endPoint: .bottom) ZStack { RoundedRectangle(cornerRadius: 40) .fill(backgroundColor) .frame(width:400, height: 300) Rectangle() .fill(.clear) .frame(width: 300, height: 50) .overlay { RoundedRectangle( cornerRadius: 20, style: .circular) .fill(foregroundColor) .stroke(gradient, lineWidth: 2) } } } }

They tell you on their web site. Okay, it is possible, it isn't very practical.

external UVC cameras are supported on iOS 17 and later on iPads with USB connectors. This is mentioned here: https://developer.apple.com/videos/play/wwdc2023/10106?time=51

thanks for posting the descriptor. Here's the descriptor of alternate interface 1 of interface 3, the audio streaming interface, when set to 12 channels of 8-bit-per-sample audio: Endpoint 0x03 - Isochronous Output Address: 0x03 (OUT) Attributes: 0x09 (Isochronous adaptive data endpoint) Max Packet Size: 0x024c (588 x 1 transactions opportunities per microframe) Polling Interval: 4 (8 microframes (1 msecs) Your sampling rate is 48kHz, so 48 samples every millisecond. The polling interval is 1 millisecond (the actual number in the descriptor is 4, we're on USB 2.0 high speed here, so that means every 2^(4-1) or 8 micro-frames. Each sample is 1 bytes, and there are 12 channels. So in each frame, there are 12x48 or 576 bytes to transfer (nominally). Up to one additional sample frame (12 bytes) may be transferred in each interval to synchronize the device rate with the host rate, which is where the 588 bytes comes from. In the 16 bits-per-channel case, the polling interval is the same - 1ms. But you need to transfer up to 1152+24 = 1176 bytes per interval. However, the maxPacketSize here is 1024 - the maximum allowed by the USB 2.0 Audio Specification. One way to fix this is to change the descriptor to reduce the polling interval from every millisecond to twice every millisecond (the number '3' in the bInterval field, and change the wMaxPacketSize to 588. Another possibility would be to ask for up to two transactions per micro frame - this is squeezed into bits 12 and 11 of bMaxPacketSize. However, the (now ancient) tech note TN2274 says "At this time, AppleUSBAudio supports at most one transaction per microframe". See Table 9-13 and section 5.6.3 of the USB 2.0 Specification and Table 4-33 of the USB Audio Class Specification v2.0 You might be asking yourself why it "works on Linux", but does it really?

Nope. External UVC devices are only supported on iPads with USB C connectors. API support is in iOS 17, the limitation is mentioned in the the "Support external cameras in your iPadOS app" presentation from WWDC 2023. The documentation for AVCaptureDevice.DeviceType.external says "On iPad, external devices are those that conform to the UVC (USB Video Class) specification.", but does not make it clear that support is limited to iPads with USB C only.

I can't tell you anything about the audio drivers in macOS, sorry. By "how custom" I meant "do you write the firmware". It doesn't really matter how much bandwidth is available on the bus. The device declares a number of different alternate interfaces in its USB descriptor, which ask the OS for a different amount of USB bandwidth. This enables multiple devices to occupy the same bus with predictable results. It is possible that there is something a bit odd about your device's USB descriptor. You could post it here. Use the usbdiagnose tool to fetch the descriptor (it is in /usb/bin) Have you checked the system log to see if it is complaining about the device, either from the USB sub-system or from the Core Audio subsystem? Since the log floods with irrelevant messages but you don't know what to look for until you've seen it, live filtering on predicates is not very useful. I would connect the device, then execute log collect --last 1m which will write the last 1 minute of log data to a file, which you can then peruse later, or export and examine with a text editor. The tech note you referenced says "Snow Leopard (and later) is able to stream 10 channels of 32-bit audio at 192 kHz to and from a USB Audio 2.0 device" - bandwidth or system performance is unlikely to be your limitation. There are USB audio mixers available for macOS with more than 12 channels at 192kHz and 16 bits. Have you compared your device's behavior with one of those?

How custom is your custom device? Does it work on other platforms? I assume since it is an audio device, that it is using isochronous transfers. Does your device reserve enough isochronous bandwidth for 12 channels of 48kHz, 16 bit per sample audio?

did you refer to https://developer.apple.com/documentation/xcode/identifying-the-cause-of-common-crashes?

Your spctl command returns "rejected" because --assess defaults to --type=execute, and you need to write --type=install. Your installer probably includes a pre-install script. If you didn't have one, you wouldn't see the warning during installation.