Cocoapods and Xcode workspaces in OpenFL/Lime projects

Haxe
#1

When building iOS apps, it is pretty common to use Xcode workspaces (instead of a simple Xcode project) and to rely on CocoaPods to manage external dependencies (works like Android/Gradle extensions, and makes it much easier to manage dependencies on native side of things. I have been using it for years now on iOS projects).

I was wondering (ping @singmajesty) if it could be considered to make OpenFL work well with these use cases. In other words, could openfl/lime:

  • Build an Xcode workspace instead of a raw Xcode project (currently it builds a project AFAIK)
  • Accept Cocoapods dependencies (with an option in the lime project maybe?)

Cocoapods allows to specify and manage dependencies very precisely with their podspec syntax. It is really the best equivalent of Gradle dependencies on Xcode/iOS. It moves the complexity of various Xcode/iOS settings to cocoapods instead of having to manage the nuances ourselves.

I am asking this because I am working on native extensions for iOS and Android and some of the iOS ones may rely on CocoaPods (because it makes them much easier to maintain). I would be happy to make them compatible with OpenFL, but that won’t be possible if it can’t handle pods.

This question is related to the automatic iOS/Android bindings utility for Haxe I am working on currently.

Any thoughts on these subjects?

#2

I have been thinking of an iOS native extension system for a long time, I need some help with considering exactly how it would work “in the iOS way”

CocoaPods was the most likely candidate in my mind, where native extensions would have their own projects, and they would be merged in (similar to how we do it on Android). One of the key things is that we try to build in a very automatic way, so it would be important that CocoaPods is up to the task of building without hands-on changes to project files. I also believe we would need to create some form of Extension.h API (similar to Android’s Extension.hx) in order to allow easier registration of onDidFinishLaunchingWithOptions and other application hooks.

We have an “Android extension system” currently, which I think is fairly good, but we lack a formal system for iOS, which I think is necessary

#3

CocoaPods is actually helping to solve the problem you mentioned: build a whole iOS project with various dependencies, and do it from command line or an automated tool if needed.

Take this SocketRocket pod library for instance, check out its podspec file in the repo. That’s basically the only file needed to make a library compatible with CocoaPods. The podspec allows to specify frameworks to depend on, other ios/pod dependencies, files to include etc… so that when running pod install in your final project, it will perform all the necessary changes in your Xcode project (workspace).

Cocoapods requires to use a workspace instead of a project, but that should not be an issue (a workspace can be built with xcodebuild the same way you would build a project).

Last but not least, a Podfile, which is somehow the equivalent of an app’s package.json that allows to specify external dependencies through cocoapods registry or through github, but also simple local dependencies with local paths.

An idea could be that OpenFL/Lime generate an Xcode project + workspace with a PodFile that has local dependencies to every haxe/lime library that provide a podspec file. I don’t think it is necessary to reproduce every podspec option in the lime build system (I know there are some already, like linking with a framework or so).

Simply adding a <podspec ... /> option in a lib’s include.xml would already give a lot of possibilities in a pretty “standard” way for iOS developers (and leave the Xcode dependency resolution complexity to Cocoapods, which is widely used and adapting to future Xcode/iOS changes).

It would also be nice (but not necessary as this can also be specified inside a podspec) to be able to add a single iOS dependency from include.xml:

<pod name="SocketRocket" version="~> 0.5.1" />

This would add a line into app’s Podfile: pod 'SocketRocket', '~> 0.5.1'

(but again, this is optional as one could just provide a podspec file that can let cocoapods add the same dependency with this: spec.dependency 'SocketRocket', '~> 0.5.1')

One more thing, a podspec defining a “pod” or “dependency” is completely independent from a library’s Xcode project. Actually, a pod doesn’t need an Xcode project to be added as a dependency, it just needs a podspec file. In practice, one can still create a library Xcode project to test his library code, but that won’t be required nor used by CocoaPods (which is fine).

Regarding AppDelegate hooks like applicationDidFinishLaunchingWithOptions, it can be nice to have these on OpenFL for sure, but that is not as mandatory as for Android Activity events because any iOS code can just hook on NSNotificationCenter to run code on these events.

Feel free to ping me if you want to try things regarding cocoapods, I have been using it with continuous integration (on travis CI) for hundreds of iOS apps in production in my previous job so I am somehow used to it :stuck_out_tongue: