IOS - multiple schemes for different targets of an app

[Roger Price]

I have an app which is working fine in Firebase - using Database and Auth (Google & Facebook).

I want to build a different version of it that will have a different name and needs a different bundle-ID so I have added a scheme for it - this requires adding an new Info.plist....and all of this seems to work fine....

BUT: How can I add the relevant GoogleService-Info.plist file the corresponds to the new Bundle-ID?   There seems to be no way to rename it and xCode does not let me drop in a file with an existing name - even if I specify that it is only part of the new target.

[Christian F. Howes]

good question - i haven't integrated firebase into iOS myself yet, but have this exact same problem - multiple targets that will need different GoogleService-Info.plist files.

cfh

[in...@intelligenti.com]

A couple of options come to mind, neither of which I’ve tried:-

1) 

Conditional compilation with a build flag per target and then use the [FIRApp configureWithOptions:] providing an FIROptions instance initialised using [FIROptions initWithGoogleAppID:bundleID:...] 

2)

Within Build Phases use a Run Script phase that runs before the Copy Bundle Resources phase to copy the target specific GoogleService-Info.plist file over the GoogleService-Info.plist that’s bundled in the app.

-Mark

[Gero H]

I have had the same problem and used the second approach. This works great and I won't clutter my actual analytics (currently only using that) data with crap from when I run the app while developing. I also have a sandbox for the analytics to play around in.

However, there is one problem: I would like my internal Testflight testers to also use my debug scheme and its associated bundle id, so that their analytics don't land in the release database either. 

Sadly, iTunes Connect makes this difficult, because I can't change the bundle id for test builds. I would have to create a separate app in iTunes connect to make the bundle id I use for my debug firebase analytics distributable in Testflight. I don't want that, though, since I don't want my testers to basically have to treat their builds like an entirely different app (once I put out a release version, I want that to replace their test version gracefully). 

What I tried so far is to use the GoogleService-Info.plist in my scheme, but still use the normal bundle id I use for the app. Obviously this is not meant to be done (and the SDK outputs an according warning to the console), but so far it seems to work (I haven't seen updates on the Firebase console so far, though, have to wait until tomorrow for that). Does anybody have experience trying this out? As I said, I am only using Analytics so far, so maybe any issues with the mismatch aren't as important here. I would also not mind if certain things won't work as long as I can test that way.

[Kato Richardson]

Hey Gero,

It feels like you've placed a pretty impossible set of constraints on the tools here and like this can be done with a bit of flexibility.

If your testers are purely testers and not real users, it seems reasonable to maintain an early release version of the app they can download. You can still replace their test version gracefully--you just maintain two apps and one of them gets bleeding edge, the other just stable.

If they are real users and just willing to endure less stable versions, it doesn't make sense that they need to be excluded from analytics. They are real users. You should be able to use the app version to differentiate edge users vs stable.

☼, Kato

--
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-talk+unsubscribe@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/049515c6-1e4f-4c82-a30d-65c78dbdcc14%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Gero H]

Hello Kato & thanks for your response.

Don't get me wrong, this was less of a feature request. I understand my case is too specific to warrant its own solution. I was just wondering how the Firebase SDK behaves if the two identifiers are mismatched. From what I can see on the console it only throws a warning, but logging events then works as normal. Unless that would somehow corrupt the database that wouldn't be a problem for me. I can picture it might be difficult to pinpoint behavior in this unspecified configuration, so if explaining what happens is too complex, just ignore me. If it's possible to say what might go wrong in one or two sentences, please let me know.

And just to explain why I'm hesitant to create a separate App in iTunes connect for my test users: They're supposed to be able to see/test potentially unstable versions, but might not have a developer background (colleagues from a different department). I just _know_ they will try to install both, the edge app from Testflight and the stable version from the normal AppStore once it is there and not tell me which they refer to when providing feedback. :)

For now I will play it safe and change that strategy, though. They will only get test versions linked to the stable firebase identifier. To avoid cluttering the analytics with usage data from these testers (they're unlikely to reflect actual user behavior) we'll turn analytics off for them when needed. And for testing new analytics concepts I'll give them developer builds directly (on dev devices, circumventing Testflight) using the developing firebase identifier.

Btw, I really like Firebase, although I'm only using it for Analytics (so far). Adding it to the project worked like a charm, great work!

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/049515c6-1e4f-4c82-a30d-65c78dbdcc14%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.