Isn't that just the normal behavior of the app sandbox? Sandboxed apps aren't allowed to access arbitrary areas of the filesystem, unless the user has implicitly given permission by navigating to a

macOS 11.1 There are quite a few folders, which behave absolutely normal using the Finder, but when my App tries to do: open(folderPath, O_RDONLY) it gets an EPERM error: "Operation not

I found the SimpleCocoaBrowser (thanks very much for your hint) and it works just fine. The BrowserDelegate (called AppController in the sample code) implements 4 required + 1 optional methods: -

Back when I was first starting to develop my UI Browser product, https://pfiddlesoft.com/uibrowser, there were three helpful Objective-C Cocoa code examples for NSBrowser from Apple:

Xcode tells me that: 'matrix(inColumn:)' was deprecated in macOS 10.10: Use the item based NSBrowser instead And when I use parentForItemsInColumn it crashes with: parentForItemsInColumn: is not

I’ve used CoreImage (CIBlendWithMask filter) to use a

Hi all, I am using Core Graphics. I have an image as a PDF resource that I want to use as a mask - specifically, the PDF only contains black and white graphics as vectors. I have code that can turn

Thanks Jack, yes, your point is well taken… but, these are in house production apps/frameworks and we have a long running well establish deployment design that works well… The structure is as

I wonder if you might want to embed the library in your application. That might make it more future-proof. Jack

Thanks for everyone’s thoughts… I really appreciate it. I would think, that’s where I went wrong apparently :D, that Xcode should respect explicit configurations, which is what I thought I had

Begin forwarded message: From: Jonathan Prescott <jprescott12@...> Subject: Re: [cocoa-dev] Ensure Framework Links to static lib not dylib Date: December 10, 2020 at 1:50:14 PM EST To:

If we have more than one of us manually adding .a, there probably must be a process that does this automatically that we don’t know about. Any ideas?

In the Other Linker Flags build setting, you can add the full path to a library instead of something like -lFoo, ensuring that you get the right one.

I fell over this the other day. If you have both the .a and .dylib in the same directory, Xcode will link in the .dylib even if you've explicitly added the .a to your "Link with ..." in the build

I have a Framework and am adding support to it from code located in an external library. I have added the ‘.a’ version of the lib to the project (build phase link to…) I dragged it to the

That makes perfect sense. Is the header the umbrella header for the framework? Is so, then the < > brackets would make more sense since they would restrict searching for headers inside the framework

I don’t have any special insights, but I think the warning is correct in that there has for some time been an (unwritten?) rule that the #imports *inside* a framework header should use angle

I was wondering about that myself. I have header files that are internal to the framework so shouldn’t be public. From: <cocoa@apple-dev.groups.io> on behalf of "Graham Cox via groups.io"

I’d check to see why it expects < > angle brackets but it seems as if you’ve done all the research. This seems to point in the right

I just updated to XCode 12.1, and my project is throwing a lot of new warnings about “double-quoted include in framework header”. This appears to be because of the build setting “Quoted include