[Bug] Incremental firebase Unity-iOS builds reset code signing on gRPC-Certificates

ferretnt commented 1 year ago

[REQUIRED] Please fill in the following fields:

Unity editor version: 2022.2.x (currently .2.8)
Firebase Unity SDK version: 10.3.3 - 10.3.5
Source you installed the SDK: UPM (.unitypackage or Unity Package Manager)
Problematic Firebase Component: Build System, but assuming Auth is source. (Auth, Database, etc.)
Other Firebase Components in use:Project includes Auth, RTDB, Firestore, Storage (Auth, Database, etc.)
Additional SDKs you are using: None (Facebook, AdMob, etc.)
Platform you are using the Unity editor on: Mac (Mac, Windows, or Linux)
Platform you are targeting: iOS (iOS, Android, and/or desktop)
Scripting Runtime: il2cpp (Mono, and/or IL2CPP)
Pre-built SDK from the website or open-source from this repo: Prebuilt Official Google Package Archive

[REQUIRED] Please describe the issue here:

Iterating on iOS Unity builds of firebase projects seems to have regressed over the last couple of years, in that.

Specifically:

By default, Unity still enables bitcode, but the generated XCWorkspace doesn't build the pods with bitcode. This isn't a huge hassle (either script to disable bitcode or do it once and your local project will then be good until you rebuild from scratch.)
More annoyingly, every single incremental Unity "Build-and-Run" build un-sets the signing certificates for gRPCCertificates-CPP, requiring (proably) 3 extra clicks in the XCode UI to resolve. This is the case even if you have set your development team directly in Unity's Editor settings.

It would be great if incremental builds of Firebase could have their painless iteration restored (it's been a while since I was working on a Firebase project, but from memory Firebase 7.x didn't have these issues?)

Steps to reproduce:

(a) Create a firebase project with the above components. Fix signing, bitcode, etc errors whilst building in latest XCode (14.2 at time of writing) (B) Build and Run on device. (c) Incrementally build a change (Command+B in Unity) (d) Observe that XCode project will have no signing certificate for GRPC-certificates, so you'll have to fix this manually (3 mouse clicks, and a scroll down to find the actual error in xcode's gargantuan list of warnings)

Have you been able to reproduce this issue with just the Firebase Unity quickstarts (this GitHub project)? What's the issue repro rate? (eg 100%, 1/5 etc)

100%

What happened? How can we make the problem occur?

Expected: Incremental build of application builds, deploys to device and runs.
Actual: Incremental build in Unity succeeds, which then invokes XCode, which fails with an error saying "grpc-Certificates requires a signing identity."

If you have a downloadable sample project that reproduces the bug you're reporting, you will likely receive a faster response on your issue.

This can be reproduced on a blank project with the above packages.

// TODO(you): code here to reproduce the problem

paulinon commented 1 year ago

Hi @ferretnt,

Thanks for reporting this issue. I'm currently replicating this, but I'm not sure if I'm facing the same behavior that you're experiencing. That said, I have a few things to ask:

When you mentioned that Xcode fails, are you referring to a failure in build? I was able to build the app successfully, but the app seems to have crashed immediately.
Could you clarify what these three clicks in the Xcode UI are as well as the actual error you're referring to?
When rebuilding your Xcode project, do you select Append or Replace? Could you also confirm if performing one of these options results in a behavior different the other?

ferretnt commented 1 year ago

@paulinon Thanks for the response. I uploaded a very basic public repro here to demonstrate the problem.

https://github.com/ferretnt/FirebaseBuildRepro

You'll see that it's basically a bare Unity project with 4 firebase packages plus PlayServicesResolver added as tgz files - they're checked into the GooglePackages folder.

Build an run this project from Unity and you will notice that the first time you build you will have to fix two issues:

(1) GRPC-Certificates needs to have a development team manually assigned in XCode even if you've set your development team in Unity.

(2) An xcode error message which is not immediately obvious from the screenshot, but is saying "hey, your unity app is built with bitcode but some of the pods aren't." This can be fixed with a simple click to disable Bitcode in XCode, or via a buildpostprocessor script in Unity, but note that once this error is fixed once in XCode, it "stays fixed" until you do a full rebuild in Unity, or change build folder.

With that set, you'll be able to build and run to device. (In the screenshots I built to my macbook M1, but the flow is identical on iOS device.)

Now, switch to unity, modify any script or scene, hit cmd+B in Unity (incremental build and run) and note that you will once again have to re-assign the development team for grpc-certificates, which is very annoying. It seems that, ideally, the development team should be auto-set if you are using automatic signing and have set a team ID for the project in Unity, and minimally that it should not be cleared on every incremental build from Unity.

