Error about transitive dependencies that include static binaries about firebaseui-ios HOT 9 CLOSED

Me too!

from firebaseui-ios.

Same with me. I fixed it by doing this with my pod file.

pod 'Firebase'
pod 'FirebaseUI', '= 0.2.6'

from firebaseui-ios.

+1

from firebaseui-ios.

Let's separate this into two issues:

1. Transitive deps include static binaries: this is an issue with the way Google does it's libraries (and by extension, how we do our libraries). I believe if you don't use_frameworks! it will work, since all the deps will be static, though this prevents the use of dynamic frameworks.
2. Splitting out auth providers into subspecs (or at the very least, a split between the core features and the auth features). Originally we wanted to provide everything together and see how people were using it to get a sense of how it should go. I see two options for this: FirebaseUI/Core and FirebaseUI/Auth or FirebaseUI/Core and FirebaseUI/Providers. Anyone have any preference?

@davideast thoughts?

from firebaseui-ios.

Item 2 will be fixed in #24, as it will allow for /Auth and /Core. /Provider is in the works, but will take a little while.

We're taking a look at the cases where Google fails out due to transitive deps on static libs--I think it's what I mentioned above, so I would try to use them statically if possible.

from firebaseui-ios.

Thanks Mike!

Indeed removing use_frameworks! does the trick. I'll stick with that until another pod necessitates otherwise.

As far as /Auth vs /Provider goes, I'd be a fan of separate /Providers for each provider since the Google support libraries appear to be fairly hefty and it leaves some room for expansion without further bloat should other providers be supported in the future. But I don't plan to use auth at all initially, so I defer to someone whom it may matter more to :)

from firebaseui-ios.

Yeah, we're thinking the same thing--though we'll start with /Auth and then move to /Providers in a later release (keeping /Auth as the sum of all providers).

Any reason you're not planning on using auth? Just don't need it while prototyping the app, too difficult to set up providers or security rules, something else?

from firebaseui-ios.

Something else :) I'll explain over email as not to derail this thread

from firebaseui-ios.

Ok, I'm going to mark this as "Works as Intended" after 0.3.1 (just shipped) since the fix here is to remove use_frameworks! or switch to using FirebaseUI/Core if you don't need auth.

If you need to use use_frameworks for Swift only libraries in addition to FirebaseUI/Auth in the future, please create a new bug that references the issue, and we'll see about how to fix it. #26 has been created to track multiple providers (which will partially solve the issue for users of auth providers other than Google).

from firebaseui-ios.