Best practice for White Labelling?

[Stephen Walsh]

Hi all,

I work for a Whitelabel company that creates iOS and Android apps for client businesses. All client apps contain the same code base with some minor tweaks for colours, images, etc.

We're struggling to work out a reasonable and scalable way to implement Firebase Crashlytics and Google Analytics in our apps. 

Seemingly, Firebases' advice is to create one Project per Whitelabel: 
"For example, if you develop a white label application, each independently labelled app should have its own Firebase project. Each app doesn't and shouldn't (for privacy reasons) share data with the others."

Source: https://firebase.google.com/docs/projects/learn-more?authuser=0

But this quickly becomes out of hand when you have hundreds or thousands of clients and want to monitor the Whitelabel apps' performance as a whole, across all the different client versions. On top of this, there is an undefined project quota, source: https://firebase.google.com/docs/projects/learn-more?authuser=0

Right now we are implementing in the one project per client manner, but this is ungainly for monitoring crashes and we haven't even started using Google Analytics yet.
I'm wondering what the consequences are of all iOS apps using a shared GoogleServices-info.plist file that points to a single app in a single project?

The Xcode console throws up a warning about using a GoogleServices file with a mismatching bundle id, but are there any impairments to going ahead with this strategy anyway?

Has anyone had any experience with this scenario? I'm at a loss as to the the best implementation going forward and would greatly appreciate any thoughts you have.

All the best,
Stephen

[Sam Stern]

Hi Stephen,

Thank you for the feedback. Simply put there is no good answer to releasing hundreds or thousands of whitelabeled Firebase apps, you're not the first person to run into this.  I think you've done a good job of exploring the options and enumerating their pros and cons.

Here are a couple points you may have missed, in no particular order:

• The limit on the number of projects is per billing account.  If you can get your clients to create their own project and then add you as a second owner, you should not have this issue.  Of course this only works if your clients are comfortable putting their own credit card behind the billing.
• If you pursue a multi-project strategy the best way to monitor them all at once is to export Crashlytics and Analytics data to BigQuery and then create a combined dashboard using Data Studio or similar.
• The main reason we advise you to use separate projects is to avoid mixing unrelated data. There are good technical reasons for this, for instance if your apps use Firebase Authentication then users would be unable to have separate accounts on each app.  There are also legal reasons for this in some jurisdictions, I am not a lawyer nor am I qualified to give legal advice but you can imagine how combining data from different clients can become a problem.  You can make your own decision about that.
• If you really want to combine things into a single project please don't use a single plist file and mismatched bundle IDs.  Instead create multiple distinct iOS apps in the same project.  There's actually no limit on apps in a project, however each time you create an app we automatically create an OAuth Client ID as well and there is a limit on those.  If you are not using auth in your app you can safely delete that Client ID in your project settings and then keep creating additional apps in the project.

I hope some of that is helpful!

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 view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/5c220f36-84f5-4250-a498-405453d80c6dn%40googlegroups.com.

[Sam Stern]

Hi Stephen,

Quick update: I was wrong about one thing (just one? wow!).  Apparently there is a hard limit of 1000 apps per project, so if you have thousands of apps you're going to need multiple projects, there's no way around that.

- Sam

[wekaso...@gmail.com]

Hi Sam,

I have a similar scenario.  Probably less than 1000 apps though.

Just reading your comments you say:

"There's actually no limit on apps in a project, however each time you create an app we automatically create an OAuth Client ID as well and there is a limit on those.  If you are not using auth in your app you can safely delete that Client ID in your project settings and then keep creating additional apps in the project."

I have removed the OAuth Client ID for my app from here: https://console.developers.google.com/apis/credentials

My app is a hybrid app and uses auth via the web app not native one so it appears to work fine, login still works.

I'm guessing this would only be a problem with login and registration on a native app?

I think I can get away with using just the one Firebase app for web for all the branded apps as long as I don't mind using the same appId and measurementId for all of them.

Does this mean I can create up to 1000 iOS and Android apps without any issues? 

