Erik Romijn

Cocoaheads January 2014 meetup summary

The CocoaHeads Amsterdam January 2014 meeting was hosted by WappZapp, in Amsterdam. There were two speakers, talking about Appcelerator Titanium and CocoaPods.

This was a live summary and has not been reviewed by the speakers. Opinions reflected are the speakers’, not necessarily matching those of the author.

Wienke Giezeman: Building native apps with Javascript

Wienke works for WappZapp. WappZapp is a video discovery app that gathers video from many sources on the internet and provides them to users in a curated way. WappZapp builds it’s apps in Appcelerator Titanium. They chose for this both for their initial development, and for the rewrite after their funding round last year.

The main advantages they see is the speed of development, and not requiring Objective C or Java, yet still delivering a native app. And it offers chances for cross platform development. They considered web apps, but they did not perform well enough.

Titanium is definitely not PhoneGap. It’s not an HTML5 application in a UIWebView. Titanium works with cross platform javascript proxies, and produces a native app. This means you can also integrate native modules for any platform. For WappZapp, it’s a good option between a UIWebView and the full cost of native development.

Wienke shows a basic hello world in Titanium, and it definitely seems a lot more brief than a native iOS hello world. However, he explains how this style of development is not scalable. To get some proper MVC structure in the Javascript, they integrated BackboneJS and AlloyUI.

Before deciding on Titanium, they built a prototype which contained their most challenging areas, to validate whether it worked for them. Older versions of Android are not on the same level, but for their video they could go for Android 4+. WappZapp also built some of their own modules to integrate into native calls. Titanium itself is also open source, so you can use that to fix issues.

Wienke does not recommend the Appcelerator Eclipse-based IDE, but a basic editor like Sublime along with the command line tools. To get started, the KitchenSink is a good example that demonstrates the API. And there is a Amsterdam Titanium meetup group.

Eloy Durán: Beyond CocoaPods

Slides published here. Eloy briefly introduces CocoaPods. It’s a dependency manager, like npm, pip, etc. It’s also a community around open source Objetive-C code. You install it with a Ruby gem, and library developers provide Podspecs, like recipes. You create a Podfile to list the dependencies for your projects, and have CocoaPods do it’s magic. CocoaPods specifically wants to create better libraries for all the users, even those that don’t use CocoaPods.


A less often known feature of CocoaPods is to manage acknowledgements, like “this app uses code from …”. Some open source licenses require this, and CocoaPods generates this automatically, including the copyright information and license text from the podspec file. It generates a plist which can be direclty integrated in the settings bundle. It also generates a Markdown template. CocoaPods automatically picks up LICENSES files as well.

Eloy also mentions that your library is not Open Source unless it has an OSI approved license. And GPL is not allowed in App Store distributed apps. Without defined license, no reuse is allowed at all.

pod lib lint

The command pod lib lint validates the metadata in your podfile. There is also a full lint, pod lib lint —verbose, which will fetch the source, resolve dependencies, install them, generate an Xcode project, and build it. This allows you to validate whether your podfile generates a valid static library. However, that does not mean that it will function correctly.


CocoaPods supports plugins as well. They are separate ruby packages, which basically add features to the command line. Popular are browser, doc and try. Try is especially handy, as it makes it easy to try out a the included demo project of a particular library. That helps to make quick decisions about whether a library is what you were looking for. This is at the core of what CocoaPods was intended for: getting things done, and quickly.

Going forward, there will be a This will support ACLs and ownerships for libraries, so that you can be sure your AFNetworking came from the proper source. Library names are assigned to owners on first come first serve. This keeps it simple, but covers the necessary cases. In addition, there will be a central database of pods, so that statistics and other tools can be built.

Iterative dependency resolver

Currently, dependency conflicts are very rare. CocoaPods will try to satisfy the dependencies, but conflicts still have to be resolved manually. Also, you should limit your dependencies to a sensible amount, making conflicts rare. However, they will add better dependency conflict resolving in future versions.