1307441 - Manually integrate the Buddybuild SDK for our Nightly channel and place behind feature flag

Status: RESOLVED FIXED

(Firefox for iOS :: Build & Test, defect, P1)

Description

[Stephan Leroux [:sleroux]]

Manual installation docs: http://docs.buddybuild.com/v6/docs/sdk-integration

It would be really great if we can start using the feedback mechanisms Buddybuild provides for Activity Stream and other QA related issues. Since the SDK has some privacy concerns surrounding it (record last 15 seconds of app use for sending videos), we should hide this behind a feature flag and only enable for our (internal) Nightly population. Also proper crash report helps!

Comment 1

[Stephan Leroux [:sleroux]]

I'll take a look and see if we can bundle the SDK only with nightly builds

Comment 2

[Stephan Leroux [:sleroux]]

Moving into this sprint to support weekly Mozillian build.

Comment 3

[Stephan Leroux [:sleroux]]

Not sure if there is an _easy_ way of doing this. 

The route I tried go down involved linking in Buddybuild and it's dependent frameworks using the `other linker flags` in the build settings instead of the `Link Binaries With Frameworks` phase. This allows us to link based on the configuration so we can have it link for Nightly but not for Beta/Release. To handle the optional linking at runtime, I created a wrapper class called `BuddyBuildSDK_Weak` written in ObjC that performs the `setup` selector. This allows the Swift code to call the setup method without needing the library to be linked since the performs selector would just be a no-op if BB isn't there.

The missing piece to all of this is actually getting the framework to be copied over to the application. The `Link Binaries With Libraries` phase does a couple of fancy things like code signing. I tried to emulate this using a custom `Run Script` phase which would allow us to use a `User-defined Setting` property for conditionally copying the framework over. Alas, the application fails to run because the framework is missing an Info.plist that describes how the framework was built. Like the other libraries we have with the `Link Binaries With Libraries` phases, it looks like the BB framework needs to be part of the binary and not alongside of it. So I'm at a bit of a roadblock here.

Other ways forward include:

1. Figure out how I can add the BB framework into the binary conditionally without using the `Link Binaries with Libraries` phase
2. Clone the `Client` target, name it DebuggableClient or something like that, and include the framework there

It's worth noting that option 2 is the more pragmatic way of doing this kind of thing. Targets should define a fixed set of libraries that are built for an application instead of relying on build settings to optionally exclude settings. It just adds more bloat and another target just for linking in a simple framework :/

Comment 4

[Richard Newman [:rnewman]]

How about a stub BB lib, and copy or symlink the real or stub in a copy script before build?

Comment 5

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

This is what I'm doing for Focus .. https://github.com/mozilla-mobile/focus/pull/22

Comment 6

[Stephan Leroux [:sleroux]]

Attachment: Github PR https://github.com/mozilla-mobile/firefox-ios/pull/2259

Comment 7

[Stephan Leroux [:sleroux]]

master https://github.com/mozilla-mobile/firefox-ios/commit/927cdec48e3272990ceb2865a118ecb648411675