I am looking at adding Google and Facebook sign-in on the hybrid mobile apps using a native implementation (just for the google/fb auth) soon would this be something that I would need the native app OAuth 2.0 Client IDs for?

Many thanks,

Flon

[Sam Stern]

Hi Fion,

Last week we actually made some updates in this area and published some new guidance:

https://firebase.google.com/support/faq/#apps-per-project

There is now a limit of 30 apps per project, and to go above that you need to contact us with a business justification. We're not trying to discourage white labeling, but 9/10 people who create 30+ apps are doing something wrong and we want to make sure we guide people in the right direction.

My succinct advice is: never re-use an app ID across multiple real-world apps. Once you do that you're going off the supported path and something will eventually break.

And for your specific question: yes if you use Google Sign In you will need distinct apps, each one with an OAuth Client ID.

- Sam

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/2b11c6c3-e1cc-432d-8acc-08afe0c179efn%40googlegroups.com.

[Flon Mackenzie]

Hi Sam,

Thanks for the prompt response. 

That is disappointing.

I am offering a SaaS for non-profits organisations.  There will be one Firebase project and multiple orgs within Firestore. 

Users can belong to multiple orgs and I have the data model and security rules all worked out and tested already.

This would have one mobile app (iOS+Android) which is branded with my platform, users would register with one or more orgs.

So far so good.  

Organisations can sign up, be on-boarded and their users can start using the app with no work from my end.

The users can switch between orgs and potentially see a summary of the orgs they belong to.

The problem:

I also offer a branded mobile app option for individual organisations.  

This is exactly the same app as above but rebuilt with different branding + AppId and then deployed to the orgs own app store account.

This app points to the same single Firebase project.

This means that an org that has already signed up to the platform can then add-on a branded app and the users can use the platform app or the branded app to access this org.

Currently all I need to do is build the app with a script and assign it an orgId in the config and release it to the app store + add an app to the Firebase project and its good to go.

If there is a limit of 30 apps that means I can only do branded apps for 13 orgs (I would need iOS and Android plus the platform app would take up 3 apps).

Realistically I would not expect more than 100 branded apps.

Options to get around this limit of 30:

1. A new Firebase project for each branded org.

Issues:

• I have to spend a few hours creating the new Firebase project.  Adding 5-10 firebase extensions.  Apply the database rules, setting up storage.  Deploy the 2 web apps I have and set up hosting for these.  Check it is linked to BigQuery.  Get FCM working for both iOS and Android, Testing all of this etc etc.
• If I have 100 branded orgs this means doing this process 100 times.  I am assuming it is not possible to clone a project?
• I would have to keep applying for my project limit to be raised.  Putting this under the clients billing account is not how the SaaS payment model works. Also from experience this would add more hours of hassle with non-tech clients. 
• Any changes to a project e.g. Firestore rules or cloud functions would have to be applied to every project.  Lets say 100 of these.
• If the org already exists on the platform and wants to upgrade to a branded app then I would have to migrate their data from the main platform to a new project.  
• Users would no longer be able to access this org in the main platform app.
• Data can't be shared so a user than belongs to multiple branded orgs will not be able to see another orgs data.  (not a big issue)
• I have an admin web app for org admins who can administer multiple orgs and switch between them.  This would not work for branded orgs in a separate project.
• I have a platform admin web app for monitoring and reporting on all the orgs in one place.  This would not work for branded orgs.
• Possibly other issues I have not thought of yet.

2. A new Firebase project that houses up to 14 orgs (29 apps, 14 iOS, 14 Android, 1 web).

• All the same issues as option 1 but reduced as I only have to set up a new project every 15th branded org that signs up.

3. Contact Google with a business justification to get my app limit increased.

• While it is great that I can contact you with a business justification to potentially get the app limit increased I need to make the architectural and platform decisions now before going live.  Is it possible to apply before I have any users?  At the moment I don't even have the production project created.  What would a potential increase look like  5, 10, 100?
  

Any insights or other options would be greatly appreciated as I didn't foresee this in my planning and I will have to make a decision in the next few days.

