New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
adrianodiasx93 opened this Issue Feb 7, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@adrianodiasx93
Copy link

adrianodiasx93 commented Feb 7, 2017

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.

@adrianodiasx93

This comment has been minimized.

Copy link
Author

adrianodiasx93 commented Feb 8, 2017

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.

@ninjaprox

This comment has been minimized.

Copy link
Owner

ninjaprox commented Feb 10, 2017

@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.

@ninjaprox

This comment has been minimized.

Copy link
Owner

ninjaprox commented Jul 8, 2017

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

@ninjaprox ninjaprox closed this Jul 8, 2017

@adrianodiasx93

This comment has been minimized.

Copy link
Author

adrianodiasx93 commented Oct 11, 2017

@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.

@adrianodiasx93

This comment has been minimized.

Copy link
Author

adrianodiasx93 commented Oct 11, 2017

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

Will I be able to use NVActivityIndicatorViewable?

@ninjaprox

This comment has been minimized.

Copy link
Owner

ninjaprox commented Oct 12, 2017

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment