How to add GoogleService-Info.plist in the sample project

[dakeshi]

This topic is about finding better way to add GoogleService-Info.plist in the sample project.
(refer to #89, 252f661)

I think that many developers are familiar with dragging GoogleService-Info.plist.
It is the most recommended way to add GoogleService-Info.plist in many google products.

• Add the configuration file to your project section in Google analytics
• Add the configuration file to your project section in Google sign-in

It's working well.
But we are developers. We have a censor to have doubt and try to find the better way.
And we need to provide the easy and simple instructions for new users not just for experienced developers.

In the FirebaseUI sample project, there are two ways to add GoogleService-Info.plist in the sample project environments.

• Dragging it in the sample project root.
• Copy GoogleService-Info.plist into sample project folder (samples/obj-c/GoogleService-Info.plist or samples/swift/GoogleService-Info.plist)

Because our sample project already have a reference for GoogleService-Info.plist, we can just fill up the reference with the second technique.

So, let's start with @yramanchuk's thought about the pros and cons of copying file. (refer to the conversation in 252f661)

pros of copying file:

• developer can determine that project is not configured on compilation time / not on runtime when appropriate error is shown;
• the official document doesn't explicitly states that we need to drag plist (anyway I can update it based on our discussion if it's needed)
• Xcode project file is not modified after file copy, thus users are not confused that they added any changes in project and will not commit them after contribution
• configuration gif should be shown on main page which already contains media (https://github.com/firebase/FirebaseUI-iOS/tree/v0.6.3) - technically page can be too heavy

cons of copying:

• it's already described in Firecasts
• can be slightly more confusing for new users

Please share your thought about this issue.

[dakeshi]

I totally agree that @yramanchuk's pros and cons.

I prefer to use dragging plist file even though copying it has some kinds of merits

• dragging GoogleService-Info.plist file into the project
  The big advantage of dragging file would be the consistency.
  Maybe, dragging is the most familiar way for developers to add something in the project.
  ex) frameworks, files and images
• copying it in the specific folder not the project itself
  What I most like of this is compile time check. You can quickly notice what is required in the project. Management of the project is easier than dragging. You can not commit for copying plist file with gitignore support.

But the latter technique is too limited. It works only in our sample project environments.
Even though our sample project has a reference for GoogleService-Info.plist file,
the most of projects users create don't have a reference setting as a default.
I think that demo project needs to configure the similar environment which developers can be faced with.

In the app development, they can create the new projects or update the project for FirebaseUI instead of starting with our sample projects. So, I guess that they would choose dragging GoogleService-Info.plist file to implement FirebaseUI.

[morganchen12]

Most of our users will drag the plist file into their project. We should adopt this method if we want our sample installation flow to be consistent with how one would set up an actual project with FirebaseUI.

This adds a burden to the maintainers since we cant gitignore the plist file within our xcodeproj file, but imo it's worthwhile.

[DevAndArtist]

@morganchen12 @dakeshi

Question: I always wondered if it's even save to simply drag and drop the .plist to the project instead of hardcoding the values?

Don't get me wrong, it's an easy way and it gets the job done, but it also exposes all the urls and API keys directly to the public, because anyone can extract the assets inside an app payload and read the .plist file, but not everyone can reverse engineer a compiled binary with hardcoded values.

Wouldn't it be better if Firebase would provide a copy and paste template of the values for each supported language as a 'safer' alternative?

[morganchen12]

@ianbarber can probably answer that in more detail than I can.

[ianbarber]

Agree that not everyone can pull values out of the binary, but I'm not sure there is much difference to a motivated individual. Those are client side variables so they're fundamentally untrustworthy. That's why we have database rules and so on for security properties.