Doesn't compile for extension targets (iOS8)

[tifroz]

The compiler protests when compiling for an extension target 'sharedApplication' is unavailable: not available on iOS (App Extension) - Use view controller based solutions where appropriate instead.

(Line 741 UIInterfaceOrientation orientation = [UIApplication sharedApplication].statusBarOrientation;)

[JVillella]

Hey @tifroz here's how we fixed this issue in our project (more of a temporary solution really). Replace line 741 (the one you quoted) with:

#ifndef APP_EXTENSION
    UIInterfaceOrientation orientation = [UIApplication sharedApplication].statusBarOrientation;
#else
    UIInterfaceOrientation orientation = UIInterfaceOrientationPortrait;
#endif

And in your preprocessor macros for your extension target add APP_EXTENSION. Here are the steps to do that if you haven't before:

1) Under your project/target click "Build Settings"
2) Find (or search) fir "Preprocessor Macros" under Apple LLVM 6.0 - Preprocessing
3) Add APP_EXTENSION in both the debug and release sections.

If the owners of the project are okay with this approach I can make a pull request.

[matej]

Hm.. I wonder if there's a better solution for this. This code path is not even needed on iOS most of the time, however there seems to be an exception for windows with no root view controller (#247).

http://stackoverflow.com/questions/24166878/how-to-detect-orientation-change-in-custom-keyboard-extension-in-ios-8

[matej]

I hope dc534dcb31a81e952b9d29de2189af3a56da91c6 makes things a bit better.

[tobihagemann]

Not sure if I should open a new issue, but I have the following problem: I'm still getting the error, because CocoaPods sets the iOS deployment target of the MBProgressHUD pod library to 4.3. I've played around with the settings and it seems to be that only the MBProgressHUD pod library is relevant for __IPHONE_OS_VERSION_MIN_REQUIRED. It doesn't matter if my main project's target is set to 8.0.

I can't say for sure if this is a new issue (introduced in CocoaPods 1.0.0.beta or MBProgressHUD 0.9.2), but now I'm uncertain on how to deal with it properly. I know it's safe for me to delete the code temporarily, because I'm only targeting iOS >8.0, but it would be great if there is a better solution.

[matej]

We still do a runtime check, so the [UIApplication sharedApplication] call won't actually be performed in your case. However we'd need to do some obfuscation here to silence the compiler. Or perhaps we can silence the warning somehow.

[tobihagemann]

It's a compile-time issue. I'm not aware of a way to silence the compiler in this case, because it's not a warning, it's an actual error.

I've solved it for now by using a post_install hook, probably the best way for now without deleting code or having to increase the deployment target of the whole library:

post_install do |installer|
    installer.pods_project.targets.each do |target|
        if target.name == "MBProgressHUD"
            target.build_configurations.each do |config|
                config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '8.0'
            end
        end
    end
end

[matej]

We could do something like [UIApplication performSelector:NSSelectorFromString(@"sharedApplication")]. Not ideal, but it should silence the error and be safe, since the runtime version check will prevent the code from being executed.

[tobihagemann]

App Extensions seem to be something rarely implemented. In my opinion you shouldn't reduce code quality, just because of edge cases. Your suggestion would work and probably won't break anytime soon, but it doesn't feel right. :D

I've made the experience that developing a library / a framework to be compatible with App Extensions could become cumbersome. Having backwards compatibility for iOS versions <8.0 doesn't make it easier.

You could either let the App Extension developers have the trouble of using a post_install hook (or any other non-destructive solution), or maybe drop legacy iOS versions. Of course you could also solve everything with "hacks", but I'm skeptical. ;)

[ayushgoel]

Are we planning a release soon? (with the fix for this issue) The last release was in Dec 2015.

[tobihagemann]

Just wanted to inform that using subspecs could be an elegant solution: https://github.com/CocoaPods/CocoaPods/issues/5373

Haven't tried it out myself, but I think this should be the way to go to deal with App Extension compatibility.

[SebastianKeller]

Any update on this? We just hit this bug :-/

[tobihagemann]

Are you positive? I've revisited this issue and updated MBProgressHUD to 1.0.0 in my project. I was even able to remove my post_install hook workaround (which was needed for versions below 1.0.0 to the best of my knowledge). I don't have any compile-time issues and I'm heavily using app extensions.

I would even say that this issue can be closed. :smile:

[SebastianKeller]

Thanks for the response!

Nevermind, just realized we are using V0.9 at the moment. (Dependency of another pod.) Sorry, my bad.