Fixed deprecations

[bpoplauschi]

• Replaced Replace deprecated identifiers #317 - NSGregorianCalendar deprecated in iOS8 and Mac OS X 10.10 replaced with NSCalendarIdentifierGregorian. Could not check for availabilty of the constant directly, since it is defined earlier, but not available for iOS
• Replaced Undeprecate lumberjack for iOS 8. #312 - aslresponse_next and aslresponse_free deprecated, replaced with asl_next and asl_release
• Updated a Podfile.lock for the CaptureASL project

[rivera-ernesto]

Looks good and Travis likes it ;)

[jmkk]

ASL changes with a check for __IPHONE_8_0 break building for the simulator (7.1 or 8) when using Xcode6 with SDK7.1

Apparently Availability.h header gets pulled in from the iPhoneSimulator8 SDK - which has __IPHONE_8_0 defined, but then linking fails as SDK 7.1 doesn't know about asl_next()/asl_release().

Seems a more appropriate fix would be to use min version check:

#if defined(__IPHONE_8_0) && __IPHONE_OS_VERSION_MIN_REQUIRED >= __IPHONE_8_0

(plus a similar check for the Mac OS)?

[rivera-ernesto]

It is not a good idea to use SDK 7.1 with Xcode 6. You should always compile against the latest supported iOS/OS X SDK.

Either keep using Xcode 5.x or compile against SDK 8.

[jmkk]

Thanks for the suggestion, but could you please provide a reference to Apple's documentation which confirms that I "should always compile against the latest supported SDK"?

The idea behind the SDKROOT build setting is to be able to choose a base SDK - a current one (the most common case), or an older one, as needed for the specific project.

Even without considering using an older SDK with a newer Xcode, checking for __IPHONE_8_0 define is not a good idea for projects that still target devices with older version of iOS, which know nothing about the new ASL APIs.

[rivera-ernesto]

It's important to understand that using an older SDK is a temporary workaround, not a solution.

https://developer.apple.com/library/ios/qa/qa1806/_index.html

Even without considering using an older SDK with a newer Xcode, checking for __IPHONE_8_0 define is not a good idea for projects that still target devices with older version of iOS, which know nothing about the new ASL APIs.

If __IPHONE_8_0 is unknown at compile time the new API calls will get striped from the code automatically.

[jmkk]

Thanks for the link. It confirms it is a supported workaround, and apps built with an older SDK do get accepted by Apple into the store.

If __IPHONE_8_0 is unknown at compile time the new API calls will get striped from the code automatically.

My point is that even though __IPHONE_8_0 is known at compile time with SDK8, when deploying for iOS7 the API calls would fail at run time:

dyld: Symbol not found: _asl_next

[rivera-ernesto]

Wait. You're right! We need to:

• Check at compile time if __IPHONE_8_0 is available to avoid build errors.
• Check at runtime which system version are we running on to actually make the call or not.

I think we can fix it on the upcoming 2.0.0 release as no production code should use Xcode 6 yet.