My guess is that this is not a compiler-related difference, but rather the effect of different algorithms. The performance depends on the initial ordering of the array. My recollection of this subject

I tried this in Xcode Version 8.3.3 (8E3004b) (Swift 3) and: 1. it works: thank you very much. I never would have figured this out from the documentation alone. 2. qsort_b is about 2.25 times slower

Yikes, this is masochistic! This is the prototype: So I think the code looks like this (syntax-checked in Xcode 9 but not tested): The “&sortedArray” relies on the compiler auto-bridging to the

I have an array: var sortedArray = [UInt32]() for _ in 0 ..< limit { sortedArray.append( arc4random() ) } sortedArray.sort() This works fine. I would like to compare the efficiency of “sort”

macOS 10.12.6 / Xcode 8.3ß6 / Swift 4 / developing for iOS I am working on a custom object which derives from UIScrollView (at least for now...see below). For initial testing, I am placing it on a

Thanks, that’s what I suspected love this Group!!! cheers Bill Pitcher bill@...

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

At my last company, we used it in our iOS apps and they shipped.

Great list, Provided the App Store review allowed it, would having a Preference that adds and sets the info.plist NSAppTransportSecurity/NSAllowsArbitraryLoads to true break my App Store

It is actually the property flipped on NSView. isFlipped is the getter function. The doc says: "If you want your view to use a flipped coordinate system, override this property and return

https://developer.apple.com/documentation/appkit/nsview/1483532-isflipped No, of course not. `isFlipped` does not exist on UIView. -b

Hi, I’m trying to find some docs on isFlipped. When I search for it in the XCode docs, it only brings up a reference in NSImage and that’s deprecated. I’m overriding this on some Classes on

Thanks a lot Quincey and Jens for your through explanation - I had imported some Mac code from another project which uses NSRect’s and as my original project was iOS this caused compile errors, so

Opening up a macOS project and looking at the definition of NSPoint, I see: So, it was the same size as CGPoint, but a different struct name, which was enough to create an ABI incompatibility. You

Sure, why not, at least for Obj-C? The method description says, "Allocates a new instance of the receiving class, sends it an init message, and returns the initialized object." And I checked out

Here are the definitions copied from my iOS SDK headers. The types/sizes for CGFloat and NS[U]Integer track the 32-/64-bit architecture used to build a particular executable. typedef CGFLOAT_TYPE

I don’t remember the exact details either, but one issue is that there are places in the Obj-C runtime/metadata/whatever where the @encode string of a method signature matters, and some similar

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

There are “really” four different SDKs: — 32-bit macOS — 64-bit macOS — 32-bit iOS — 64-bit iOS They are different in the sense that certain basic C types (such as int and float) are

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