Support for iOS static framework about rules_apple

[allevato]

Yes, the main use case is to ship a static framework for others to consume without adopting Bazel.

I think we can make this happen.

Another internal use case is that I am trying to adopt Bazel in the project incrementally, thus by building subproject as static framework may help the transition.

This one is trickier, because the other objc_* compiling/linking rules don't really support depending on static frameworks, and I don't think it's something we'd want to add (because in a Bazel world, you should just be using objc_library for your dependencies instead of building a static framework target and then having other libraries depend on that).

If what you want from "building subprojects as static frameworks" is getting a prebuilt static library that you can link from other rules, have you looked at objc_import? It's like objc_library but lets you point it to a prebuilt .a file instead, but you can also have it expose hdrs and include resources. It sounds like that would get you what you need (if I'm understanding you correctly)—the only thing a static framework rule would add on top of that is bundling into a .framework folder, which sounds superfluous here.

[allevato]

Is this a feature on the backlog now?

There's been some progress internally in this area, but it needs a bit more work before it's ready to be pushed out to the world. It hasn't been highest priority and we've had a number of other tasks that have come before it, but given the amount of interest shown here, let me see what I can do to drive it forward.

[allevato]

ios_static_framework is available as of c0739fa. Documentation can be found here.

[allevato]

I'd like to know more about your use case first. What do you want to do with a static framework rule? Do you want to use Bazel to build an SDK that's distributed as a static framework (with or without a system like Cocoapods), or is it purely for building a dependency that would be used in the same workspace?

[zetachang]

Yes, the main use case is to ship a static framework for others to consume without adopting Bazel. Another internal use case is that I am trying to adopt Bazel in the project incrementally, thus by building subproject as static framework may help the transition.

[rahul-malik]

@zetachang - Went through a similar approach so thought I'd share:

We've been incrementally adopting Bazel at Pinterest over the last few months and have been able to rely on objc_library, obj_framework rules to build portions of our codebase without moving off xcodebuild entirely. Our current approach is to use an External Build Tool (shell script) target in XCode that is a dependency of our App target. This build tool executes a shell script which builds static libraries using bazel and copies them to a specific location in your repository. Then we've defined relative paths for our app to link to these frameworks.

Here is a few other tips / gotchas for your integration:

• Using Tulsi to generate a XCode Project for your bazel targets and adding to that to your workspace will help with symbol indexing / breakpoints
• If the portion of your project that is built with Bazel and the rest of the project depend on a 3rd party dependency, you'll have to migrate it out of Cocoapods/Carthage into Bazel
• Clean in XCode will have to trigger a bazel clean as well

[lswith]

@allevato I think the use case for adopting bazel incrementally is a strong one. By allowing specific parts of our codebase to be built with bazel and exporting a static_framework, this would have a huge effect on adoption.

In the bazel world can't you have both the objc_library as well as a static_ios_framework?

[Steve-Munday]

@allevato In your May 12 comment you said:

Yes, the main use case is to ship a static framework for others to consume without adopting Bazel.

I think we can make this happen.

Is this a feature on the backlog now? This would be really useful for my team as well. We package and ship our product as a .framework file.

[dmytrol]

@allevato If I may, I would appreciate some inputs on a related case that does not seem to qualify as a standalone feature request, but rather is closely related to dealing with static frameworks.

Consider a dynamic iOS framework that is going to be distributed to external, non-Bazel-aware consumers. This framework has three build dependencies: one is the framework source code itself, and the other two are static libraries (one migrated from CocoaPods and the other one is proprietary). Important point: the static libraries are not going to change in foreseeable future.

Now, given that the two libraries are not going to change very often (if at all), I'd think it might be a good idea to have then packaged as pre-compiled static frameworks. First, that would simplify migration of all this setup from xcode to Bazel without touching the source code (e.g. currently there are import statements looking like #import <FrameworkName/UmbrellaHeader.h> that do not play nice with Bazel's native objc_library rules even when properly declaring public headers in the hdr attribute.

Second, that would allow saving on build times even when building the dynamic framework itself after a full clean.

However here's a double-catch: first, the ios_static_framework rule is currently not designed to serve as an input to other objc / ios rules. And, second, to stay compatible with Tulsi, I gather we have to stick to the obc_library rule to declare dependencies on the static library (while otherwise we could probably use objc_framework and new_http_repository to introduce CocoaPods-like dependencies)