XCFramework Support

[sethfri]

Is your feature request related to a problem? Please describe.

When importing gRPC via CocoaPods, it is currently only available as a source pod. This means when we import gRPC into our app, we have to rebuild it every time we do a clean build. This adds over 60 seconds to our build times, and is one of the slowest things that happens during our builds.

Describe the solution you'd like

Apple has a native binary format called an xcframework that would allow for gRPC to be distributed as a binary pod, and CocoaPods plugins like cocoapods-pack exist to produce xcframeworks from podspecs. If gRPC was distributed as an xcframework, we would be able to import it as a binary pod and shave a full minute off our clean build times, which would speed up the builds for our app in particular by 15%. This would be a huge boon for every iOS app that imports gRPC.

[sethfri]

Hi @dennycd! Any update on this?

[dennycd]

Hey @sethfri , we will be adding this support in Q2, stay tuned

[sethfri]

Hey @dennycd, I hope all is well! I wanted to check in with a few questions:

• Is the team still on track to deliver this for Q2?
• Will this include XCFramework support for all of gRPC, gRPC-Core, gRPC-RxLibrary, BoringSSL-GRPC?

For BoringSSL-GRPC, I don't see a public repo for the fork, so I'm not able to open a separate issue. It also appears as though gRPC uses abseil, so I've opened an issue on that repo abseil/abseil-cpp#1154

[dennycd]

• Is the team still on track to deliver this for Q2?

Hey @sethfri, YES ! that is still the case for us.

• Will this include XCFramework support for all of gRPC, gRPC-Core, gRPC-RxLibrary, BoringSSL-GRPC?

We will have 3 stages for this, roughly matching the dependency graph in our current Cocoapod target settings

• iOS/ObjC: gRPC-ProtoRPC, gRPC-RxLibrary, gRPC
• Native C-Core: gRPC-Core, gRPC-C++
• 3rd party deps: BoringSSL-GRPC, Abseil (GRPC) and others

Likely you would see build improvement when we get to stage 2 (Native C-Core) as gRPC-Core is the one taking the largest chunk of build time. But the goal is to at least have stage 1 & 2 done by end of Q2 ; ) Hope this helps clarify the timelines a bit more.

For BoringSSL-GRPC, I don't see a public repo for the fork, so I'm not able to open a separate issue. It also appears as though gRPC uses abseil, so I've opened an issue on that repo abseil/abseil-cpp#1154

note that we (gRPC/iOS) currently maintains BoringSSL-GRPC and Abseil Cocoapod build & release distribution.

[sethfri]

Hi @dennycd! Are we still on track for Stage 1 and 2 by end of this week?

[dennycd]

Hey @sethfri , the dev preview for the xcframework build should now be available in our v1.48.0 release (see our release notes for more details). Please give it a try and let us know if your team run into any issues using it. Happy to follow up and address them.

[nadavm391]

Hey @dennycd, first of all - thank you very much!
Would it be possible to release those xcframeworks as staticlly linked, what you uploaded in the preview is dynamically linked.
This will shave off build times but may slow down launch times since this is indeed a big library