Warning that may cause rejection on Apple's app review appears when using lib on an app extension

[Adriano Dias]

I am using NVActivityIndicatorView on a Today Extension, and I get the following warning:

ld: warning: linking against a dylib which is not safe for use in application extensions: /{path}/NVActivityIndicatorView

It seems such warning may cause rejection on Apple's app review. In Apple Documentation https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/ExtensionScenarios.html:

Make sure your embedded framework does not contain APIs unavailable to app extensions, as described in Some APIs Are Unavailable to App Extensions.If you have a custom framework that does contain such APIs, you can safely link to it from your containing app but cannot share that code with the app’s contained extensions. The App Store rejects any app extension that links to such frameworks or that otherwise uses unavailable APIs.

In this lib's case, I believe this happens because of the use of UIApplication, which is not available for app extensions.

I did some research and according to some github/stackoverflow users, it can be fixed by changing the "Require Only App-Extension-Safe API" build setting to Yes on the framework target.

To configure an app extension target to use an embedded framework, set the target’s “Require Only App-Extension-Safe API” build setting to Yes. If you don’t, Xcode reminds you to do so by displaying the warning “linking against dylib not safe for use in application extensions”.

However, if this doesn't work, it may be necessary to remove the use of APIs unavailable to App Extensions.

Could you please look into it? Soon I will be submitting the app to App Store, and I would like to continue using your lib.

[Adriano Dias]

Reading your code a bit more, I believe you use UIApplication only on NVActivityIndicatorPresenter. Such class will be used only when passing data to the methods startAnimating/stopAnimating. I guess you could add a parameter controller to ActivityData and use it instead of accessing UIApplication.shared.keyWindow. At least, it was how I did in my fork. Let me know if you agree or have a better idea.

[Vinh Nguyen]

@adrianodiasx93: Thanks for letting me know this. I didn't know that using UIApplication may cause rejection in use case of app extension. Your suggestion to use a view controller instead of UIApplication.shared.keyWindow makes sense to me. We could add view controller as additional param instead of putting into ActivityData like this startAnimating(_ data: ActivityData in viewController: UIViewController). I'll make this change soon, however, PR is more than welcome.

[Vinh Nguyen]

This's fixed in 3.7.0 by using subpod NVActivityIndicatorView/AppExtension.

[Adriano Dias]

@ninjaprox Some way I can achieve the same behavior of the subpod NVActivityIndicatorView/AppExtension using Carthage instead?

I don't use Cocoa Pods in my project.

[Adriano Dias]

Also, is there some drawback in using NVActivityIndicatorView/AppExtension?

Will I be able to use NVActivityIndicatorViewable?

[Vinh Nguyen]

@adrianodiasx93: I think it's possible by creating a branch with an appropriate target for Carthage, then point to that branch in Cartfile. The drawback will be removal of NVActivityIndicatorViewable and NVActivityIndicatorPresenter. However you still can replicate the same thing by yourself.

_{Sent with GitHawk}