Sets APPLICATION_EXTENSION_API_ONLY = YES

[r-peck]

This currently causes a linker warning when using IDZSwiftCommonCrypto in an extension target.

[coveralls]

Coverage remained the same at 77.308% when pulling 34f8c9b on r-peck:extension-safe-api into be15046 on iosdevzone:master.

[r-peck]

Checking in on this since it has been open for over a month. Are there any concerns I can address?

[iosdevzone]

Hi @r-peck, sorry for the delay, I have a day job that limits the time I can spend on this stuff. The issue is that this option should also be set for CocoaPods so the podspec needs to be updated, tested and pushed at the same time as the release for this merge. CocoaPods recently have changed the recommended way of handling such issues and I haven't had time to check the best way as yet.

[r-peck]

No worries, I completely understand. Just wanted to give it a bump. I did go ahead and update the podspec in my branch to reflect the change, but understand you're looking into release process as well. Let me know if there's anything I can do to help or any further changes you need from my side. Thanks!

[coveralls]

Coverage remained the same at 77.308% when pulling c323116 on r-peck:extension-safe-api into be15046 on iosdevzone:master.

[iosdevzone]

Thanks for this, unfortunately there is some discussion about whether this is the correct way to do this. See issue #69 and follow this links to see.

[coveralls]

Coverage remained the same at 77.308% when pulling e77151a on r-peck:extension-safe-api into be15046 on iosdevzone:master.

[r-peck]

Yeah, see that now - the extension safe setting would be more problematic than the existing settings. I was testing it against an empty project, so it didn't cause any issues. Went ahead and switched it for all of them and tested. Project settings vs pod settings are what I would expect and everything builds fine.

[iosdevzone]

Thanks for this. I hope to get some time (over the weekend) to do a few tests and merge this. I really appreciate you help!

[beseder42]

Will it be possible to merge it soon?

[iosdevzone]

So for those of you waiting on this, what sort of extension are you building? I am trying to add regression tests for this to my release process and, at least for a watch extension, I am not getting the linker warning. I will try some other extension types but it might save some time if I know which extension type is producing it. (Don't get me wrong, I know the library should have this flag set, just want to introduce the test...)

[beseder42]

Did you set the "Allow app extension API only" flag in the "General" tab of your watch extension target? I use a CallKit extension and a framework and both trigger the warning after setting this flag.

[r-peck]

Unsure on the watch front, but for share extensions it definitely warns. Also for any framework targets that themselves need to be used in an extension.

[beseder42]

Is there anything we can help with?

[iosdevzone]

Hi folks,
Thanks for your patience on this. I've created a repo to show the problem I have with this pull request: https://github.com/iosdevzone/IDZSCCGitHub63.
I created this using Xcode 8.3.3 and CocoaPods 1.2.1 (but I am pretty sure this is what I saw with 8.3.2).
I created a single view iOS app, added a share extension, then quit. From the terminal I created a pod file with pod init added pod 'IDZSwiftCommonCrypto' and compiled. No warnings.

To ensure the optimizer wasn't smart enough to figure out that I wasn't really using the library I put in a logging command that printed an MD5 -- this would require the library to be linked.

I ran the project on device and simulator. No problem.

On inspecting the Pods project I noticed that "Require Only App-Extension-Safe API" is set to "YES"... so, in short, I think CocoaPods is setting this flag if the target is an extension.

BUT

Perhaps I made a mistake. Please take a look at the linked repository and let me know how mine varies from what your are seeing.

Sorry this is taking so long. Hard to get time to work on Open Source these days.

[r-peck]

It does look like CocoaPods handles it automatically without this change based on the type of the target. Carthage definitely does not (it has no concept of where you will be using the framework it builds), and the flag being set would help ensure future updates do not introduce extension-unsafe calls. Happy to revert the CocoaPods part of this PR if it is not needed.

[iosdevzone]

OK folks, thanks to all that helped out on that and also sorry that my worries about CocoaPods derailed things a little. I'll tag a new release in the next few minutes.