AppAuth-iOS: API_UNAVAILABLE(macCatalyst) prevents Xcode 10 from compiling version 1.3.0

Downgrading the version of the library to 1.2.0 solved my problem:

In my Podfile: pod 'AppAuth', '1.2.0'

Had to delete Podfile.lock and then run

rm -rf ~/Library/Caches/CocoaPods; rm -rf Pods; rm -rf ~/Library/Developer/Xcode/DerivedData/*; pod deintegrate; pod setup; pod install;

to reset and reinstall all pods

You could argue that not supporting Xcode 10 anymore is a breaking change, which would’ve warranted version 2.0.0 instead of a minor bump to 1.3.0.

Thanks for the clear explanation.

On our side we have a clear policy about iOS base SDK. And as of today, iOS13 has not been cleared out yet. So we must keep building under iOS12, which is not possible using Xcode 11 as Xcode does not allow to change the base SDK. So we have to stick with Xcode 10.

For the time being we will stay under AppAuth 1.2.0 then.

As iOS 13 is not required to be the base SDK until march 2020, do you think manually do the change you suggested will be enough to build AppAuth 1.3.0 under Xcode 10? I would not want to miss any new developments in the meantime.

You could even argue that this is because CocoaPods doesn’t allow specifying the minimum Xcode version.

This problem exists without the use of CocoaPods though. Opening the example project with Xcode 10 yields the same compilation error.

The policy of AppAuth is only to target the current base SDK, and current versions of Xcode (which is Xcode 11), which is why the Catalyst support doesn’t have Xcode checks. Using Xcode 11 you can still target back to iOS 8, as we support a deployment target of iOS 8.

We do use #if !TARGET_OS_MACCATALYST exactly in the way suggested by Apple that you linked (to guard against code not supported on Mac). If we wanted to support Xcode 10, the preferred approach would be using IOS version #defines, like so:

#if __IPHONE_OS_VERSION_MAX_ALLOWED >= 130000
#endif

This is what we use on the beta branches, for example.

So this isn’t a bug in the Catalyst implementation, it’s just the reality of us no longer supporting Xcode 10.

The reason we don’t support Xcode 10 is that there’s not really any value. You may as well be using version 1.1.0, as 1.2.0 and 1.3.0 add features that would simply be #ifdef’d out for you anyway.

To reiterate, while we only support the latest SDK for compiling, we support a deployment target of iOS 8, and if you need to build on older SDKs, you can always use older versions.

@anastely Use 1.2.0 instead of 1.3.0

Please see #489 (comment) above.

I am able to resolve this issue by below steps :

close Xcode rm -rf ~/Library/Developer/Xcode/DerivedData/ pod deintegrate pod install restart Xcode

Thanks for response.

Facing same issue. Any updates?

That’s an interesting point.

At surface level, this is not a “breaking” code change. The user doesn’t have to update their code due to the change from 1.2.0 to 1.3.0. On the other hand, users do have to update their compilation toolchain as Xcode 10 doesn’t compile the new code.

In the first place, the API_(UN)AVAILABLE macro is not anything new, so I imagine this change could’ve been tricky to determine as “breaking Xcode 10”.

You could even argue that this is because CocoaPods doesn’t allow specifying the minimum Xcode version. Rust crates has an ongoing discussion that seems very similar to this.

Same happening for me. For the time being I am staying on 1.2.0