Roadmap: Distributable Dynamic Framework

[sergiocampama]

There have been multiple requests to expand ios_framework into something that can be imported into Xcode, or distributed to a build system outside of Bazel (#81, #112, #301).

The intent of the ios_framework rule is described here, but as a short summary, its intent is to automatically gather common code and assets to reduce binary and resource size of ipas that have shared dependencies between the application and extensions within a Bazel build, and not for distribution or dependency management.

I believe that the fact that ios_framework produces an output that's similar to a distributable dynamic framework is the main source of confusion here. In hindsight, ios_framework isn't the best name for its purpose.

In order to clear this up and resolve this confusion, I'm proposing the following:

1. Rename ios_framework to apple_bundling_framework/ios_bundling_framework

This rule will perform the duties that ios_framework currently performs, which is to reduce the binary and resource size in ipas. Same as today, this rule will only be allowed in framework attributes of top-level rules, like ios_application and ios_extension. Whether we can make this rule name platform-type agnostic will depend on how flexible the configuration transitions work in Bazel is to allow this use case.

2. Create a new rule ios_dynamic_framework

This new rule will output a distributable dynamic framework as requested by rules_apple clients. This rule will not be allowed to be a dependency on other rules_apple's rules, or nor objc_library or swift_library. Its sole purpose will be for it to be taken from a Bazel build environment to another build system, and will package modulemaps and headers.

Why not allow ios_dynamic_framework as dependency to objc_library/swift_library targets?

By allowing ios_dynamic_framework as dependencies to objc_library or swift_library targets, we introduce a path in which it would be fairly simple to introduce duplicate symbols warnings at runtime.

Say for example you have ios_dynamic_framework(Foo) and ios_dynamic_framework(Bar)that depends on objc_library(Base). The Base library would be linked into both dynamic frameworks, triggering the duplicate symbol warning messages at runtime, and also duplicating binary size for `Base.

You could in theory wrap Base inside another ios_dynamic_framework to avoid this issue, but this just means that to avoid this problem, you'd need to convert every objc_library target into an ios_dynamic_framework, which might lead to too many dynamic frameworks being loaded at runtime.

This approach also removes control from ios_application owners into deciding whether they'd like to have their app statically or dynamically linked, especially if they're sensitive to dyld load times.

cc: @keith, @steeve

[steeve]

This looks good.
Indeed it's not always easy (nor desirable) upgrading everybody to Bazel inside an org and having a path to distribute an artefact is a good thing imho.

[kastiglione]

Name possibilities:

ios_app_framework to indicate that it's a framework target used by an app. This name doesn't cover the extension case but that's the less common case, and it's more specific than the generic "bundle".

ios_distributable_framework, this one comes from the fact that it's worth considering supporting the building of distributable static frameworks.

[keith]

For 1 apple_bundling_framework makes sense if you can use the same one for multiple platforms like tvos (I don't know if this works today or not)

[sergiocampama]

I believe this proposal lines up quite nicely with the announcement of XCFrameworks. Given that this is becoming the official way of distributing binary frameworks, the new rule should be called something like apple_xc_framework.

I talked to Harlan (they guy who presented XCFrameworks in the WWDC talk) and he mentioned that this supports static and dynamic frameworks, and with the introduction of the .swiftinterface files, Swift should also be supported here.

One caveat for Swift is that Swift enforces that the framework bundle name is the same as the Swift module included in the framework, so we'll need to figure out the best way to enforce this restriction, and how to make sure that a mixed Objc/Swift framework is properly configured.

For the former, one way would be to enforce that there is a single swift_library target in the dependencies, and that its module name is equal to the module name of the framework.

apple_xc_framework would take a list of supported platforms, and would create .framework bundles for each of them, and finally would bundle them into an .xcframework bundle.

[keith]

We're using a custom made rule for distributing a swift framework that can be found here envoyproxy/envoy-mobile#188

[vincephamgrab]

Hi @keith , thanks for sharing. I'm new to Bazel. Do we have the custom rule for making a Dynamic framework? Or any idea how to do it?

[keith]

If you're doing it in the build you can use ios_framework

[vincephamgrab]

I want to make it a bundled framework, can drag and drop to be used for another project. Similar to swift_static_framework custom rule as you mentioned.

[keith]

This rule hasn't been added yet. I'm not sure if anyone has tried to make their own custom rule yet.

[fenollp]

We're using https://github.com/fenollp/mediapipe/blob/facial-search/mediapipe/examples/facial_search/ios/BUILD#L58-L76 to build a distributable Obj-C++ iOS Framework. It's not a rule but a hacky script.

I'd like to help move this issue forward. Is creating a multiplatform apple_xc_framework still the goal here?

[tinder-maxwellelliott]

I want to make it a bundled framework, can drag and drop to be used for another project. Similar to swift_static_framework custom rule as you mentioned.

I would check out https://github.com/line/rules_apple_line/blob/master/docs/README.md#objc_static_framework , I have had some success with it lately

[keith]

You can now use ios_dynamic_framework and friends for the original issue here

[keith]

I filed #1249 as a tracking issue for supporting producing xcframeworks

If there were any other issues I'm missing with these 2 please file a new one!

[emad-eldeen]

You can now use ios_dynamic_framework and friends for the original issue here

Hi Keith, @keith
Do you have an example for the properties of this new bazel rule?

[brentleyjones]

https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-ios.md#ios_dynamic_framework