How to use 3rd Party Libraries in Ios Extension? - ios

I want to use AsynchronousImageView and AsynchronousNetworking classes in Keyboard Extension. Can you Please tell How to use this classes in code. I has implemented AsynchronousImageView code its compile perfect but during run time it will crash..
my code is:
self.imageVw.ImageUrl=[NSURL URLWithString:#"http://www.gamacompass.com/imagesuploaded/000001631/_thumbnails/sku_3451_000001631_large.jpg"];

As i found in apple documentation we need one flag to use that library in extension.
Use any API marked in header files with the NS_EXTENSION_UNAVAILABLE macro, or similar unavailability macro, or any API in an unavailable framework

Related

Can a Framework Collision happen in a Swift SDK?

I am trying to develop a library, and then distribute it later as an SDK. In that library I am thinking of using a third party library.
What I am afraid of is if one of my users also include that same third party library. Would it still build? Otherwise, is there a way around this issue?
Note that I cannot use CocaoPods.
Yes, this can and will collide. You must not include a third-party library inside your library. You must have the app link both your library and your dependencies at the app layer. Tools like CocoaPods, Carthage, and SwiftPM simplify this. If you cannot use those, then you must provide instructions to your users of what libraries they must link.

Using a third party library inside a framework

I am building an SDK which uses some third party library (for example, AFNetworking).
As far as I know, if an app using my SDK also wants to use the same library, it will end up generating a compile error with duplicate symbols.
What is the best way to overcome it?
Thanks!
P.S. I understand that prefixing the library's files inside the framework with some SDK prefix will solve the problem, but is there a cleaner way?

How do I build a Cocoapod framework for swift, while keeping implementation details hidden?

I am trying to build an iOS swift framework to display encrypted photos. Photos are sent by my server (something like a hashed binary file) after calling a specific API with specific details. I will then decrypt the photo, and display it to the user.
Correct and point me in the right direction if I am wrong, but swift only allows frameworks - meaning no static library. And this will expose my implementation details (such as the method to decrypt my photo).
What I would like to achieve is to create a cocoapod distributable framework for paid developers to implement (once they subscribe to me). It is supposed to expose simple public APIs, and hide implementation details.
I have tried various ways to achieve that but to no avail. I would really like to keep the implementation to swift codes only, with minimal Obj-C codes.
Build a swift framework, and build an objective-c static library as a wrapper
But I cannot seem to get it to work. Any idea if this is possible?
Build a swift framework in a swift framework
Stupid idea, i'm able to see the framework's implementation details within the other framework...
Build a swift framework, and build an objective-c framework as a wrapper
I cannot seem to get this to work either...
I have been working on this project for about 2 weeks now, and have been all over Googling for it. Just in case anybody would like to try, you may try to do the following and check if it works.
Cocoapods Friendly Framework
Implementation Details Hidden
Uses Alamofire (or any public framework that connects to internet)
Any help would be appreciated, thanks!

Using CommonCrypto in Swift generates not safe for use in extensions warning

I've created a simple lib to use HMAC digest for Swift called "SweetHMAC". This lib is so simple, basically is a wrapper to CommonHMAC.h in Swift.
I can build and deploy any iOS project using SweetHMAC correctly but, seems by some security issue, my approach is not safe. There is the warning I receive after run the iOS tests for example.
warning: linking against dylib not safe for use in application extensions
This code is not safe enough to put in iOS AppStore, and the app can be rejected by that. For OSX, there is no problems.
I know, there are HMAC ports for Swift, but my challenge is to try to enable Swift to use CommonCrypto safely.
I have implemented this project using this approach and works fine!
My question is, how possible is to create and use use modules like CommonCrypto in Swift frameworks safely for iOS?
Looking at the documentation from Apple, the suggestion for said error is to make sure that the option of using "Require Only App-Extension-Safe API" is checked.
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”.
Here's the full documentation on extensions
It is also worth noting that parts of the CommonCrypto API might not be available, as per this discussion

Whirlyglobe private API complain during app submission

I have a simple app which uses whirlyglobe framework (2.2). Otherwise, it is pretty basic program with Apple frameworks.
When I tried to validate the app (and during the distribution, Xcode complains that my app is using private API; specifically it calls "rootElement", and "attributeForFont:". I suspect these functions are part of WhilyGlobe component distribution.
What is the easiest way to remove those files from the framework? Do I need to have the source and compile the framework myself? Or is there a simpler way?
Solved. Here is what I did:
1) Searched in github repository of WhirlyGlobe and found the file that uses the functions which caused issue.
2) I did not need the functionality provided by the file that had the functions.
3) Removed the references (class instantiation) to the file from my project.
That's actually part of the KissXML framework and the implementation is in there. I suspect Apple's test is in error.
In any case, if you're not using the WMS functionality, you can probably drop it out just fine.

Resources