New Firebase version 3.2.0

[telip007]

Have to update the requirements...

[vzsg]

It's quite a breaking change, most of the classes have been renamed, the SDK is built differently and there are tons of new features.

I've ported the extensions over to the new SDK in my fork (https://github.com/vzsg/FirebaseRxSwiftExtensions), but I'm a little hesitating to set up a PR, because there were some sacrifices.

• I removed OSX support because FirebaseOSX has not been updated (yet?).
• And I set ENABLE_BITCODE to NO, because I could not otherwise get the library to compile. See the podspec for my workaround. There might be a better way for more experienced Pod users...

---

That compilation error might be a bug in CocoaPods or a mistake on Google's part. Either way, if you add the new Firebase SDK to a brand new Pod library, the development pod cannot import the modules ("No such module" error), even though the example project can.

I think it might be because the SDK pods contain vendored frameworks instead of the old headers+dylib setup. But I'm just a newbie. If there's a clean solution, I'll clean up my fork in a jiffy.

[mbalex99]

I've been trying to do this project in https://github.com/RxSwiftCommunity/RxFirebase
However I'm having quite some difficulty with exactly what @vzsg mentioned.

For those still on v2, please don't update just yet. You can migrate your database to the next console, but don't update your client specs.

As my projects heavily depend on RxSwift and Firebase.
I'll be at Google IO in the morning down in the MountainView and will hopefully get some help.

@vzsg I added this issue to the Cocoapods repo seeking help as well: CocoaPods/CocoaPods#5368

Trying to fix it right now but let me know ASAP if you have a solution!

[vzsg]

Good luck!

I spent last night with experimenting instead of sleep, but I haven't found anything apart from the -undefined workaround I mentioned. :(

It's very hard to search for this issue, but this seems close enough, and doesn't help us at all: CocoaPods/CocoaPods#3841

---

As I use FirebaseRxSwiftExtensions heavily, but will have to update to 3 soon, I think I'll just copy the source files into the app. That's another temporary workaround that doesn't involve killing Bitcode.

[mbalex99]

CocoaPods/CocoaPods#3161

