I am using an NSTableView with the .inset style on macOS Big Sur. The table view is working well and has appropriate left and right margins. However, it seems like the table view has zero top margins, which means that its top sits flush with the enclosing scroll view's top. That results in an "asymmetrical" appearance compared to the larger horizontal margin. Is there a way to increase the table view's vertical insets? It appears that setting the contentInsets of the enclosing scroll view to e.g. {20, 0, 0, 0} has no effect. Edit: See imgur.com/a/rMPttaX for a screenshot demonstrating the different margins (the "Filters" header is part of the table view and should have more vertical space above it).

Since the end of 2021, I have been getting reports from my users that my app Timing (https://timingapp.com) no longer records window titles and file paths for the apps they use, despite Accessibility permissions having been granted. The problem manifests itself such that sometimes (see below on the conditions I was able to identify), the "Timing Tracker" app is shown and appears checked in "Security & Privacy" System Preferences, and calling AXIsProcessTrustedWithOptions() with options @{ (__bridge id) kAXTrustedCheckOptionPrompt : (id) kCFBooleanFalse } returns true. However, any of my actual Accessibility code (e.g. obtaining a process's windows) only returns nil (or empty arrays) when the problem is occurring. Any pointers as to what could be the reason or what I could investigate would be very appreciated, as I really am at a loss here. Here are a few additional things to note that may or may not be related to the issue at hand: My use of the Accessibility API usually works fine and has been working fine for quite a while; only recently has it started to sporadically stop working for some users. The app consists of a "main" app, with a helper contained therein that actually performs the Accessibility requests. In the "Security & Privacy" System Preferences, the helper (called "Timing Tracker") is shown and appears checked (i.e. Accessibility permissions seem to be granted). This only seems to affect the Accessibility API; Automation (i.e. Apple Events) continue to function if the user has granted permission for them. It appears that these issues occur more frequently after the app gets updated and the helper restarts itself because it has detected changes to its application bundle, but it appears that's not the only cause for this issue (i.e. it also happens without a recent app update having taken place). The helper uses the following code to relaunch itself: - (void)relaunchWithDelay:(NSTimeInterval)delay { // $N = argv[N] // Sleep until our own process has been killed, then sleep for another 15 seconds, then relaunch the app. NSString *killArg1AndOpenArg2Script = [NSString stringWithFormat:   @"/bin/kill $1; (while /bin/kill -0 $2 >&/dev/null; do /bin/sleep 1; done; /bin/sleep %lf; /usr/bin/open \"$3\") &",   delay]; // NSTask needs its arguments to be strings NSString *ourPID = [NSString stringWithFormat:@"%d",                                               [NSProcessInfo processInfo].processIdentifier]; // this will be the path to the .app bundle, // not the executable inside it; exactly what `open` wants NSString *pathToUs = [NSBundle mainBundle].bundlePath; NSArray *shArgs = @[ @"-c", // -c tells sh to execute the next argument, passing it the remaining arguments. killArg1AndOpenArg2Script, @"", // $0 path to script (ignored) ourPID, // $1 in restartScript ourPID, // $2 in restartScript pathToUs ]; // $3 in restartScript NSTask *restartTask = [NSTask launchedTaskWithLaunchPath:@"/bin/sh" arguments:shArgs]; [restartTask waitUntilExit]; // wait for killArg1AndOpenArg2Script to finish NSLog(@"*** ERROR: %@ should have been terminated, but we are still running", pathToUs); assert(false && "We should not be running!"); } I am unsure whether this invocation somehow relaunches the helper in a state that temporarily strips it of its TCC/Accessibility permissions. According to user reports, this can usually be fixed either relaunching the helper, rebooting the Mac, or (in some cases) unchecking the helper in the "Security & Privacy" System Preferences. (It seems like which of these escalating steps is required for the fix varies from user to user.) I have heard reports of this from both macOS 11 and macOS 12 (not sure whether it also occurs on macOS 10.15). Given reports of some TCC vulnerabilities having been fixed recently, I wonder whether some of the fixes could trigger a denying of Accessibility permission to my app. I still haven't been able to reproduce the issue myself, but have received plenty of credible reports that this is actually happening. As mentioned above, rebooting the Mac usually seems to fix the problem, which makes this particularly hard to investigate and debug. The app itself has been around since at least 2017, yet these problems seem to have only started occurring (or at least became much more frequent) towards the end of 2021. I do not recall any substantial chances to the relevant code paths recently. The app is not sandboxed; it is correctly signed and notarized with Developer ID. Hardened Runtime is enabled; the only Hardened Runtime entitlement requested is "Apple Events". I do have changed the Organization name of my Apple Developer account in 2021, but I don't think that's related, because the designated requirement (csreq) stored in tcc.db for Accessibility with my app is anchor apple generic and identifier "info.eurocomp.TimingHelper" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = NDB5JK3DZG). This seems to be appropriate, and does not include the organization name itself. My Organization's Team ID (NDB5JK3DZG) has not changed.