[quote='841832022, Etresoft, /thread/786625?answerId=841832022#841832022, /profile/Etresoft'] A Launch Agent would run with a user space UI role. That's how Launch Agents work. That's not the same as a Launch Daemon that runs as root and does not require a login session. [/quote] Ah, you’re right! I feel a bit silly for not testing the null hypothesis earlier, but indeed even if I don’t embed my launch agent in an app bundle I still see the same output from taskinfo.

[quote='841858022, DTS Engineer, /thread/786625?answerId=841858022#841858022'] It can call a framework, which can have its own resources [/quote] This is a good point, I suppose I don’t really need the bundle structure to package resources. I think it makes my build phases in Xcode a little cleaner, though, so I’ll stick with it. Thanks!

Perfect, thanks for the help!

That all makes sense, thanks! With “named XPC endpoint”, do you mean an entry under MachServices in my agent’s launchd.plist(5)? Also, since my app is sandboxed, what’d be the best way to allow it to access the endpoint: a Mach temporary exception entitlement, or an app group?

That makes perfect sense, thank you for clarifying!

From my testing FSEvents stops delivering events once the root has been changed, so creating a new event stream is necessary. AFAICT the documentation’s reason for recommending you keep around a file descriptor is only so that you can determine the root’s path after the rename, which in turn lets you create a new event stream.

My app monitors a folder selected by the user for internal changes with FSEvents, which sadly only takes a path, not a file descriptor. As a result, the “leave it open” approach doesn’t work for my use case. Instead, the app needs to respond immediately when the folder is renamed so it can destroy and recreate the necessary FSEvents event stream – hence the Dispatch source. The reason I feel security-scoped bookmarks are a bit of a hack here is that AFAIK they’re intended for persisting sandbox extensions across app launches, rather than within a single run of an app. Shouldn’t non-security-scoped bookmarks work here?

I’m so glad to see someone else mention this! I honestly thought I might be going crazy, thinking that inertia doesn’t feel quite right in NSScrollView. When scrolling a basic NSScrollView there seems to be a sudden jump after each flick. Scrolling does not appear smooth and is disorientating. I too have noticed this for years, and it’s always bothered me! A few months ago I tried to investigate these inconsistencies. It turns out that WebKit contains a custom reimplementation of NSScrollView which tries (and IMO succeeds) at being essentially indistinguishable from the real thing, except for the improved smoothness and faster scrolling speed, as you mentioned. I believe at least some of the hitches in AppKit you’re seeing aren’t down to rendering or view updates or anything like that, but simply because AppKit scroll event inertia is “stepped”: https://pavelfatin.com/images/scrolling-with-pleasure/scrolling-velocity.png. I think WebKit might also have a custom reimplementation of inertia (ignoring AppKit’s scroll inertia events, instead synthesizing its own), which would explain the difference. It, like every custom scroll view, also reimplements elasticity. As for responsive scrolling, I personally can’t tell the difference between NSScrollView with responsive scrolling enabled vs disabled.

[quote='816385022, DTS Engineer, /thread/770062?answerId=816385022#816385022'] That’s about it. [/quote] I have to admit that I’m mildly disappointed! I’d kind of convinced myself that workloops must be some sort of dark magic. [quote='816385022, DTS Engineer, /thread/770062?answerId=816385022#816385022'] Because the workloop is intended to be the target, not the source, of work. The idea is to have one workloop per subsystem and then have various serial queue, or serial queue hierarchies, target that. [/quote] This makes sense, thank you! I can see how workloops map well onto the ideas presented in the WWDC session you linked. Keep using serial queues where ordering matters, otherwise target everything at one workloop (instead of a serial queue) per subsystem. [quote='816385022, DTS Engineer, /thread/770062?answerId=816385022#816385022'] Honestly, if you could set a target queue I’m not sure how that’d even work. If you set a workloop’s target queue to a serial queue, you’d be back in FIFO Land™. [/quote] I was imagining that targeting a workloop at a serial queue would interleave the workloop’s work items (which are still ordered by priority) with the serial queue’s other work items (which maintain their ordering); it’s as if you’d targeted one serial queue at another, except that the first queue happens to have had its work submitted in descending priority order. Targeting a workloop at another workloop would function in the same way as how targeting a serial queue at a workloop does today, minus the ordering requirement. I suppose the purpose of this would be the same as why we target serial queues at one another: to apply labels for debugging and to assign QoS classes. Of course, none of this matters since I’m just imagining things. [quote='816385022, DTS Engineer, /thread/770062?answerId=816385022#816385022'] ps I love your blog! [/quote] Thank you for the compliment and for the fantastic answers!

I’ve filed it FB14027711.