There’s no easy way to limit this breakpoint to the calls getting just the bundle ID. I should’ve known: an app needs its main bundle for many reasons: for example, getting resources. When I ran the app, I was greeted with a flood of calls, too many to analyze. I thought putting a breakpoint on this method would allow me to find every place that checks for bundle IDs. My first approach was to attach a debugger to VS Code, and examine every access to the main bundle of the app.Īll accesses to the main bundle, including Cocoa’s + and Carbon’s various methods, eventually uses CFBundleGetMainBundle().

Thus, I had to manually find which method is actually responsible for the bug. However, IDA Free’s “Xref” command showed multiple method all checking for com.microsoft. I found the “com.microsoft.” text when running strings on AppKit: so it’s checking it somewhere. I then started looking for the misbehaving patch. I was able to reproduce the issue, and confirmed that changing the bundle ID fixes it. But which one? And how can we disable it? Narrowing down the issue This definitely sounds like a misbehaving compatibility patch, since it’s only applied to specific bundle IDs. (screenshot by VS Code developers realized the issue only happens if the bundle ID begins with com.microsoft. VSCode, it turns out, couldn’t display native macOS tabs on High Sierra: after selecting Window->Merge Window, there should be a tab bar at the top of the window:īut on High Sierra, the bar is completely empty: IntroductionĪfter writing the AppKit Bundle ID post, a Visual Studio Code developer reached out to me about one misbehaving bundle ID check. I also learned to avoid introducing new bugs in bugfixes. I helped track down the misbehaving macOS compatibility patch that broke native tabs support in VS Code.

Visual studio code macos