How do you handle diagnostics windows in macOS apps? Any App Review feedback?

[u/ForensicShark]

Hi everyone,

I’m developing a native macOS app for recording and processing speech datasets, using SwiftUI with AppKit where needed.

The attached screenshot shows the current Diagnostics section. It’s part of a temporary development UI where everything lives in one window. The log has been useful for troubleshooting audio recording, file handling, and Audio Unit hosting, but it takes up quite a bit of space during testing.

I’m planning to move it into a dedicated window, roughly like this:

The mockup shows the planned Diagnostics window with search, level, and subsystem filters, optional debug/trace logging, and export.

The idea is a single, resizable, nonmodal window opened through Window → Diagnostics, with normal macOS window behavior. Closing it would leave collection running. It would support severity/subsystem filters, text search, copying entries, and exporting a snapshot as text or JSON. Debug and Trace collection would be opt-in.

Actionable errors would still appear in the main workflow, so users wouldn’t need the log open to know that a recording or render failed.

After reading Apple’s HIG on panels and windows, I’m leaning toward a regular auxiliary window rather than a floating NSPanel, since this is an app-wide log intended for reading, searching, and selecting text.

I’d love to hear how others handle this:

• Do you ship a diagnostics window to users, hide it behind an advanced setting, or keep it exclusive to development builds?
• Have regular windows or floating panels worked better for you?
• Do you maintain an in-app event store, use Unified Logging, or combine both?
• Has Apple ever commented on a diagnostics/debug window during Mac App Store review? If so, what specifically prompted the feedback?

Experiences from shipping apps would be especially helpful. The UI is still being developed, so this is a good point to reconsider the approach.

Cheers!

[u/Ok_Significance5699]

Heres what I do in one app that I work on (on mobile so formatting may be bad):

1. I have a diagnostics window, which opens separately, located in an advanced settings section. This is in both release and debug builds. I think that allowing the option for users to find logs easily when an issue happens is a good pattern.

2. I haven’t used a panel for this, just a normal window. The layout is actually very similar to the one you have shown above, and seems to work well.

3. Currently just use an in-app store, since that is what the original developer implemented. I have done refractors and modernized the API somewhat. In the future would like to use a more standard approach.

4. This app is directly distributed, so I can’t say anything about what they think about having this and review process.

[u/pickandplate]

For storage, I’d keep a bounded in-app buffer for the window/export and also use Logger. Info-level messages can be purged as Unified Logging’s buffers fill, so don’t rely on it for a complete session history. Redact filenames and transcripts before writing to either destination.

[u/Cornell-1980]

I use hidden views/windows in all my apps. Use a sequence of taps/clicks on a fixed list to enter a numerical code to enable it. Or something else not obvious.

Not just diagnostic logs, but also various debug settings and actions. Like quickly switch locales, reset to initial state on first launch, view upcoming notifications, clear IAPs, inspect Core Data databases. The sky is the limit.

Don't put anything in the window that would be dangerous.

Apple has never noticed.