Also suffering from the same ergonomic pain here (we'll swap bundle ID based on environment and product ID) and frequently run into this dialog when doing so. I'd love to see this dialog suppressed based on a project setting (that can be checked into source) - or honestly, just dropped to an error/warning in BuildPlayer()

1 for null pointer exceptions prevention
I'm going to need the proxy too and I'm going to write one for our project.

Hi @jhughes2112,

I'm sorry that you're having issues and thanks for your feature requests! It does help us track them internally if you break them up into multiple issues, but if you don't mind I'll try to address them as I can.

We do know that multiple targets are an issue, and one that many developers want. See firebase/firebase-unity-sdk#376 , we are tracking these.

For the dialog box, I understand that it is frustrating, but for many of our newer users would be more lost without that modal dialog. I'll try to log this as a separate feature request associated with this bug. I'm a heavy user of multiple virtual desktops on Windows (going back to the Microsoft PowerToys days), Linux, and MacOS, so I understand where you're coming from there.

With respect to native libraries, it can be confusing to have aar files in your Assets directory. Firebase relies heavily native interfaces to really take advantage of the underlying platforms and the C layer helps ensure that all game developers get an equally functional and tested experience on all supported platforms. If you use the new Unity Package Manager integration, many of user experience issues related to aar, a, so, and other "build artifacts" (to many VCS products) in your Assets directory will go away. There have been some issues found in the 6.13 Firebase release and rest assured that the team is working as fast as possible to improve that experience. I'm mostly excited about these improvements as I'll be able to upload projects to GitHub without requiring everyone to turn on Git LFS again!

Finally, the lazy singleton design is annoying in a purely Unity context. The project has roots back into early versions of Unity, when many developers (including some projects I worked on prior to Google) would ship core parts of their game as unit tested DLLs with Unity acting as a thin view model. The current Firebase design pattern avoids alienating similarly structured workflows (and fits well with ZenJect projects I've worked on), but can be frustrating in a modern vanilla Unity setup. I'd love to hear about the kinds of wrappers you're building and what the shape of the proxy you envision would look like!

I hope that all helps, and I'm definitely hanging around Twitter and StackOverflow if you get stuck on any individual thing (or need a temporary workaround)!

--Patrick

I hope you don't mind that I changed the title. It'll be easier for my coworkers to follow the actionable requests in the issue this way!

@patm1987 I'm not offended at the title change. :-) What I would suggest is that FIrebase is integrated in a most egregious way, and breaks all kinds of best practices. Let me elaborate.

Never, ever assume a file exists for your pleasure at a specific path.
Example 1: We can't currently move the Firebase folder to a 3rd party folder, because it assumes .dll's and whatnot are specifically stored in Assets/Firebase. Please make it relative or irrelevant where the files are stored. It causes pain for people who move them only to find everything breaks for no obvious reason.
Example 2: The GoogleService-Info.plist and google-services.json files must exist in Assets/PlayServicesResolver, which by itself is an enormous problem because the contents of these files must be modified in order for Firebase to allow multiple bundle ids in one project. All it would take is a trivial script to LOAD these files and SEND their contents into your API, but instead your API reads the files directly. Don't do that. You haven't got a clue where the data might be stored or what format it's in. As an API, your job is to react to someone poking data into you, not read data for yourself. If you stay in your lane, we all get where we want to go faster.

As for the proxy that everyone has to write, it's because we can't call any of your functions before the Init is complete, which is asynchronous (and unity is not inherently async friendly). So most people set up a coroutine on an object that polls for completion of the Firebase Initialization, then does a Remote Config fetch and sets up another coroutine waiting for that to finish, then unblocks calls to the API proxy. So there's a ton of polling all around. Clever use of delegate callbacks make this less messy, but it's still something every dev will do once they are burned by the way Firebase handles exceptions a few times.

Case in point. Our last major push of 23 apps had recently included RemoteConfig. When you request a string from RemoteConfig that doesn't exist, you get a string back. When you request a DOUBLE from RemoteConfig, you get an exception. Didn't know that. We pushed out some data that caused the apps to fetch something unexpected and blew up about 300,000 users' experiences, since uncaught exceptions in our apps are fatal. Thanks, guys. Not documented behavior.

I know, it just sounds like I'm griping, and I am, but the quality bar can be raised so much higher with such little effort, that it's really astonishing you haven't had more developer feedback telling you so. And just so you know I'm not just a crank (although I do accept cranky as appropriate), I wrote the first chapter on Game Engine Gems, entitled "What to Look For When Evaluating Middleware for Integration". So I'm opinionated. :-)

I hope some of this strikes a chord and positive change comes out of it. Firebase has a lot to offer, but it asks a lot more of developers than you probably know.

JH

I would also mention, since we're on the subject, that I had to spend a lot of time reverse-engineering how to make FirebaseApp.Create work properly to force Firebase to use my specific app configuration while in the Unity Editor. Again, it's utterly broken because Default is whatever happens to be stored in "StreamingAssets/google-services-desktop.json", and we can't control that at runtime, so Firebase generates Default with whatever is in there, then I have to create a different AppOptions with what I really want there, but there's no way to overwrite Default nor remove Default, so I have to call it something else... anything else. If I could simply feed the Default AppOptions correctly before Firebase initializes, all this problem would go away. Again, because you're reading files rather than looking to be told what to do.

For reference, here's what I had to do to init properly. It's a rat's nest of poking and reverse engineering.

Debug.Log("FirebaseInit start initialization.");
		pathToConfig = Path.Combine(Application.dataPath, "StreamingAssets/google-services-desktop.json");

		// Set log level so we can see exceptions being thrown in the game.
		Firebase.FirebaseApp.LogLevel = Firebase.LogLevel.Debug;
		Task<Firebase.DependencyStatus> initTask = Firebase.FirebaseApp.CheckAndFixDependenciesAsync();
		initTask.ContinueWithOnMainThread(t => { 
				Firebase.DependencyStatus status = t.Result;
				if (status!=Firebase.DependencyStatus.Available)  // failed to init Firebase for one reason or another
				{
					Debug.LogError(System.String.Format("Could not resolve all Firebase dependencies: {0}.  QUITTING", status));
					Application.Quit();
				}

#if UNITY_EDITOR
				Firebase.AppOptions appOptions = new Firebase.AppOptions();
				string appName = Firebase.FirebaseApp.DefaultName;
				// Pull in the google-services-desktop.json file
				string jsonConfig = File.ReadAllText(pathToConfig);
				appOptions = Firebase.AppOptions.LoadFromJsonConfig(jsonConfig);
				appName = "current_app_name";  // just a disambiguating string

				// Create the app we want to actually work with (in UNITY_EDITOR this is often NOT the same as the default app, but on device it should be the same thing)
				Firebase.FirebaseApp.Create(appOptions, appName);
#endif
				initialized = true;
				Debug.Log("FirebaseInit initialization complete!");
				Firebase.Analytics.FirebaseAnalytics.LogEvent(Firebase.Analytics.FirebaseAnalytics.EventAppOpen);
			});

And the modal dialog fails A LOT, just hang in the middle, with the progress bar shows 12% or 36% - with version 6.11.0, for scripting build which I use the code below to process my build for package name change:

GenerateXmlFromGoogleServicesJson.ForceJsonUpdate();
GooglePlayServices.PlayServicesResolver.Resolve(
            null, false, b =>
        {
            if (!b)
            {
                Debug.LogError("Build - Google play service resolve failed");
                return;
            }
    
            PostBuild();
        });

I have to retrigger my build script one more time to come over this problem.

I did tried the version 6.13.0, it won't stuck, but got many other issues and I just have to roll back.

So if you are able to, better take the newest version a try.