Open Source & Free  

TIP: Use iOS CocoaPods Dependencies in Native Code

TIP: Use iOS CocoaPods Dependencies in Native Code

Header Image

Last week I talked about using gradle dependencies to build native code, this week I’ll talk about the iOS equivalent: CocoaPods. We’ve discussed CocoaPods before but this bares repeating especially in the context of a specific cn1lib like intercom.

CocoaPods allow us to add a native library dependency to iOS far more easily than Gradle. However, I did run into a caveat with target OS versioning. By default we target iOS 7.0 or newer which is supported by Intercom only for older versions of the library. Annoyingly CocoaPods seemed to work, to solve this we had to explicitly define the build hint ios.pods.platform=8.0 to force iOS 8 or newer.

Including intercom itself required a single build hint: ios.pods=Intercom which you can obviously extend by using commas to include multiple libraries. You can search the cocoapods website for supported 3rd party libraries which includes everything you would expect. One important advantage when working with CocoaPods is the faster build time as the upload to the Codename One website is smaller and the bandwidth we have to CocoaPods is faster. Another advantage is the ability to keep up with the latest developments from the library suppliers.


  • 3lix says:

    I am not familiar with cocoapods.
    I have two questions:
    1) When adding a a cocoapod library would it work on all three platforms (iOS , Android and Windows? )
    2) In your previous post you had mentioned that there are over 18000 libraries. […]( Do they need to be converted to CN1LIBS before use (some sort of a JAVA api) ?

  • Shai Almog says:

    CocoaPods are used with native code similarly to the Android gradle build options being used for native code. This is important since libraries for iOS can sometimes be pretty huge (100mb+) thus become impractical for build processes.

    You need to build a cn1lib to wrap every library that’s required, e.g. Native Google Maps support transitioned to using CocoaPods instead of just bundling the maps. This was a HUGE benefit as it allowed us to keep up with the latest version from Google with no effort. But it also made the build MUCH faster as the original build size approached 50mb and would take forever to upload each time, not it can even be used by free accounts as it clocks under the free quota size.

  • 3lix says:

    Thank you for the explanation. This makes sense now

Leave a Reply