Expected: Incremental build and run from Unity works after you have configured signing and bitcode in the local XCodeProj the first time.
Actual: Signing for grpc-certificates is cleared every time, so you have to re-assign a development team in Xcode EVERY SINGLE TIME you hit build and run in Unity.

paulinon commented 1 year ago

Thanks for the additional information, @ferretnt. I've used the sample project you provided, but I still haven't encountered the behavior you're facing. It seems that none of the error messages you encountered appeared in any of the builds. It's quite odd that you're facing a bitcode-related issue considering bitcode inclusion in the SDK is discontinued starting version 10.1.0.

Could you provide the generated Podfile along with your iOS Resolver settings in Assets > External Dependency Manager > iOS Resolver > Settings? It would be great if you could also answer the questions in my previous response in order to identify what's causing your issue.

ferretnt commented 1 year ago

Hi @paulinon

A couple of clarifications to try to help. Firstly, to your original email:

When you mentioned that Xcode fails, are you referring to a failure in build? I was able to build the app successfully, but the app seems to have crashed immediately.

Yes, I'm referring to the fact that Xcode cannot build the project, because certain options are not configured correctly, specifically the signing team for grpc-certificates.

I am not sure why you are having runtime crashes - the project I sent you definitely runs directly on device (in fairness, it only contains one line of non-Firebase or default code, which is to make the cube spin just so I could see the app was running. To be clear, this issue can be reproduced with a minimal, blank, firebase project so you don't HAVE to use my project, which was really just the work to make such a project as a repro. I assume other users would have reported a bug if a blank unity project with fireabase SDK crashed on startup. To be clear, when you say "I was able to build the app successfuly", the first time you built the project from Unity, did it seamlessly perform Unity Build, Xcode build of the resulting xcworkspace, and iOS deploy with no user intervention? If so, that is surprising, and different from the behaviour I'm describing.

Could you clarify what these three clicks in the Xcode UI are as well as the actual error you're referring to?

I think I tried to clarify what I meant in the second email. I'm not sure it's exactly 3 clicks, but nontheless, any time you hit Cmd+B in Unity, the result will be an XCodeProj that cannot be built, because grpc-certificates does not have a development team assigned.

When rebuilding your Xcode project, do you select Append or Replace? Could you also confirm if performing one of these options results in a behavior different the other?

I'm hitting Cmd+B, which is equivalent to an incremental build, i.e. selecting Append. The behaviour also reproduces if you explicitly select file-->Build and Run with Append.

Thanks for the additional information, @ferretnt. I've used the sample project you provided, but I still haven't encountered the behavior you're facing. It seems that none of the error messages you encountered appeared in any of the builds. It's quite odd that you're facing a bitcode-related issue considering bitcode inclusion in the SDK is discontinued starting version 10.1.0.

To be clear, bitcode is not really the focus of this bug. Firebase does not include bitcode in its builds anymore. This is fine. Unity 2022.2.x still, by default, builds with bitcode enabled. This is arguably a poorly chosen default by Unity, but the only way that this is relevant to the real issue (grpc-certificates signing) is that if you fix the bitcode issue in XCode, it will then stay fixed (i.e. not be overwritten) by any other Build-And-Run operation, so you only have to fix it once. In other words, this is not a major workflow issue. By comparison, the fact that you have to reset your grpc-certificates team every single time you build incrementally from Unity is a more significant development workflow issue.

Could you provide the generated Podfile along with your iOS Resolver settings in Assets > External Dependency Manager > iOS Resolver > Settings? It would be great if you could also answer the questions in my previous response in order to identify what's causing your issue.

Oops, am typing this on my PC. Will switch to mac to grab them and add another comment with attachments.

ferretnt commented 1 year ago

Attaching podfile and screenshot of resolver settings (which should be the default - I haven't changed anything) here. Note that podfile has had .txt appended so that github will upload it.

Podfile.txt

a-maurice commented 1 year ago

So, I'm not sure how much can be done within the Unity SDK to fix this. I was able to reproduce this by just running pod install in the build directory as well, and it seems like almost any modification to the project results it it just reseting that field.

There was a report for the same issue on the iOS SDK, https://github.com/firebase/firebase-ios-sdk/issues/10411, that suggests a possible fix.

So, one possible workaround: 1) Run the Unity build once, to generate everything. 2) Edit the iOS project 3) Add the follow to the end of the Podfile:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      if target.respond_to?(:product_type) and target.product_type == "com.apple.product-type.bundle"
        target.build_configurations.each do |config|
            config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
        end
      end
    end
  end
end

4) In Unity, in the iOS resolver settings, uncheck the Podfile Generation item at the top. This will prevent the incremental build from regenerating the Podfile, which would undo step 3.

Doing that seems to have prevented it from reseting the gRPC certificate. The problem with this is if you ever do need to do a clean build, you have to remember to do all this set up.

