Trying to get ObjectiveDDP Pod to work

[rclai]

HI all, I tried adding the ObjectiveDDP pod but its classes are not exposed in my app. I followed these instructions: https://www.nativescript.org/blog/using-cocoapods-is-a-piece-of-cake-with-nativescript-1.3.0

My error:

JS ERROR ReferenceError: Can't find variable: ObjectiveDDP

I also confirmed via the debugger and don't see the pod's classes in the global scope.

Has anything changed since then or am I missing something?

My project was able to build and install the pod and its dependencies. I'm on El Capital, 0.39 CocoaPods and here's the Podfile generated in my platforms/ios folder:

use_frameworks!
# Begin Podfile - /Users/profab/Desktop/Smartie-App/Smartie App/node_modules/nativescript-objective-ddp/platforms/ios/Podfile 
 pod "ObjectiveDDP" 
 # End Podfile 

Podfile.lock:

PODS:
 - M13OrderedDictionary (1.1.0)
 - ObjectiveDDP (0.1.8):
 - M13OrderedDictionary
 - SocketRocket (= 0.3.1-beta2)
 - SocketRocket (0.3.1-beta2)

DEPENDENCIES:
 - ObjectiveDDP

SPEC CHECKSUMS:
 M13OrderedDictionary: 6e157fe9c82aa6b3cd7198f5c5c30c7a6834c4a6
 ObjectiveDDP: 87609d002487bdb2e81b460de707b684551c04de
 SocketRocket: 7284ab9370a06c99aba92b2fe3a32aedd0f9a6fa

COCOAPODS: 0.39.0

I'm also targeting iOS 7.1. TNS 1.4.3, TNS iOS 1.4.1.

[rclai]

In another attempt, I tried to get the build to install the app on my device via Xcode instead of TNS and was able to get this error:

ld: warning: directory not found for option '-F/Users/profab/Desktop/Smartie-App/Smartie App/platforms/ios/../../lib/iOS'
ld: framework not found M13OrderedDictionary
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[ivanbuhov]

Hi, @rclai, when using CocoaPods, NativeScript CLI bumps the depoyment target to 8.0. You may have noticed tha following message when running tns prepare ios:

The iOS Deployment Target is now 8.0 in order to support Cocoa Touch Frameworks in CocoaPods.

I guess you have manually edited platofrms/ios/Smartie App.xcworkspace in order to target iOS 7.1. Please make sure the deployment target is set to 8.0 and try reproducing the issue.

If you really want to target iOS 7.1 you have to give up using CocoaPods. In this case, your best solution is to drop pre-built static frameworks in {your-plugin}/platforms/ios folder and the CLI will do the rest of the work.

[rclai]

Oh okay, so what is the procedure of including iOS libraries without using CocoaPods?

[rclai]

I changed the deployment target to 8.0, but I am still not seeing the exposed JS variables.

[ivanbuhov]

In order to use my comment for future reference I will describe the whole story from start to end.

Basically there are four types of "packages" in the iOS world:

1. static library (libMyLib.a) which comes with a headers folder (usually called include) containing .h files.
2. shared (dynamic) library (MyLib.dylib) which also comes with a headers folder (usually called include) containing .h files.
3. static framework (MyFramework.framework) which is an ordinary static library wrapped in a framework (most of them come without the needed module.modulemap file in it)
4. shared framework (MyFramework.framework) which is an ordinary shared library wrapped in a framework (with module.modulemap file incldued)

Theoretically speaking, NativeScript for iOS supports all of these (without even using plugins), but all of them require a manually editing the Xcode project file in {your-app}/platforms/ios, which often is not trivial and additionally {your-app}/platforms/ folder is auto-generated and this is why it should not be submitted in VCS, so we don't encourage editing its content.
So, the question is how to use a library without editing platforms/ folder. Here come the plugins to the rescue.The main problem plugins solve is to enable you to use libraries without making manual changes to the Xcode project in platforms/ios folder.
However, the plugins are limited to frameworks only (both static and shared). The most significant difference between library and framework (in the context of NativeScript) is that the framework has a well defined structure and contains metadata (module.modulemap file) for the containing library.
However, most of the static frameworks don't contain module.modulemap file, so you have to add it manually. This information is needed to the iOS Runtime in order to expose correctly all library APIs. This is the reason why NativeScript plugins support only frameworks with module.modulemap file in it (in other words - shared frameworks and static frameworks with manually added module.modulemap file).
If you drop a valid framework in your plugin's platofrms/ios folder its API will be automagically exposed in your project when you add the plugin to it. If you want to use a bare library (.a or .dylib file) from a plugin you can wrap it manually in a framework. In most of the cases it won't be a rocket science - just moving all files in the proper folders and adding a standard module.modulemap file will do the trick. However, this approach does not saves you from the burden of storing your frameworks in your repo and manually handling dependencies and new versions of the frameworks. So, here comes the CocoaPods support.
Using CocoaPods means you can remove all frameworks (with all the binary files in it) from your plugin's repository and keep only single Podfile. You also get all the benefits of using a package manager. In the context of NativeScript plugin, CocoaPods can only be used with shared frameworks because of the needed manual work mentioned above for the other types of "packages".

Also, existing limitation of static libraries is that only Objective-C APIs are exposed (no C functions and C constant). This limitation has a solution which includes manually editing the Xcode project file, so it should be used only as a last resort.

Additionally, another limitation exists (this time it comes from Apple) - shared libraries and frameworks can be used only in iOS 8 and above. Bare in mind that this limitation is valid for pure native applications, too.

So far, so good. Based upon these facts and known limitations you can use the following strategy when wondering what is the best way to add a third-party code in your app:

1. Try using plugin with CocoaPods (only shared frameworks supported). If not possible (maybe because there is no pod for the library or you are targeting iOS version lower than 8.0) ->
2. Try using plugin with pre-built frameworks in it. If targeting iOS version lower than 8, use only static frameworks (with module.modulemap file added in it). If you have only bare libraries (.a or .dylib) try wrapping them in frameworks. If not possible (e.g. the library can't be easily wrapped in a framework) ->
3. Edit your Xcode project manually (NOT RECOMMENDED)

More info about NS plugins you can find here.

In your current scenario I would consider dropping support for iOS versions lower than 8.0. This will give you the possibility to use the best option - plugin with CocoaPods in it.
However, if you insist on supporting iOS versions lower than 8.0, I suggest building all needed dependencies as static frameworks from their source code (or downloading already built versions) and adding module.modulemap file manually (which in most cases is trivial) and wrapping them in a plugin.

P.S. I made a new plugin from scratch and added ObjectiveDDP pod in it. After that, included the plugin in a brand new app and all the JS APIs ware exposed. How does your app crashes? What is the error message? Can you try making the plugin from scratch and adding it in a brand new app in order to isolate the issue?

[rclai]

My plugin looks like this:

nativescript-objective-ddp
-- platforms
 -- ios
 -- Podfile
-- package.json

package.json

{
 "name": "nativescript-objective-ddp",
 "version": "1.0.0",
 "description": "This package installs ObjectiveDDP (iOS only)",
 "main": "index.js",
 "nativescript": {
 "platforms": {
 "ios": "1.4.1"
 }
 }
}

Podfile

pod "ObjectiveDDP"

Is this right?

[rclai]

This is really odd, but it seems like when I created a brand new project, ObjectiveDDP now works. I copied my main project files into this brand new project and ObjectiveDDP continues to work. Really weird.

[rclai]

Thanks for the help.