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

Turning off "Allow debugging during browsing versions" helps this work like it should, but still not perfectly. The windows tend to appear in the right order and location, but their rendering is still

I'm trying to figure out why the versions browser is doing this weird thing with my windows. A video is linked below. The top-left corner of each window contains a timestamp for when the window gets

Ok perfect - thanks Jens - that's exactly what I needed to know. Leo

I would use NSFileManager. CloudKit is for storing a server-side database that supports queries, indexes and sharing … that's overkill for a simple settings file. Also, I believe if you use the

A question for those experienced in iCloud: I want to implement some very basic iCloud tasks in my apps. Just to sync a few XML files that contain settings presets. So that the users can access

The shows this property: @property (readonly, copy) NSArray *results; // this is for K-V Bindings, and causes side-effects on the query Anybody know what the cryptic comment means about

Correct. Older apps (build with some SDK < 14) get the default value for "Privacy - Local Network Usage Description” and do not require "Bonjour services” when run in iOS 14. Gerriet.

Oh, right! It's the "Access local network" permission. I've seen that pop up. The Info.plist key must be required only if you build the app against the iOS 14 SDK, right? Otherwise that would break

I watched "WWDC 2020 - Support local network privacy in your app” and found out that in iOS 14 the Info.plist needs additional info: • Privacy - Local Network Usage Description if not present -

I'm guessing your network environment includes a DNS server that supports DNS updates (i.e. wide-area Bonjour) but you don't have the credentials to push updates to the DNS server. This error probably

This worked up to iOS 13: let serviceType = "_Gmd-BackGround._tcp." let parameters = NWParameters() parameters.includePeerToPeer = true let browser = NWBrowser(for: .bonjour(type: serviceType,