Many Apps, Same Project

[Zach Whelchel]

We use a single Firebase project to create many white-label'd apps. We like this because all of our apps have a single user base and share a single database.

The problem is that Firebase has a hard cap limit on the amount of apps (around 100) you can have in a single project.

So now we have 100+ apps that we need to migrate in some way to account for this hard cap. We'd love for each of our apps to use the same Firebase app (well at least one per platform, iOS, Android, etc)... but this isn't possible as you have to provide a matching bundle id... and the App Store dictates that those all must be different.

Is it possible that the bundle id is only used for certain services? I know for sure it must be accurate for push notifications to work. But if we switched to a different service (OneSignal) for push notifications would the rest work alright? Or is the white-labeled "many apps, same project" model just not a good fit for Firebase?

[Samuel Stern]

Hi Zach,

If you search around on this mailing list you'll see that this is a relatively frequent topic.  In short, we don't recommend putting many white-labeled apps in a single Firebase project.  We generally suggest only putting apps in the same project if they represent the same experience on different platforms/devices.

Putting many apps in the same project creates issues around data privacy, authentication, billing, analytics, etc.  I don't think switching to another push notification provider will help you here, targeting by bundle ID / package name is necessary for many mobile app services and is not specific to Firebase.

- Sam

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/ee629f1d-dfec-4015-9e37-cdd925b33c3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Zach Whelchel]

Got it. Thanks for the reply. I'm curious then what Firebase's suggestion would be? Should we make a separate project for each white-labeled app? And then have each app use a custom configuration that points to a common project to share the same database as is detailed here? https://firebase.googleblog.com/2016/12/working-with-multiple-firebase-projects-in-an-android-app.html

Unfortunately this would mean we would have our auth split apart which is concerning for our setup. We have a dashboard where users of any app can login online and make changes to the database that may change any of our white-labeled apps... so it really would be difficult to pull everything apart.

I guess we could switch to a different Auth provider also? We just really need to be able to access the same database...

So... would Firebase just say sorry, this project isn't a good fit?

You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/zkAUYfWJgN8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAHafJBraWKMUH5hyrK09CEvmonoBE6HW11gSU41UeMcAtVKV5w%40mail.gmail.com.

[Zach Whelchel]

Ok, a few more questions. There is a precedence for pointing a single client towards multiple Firebase databases (as shown in that blog post), but I can't find if they have to be using the same bundleId.

Currently I'm testing using the same firebase app configuration in multiple iOS apps and the Auth and Database access are working... if those two services continued to work despite the fact that the bundle id in the GoogleService-Info.plist doesn't match the app's actual bundleId then I'd be good to go. But you mentioned in your reply that a false bundleId effects things in Authentication, etc? So what does it effect? What will break about my current solution?

And if this solution won't work... then what would Firebase recommend? If it just isn't possible to set up a white-labeled set of apps on Firebase then it would be helpful for someone from Firebase to say that so that we weren't left trying to make it happen in vain.

[Samuel Stern]

Hi Zach,

Thanks for providing more details.  You are right that the general recommendation is one project per white-labeled app but I can see how that makes things difficult for you.  So here are a few suggestions:

• If you have any truly shared data, put that in a separate Firebase project.  None of the apps should "belong" to this project but they can all access it (via the method you described above).  There is no bundle ID / package name requirement for accessing the database unless you implement it yourself.
• Keep any app-specific data in the default database for the app's project.
• To authenticate each app to the central database, you will probably want to look into custom authentication.  Here's an example of a possible flow (but not the only one);
• 1. When the app starts, authenticate to its own project.  This should get you an ID token valid for the app-specific project.
• 2. Send that ID token to a cloud function running in the "master" shared project.  That cloud function can validate the token, likely checking it against a whitelist of apps. Then that function can use custom auth to mint a new token belonging to the master project and return that token to the client app.
• 3. The client app receives the custom token and uses it to sign in.  Now the client can securely communicate with the master database.

I hope that all makes sense!  In this way you can have the benefits of shared data while also keeping strict separation of bits you don't want to share.  This also allows you to give your clients access to their Firebase projects without ever giving them control of the "master" project which contains shared data.

- Sam

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CA%2BAN_vr8cE%3DjAFuko17LtEYG1Mgisb_7Omt%2BEgyjHStYkg-wWg%40mail.gmail.com.