Is a good lead. But in the worst case scenario I will ask mike macdonald
since he works on firebaseui which should effectively have the same pod
layout (unfortunately I don't think it does)
On Thu, May 19, 2016 at 1:10 AM Zsolt Váradi [email protected]
wrote:

Good luck!

I spent last night with experimenting instead of sleep, but I haven't
found anything apart from the -undefined workaround I mentioned. :(

It's very hard to search for this issue, but this seems close enough, and
doesn't help us at all: CocoaPods/CocoaPods#3841

CocoaPods/CocoaPods#3841

As I use FirebaseRxSwiftExtensions heavily, but will have to update to 3
soon, I think I'll just copy the source files into the app. That's another
temporary workaround that doesn't involve killing Bitcode.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#8 (comment)

Maximilian Alexander
[email protected]
http://blog.edenmsg.com

[neoplastic]

I've started a project, coincidentally, called RxFirebase. I've added extensions for Auth, Database and Storage. Going to do more but I need sleep... Have fun!

[vzsg]

It seems this hack is getting popular, @neoplastic reached the same conclusion as I did last night:

  s.pod_target_xcconfig = {
    'ENABLE_BITCODE'         => 'NO',
    'FRAMEWORK_SEARCH_PATHS' => '$(inherited) $(PODS_ROOT)/**',
    'OTHER_LDFLAGS'          => '$(inherited) -undefined dynamic_lookup'
  }

But xcodebuild complains about it (-unused is deprecated and FirebaseDatabase is not a dylib). We shouldn't do this in production...

[neoplastic]

Weird, I'm not getting those warnings.

[mbalex99]

Warnings or no, I don't think this is a solution. This definitely is a hack.

[mbalex99]

@neoplastic What did your podpsec look like. You said you implemented those methods so I assume your development pod classes built properly.

[vzsg]

I copied the above lines from his podspec.

@mbalex99: Any news from the I/O?

[mbalex99]

I just talked to @mcdonamp about this and he agreed that the podspec was published oddly. I brought it up to their attention and sent him an email and he'll look into it.

[neoplastic]

@mbalex99 Yeah, what @vzsg copied is from my pod spec. The development pods build properly however indexing in Xcode is prone to mistakes and slowness which is not ideal but doesn't stop me from writing code backed on it, makes me hesitant to publish anything as a pod though.

Definitely there's a podspec weirdness on Firebase's side which without the hack makes it impossible to develop an extension library without it.

Also I believe some of the Google libraries are not bitcode compatible? Its quite likely, hopefully that can be resolved down the track too but I wouldn't hold my breath.

[mbalex99]

Firebase guys confirmed that their library is bitcode compatible. This is just a podspec issue at the moment!

[asciimike]

Sorry, busy day, and now, long story...

"That compilation error might be a bug in CocoaPods or a mistake on Google's part. Either way, if you add the new Firebase SDK to a brand new Pod library, the development pod cannot import the modules ("No such module" error), even though the example project can."

This is super weird: the Firebase pod is built with Bitcode enabled, so it's pretty strange that you have to disable Bitcode in order to get your app to compile. We also build a sweet modulemap, so import Firebase should just work.

OSX (along with tvOS and watchOS) support is something we're still working through: given that Firebase is now much more than just a database and an auth product, what it means to use features like Analytics, Config, Crash Reporting, and Invites/Dynamic links on these platforms, and how they interact with the various system resources is something we're still working through.

On the FirebaseUI podspec--I'll come clean and admit my hideous technical sins. It's a byproduct of a few things:

• Firebase builds static "frameworks" (we're supporting iOS 7 still), so you're often likely to end up in the scenario where you get the error: "Transitive dependencies on static binaries." This is because the dependency on Firebase that your app has, and the dependency to FirebaseUI (which depends on Firebase), means that our "static framework" appears dynamic in the first case, but is static in the other, so CocoaPods doesn't know how to handle this (should it be dynamic in the first case but static in the second? Which does it pick?).
• Since we couldn't solve the above issue (and it's not clear that anyone who ships closed source code in this manner can solve it), we decided to ship the FirebaseUI pod as closed source, and provide the open source in Github. Since it's closed source, it gets around the issue above (since the deps can be locked in rather than attempted to be built, forcing CocoaPods to pick dynamic or static).
• FirebaseUI shares the same code with what we've open sourced, but the project provided doesn't yet build properly in the .xcodeproj provided--we went ahead and built all the frameworks separately, globbed them together into a zip file, and shipped them to you in this fashion, solving the above problem while also keeping the onboarding experience cleaner (and providing the code as open source). Since our code labs and quickstarts depend on FirebaseUI, we had to ship this in a usable state and clean up later--this will likely end up being my weekend project.
• I have no clue how development pods work internally (horray for documentation!), so my solution while developing FirebaseUI was to actually hack my ~/.cocoapods/repos/master/Specs/FirebaseUI/0.4.0 podspec to be my development pod (instead of using :path =>), meaning I got around all the pathing issues, since it treated my pod like a real pod. If someone can get my any useful information on how development pods work, I'd love to hear that :)

Short term, you can just copy the source of this library into your app and hack around it, though I don't anticipate that being a long term solution. Medium to long term, I see a few ways this could go:

• Ship the FirebaseRXSwiftExtensions pod as a vendored framework (as I'm doing for FirebaseUI)
• Make everything a weak reference to Firebase, and have the developer also import Firebase. Since there's no longer a dependency on Firebase in CocoaPods, it'll let you install both, and at runtime since Firebase will exist, everything should link up properly

Very long term, if we stop supporting iOS 7 and build everything as a dynamic framework, everything will Just Work™

Happy to work with folks on these, since I definitely have a vested interest (through FirebaseUI, as well as just as a developer who builds on Firebase) to have a cleaner solution to this problem.

[neoplastic]

Thanks @mcdonamp that clears a whole lot up! I'm looking forward to implementing the shiny new stuff!

[mbalex99]

@neoplastic are you familiar with how to do weak frameworks?

[neoplastic]

I'm assuming that @mcdonamp is referring to the podspec weak_frameworks thus requiring that the base project includes the required libraries in the podfile.

I've not used this myself though, never really needed to until now.

[mbalex99]

Alright so I'm guessing

1. We can add the frameworks into the repo manually, mark them as vendored
   and weak
2. But the podspec will require that the users also have a pod for Firebase
3. This should allow us to compile the development pod correctly.

Correct me if I'm wrong?

On Sat, May 21, 2016 at 7:06 PM neoplastic [email protected] wrote:

I'm assuming that @mcdonamp https://github.com/mcdonamp is referring to
the podspec weak_frameworks
https://guides.cocoapods.org/syntax/podspec.html#tab_weak_frameworks
thus requiring that the base project includes the required libraries in the
podfile.

I've not used this myself though, never really needed to until now.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#8 (comment)

Maximilian Alexander
[email protected]
http://blog.edenmsg.com

[mbalex99]

@mcdonamp

Hey Mike, I talked to a ton of people and it looks like most Google published pods have a lot incompatibilities. I searched and I think SegmentIO's pods which uses GoogleAnalytics seem to not have this issue.

I can't tell what they're doing that's so special but the pod with development classes works fine here: https://github.com/segment-integrations/analytics-ios-integration-google-analytics/blob/master/Segment-GoogleAnalytics.podspec

[dbburgess]

Has anyone found a solution for this?

[mbalex99]

@mcdonamp Do you think you can create a dynamically linked framework and static version at the same time like how Localytics does it?

This is what they have in their docs

In your Podfile add the following content

platform :ios, '8.0'
pod 'Localytics', '~> 4.0'

The Localytics pod uses a dynamic framework. If you need to use a static binary (e.g. you support iOS 7) then use the following pod

platform :ios, '7.0'
pod 'LocalyticsStaticFramework', '~> 4.0'

Localytics iOS Docs

[asciimike]

It's something I've thought of, though I'm not sure how feasible it is with our current build process. I'll ask around and see if we can come up with a better solution.

[mbalex99]

@mcdonamp Let me know how if I can help in anyway. I just updated the RxJavaFirebase and RxJSFirebase projects with extreme ease but this one is a toughie especially with Swift PKG manager coming out in full force lately.

[asciimike]

@mbalex99 looks like we're planning a transition to dynamic frameworks for the CocoaPod, though no word on timeline. I'll let you know if you can help out though, especially when it comes to testing this :)

[mbalex99]

@mcdonamp I will take you out for drinks if you can push it! Thank you so much!