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
<pod name="SocketRocket" version="~> 0.5.1" />
This would add a line into app’s
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