![\"Screenshot](\"https://indiestack.com/wp-content/uploads/2025/11/DebugXPC.png\" "\\"DebugXPC.png\\"")
For the vast majority of developers of software for Apple products, the process (har, har) of debugging involves attaching to and inspecting only one process: the main application binary. This is particularly true on iOS-based systems, where spawning subprocesses is not allowed, and arbitrary XPC services are limited. But developers of “app extensions”, a specialized form of XPC service, may well need to attach to at least two processes.
\nMac developers, on the other hand, are more likely to encounter situations where attaching to multiple subprocesss is either necessary or very convenient. In particular, the use of custom XPC services allows a Mac app to subdivide the work it performs into separate components that run with potentially different security entitlements from the main application.
\nFor these scenarios, Xcode provides a handy checkbox that can be used to automatically attach when one of an app’s XPC services is launched. Look deep in the “Options” tab of the scheme editor’s “Run Action” page:
\n
This is handy, for example, if you need to attach to components of the open source Sparkle project, which uses XPC services to compartmentalize some parts of the software update process. Here, Xcode automatically attached to the service that handles relaunching the freshly-updated application:
\n![\"Screenshot](\"https://indiestack.com/wp-content/uploads/2025/11/InstallerLauncher.png\" "\\"InstallerLauncher.png\\"")
While this feature is great for XPC services in particular, there are many caveats. For example, Xcode will not automatically attach to XPC services that you didn’t build yourself. So, while an app that uses WebKit will employ many XPC services for accessing network resources or rendering web page content, Xcode will not attach to those processes automatically unless you built the WebKit project locally and are running against that version.
\nAnother shortcoming of Xcode’s default behavior is that it will only attach to XPC processes specifically. If your app spawns other subprocesses that are not XPC services, you have to laboriously ask it to attach to your process by name or by process ID. My app FastScripts, an AppleScript utility, uses subprocesses to run scripts in isolation, both for resilience against crashing scripts, and to accommodate running an arbitrary number of scripts in parallel. When I’m debugging an issue in the subprocess, named “RSScriptRunner” in my debug builds, I have to manually select the “Debug -> Attach to Process by PID or Name” menu item, and type in “RSScriptRunner”:
\n![\"Screenshot](\"https://indiestack.com/wp-content/uploads/2025/11/AttachToProcess.png\" "\\"AttachToProcess.png\\"")
But here I run into another unfortunate limitation of Xcode’s attachment functionality: Xcode only attaches to the first named process it finds. FastScripts always keeps at least two RSScriptRunner processes going, so that when a script is invoked there will always be a process “primed and ready”. When several scripts are running in parallel, several RSScriptRunner processes are running. How do I attach to the one I care about debugging?
\nThe solution I’ve come up with is to attach to them all. I’ve created an AppleScript that determines the process identifiers for every running process of a given name, and asks Xcode to attach to each one. I invoke the script (from FastScripts, but any scripting utility would work), type in the name “RSScriptRunner”, and Xcode attaches to each and every one of them:
\n![\"Screenshot](\"https://indiestack.com/wp-content/uploads/2025/11/RSScriptRunnerDebug.png\" "\\"RSScriptRunnerDebug.png\\"")
I’ve clipped this screenshot to save space, but there are four instances of RSScriptRunner that Xcode has attached to in this example. Once you’ve attached to any number of processes in Xcode, any breakpoints you set will fire when any of the processes reaches them.
\nYou can download the script directly, or copy and paste from this text into your favorite script editor:
\nset processName to text returned of (display dialog \"Enter process name:\" default answer \"\")\n\nset processIDs to {}\ntell application \"System Events\"\n set processIDs to unix id of every process whose name is processName\nend tell\n\ntell application \"Xcode\"\n repeat with processID in processIDs\n tell workspace document 1\n attach to process identifier processID without suspended\n end tell\n end repeat\nend tell\n\nIdeally, I would love for Xcode to expand its “Debug XPC Processes” option so that it attaches automatically to any child process created by an app, or perhaps any child process matching a particular regular expression. In the meantime, I hope this script helps some of you manage debugging your multiprocess apps!
\n", "date_published": "2025-11-17T18:03:20-05:00", "date_modified": "2025-11-17T18:43:40-05:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://indiestack.com/2023/10/conditional-xcode-build-settings/", "url": "https://indiestack.com/2023/10/conditional-xcode-build-settings/", "title": "Conditional Xcode Build Settings", "content_html": "In the previous post, I described a problematic warning introduced by the new linker in Xcode 15. In it, I shared that the warning can be effectively disabled by passing a suitable argument to the linker:
\nOTHER_LDFLAGS = -Wl,-no_warn_duplicate_libraries\n\n
This simple declaration will address the problem on Xcode 15, but on Xcode 14 and earlier it will cause a link error because the old linker doesn\u2019t recognize the argument. What we want to do if the project will continue to be built by both older and newer versions of Xcode, is to effectively derive a different value for OTHER_LDFLAGS depending on the version of Xcode itself. (Maybe more correctly, depending on the version of the linker, but for this example we\u2019ll focus on varying based on Xcode version).
\nThere\u2019s no straightforward way to avoid this problem, but Xcode build settings offer a sophisticated (albeit brain-bendingly obtuse) mechanism for varying the value of a build setting based on arbitrary conditions. Technically this technique could be used in Xcode\u2019s build settings editor, but because of the complexity of variable definitions, it\u2019s a lot easier (not to mention easier to manage with source control) if you declare such settings in an Xcode configuration file. The examples below will use the declarative format used by these files.
\nThe key to applying this technique is understanding that build settings can themselves be defined in terms of other build settings. For example:
\nOTHER_LDFLAGS = $(SUPPRESS_WARNING_FLAGS)\nSUPPRESS_WARNING_FLAGS = -Wl,-no_warn_duplicate_libraries\n\n
These configuration directives have the same effect as the single-line definition above, because Xcode expands the SUPPRESS_WARNING_FLAGS setting and uses the result when setting the value of OTHER_LDFLAGS. Even more powerfully, you can nest build settings so that the value of one build setting is used to construct the name of another:
\nSHOULD_SUPPRESS = YES\nOTHER_LDFLAGS = \\((SUPPRESS_WARNING_FLAGS_\\)(SHOULD_SUPPRESS))\nSUPPRESS_WARNING_FLAGS_YES = -Wl,-no_warn_duplicate_libraries\n\nHere, the final value for OTHER_LD_FLAGS will only include the specified flags if the SHOULD_SUPPRESS build setting is YES, because expanding SHOULD_SUPPRESS yields the build setting SUPPRESS_WARNING_FLAGS_YES. If SHOULD_SUPPRESS is NO, or any other value, then the expansion will lead to an undefined build setting, and thus will substitute an empty value.
\nSide note: when editing Xcode configuration files, keep one editor pane open to the configuration file, and one pane open to the Xcode build settings interface, focused on a project or target that depends on the configuration file. As you edit and save the file, Xcode updates the derived build settings in real time so you can check your work. For example, if you were to change the value of SHOULD_SUPPRESS to NO, you would see the \u201cOther Linker Flags\u201d value change to empty in Xcode.
\nObviously, hard-coding SHOULD_SUPPRESS to YES as we did above isn\u2019t going to solve the problem, because these configuration settings will cause the incompatible linker parameter to be passed on Xcode 14 and earlier.
\nThe simple ability to nest build settings leads to a huge variety of clever tricks that allow you to impose a kind of declarative logic to settings. For example, here\u2019s a cool technique I learned from the WebKit project:
\nNOT_ = YES\nNOT_NO = YES\nNOT_YES = NO\n\n
NOT_ equals YES? What does it meeeeaaan? It only makes since when you consider what happens when you combine NOT_ with another build setting that is defined as a boolean value:
\nSHOULDNT_SUPPRESS = \\((NOT_\\)(SHOULD_SUPPRESS))\n\nThis expands to $(NOT_YES) which in turn expands to NO. You can make sense of these exotic uses of nested build settings by slowly walking through the expansion, from the inside out. Each time you expand the contents of a $() construct, you end up with text that combines with the adjacent text to yield either a new build setting name, or the final value for a setting.
\nFinally, let\u2019s apply a similar trick to the question of whether we\u2019re running Xcode 15 or later. For this I am also leaning on an example I found in the WebKit sources. By declaring boolean values for several Xcode version tests:
\nXCODE_BEFORE_15_1300 = YES\nXCODE_BEFORE_15_1400 = YES\nXCODE_BEFORE_15_1500 = NO\n\n
We lay the groundwork for expanding a build setting based on the XCODE_VERSION_MAJOR build setting, which is built in:
\nXCODE_BEFORE_15 = \\((XCODE_BEFORE_15_\\)(XCODE_VERSION_MAJOR))\nXCODE_AT_LEAST_15 = \\((NOT_\\)(XCODE_BEFORE_15))\n\n
In this case, on my Mac running Xcode 15.1, XCODE_BEFORE_15 expands to XCODE_BEFORE_15_1500, which expands to NO. XCODE_AT_LEAST_15 uses the aforementioned NOT_ setting, expanding to NOT_NO, which expands to YES.
\nEasy, right?
\nPutting it all together, we can return to the original example with SHOULD_SUPPRESS, and replace it with the more dynamic XCODE_AT_LEAST_15:
\nOTHER_LDFLAGS = \\((SUPPRESS_WARNING_FLAGS_\\)(XCODE_AT_LEAST_15))\nSUPPRESS_WARNING_FLAGS_YES = -Wl,-no_warn_duplicate_libraries\n\nOTHER_LDFLAGS expands to SUPPRESS_WARNING_FLAGS_YES on my Mac running Xcode 15.1, but on any version of Xcode 14 or earlier, it will expand to SUPPRESS_WARNING_FLAGS_NO, which expands to an empty value. No harm done.
\nI hope you have enjoyed this somewhat elaborate journey through the powerful but difficult to grok world of nested build settings, and how they can be used to impose rudimentary logic to whichever settings require such finessing in your projects.
\n", "date_published": "2023-10-04T11:51:31-04:00", "date_modified": "2023-12-05T00:18:16-05:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://indiestack.com/2023/10/xcode-15-duplicate-library-linker-warnings/", "url": "https://indiestack.com/2023/10/xcode-15-duplicate-library-linker-warnings/", "title": "Xcode 15 Duplicate Library Linker Warnings", "content_html": "Apple released Xcode 15 a couple weeks ago, after debuting the beta at WWDC in June, and shipping several beta updates over the summer.
\nI’ve been using the betas on my main work machine, and for months I’ve been mildly annoyed by warnings such as these:
\nld: warning: ignoring duplicate libraries: '-lc++'\nld: warning: ignoring duplicate libraries: '-lz'\nld: warning: ignoring duplicate libraries: '-lxml2'\nld: warning: ignoring duplicate libraries: '-lsqlite3'\n\n\n\n
You may have run into similar warnings with other libraries, but warnings about these libraries in particular seem to be very widespread among developers. Even though I’ve been seeing them all summer, and have been annoyed by them, I made the same mistake I often make: assuming that the problem was too obvious not to be fixed before Xcode 15 went public. Alas.
\nSo what happened in Xcode 15 to make these suddenly appear, and why haven’t they gone away? The root of the problem is not new. Something about the way Xcode infers library linkage dependencies has, for several years at least, led it to count dependencies from Swift packages separately from each package, and to subsequently pass the pertinent “-l” parameter to the linker redundantly for each such dependency. In other words, if you have three Swift packages that each require “-lc++”, Xcode generates a linker line that literally passes “-lc++ -lc++ -lc++” to the linker.
\nSo why have the warnings only appeared now? One of the major changes in Xcode 15 was the introduction of a “completely rewritten linker”, which has been mostly transparent to me, but which was also to blame for an issue with Xcode 15 that prevented some apps from launching on older macOS (10.12) and iOS (14) systems. That bug has been addressed in the Xcode 15.1 beta 1 release, which was released this week.
\nAnother change in the new linker was the introduction of a new warning flag, on by default: “-warn_duplicate_libraries”. Kinda obvious, isn’t it? It’s the new warning flag on the linker that is leading this old Xcode behavior to suddenly start spewing unwanted warnings.
\nLuckily, in conjunction with the new warning flag, the linker also introduced a negating flag: “-no_warn_duplicate_libraries”. If you pass this flag to the linker, the warnings go away. When Xcode links your target, it actually invokes “clang”, which in turn invokes the linker (“ld”). So to see that the flag gets passed down to the lower lever linker, you need to specify it as a parameter to clang that instructs it to propagate the parameter to ld:
\n\nOTHER_LDFLAGS = -Wl,-no_warn_duplicate_libraries\n\n\n\n
OTHER_LDFLAGS is the raw name for the build setting that appears in Xcode as “Other Linker Flags”. The excerpt above is in the text-based Xcode configuration file (.xcconfig) format. You could also just paste the “-Wl,-no_warn_duplicate_libraries” argument into the Xcode build settings for your target, but generally speaking, using Xcode configuration files is better.
\nOne problem with pasting the OTHER_LDFLAGS value in to Xcode’s build settings, is you won’t be able to build the project on Xcode 14 or earlier. Maybe that is OK, but if like me, you use an older version of Xcode on your build machine (or your dedicated continuous integration service does), you’ll run into a build error when the older linker fails to recognize the new option:
\n\nld: unknown option: -no_warn_duplicate_libraries\n\n\n\n
So how can we suppress the warnings while using Xcode 15, while continuing to build without errors on older versions of Xcode? Xcode configuration files to the rescue! Because of the general utility of the method used to conditionalize build settings based on Xcode version, I have written a separate blog post describing this technique. Read Conditional Xcode Build Settings to learn more.
\nI’m not going to fret too much about disabling the “warn_duplicate_libraries” option on the linker, because I don’t foresee it protecting me from many real-world pitfalls. However, all else being equal I would leave the warning on, because you never know.
\nI filed FB13229994 with a sample project demonstrating the problem. Hopefully at some point in the future Apple will update Xcode so that it effectively removes duplicated library names from its list of derived dependencies, alleviating the problem and allowing the warning to be enabled again.
\n", "date_published": "2023-10-04T11:50:53-04:00", "date_modified": "2023-10-04T14:46:27-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://indiestack.com/2023/06/view-clipping-sonoma/", "url": "https://indiestack.com/2023/06/view-clipping-sonoma/", "title": "View Clipping Changes in macOS 14 Sonoma", "content_html": "One of the most impactful changes to AppKit in the forthcoming macOS 14 Sonoma update is a change to the default clipping behavior for views. Apple announced that a long-present internal property, “clipsToBounds”, is now public. In tandem with this change, they are changing the default value for this property to false for apps that link against the macOS 14 SDK.
\nWhat does it mean for a view to “clip to bounds”? It simply means that no matter what the view does, it will not succeed in drawing outside its own bounds. This sounds like a reasonable thing, but it has historically been a headache for views with shadowed borders, for example, or views that render text that might extend slightly outside the bounds of the view.
\nApple acknowledges in the AppKit Release Notes that this change will pose problems for some custom views. One example has to do with the “drawRect:” method and the value of the “dirtyRect” parameter:
\n\n\nFilling the dirty rect of a view inside of -drawRect. A fairly common pattern is to simply rect fill the dirty rect passed into an override of NSView.draw(). The dirty rect can now extend outside of your view\u2019s bounds.\n
I ran up against this with my own app, MarsEdit, where I noticed the date editor panel was missing the “OK” button:
\n![\"CalendarClipping\"](\"https://indiestack.com/wp-content/uploads/2023/06/CalendarClipping.png\" "\\"CalendarClipping.png\\"")
What’s happening here is my custom calendar view is filling the “dirtyRect” with its background color before continuing to draw the rest of its content. Unfortunately, what Apple promised in the excerpt above has come to pass: the dirtyRect encompasses nearly the entire window! So when my calendar view redraws, it is evidently overwriting the “OK” button, as well as a date picker that is supposed to appear below the calendar.
\nThe fix is relatively simple in this case: because I don’t anticipate the view being very large, and filling a rect is a pretty cheap operation, I simply changed it to fill “self.bounds” instead of “dirtyRect”.
\nFilling the dirty rect is such a pervasive pattern that I expect many apps will see problems like this. It also seems odd that views such as mine are being passed such a large dirtyRect. It makes me wonder if, during the beta testing phase, Apple is intentionally passing extra-large dirty rects to views, to expose issues like this.
\nThe takeaway is you probably want to do a global search in your projects for “dirtyRect” and evaluate whether the pertinent code in each case assumes the rect is constrained to your view’s bounds. As soon as you start compiling and linking against the macOS 14 SDK, it won’t be.
\n", "date_published": "2023-06-27T10:18:40-04:00", "date_modified": "2023-06-27T11:41:17-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://indiestack.com/2023/06/xcode-build-script-sandboxing/", "url": "https://indiestack.com/2023/06/xcode-build-script-sandboxing/", "title": "Xcode Build Script Sandboxing", "content_html": "Apple added a new build setting to Xcode last year, ENABLE_USER_SCRIPT_SANDBOXING, which controls whether any “Run Script” build phases will be run in a sandbox or not. From the Xcode 14 Release Notes:
\n\n\nYou can now enable sandboxing for shell script build phases using the ENABLE_USER_SCRIPT_SANDBOXING build setting. Sandboxing blocks access to files inside the source root of the project as well as the Derived Data directory unless you list those files as inputs or outputs. When enabled, the build fails with a sandbox violation if a script phase attempts to read from or write to an undeclared dependency, preventing incorrect builds.\n
If I noticed it last year I had already forgotten about it, but I was reminded today while putting together a sample app to demonstrate a bug I was reporting. How was I reminded? Because evidently, starting in Xcode 15, the build setting now defaults to YES. I had added a custom Run Script phase to my project in order to finesse the contents of the built product, but when the script ran I was greeted with this error:
\n\n\nerror: Sandbox: cp(25322) deny(1) file-read-data /Users/daniel/Project/File.txt\n
Luckily when I searched the build settings for the word “sandbox” it turned up the setting, and I was able to turn it off. If you run into this with your projects, it sounds like a better fix is to specify the specific input and output files so that the script phase is allowed access only to the files you think it should be working with.
\n", "date_published": "2023-06-11T16:41:03-04:00", "date_modified": "2023-06-11T16:41:03-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://indiestack.com/2023/04/magic-loading-property-wrappers/", "url": "https://indiestack.com/2023/04/magic-loading-property-wrappers/", "title": "Magic Loading Property Wrappers", "content_html": "tldr: MagicLoading is a reference implementation of a @ViewLoading-style property wrapper.
\nI hadn’t really paid too close attention to Swift’s property wrapper features until my curiosity was piqued earlier this year by Apple’s introduction of some very interesting wrappers designed to work with UIViewController, NSViewController, and NSWindowController. The aim in each case is to address this vexing situation:
\n\n// Will be non-nil after loadView\nvar important: Thingy! = nil\n\n\n
By wrapping in such a way that guarantees the view will get loaded if you access the property:
\n\n@ViewLoading var important: Thingy\n\n\n
Anybody who has done substantial work on iOS or Mac platforms can appreciate how helpful this is, to convert an otherwise fragile implicitly unwrapped optional into a totally predictable non-optional property. Apple’s new property wrappers make this possible by essentially rewriting the “important” property with boiler-plate code that first loads the view if needed, and then returns the underlying wrapped value. As Apple says in their documentation, this stands to prove particularly useful for @IBOutlet properties, which can all be converted to using this mechanism.
\nUnfortunately, Apple’s new property wrappers are only available for pretty recent deployment targets: iOS 16.4 and macOS 13.3. I am excited to start using these, but I still need to deploy to earlier targets. So I set out to re-implement something similar on my own.
\nThe magic in Apple’s wrappers is an under-documented but widely used alternative mechanism for property wrappers: the ability to define getters and setters with knowledge of the containing object’s type, and access to the specific instance. The “subscript” variant of property wrappers is described in the original proposal, but has never been publicly endorsed, as far as I know, by Apple or the Swift team.
\nUsually I would shy away from undocumented features, but in this situation I believe it’s safe to use the undocumented subscript functionality because doing so only instructs the compiler to generate wrapper code that is compiled into the resulting binary. In other words: there are no private runtime dependencies that are being assumed by opting into this more sophisticated form of property wrapper. It’s just a way of getting the Swift compiler to write the pertinent code for us.
\nThere are plenty of tutorials about how to use these subscript-based property wrappers, but I thought it would be useful to share a reference implementation that boils it down to how you might write one of these @ViewLoading style property wrappers yourself. MagicLoading is a GitHub repository that aims to do that. It implements only one such wrapper: MagicViewLoading, which is intended to replicate UIViewController.ViewLoading.
\nFor my own purposes, I’d like to add other wrappers to handle the NSWindowController and NSViewController cases, but I’m also a little annoyed by the prospect of having to replicate that ugly “subscript” code everywhere. I was curious about whether I could somehow factor out the subscript wrapper and allow other wrappers to be declared by just providing the “getter logic” and “setter logic”.
\nI made a few attempts at declaring a more generic property wrapper that exposed var properties for getting and setting, but I ran into issues figuring out how to declare concrete types that could take advantage of the more general wrapper without introducing complexity at the property declaration site. If anybody has clever ideas about how to approach that, I’d love to be able to have @MagicLoading be a property wrapper type that other wrappers could inherit from or compose in some way.
\n", "date_published": "2023-04-17T12:49:33-04:00", "date_modified": "2023-04-18T01:29:12-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://indiestack.com/2023/01/inline-applescript-documentation/", "url": "https://indiestack.com/2023/01/inline-applescript-documentation/", "title": "Inline AppleScript Documentation", "content_html": "While perusing Xcode’s AppleScript scripting dictionary, I was surprised to discover a rather robust “example code” section included right there among the usually spartan reference of the app’s scriptable entities:
\n![\"Screenshot](\"https://indiestack.com/wp-content/uploads/2023/01/XcodeBuildCommand.png\" "\\"XcodeBuildCommand.png\\"")
Curious to learn more, I used a relatively little-known trick for examining the raw source code of a scripting dictionary. Simply click and drag from Script Editor’s document proxy icon, into a text editor such as TextEdit, Xcode, or BBEdit:
\n![\"Screenshot](\"https://indiestack.com/wp-content/uploads/2023/01/DragProxyScriptEditor.png\" "\\"DragProxyScriptEditor.png\\"")
This trick is especially handy because even if the app in question doesn’t have a standard scripting definition (.sdef) file representing its interface, Script Editor will generate one dynamically for you. It’s a quick-and-dirty way to learn how specific outcomes are achieved, and how you might incorporate similar features in your own app’s scripting definition file. In this case, I discovered a new (to me) “documentation” element in the file:
\n![\"Screenshot](\"https://indiestack.com/wp-content/uploads/2023/01/DocumentationElementXcode.png\" "\\"DocumentationElementXcode.png\\"")
I was not aware of the feature until a few weeks ago, but apparently it’s been there since at least Mac OS 10.5. Script Debugger supports it, too! You can read more about the “documentation” element by invoking “man 5 sdef” from the Terminal:
\n\nWhen an element needs more exposition than a simple \u2018description\u2019 attribute can provide, use a documentation element. A documentation element may contain any number of html elements, which contain text that will be displayed at that point in the dictionary.
Given the sad state of support for AppleScript by Apple, and the continued low level of adoption by 3rd-party developers, a feature like this will probably never be widely used or celebrated. But at least in FastScripts 3.2.4, which I just released this morning, I’m now taking advantage of it:
\n![\"Screenshot](\"https://indiestack.com/wp-content/uploads/2023/01/SearchTextDictionary.png\" "\\"SearchTextDictionary.png\\"")
If you’re among the few remaining Mac developers who is investing time and effort into your AppleScript scripting definitions, hopefully you’ll find this feature useful!
\n", "date_published": "2023-01-02T11:15:37-05:00", "date_modified": "2023-01-02T11:32:05-05:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://indiestack.com/2022/11/opting-out-of-textkit2-in-nstextview/", "url": "https://indiestack.com/2022/11/opting-out-of-textkit2-in-nstextview/", "title": "Opting Out of TextKit 2 in NSTextView", "content_html": "Starting in macOS 13 Ventura, Apple is automatically opting-in most NSTextView instances to use TextKit 2, a modern replacement for the traditional NSLayoutManager based text system that has been part of Mac OS X since its debut.
\nThis change may bring a variety of surprises, so it’s important to test carefully if you use NSTextView. Somewhat unintuitively, you are more likely to be affected by the changes if you do little customization of the default NSTextView behavior.
\nApple explained the new opt-in behavior and some of the consequences in the 2022 WWDC session titled “What’s New in TextKit and text views”. They also explain that the decision to use TextKit 2 can be explicitly opted out of:
\n\n\nWhen you explicitly call an NSLayoutManager API, the text view replaces its NSTextLayoutManager with an NSLayoutManager and reconfigures itself to use TextKit 1.
\n
Perhaps the biggest risk for malfunction lies in scenarios where some significant customization is expected to work, but not in a way that affects the text view’s decision to carry on using TextKit 2. One such example is when it comes to customizing the drawing of the insertion point cursor. Since “the dawn of time” Apple has offered an overridable method on NSTextView:
\nopen func drawInsertionPoint(in rect: NSRect, color: NSColor, turnedOn flag: Bool)\n\n
A custom NSTextView subclass that thinks it can do better than Apple’s default text-colored vertical bar can override the method to impose its own dubious design choices:
\n![\"Screenshot](\"https://indiestack.com/wp-content/uploads/2022/11/RedGreenCaret.png\" "\\"RedGreenCaret.png\\""){kind=icon}
By default, starting in macOS 13 Ventura, the above customization will fail, because it is evidently not supported by TextKit 2. The simple workaround, for the time being anyway, is to force your text view to use TextKit 1. As explained in the WWDC excerpt above, this is as simple as asking it once for its layout manager, which will cause it to rebuild its entire text architecture to suit the TextKit 1 way of functioning:
\n\nlet _ = myTextView.layoutManager\n\n
I’ve filed FB11771261 with Apple, requesting that the functionality either be restored, or the method in question be overtly documented as non-functioning.
\nUpdate: The insertion point behavior described here is among many other bugs documented on Marcin Krzyzanowski’s STTextView project on GitHub. Looks like a good resource for folks who are curious about possible issues, and possibly a good alternative to NSTextView until/unless Apple fixes NSTextView to be more functional in TextKit 2 mode. Thanks to Greg Pierce for the link.
\n", "date_published": "2022-11-09T09:57:02-05:00", "date_modified": "2022-11-09T10:43:09-05:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://indiestack.com/2022/04/designing-macos-menu-bar-extras/", "url": "https://indiestack.com/2022/04/designing-macos-menu-bar-extras/", "title": "Designing macOS Menu Bar Extras", "content_html": "A great article by Marc Edwards, essentially the “missing manual” for macOS menu bar extras:
\n\nApple\u2019s HIG is great, but it doesn\u2018t contain much information related to designing menu bar extras. This article aims to provide additional details and context needed to create icons for macOS menu bar extras.
There are a lot of subtleties to get right, and this will help you if you are unfamiliar with the conventions!
\n", "date_published": "2022-04-26T10:00:19-04:00", "date_modified": "2022-04-26T10:00:34-04:00", "author": { "name": "Daniel Jalkut" } }, { "id": "https://indiestack.com/2022/03/quieting-cvdisplaylink-logging/", "url": "https://indiestack.com/2022/03/quieting-cvdisplaylink-logging/", "title": "Quieting CVDisplayLink Logging", "content_html": "In recent months I’ve noticed an accumulation of garbage log messages when I’m debugging an app in Xcode. Line after line along the lines of:
\n\n[] [0x124858a00] CVDisplayLinkStart\n[] [0x124858a20] CVDisplayLink::start\n[] [0x600003c3cee0] CVXTime::reset\n\n
Today I went digging to find the source of these log messages, and in the process I discovered a workaround that disables them. Just pass “-cv_note 0” as a parameter to the Run task in the Xcode scheme. Alternatively, you could disable them across all of your apps by setting this global default:
\n\ndefaults write com.apple.corevideo cv_note 0\n\n
The only downside to disabling the messages globally is that you will have to remember you disabled it if you ever decide you want to see massive quantities of Core Video debugging logs!
\nI discovered this user default by spelunking the system frameworks code from which they originate. After setting a breakpoint early in my app’s launch, I set a breakpoint on a variety of logging related methods until I discovered that these messages are all originating from a function called cv_note() in the CoreVideo framework. Within that function, there is a call to another function called “cv_note_init_logging_once”, and within that is a check for a user default value along with this tasty morsel:
\n![\"Screenshot](\"https://indiestack.com/wp-content/uploads/2022/03/ThanksForSettingCVNote.png\" "\\"ThanksForSettingCVNote.png\\"")
And thank you, Apple, for providing such a mechanism, even if it’s unfortunately configured to log by default. I filed FB9960090: “CoreVideo logging should default to 0”, requesting that Apple change the behavior of this initialization function so that if a user has not set the cv_note value to anything particular, it defaults to 0.
\n", "date_published": "2022-03-17T10:08:19-04:00", "date_modified": "2022-03-17T10:08:19-04:00", "author": { "name": "Daniel Jalkut" } } ] }