Require Xcode 7.3 due to NS_SWIFT_NAME

[1ec5]

We’re using the NS_SWIFT_NAME macro in a few places in MGLMapView.h, breaking compilation in versions of Xcode before 7.3. MGLTypes.h should #define NS_SWIFT_NAME to nothing if that macro is undefined.

Alternatively, we could require Xcode 7.3 and simultaneously inline all our uses of NS_ARRAY_OF and company, which are intended to keep Xcode 6.x happy.

/cc @friedbunny

[1ec5]

Defining NS_SWIFT_NAME to nothing will avoid an error on Xcode 6.x but not Xcode 7.0–7.2, in which the macro is defined but can’t be used on methods they way we’re using them.

At this point, MGLTypes.h is so chock full of workarounds for Xcode 6.x that we should just require Xcode 7.3; it isn’t much trouble to upgrade 7.0 to 7.3 anyhow. If @mapbox/gl agrees, the next steps are:

• Document Xcode 7.3 is a requirement for building the iOS and macOS SDKs
• Inline NS_ARRAY_OF and company and remove these aliases from MGLTypes.h
• Remove MGLTypes.h import statement from any header that’s only importing it for the nullability macro compatibility shims

[kkaefer]

I'm fine with requiring Xcode 7.3. Do we have statistics on what versions are still in use out there? Given that Xcode typically auto-updates, I imagine there aren't many older versions out there?

[1ec5]

I’m unaware of any publicly available statistics on Xcode version usage. Typically Mac and iOS developers either stay up-to-date or stick to the previous major version. The latter case sometimes happens in large companies that have cumbersome upgrade processes. If a developer codes against the iOS 9 SDK in Xcode 7, it’s easy and entirely normal to deploy backwards to iOS 7 or 8. The only other argument I can think of for supporting Xcode 6 would be that a developer has written so much Swift 1 code that migrating to Swift 2 would require significant effort – in which case we’d be doing them a favor by acting as their forcing function.

[friedbunny]

Xcode 7.3 is evidently already a requirement — trying to use Xcode 7.0-7.2 will throw Only factory methods can have the swift_name attribute..

[friedbunny]

Per chat with @1ec5, we still need to have different NS_ARRAY_OF definitions to support iOS 8 and macOS 10.10.

[friedbunny]

Theoretically something like this could work:

// Versions of Xcode lower than 7.3 do not fully support NS_SWIFT_NAME.
#if defined(__apple_build_version__) && __apple_build_version__ < 703029
    #undef NS_SWIFT_NAME
    #define NS_SWIFT_NAME(_)
#endif

... but we’ve already broken backwards Xcode support in other ways, so I’m going to forge ahead with requiring Xcode 7.3.1.