3

I've a SDK in Swift 5.1 which our customer would like to distribute (sell) as a compiled SDK instead of giving its sources.

Unfortunately this SDK depends on some third party libraries, integrated using CocoaPods (Alamofire, RealmSwift, ReachabilitySwift, etc...). I know you should avoid having third party dependencies in your frameworks/libraries, but unfortunately we started working on this project after another agency started it. This SDK is actually a cocoapod's Pod, but it's not a compiled pod.

What is the best approach in order to distribute this SDK as a compiled SDK (in order to avoid giving source files to the final consumers who'll buy it) ?

As far as i've understood, if you compile your sdk with third party dependency, you must be sure the app that will use the same libraries with the same public apis as the one used by the compiled sdk, otherwise the app will crash at runtime. The only way to do so, as far as I understand, is to specify a very strict version of each third party dependency in the compiled sdk podspec. For example, Alamofire, '~> 4.2.0'. But I don't like this approach because this way the app can't use a newer version of Alamofire (or the other dependencies), only because the compiled sdk has been compiled with that version.

I'm creating an XCFramework, then a podspec with that XCFramework vendored as vendored_framework (using CocoaPods 1.9.0-beta2 which is the only one that currently supports XCFrameworks as vendored_framework).

I tried many different approaches, like trying to build the compiled sdk as static libraries and linking it's third party dependencies as static libraries too, but in this case when using it in the app, along with the same dependencies (e.g. Alamofire), i see in the console some "Class X is implemented in both Y and Z. Which one to use is undefined" (where Y and Z are the sdk and the app).

Have you any suggestion? How would you do that ?

Thank you!

Toto
  • 593
  • 7
  • 20
Marco Siino
  • 41
  • 1
  • 6
  • were you able to find a solution to this Marco ? – Shawn Frank Feb 16 '21 at 06:21
  • No shawn, we "simply" blocked all the dependencies' version to a specific minor version in the podspec, and we are distributing the SDK this way, and until now it seems to be ok. – Marco Siino Feb 17 '21 at 07:33
  • Hi Marko, you can convert all cocopods to a Swift Package Manager dependency. All listed libraries probably have an SPM version. This is how I solved it. You don't have to use the Cocopods. – MGY Apr 26 '21 at 12:45

1 Answers1

-2

When you say For example, Alamofire, '~> 4.2.0'. But I don't like this approach because this way the app can't use a newer version of Alamofire (or the other dependencies), only because the compiled sdk has been compiled with that version. I don't think you understood the concept of compiled SDK... When you package the SDK it will be static, so it doesn't matter the possibility of newer third-party dependencies, to update the SDK you need to release a new version to the customer, so you can upload when necessary... The customer isn't able to update the SDK by himself, not at all.

(should be a comment but too big for it)

Carla Camargo
  • 574
  • 5
  • 14
  • I know the concept of compiled SDK, I think instead you didn't understand my question ;) I know that who will use the compiled sdk, OBVIOUSLY, can't update/modify the compiled sdk itself to support a newer version of the third party library, because it is...COMPILED. The question is instead: if you lock the version of the third party dependencies in the podspec of the compiled sdk, the app will be bound to that versions of the dependencies (or version range), so in the example above the app doens't have the freedom to install, for example, Alamofire 4.3.0 in its Podfile. – Marco Siino Jan 23 '20 at 16:40