Thanks,

Flon

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/fHPkO31MpFU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAHafJBrqBUTMOLQPr9ONKEnovep%2BzwedQbEus%3D1GcOqw4-%3DOtw%40mail.gmail.com.

[Sam Stern]

Hi Flon,

Thank you so much for providing all of that detail. It really seems like you have a deep understanding of the platform and what you want to do is pretty reasonable. Before I start discussing the details I want to be clear that your use case, with or without the 30 apps per project limit, is going to be somewhat more painful since it's not completely well supported. I am not 100% sure we can make this work for you, but I'm willing to try and help if you're willing to experiment!

Note: I'm going to try and use "App" when talking about the Firebase concept and "app" to mean something a user installs on their phone.

First of all let me enumerate the Firebase products I heard you mention, just to make sure I'm not missing anything:

• Firestore
• Firebase Auth (possibly with Google/Facebook login?)
• Extensions
  
• Cloud Storage
• Cloud Functions
• FCM
• Analytics (you didn't mention this, but I'm assuming)
• BigQuery (not clear which services you're linking though)

Before I get into workarounds, It's important to understand which limits of a single-project architecture are fundamental.

• Auth - when using auth there are a number of services where your project's name, support, email, etc will appear. If a user is using "Org Branded App Foo" and sees "Please Sign In to Flon App Bar" they will be confused and possibly scared off.
• Firestore - one instance per project. In some cases there could be regulations or customer requirements that mean you need strict separation of data by customer or by location, but you won't be able to do this in a single project.
• Analytics - the concept of an "App" within FIrebase is largely an Analytics concept and affects all the other Firebase products that use Analytics for targeting. Abusing or misusing the "App" concept will break things here.

Ok now let's get into the fun part, solutions!  

One app, multiple projects

So first of all a single app can communicate with multiple Firebase projects: https://firebase.google.com/docs/projects/multiprojects

So I think you could go with an architecture like this:

• Central Project - keep your data, central auth, functions, etc here as much as possible. In this project the "Apps" won't really matter much as most of the backend products (Firestore, Storage, etc) don't care which App they're talking to they only care about end-user identity.
• One Project per Brand - here's where you'll do Brand-specific or app-specific things like Analytics, FCM, etc. If you're lucky you may even be able to keep all of these projects on the Spark plan which would mean you won't run into the projects-per-account limit.

This multi project functionality has some rough edges (mostly around Analytics and FCM) but for products like Firestore and Auth it works just as you'd expect. What this means is that you can have a central project with just one Firestore database and Firebase Auth database and have all of the different "branded" apps communicate to this single instance for data. I think that will save you a lot of trouble.

Now the tricky thing here is Auth. What you're going to need to do is use Custom Auth to manage all of the auth for this project. So imagine this flow:

• User downloads a branded app
• User signs in using Google, which connects them to the project that is specific to that branded app. This means they see the right logo in the sign-in process and all that.
• In the background, you also go and create a Custom Auth token for that user in your central project which contains all of the Firestore data which mirrors their identity into the central project.
• The branded app silently signs in using the custom token so that it can communicate securely with the central Firestore.

I'm not sure how you're using Extensions, Storage, and Functions but it may be possible to keep all of those things in the central project as well.

Leverage the Firebase CLI

Many of the things you will need to manage on an ongoing basis can be automated through the Firebase CLI. You can deploy rules, add extensions, deploy functions, etc.

You can use something like Cloud Build to create a nice automatic deploy pipeline so that you can, if you ever need to, deploy changes to 100 different projects without sweating much.

You will need to do some one-time setup for each branded customer to configure Analytics, accept terms of service, setup auth, etc but hopefully the value of customer acquisition is high enough to make this worthwhile.

Leverage BigQuery

If you need to unify data across projects for analysis, export this data to BigQuery and then import it into a central data warehouse project of some kind. You'll pay more for data transfer but at least you won't have to flip through 100 projects.

I hope this is all helpful and that we can continue the conversation! 

- Sam

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/Mailbird-9dbdbfab-93e6-4b6d-9d75-c8b3b64347cd%40gmail.com.

[Flon Mackenzie]

Hi Sam,

Thanks for the detailed response it is was really helpful.  That is a comprehensive solution.

I am still learning the ins and outs of Firebase and this is the first time I have really pushed it.

You have all the Firebase products listed that I use.

BigQuery I only use with the BigQuery Firebase extension to export collections/documents from Firestore.

I also use the image resize extension.

I do use analytics also but not with BigQuery.

The mobile app I have is a hybrid app created with Ionic / Capacitor and built for Android / iOS.

This means I actually use the web Firebase App config to connect to firebase for most of the firebase products.

I believe the only product that uses the native Firebase app (google-services.json / GoogleService-Info.plist) is FCM as I went with the web analytics.

I tried it with your solution

One app multiple projects

This worked fine, however as I mentioned above I use the web config the only thing this actually affected was FCM.

FCM

This meant I had to send FCM messages from the new app specific project for that app. 

I would actually prefer for FCM to use the central project too and just use a topic for each app as it works this way now, otherwise I would have to send a message from the central platform (admin panel) to FCM in the specific project.

Auth 

You mention "Auth - when using auth there are a number of services where your project's name, support, email, etc will appear. If a user is using "Org Branded App Foo" and sees "Please Sign In to Flon App Bar" they will be confused and possibly scared off."

I believe this will only be for Auth password reset as this still uses the central project.  This is not an issue for me.

I am not worried the users will get confused and will handle this in the UX, again not ideal but I can deal with it.

Would this show up for google sign-in too?

Firestore 

Uses the central project.  No issues here.

Analytics

I don't mind if these get all lumped together for the various apps.  Not an issue for me at this stage.

Sure it would be better to have the analytics split out for each app but at this stage its not the end of the world if I don't.

So it looks like I could get away with not needing a separate Firebase App for every mobile app.

The only issue appears to be need to have a different appId for each app for the App and Play stores.

e.g. nz.co.myplatform.brandedtenant

I know it is not recommended but I am looking at finding a way to use a single Firebase App for each platform mobile app e.g 2 apps iOS and Android.

Perhaps I can just change the appId and leave everything else pointing to the central project.

For me I believe if I can do this the benefits would outweigh the potential issues as I would avoid having to set up a new project for each branded tenant.

If this does not work then I can create a new project for each app but initially I would just be doing this for the unique appId and FCM.  I would look at adding analytics to this also.

Once I have done some more testing and analysis I will make a decision between these 2 methods -one project one App vs many projects many Apps.

What are your thoughts on this?

I am curious on the limit of 30 Apps vs making a new project for each app as far as how it affects Firebase.

Is there a technical reason that for doing this? 

If I have 100 Apps in one project or 100 projects what is the difference to Firebase? 

Just trying to understand.

Cheers,

Flon

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

[Sam Stern]

Hi Flon,

Glad that was helpful!  Answers inline:

On Mon, Feb 15, 2021 at 12:44 AM Flon Mackenzie <wekaso...@gmail.com> wrote:

Hi Sam,

Thanks for the detailed response it is was really helpful.  That is a comprehensive solution.

I am still learning the ins and outs of Firebase and this is the first time I have really pushed it.

You have all the Firebase products listed that I use.

BigQuery I only use with the BigQuery Firebase extension to export collections/documents from Firestore.

I also use the image resize extension.

I do use analytics also but not with BigQuery.

The mobile app I have is a hybrid app created with Ionic / Capacitor and built for Android / iOS.

This means I actually use the web Firebase App config to connect to firebase for most of the firebase products.

I believe the only product that uses the native Firebase app (google-services.json / GoogleService-Info.plist) is FCM as I went with the web analytics.

I tried it with your solution

One app multiple projects

This worked fine, however as I mentioned above I use the web config the only thing this actually affected was FCM.

FCM

This meant I had to send FCM messages from the new app specific project for that app. 

I would actually prefer for FCM to use the central project too and just use a topic for each app as it works this way now, otherwise I would have to send a message from the central platform (admin panel) to FCM in the specific project.

Auth 

You mention "Auth - when using auth there are a number of services where your project's name, support, email, etc will appear. If a user is using "Org Branded App Foo" and sees "Please Sign In to Flon App Bar" they will be confused and possibly scared off."

I believe this will only be for Auth password reset as this still uses the central project.  This is not an issue for me.

I am not worried the users will get confused and will handle this in the UX, again not ideal but I can deal with it.

Would this show up for google sign-in too?

Yes Google Sign In will show your app's name, logo, and support email. This is based on the OAuth Client ID but there are a limit of 30 of those per project. More on this below.

 

Firestore 

Uses the central project.  No issues here.

Analytics

I don't mind if these get all lumped together for the various apps.  Not an issue for me at this stage.

Sure it would be better to have the analytics split out for each app but at this stage its not the end of the world if I don't.

So it looks like I could get away with not needing a separate Firebase App for every mobile app.

The only issue appears to be need to have a different appId for each app for the App and Play stores.

e.g. nz.co.myplatform.brandedtenant

I know it is not recommended but I am looking at finding a way to use a single Firebase App for each platform mobile app e.g 2 apps iOS and Android.

Perhaps I can just change the appId and leave everything else pointing to the central project.

For me I believe if I can do this the benefits would outweigh the potential issues as I would avoid having to set up a new project for each branded tenant.

If this does not work then I can create a new project for each app but initially I would just be doing this for the unique appId and FCM.  I would look at adding analytics to this also.

Once I have done some more testing and analysis I will make a decision between these 2 methods -one project one App vs many projects many Apps.

What are your thoughts on this?

I think Google Sign In will be your biggest blocker here, as mentioned above,

 

I am curious on the limit of 30 Apps vs making a new project for each app as far as how it affects Firebase.

Is there a technical reason that for doing this? 

If I have 100 Apps in one project or 100 projects what is the difference to Firebase? 

Just trying to understand.

There are two technical justifications here, although they were not primary drivers in the decision:

• You can only have 30 OAuth Client IDs in a single project.
• Google Analytics has serious performance issues when a project has too many Apps.

The main reason we made this change was because most developers who have many apps in a project are doing something wrong, and we want a chance to speak to them and guide them before they get committed to a setup they can't support long-term.  For instance many developers are disappointed that they can't truly isolate customer Firestore/Auth in a single-project setup, but they don't find this out until it's too late.

- Sam

 

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/Mailbird-e441d999-8538-4e9b-b249-221d94c326c3%40gmail.com.

[John Rodkey]

If I may, I'd like to offer up another alternative.

I do believe a separate project per customer is best and here is how we are developing for it.

We create a central project to store all client configurations, store client data usage regarding our application, and we are currently working on a sink to capture all logs.

The benefit of the central project is to allow your users to leverage one application but achieve data locality and isolation at the DB/Project for compliance and security reasons.  Now the tricky part of this configuration comes with firestore rules and event function deployments.

How we are currently experimenting and  deploying the rules and functions 

1. Leverage a single repository for rules and functions (e.g., Github or Google Cloud Source Repo)

2. Establish a cloud build trigger in each client project to build and deploy based on the rules and functions repo.

3. Establish a pub/sub listener for cloud build notifications and allow it to attempt a pre-determined number of deploys before pushing the failed build to a dead letter queue. We then trigger a notification to our team when a dead letter queue receives messages.

Now things you may need to worry about - the total number of projects you create and if creation starts to fail. This can be overcome by establishing a relationship with your GCP Rep. Let them know your business model and why you are needing to create so many projects, etc.  They want to work with you to grow your business because it also grows the GCP cloud.

You can get pretty far automating the setup with Terraform and the REST APIs for the missing pieces.  

Also, a benefit of the per-project model is the fact that you can allow customers to select the database location and most customers will choose the location closest to them, providing them with better latency if the location they select is closer than your default location selected.