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.
Related
So, we need to integrate a library in our application, which is gonna be developed by another organization. This library will wrap some other, external, libs and export them to our app + an small sdk to handle a specific flow. At the end, this sdk is going to make some network calls.
The developers of the library are asking us to provide dependencies if any and how to distribute the lib.
We will agree on cocoapods, minimum sdks, and i think its wise to tell them to use the same swift version we are using as well as the same Alamofire version.
Any other suggestions?
Thanks all in advance!
If you are using cocoa pods for the integration of the plugins, the resolving of the dependencies will be managed by cocoa pods. In the .podspec file of the plugin, you can define dependencies of the plugin itself. (podspec documentation)
If you are currently developing the plugin you might hit some incompatibilities, but if you have contact to the developers of the plugin, those should be solvable.
I am working on an iOS framework, I need to have some guidelines on third party framework dependencies.
Suppose I need to use some open source framework(e.g.: AFNetworking) to build my own framework and my framework will be used by some partner applications who also using the same AFNetworking in their main project. Or their app is using another library/framework that is also using AFNetworking.
So my intension is to avoid integrating that AFNetworking into my framework and asked to partner to do that by their own through proper guidelines, I mean with documentation.
So what should I don in my app side as well as the process that partner app should follow. Actually to clarify the dependencies.
Any on hand tutorial will be great. Thank you :)
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?
I'm making a framework (an SDK) that will be made public. I'm thinking about a situation when it's not distributed via Cocoapods / Carthage, but rather via a simple Downloads page.
In the SDK I need to provide users an opportunity to login and share via Facebook, so I would like to use appropriate Facebook SDKs (FBSDKLoginKit / ShareKit, I assume). But if the end user of my SDK will also have these Facebook SDKs (or any other duplicate dependency), there will be a conflict.
What is the proper way to handle this situation without using Cocoapods / Carthage? I believe, one way is to avoid including / statically linking dependencies into my framework, but rather have end users download dependencies separately, but maybe there is another way around it? Making people download tons of libs from different sources isn't very convenient.
The question isn't about Facebook SDKs in particular, but about a general situation with third-party dependencies when developing a framework / library.
P.S. I found this question: Integrate Facebook SDK inside my iOS Framework. But it's specifically about Facebook, and it might be outdated (a lot of stuff happened in the iOS world since 2014).
UPDATE: the SDK will be closed source.
You could do a combination of the two ideas you suggested:
Don't include the other SDKs directly in your framework, but have them in the same project when the user downloads it. That way, if the user doesn't already have them, they can copy over all of the frameworks that they need. And if the user does already have them, then they can just copy your SDK by itself and have it just work in their project.
This combination also allows you to include tests and samples in the download. Then users end up downloading a complete, functioning project that they can try out before integrating it with their own code.
I want to add add 3rd part library to my library (which will be used by other developers), so if I have for example this class SBJson do I prefix it with my two letter prefix to be EXSBJson also I saw somewhere somebody is using underscore EX_SBJson. What is the naming convention/style in this case?.
There is no general convention, but we have used the following approaches:
Use the same prefix as the library (so if we develop XYFunctionality, we would name it XYSBJson). A lot of source projects use this approach (e.g. Dropbox)
Talk to other devs, if possible. In most cases, it is enough to distribute the library separately from 3rd party libs (so we ship a .a binary file and a working source project of the 3rd party library so other devs can use it). This also allows other devs to upgrade the 3rd party library to get bugfixes as long as there aren't breaking API changes.
Btw. much of what SBJson does can also be done using NSJsonSerialization which comes with iOS 5+