# Objective-C API availability checks give wrong results

**URL:** <https://travis-ci.community/t/objective-c-api-availability-checks-give-wrong-results/6144>\
**Category:** macOS\
**Created:** [November 26, 2019, 3:11am UTC](https://travis-ci.community/t/objective-c-api-availability-checks-give-wrong-results/6144 "2019-11-26T03:11:47Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![patr0nus](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/patr0nus/32/3240_2.png) [@patr0nus](https://travis-ci.community/u/patr0nus)\
**Post date:** [November 26, 2019, 3:11am UTC](https://travis-ci.community/t/objective-c-api-availability-checks-give-wrong-results/6144/1 "2019-11-26T03:11:47Z")

</div>

On old versions of macOS I get failed tests which turn out fine on my own machine. It seems that the macOS environments on travis CI give wrong information about ObjC API availabilities. Here is a simple ObjC program to demonstrate the issue: [https://github.com/patr0nus/travis\_objc\_if\_available/blob/63a928b63ae7bf9aed1dda6456da885887df3565/objc.m](https://github.com/patr0nus/travis_objc_if_available/blob/63a928b63ae7bf9aed1dda6456da885887df3565/objc.m)

On travis I compiled this program on 10.14 and ran it on 10.11-10.13. Here is the results:

[https://travis-ci.com/patr0nus/travis\_objc\_if\_available/jobs/259338793](https://travis-ci.com/patr0nus/travis_objc_if_available/jobs/259338793)

[https://travis-ci.com/patr0nus/travis\_objc\_if\_available/jobs/259338794](https://travis-ci.com/patr0nus/travis_objc_if_available/jobs/259338794)

[https://travis-ci.com/patr0nus/travis\_objc\_if\_available/jobs/259338795](https://travis-ci.com/patr0nus/travis_objc_if_available/jobs/259338795)

macOS 10.11-10.13 all claim that the 10.14 APIs are available but they are actually not. This break tests that depend on the API availability checking.

---

<div class="post-metadata">

**Author:** ![native-api](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/native-api/32/430_2.png) [@native-api](https://travis-ci.community/u/native-api)\
**Post date:** [November 26, 2019, 11:38am UTC](https://travis-ci.community/t/objective-c-api-availability-checks-give-wrong-results/6144/2 "2019-11-26T11:38:03Z")

</div>

According to [https://developer.apple.com/documentation/swift/objective-c\_and\_c\_code\_customization/marking\_api\_availability\_in\_objective-c](https://developer.apple.com/documentation/swift/objective-c_and_c_code_customization/marking_api_availability_in_objective-c), `@available` checks availability at compile time, you need to use `#available` to check it at runtime.

---

<div class="post-metadata">

**Author:** ![patr0nus](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/patr0nus/32/3240_2.png) [@patr0nus](https://travis-ci.community/u/patr0nus)\
**Post date:** [November 27, 2019, 3:51am UTC](https://travis-ci.community/t/objective-c-api-availability-checks-give-wrong-results/6144/3 "2019-11-27T03:51:47Z")

</div>

It turns out it IS a runtime/compile-time thing, but not that simple.

`if (@available(...))` in Objective-C should be a runtime check, just like its swift equivalence `if #available(...)`. But the compiler optimizes the else branch out in release builds, because it assumes the program will only be deployed on the same version of macOS where the compilation happens.

To force the compiler to do the check at runtime one must tell the compiler that the program could run on an older macOS by setting the MACOSX\_DEPLOYMENT\_TARGET environment variable.