A more stable option, if you want: You could add a build step to edit the Podfile. For reference, order of operations that the iOS resolver that currently generates the Podfile uses is here: https://github.com/googlesamples/unity-jar-resolver/blob/master/source/IOSResolver/src/IOSResolver.cs#L412

So you could add something between 40 (when it makes the Podfile) and 50 (when it runs pod install) to append the Podfile with those lines from above.

ferretnt commented 1 year ago

Thanks @a-maurice and @paulinon

In the immediate term (i.e. today) I'll do as you said, and after building the first time modify podfile and disable generation. Thanks! This will work for now for local iteration for the small number of our team members that actively iterate on iOS. The cost/benefit of the second solution doesn't seem worth it for us, although I'm surprised more firebase users aren't unhappy about this, especially given it also affects the native iOS SDK (maybe I'm just a luddite who still iterates on my device when writing code instead of pushing to a devops cloud build system and getting an artefact to test?)

Just wanted to check my understanding of the deeper threads. I'm not sure what KMP is (Kotlin Multiplatform?), but after tracing through the links in various issues down to here, my understanding is...

This is an issue affecting iOS firestore platform
It is caused by a file (grpc-certificates bundle) that firestore doesn't need being included by ??something, although I wasn't clear who needed to make a commit to remove it.
That files will be (??has been??) removed from the iOS SDK
Once all the dependencies bubble through (Firebase Unity release using Firebase iOS release etc) this will be resolved?

tl;dr:L Are all the wheels turning somewhere to resolve this, so at some point it will be fixed?

https://github.com/uhooi/firebase-ios-sdk/commit/28ee475a0fd71e587633c6a80edf25f73f958ec9

This issue is closed, although I wasn't clear if it was resolved? https://github.com/firebase/firebase-ios-sdk/issues/10411

This issue is still open though, so not sure.

https://github.com/firebase/firebase-ios-sdk/issues/9184#issuecomment-1007864247

hsallander commented 1 year ago

I have the same issue in our project. I'm on an M1 Mac, using cocoapods 1.11.3 via brew.

The project is using Unity 2021.3.17f1 and the following Firebase packages (as tgz files) :

com.google.external-dependency-manager-1.2.175
com.google.firebase.analytics-10.6.0
com.google.firebase.app-10.6.0
com.google.firebase.auth-10.6.0
com.google.firebase.crashlytics-10.6.0
com.google.firebase.dynamic-links-10.6.0
com.google.firebase.firestore-10.6.0
com.google.firebase.functions-10.6.0
com.google.firebase.remote-config-10.6.0
com.google.firebase.storage-10.6.0

I get both the abovementioned errors

need to manually select a Signing Team for the gRPC-C++-gRPCCertificates-Cpp
need to manually set bitcode to No

ferretnt commented 1 year ago

Thanks for confirming. My personal feeling is that this issue should focus only on the gRPCCertificates issue, because that's the one that's disruptive to build workflow and nontrivial (as pointed out by @a-maurice above) to fix locally.

In retrospect, I wish I hadn't mentioned bitcode. The bitcode issue is a result of Unity's decision to have bitcode on by default (which although Apple's recommendation doesn't align with anyone's reality). Also disabling bitcode can be done by by adding an OnPostprocessBuild step to the unity project. Why there still isn't a "disable bitcode" option in PlayerSettings (or just disable it by default) I don't know, but a fix like this solves the bitcode issue permanently.

https://support.unity.com/hc/en-us/articles/207942813-How-can-I-disable-Bitcode-support-

a-maurice commented 1 year ago

Yeah, the bitcode thing is definitely outside our control. Looking more into the gRPC issue, I'm still struggling to see where exactly the problem lies, if it is something in the Firebase iOS side, or the gRPC side, but am reaching out to folks. We could potentially add a workaround in the Unity SDK, though I'm not entirely sure what the other implications of adding that code block might have to projects.

hsallander commented 1 year ago

I did some more testing today and it seems to possibly be Xcode version dependent. Could that be, @a-maurice? I haven't tested with different Xcode versions myself locally, but using our Unity Cloud Build pipeline I have been able to do some tests. All tests using Xcode 14 (current released Xcode is 14.2 as of this writing) or above failed with this error, and all tests using Xcode 13 succeeded.

Tested Xcode versions:

Xcode 14.0.1, 14.1.0 failed
Xcode 13.2.1, 13.4.1 succeeded

a-maurice commented 1 year ago

It definitely could, Xcode tends to change a lot of those settings between versions (like bitcode is no longer an option with Xcode 14).

Still reaching out to folks about it on my end, but the general consensus seems to be that the gRPC-C++-gRPCCertificates-Cpp shouldn't even be needed, and it is just getting added by one of the underlying dependencies. So one possible course of action would be to delete it. Though I suspect it would keep coming back when doing an incremental build (unless you disable the Pod step again).