The compiler probably inlines the call to the comparison function, as opposed to qsort_b which has (of course) already been compiled so it has to make a regular function call. That makes a big differe

You can't edit your Info.plist, or change settings like these; the app bundle is immutable. At WWDC this year Apple said that they're getting stricter about App Transport Security exemptions like this

I don't see how they could be incompatible if they're the same size. The only 4-byte floating point type is 'float', so if the CG and NS types are using the same-size values, how can they be different

Historical reasons. AppKit predates Core Graphics (it predates Apple's acquisition of NeXT.) —Jens

I answered that yesterday. —Jens

NSData.bytes is a property of type "void*". And NSPointerFunctions even has a property whose type is a C function pointer: @property (nullable) BOOL (*isEqualFunction)(const void *item1, const void*it

TARGET_OS_MAC is incorrect — for some reason that evaluates to true on all Apple platforms. You want TARGET_OS_OSX instead. Here's the full list as documented in <TargetConditionals.h>, which is the h

No one said this was a property. It's just an instance variable. Also, it's fine for properties to be C types — after all, there are plenty of integer or boolean properties, and UIKit and AppKit have

The time to read and unwrap an integer from an NSArray is probably under a microsecond, so it's unlikely to be a performance problem. But there's nothing wrong with using a C array. It's what I'd do,

(IIRC you suggested using an NSMutableArray of NSNumbers?) Honestly, it depends. It does have overhead, although not as much as it used to, since NSNumbers of reasonable-size integers don't allocate a

This is a classic newbie networking mistake. (No offense I hope!) TCP is a stream, and there is absolutely no delimiter between writes, and no association between the number of bytes written vs. the n

You can't assign (or compare) arrays in C/C++. You have two options: (a) Call memcpy: memcpy(&myArray, &_mArray, sizeof(myArray)); (b) Wrap a struct around the array, since structs are copyable. Drawb

Right. You need to keep track of that yourself, like with a Peer class that can hold onto those streams and act as their delegate. NSNetService doesn't really have anything to do with those streams. A

It wouldn’t be a valid filesystem if it didn’t support the system calls like stat() that NSFileManager uses to get file attributes. Now, not every filesystem supports every attribute (you’re not going

If it did, it would break most apps, so no. —Jens

It does seem absurd that the most fundamental APIs — the C standard library and POSIX/Darwin system calls — aren’t supported by Xcode’s documentation features. Especially since the header files give z

For some reason lost in ancient Unix history, if you write to a file-descriptor that’s been closed at the other end, a SIGPIPE signal is raised. This will by default kill your process. It’s annoying b

LaunchDaemons is the wrong directory; that’s for system daemons that run outside of any user context. (I’m surprised you actually got this to work, because it’s difficult to present any UI from a daem

The call you showed runs the block on the main thread. That aspect may be crucial. Does the code this is part of run on a different thread/queue? Also, it can often be very useful to defer some code u

I think you resolve this by changing it to the form shown in the error messages, i.e. - (BOOL)isNiceAndHas: (NSArray *__autoreleasing *)friends; —Jens