
Welcoming Fabric to Google - mayop100
https://firebase.googleblog.com/2017/01/FabricJoinsGoogle17.html
======
s_dev
Fabric was a much better analytics tool than Google Analytics.

It's better because:

Instant crash reporting reduces release time anxiety. iTunes and Google
analytics need 24 hour collection period.

Fabric can offer Fastlane and Beta -- Toolkits that help deal with
distributing builds to testers and releasing apps. Google has nothing to
compete with here.

Whatever way Fabric seem to define active users and sessions they seem to
produce more accurate reporting while Google numbers integrated with the exact
same app produce higher more ego stroking numbers.

~~~
odbol_
Really? That's interesting because for our purposes, Fabric's graphs and
windows into the data were much too general and coarse-grained.

For instance, there is no way to see all the data! They only give you the
first page of top results. I asked them for pagination and they said it was
"technically difficult." Whereas with Google Analytics, I could dive as deep
as I wanted into the data. Even when I wanted to isolate a unique, rare event
out of thousands.

Plus I could search GA, and correlate different events and properties. Fabric
only gave the very basic essential graphs. Which might be great for monitoring
a giant app like Twitter, where individual events are just noise, but when
you're just getting started with 100-1000 users, you want to see everything
those users are doing, especially the outliers.

------
huangc10
The title is a bit ambiguous. From my understanding, Google (Firebase)
acquired Fabric from Twitter (not necessarily "joining").

Fabric is one of the top dev tools I use for iOS. I wonder what kind of change
is in store...

~~~
krat0sprakhar
Yes, you're right - it is an acquisition. Jeff Seibert clarifies in his tweet
[https://twitter.com/jeffseibert/status/821780349164388356](https://twitter.com/jeffseibert/status/821780349164388356)

~~~
mbesto
More specifically, Twitter is carving out (i.e. divesting) Fabric and selling
it to Firebase, which is a wholly owned subsidiary of Google (or perhaps
selling it to Google directly).

~~~
trevyn
Firebase is really just a Google brand at this point, not a separate company.

~~~
nstj
sounds like @mbesto is referring to the changes in cap table/shareholding
structure rather than the 'vibe' of the deal

------
niftich
Huh, interesting. I once responded to speculation that Google would buy
Twitter by saying [1] they'd be better off neutering Twitter's ad network and
data mining ambitions that were largely buoyed by Fabric and Crashlytics, and
now I figure this will largely accomplish that. It also disproves my point
that Twitter can sustainedly pivot into this space [2] by leaning on Fabric,
Digits, and Magic Pony, and answers my more recent musing about how Fabric
will fare with Twitter's recent downsizing [3].

[1]
[https://news.ycombinator.com/item?id=11913828#11914620](https://news.ycombinator.com/item?id=11913828#11914620)
[2]
[https://news.ycombinator.com/item?id=11937756#11942293](https://news.ycombinator.com/item?id=11937756#11942293)
[3]
[https://news.ycombinator.com/item?id=12784274#12784473](https://news.ycombinator.com/item?id=12784274#12784473)

------
danielhooper
Knowing Google's reputation with abandoning developer tools and services, can
anyone offer suggestions as to possible alternatives? Or counterpoints as to
why I shouldn't fear this service degrading over the next year or two? We're
currently using Fabric and Crashlytics for our iOS app where I work and this
news has prompted us to research alternatives.

~~~
the_mitsuhiko
> We're currently using Fabric and Crashlytics for our iOS app where I work
> and this news has prompted us to research alternatives.

I spent the last few months working on getting iOS Support going in Sentry
(sentry.io). Would love to hear feedback. Not only do we provide a hosted
solution but it's also 100% Open Source which should give you the confidence
that it will continue working for you no matter what happens.

~~~
nstj
Bravo on Sentry - it's a terrific platform. I'm especially fond of the
breadcrumbs, they're a great feature.

~~~
the_mitsuhiko
Thanks so much. It's always great to hear when people enjoy what we're doing
:)

~~~
julien_c
Love it as well and I am recommending it to everyone I know who's shipping iOS
apps

------
fharper1961
Seems to me like the main value for Google is the data from all the apps that
have Fabric SDK integration (e.g. Crashlytics).

Quote from the Fabric blog post [https://fabric.io/blog/fabric-joins-
google](https://fabric.io/blog/fabric-joins-google)

"Fabric has grown to reach 2.5 billion active mobile devices".

~~~
guelo
They have the app data on the Android side which is probably a decent proxy
for the iOS app market, but Crashlytics gives them direct visibility into a
sizable chunk of the ios market.

------
nstj
Having experienced some rather concerning keychain issues with Digits a few
months back and seeing the writing on the wall with Twitter and their
stockholders calling for blood I dropped all of my Fabric dependencies in
November.

For crash reporting the best alternative I found (superior to Crashlytics IMO)
is Sentry[0]. It's been awesome so far and allows you to easily federate crash
reporting over multiple platforms. I have no association with the company.

[0]: [https://sentry.io/](https://sentry.io/)

~~~
zeeg
Aside we're also building a bunch of open source tooling (our entire platform
is open source) around mobile, so if you're looking to roll your own or bring
something in-house, we'd love to hear your feedback.

[https://github.com/getsentry](https://github.com/getsentry)

------
atarian
Twitter just lost one of their crown jewels; Fabric is probably the biggest
mobile analytics platform out there.

~~~
on_and_off
It is also a bizarre buy.

Google has been building a competitor to fabric crash reporting. 6 months ago
it was an MVP, but the version unveiled recently is pretty close to fabric.

I am not sure what they are buying here, it seems that google could sherlock
everything that fabric does, especially since fabric is not that great in my
experience.

Maybe it just illustrates that I am missing some info on why Google would get
in such a buyout

~~~
crgt
As an example - we use Crashalytics at work. Even if Google built a parity
product, we wouldn't have switched; Crashalytics was a known entity with few
pain points. So if Google wanted our data (and others like us..) the only way
to get that data is by acquiring Crashalytics. tldr: they bought it for the
install base, not the product.

------
rjvir
What does this mean for Twitter Digits? Will their free SMS authentications
continue?

It would be a perfect fit if they phased in Twitter Digits as a Firebase
authentication provider - I suspect many developers (including myself) already
use these 2 services in tandem.

~~~
jrowley
I wonder what it costs to operate Twitter Digits. I can't imagine they are
using Twilio as an SMS gateway.

~~~
bdd
Twitter used to be the biggest SMS sender in United States. Much larger than
Twilio, even bigger than operators like Verizon and AT&T. Infrastructure that
came from Cloudhopper acquisition with continuous care and improvement gave
Twitter a reliable and super cost effective _world-wide_ SMS delivery
platform.

(I was an employee 2012–2016)

~~~
jrowley
Wow, thanks for the insight. It's easy to forget that Twitter was an SMS
centric platform not too long ago.

------
jrowley
Silly me - I was concerned they somehow acquired the Fabic python library.

[http://www.fabfile.org/](http://www.fabfile.org/)

~~~
gdulli
Yeah, that moment of panic when you think something Google acquired is
something you use.

~~~
tobltobs
In the case of fabric/fabfile this wouldn't matter, as fabric/fabfile looks
dead anyway. No Python 3 support, no road map, last Github activity 5 months
ago.

~~~
closed
There is a roadmap:
[http://www.fabfile.org/roadmap.html](http://www.fabfile.org/roadmap.html)

One of the goals in the roadmap is to move part of Fabric's functionality into
another library (Invoke), which does have recent activity and supports Python
3.

~~~
neuronexmachina
Unfortunately, the main dev has been saying that he'll be releasing a rewrite
with Python 3 support "at the end of the month" for the past 2-3 years.
There's actually a fork ("Fabric3") which fully supports both Python 2.7 and
Python 3.4+, but the Fabric dev refuses to merge in any PRs that have been
submitted to help with Python 3 support. It's somewhat infuriating.

[https://github.com/fabric/fabric/pulls?q=is%3Apr+python+3](https://github.com/fabric/fabric/pulls?q=is%3Apr+python+3)

------
mxstbr
I hope this isn't Twitter saving the good parts of the company before they
crash and burn...

~~~
swanros
The trend states so.

------
closed
(This Fabric is not the popular python library for deploying things from the
command line.)

------
pkamb
So weird to see the mostly dead
[http://crashlytics.com](http://crashlytics.com) and its iOS 6-era design
(linen texture!) as it's been superseded by "Fabric" and now "Firebase". Seems
like such a strong brand name to kill in favor of these very generic
alternatives.

~~~
huangc10
Actually, the entire platform is called Fabric while Crashlytics is only a
part of the platform (albeit the main part...).

They've just kept the website as-is since being acquired by Twitter and
integrated into the larger Twitter products portfolio.

It is confusing at first though.

~~~
skyebook
its confusing at second, third, fourth looks too. I use Fabric and Crashlytics
pretty heavily and still end up here a few times a month without thinking.

~~~
shortstuffsushi
I end up going almost exclusively to Crashytics' website, then being
redirected at login and have the "oh, right" moment.

------
gorkemcetin
I wonder whether China will start banning Fabric servers, as they'll literally
be owned by Google. If that would be the case, I cant imagine the mess Chinese
developers will face. Assuming they have access to Fabric services now.

~~~
azurezyq
twitter.com is also blocked, so no difference.

~~~
gorkemcetin
Twitter.com only, or also Crashlytics services too?

------
sulam
How things change, three years ago Fabric was a key part of Twitter's platform
strategy. This has to feel like a big letdown, unless you're Jeff Seibert.

------
mindcrime
Well, this is probably good for Google and Fabric, but I'm less sure about it
being good for Twitter. My opinion has long been that Twitter needed to
double-down on being developer friendly and developer focused. This seems like
the exact opposite of that.

It strikes me as being about as smart as Sears selling off the Craftsman
brand. At least, to me, this feels self-defeating.

------
orbitur
I'm happy that Crashlytics will live on, as that was something I was concerned
about in light of Twitter's recent poor performance.

However, I'm really not looking forward to the eventual Firebase-
ifying/Google-ifying of the UI/design. The Firebase/Google Console interfaces
are terrible. Just awful. I cringe thinking about what could happen to the
Crashlytics UI.

~~~
mbleigh
Firebase engineer here -- what don't you like about the Firebase Console? Any
specific things that we could improve?

~~~
tobltobs
Your texts and instructions are byzantine. For example, what is the following
supposed to say:

"By default, your Firebase Analytics data will enhance other Firebase features
and Google products. You can control how your Firebase Analytics data is
shared in your Firebase settings at any time. Link your AdMob app(s) to
Firebase and we'll share your data from the free Firebase Analytics tool with
AdMob to improve app monetization and user engagement. You understand that
this linkage may also allow AdMob Data to be shared with Firebase for enhanced
reporting purposes."

I guess it means something like "Link you Admob account to Firebase" but it
sounds kind of scary.

------
sapeien
I haven't heard of Fabric before. Fabric seems to have an ambiguous name and
their marketing website is equally ambiguous. Something to do with mobile app
analytics? I find this trend in developer tool marketing to be appalling.

~~~
srinathrajaram
They used to be called crashlytics. Best crash reporting tool . Just works. I
guess they probably are a lot more interested in ranking for stuff like crash
reporting than people chancing upon their website and trying to figure out who
they are.

~~~
huangc10
agreed

------
Sujan
What about Fastlane?

------
Hydraulix989
Glad to see this under a better umbrella. The Twitter developers kept blowing
off everyones' requests for Crashlytics to support the gradle-experimental
plugin (which was necessary to use the NDK within Android Studio for the
longest time).

------
sebleon
Unlikely that we'll see improvements in Fabric services for a while...
presumably, engineering resources will be focused on integrating with Firebase
:(

Anyone recommend alternatives for Crashlytics and Digits?

~~~
HodGreeley
Apteligent, for one. Long time player with a strong offering for crash
reporting and much more. (I'm not associated, just a fan.)

~~~
robbyk
Ahh they used to be called Crittercism. Yeah I used to use them too

------
guelo
Huh? If Twitter's future is not ads and analytics then what is it?

~~~
farquaad
How does selling Fabric make them less focused on ads? Looking at the numbers,
ads is their main source of revenue.

------
nnd
Any recommendations for cloud-based CI/CD services? I'm currently using
Bitrise, then delivering to Fabric via fastlane.

~~~
viktorbenei
Do you have any issue with Bitrise? Just curious (CTO here)

You can use fastlane on Bitrise.io if you want to, and you can use the Bitrise
CLI locally ([https://www.bitrise.io/cli](https://www.bitrise.io/cli)),
similar to fastlane.

------
stevepotter
I'm an active user of Fabric and have found it rather convoluted and limited.
For example, there is no way to easily get device UUIDs from Beta testers.
Given they also sponsor Fastlane, I'm blown away they haven't provided a way
to automatically register UUIDs. This is possible with HockeyApp through their
API and some Fastlane scripts.

Crashlytics is their killer feature. The rest is mediocre. Hopefully Google
will improve it. I'm not holding my breath.

~~~
chrisstott
You might be interested in buddybuild's beta distribution which does automatic
UDID management.

It basically makes it so neither the developer nor the tester ever have to
worry about UDIDs ever again. Instead you can send a build to a new tester &
trust they can immediately install it.

[Disclaimer, I built that feature at buddybuild]

------
KerryJones
More of a comment on Firebase -- as someone who was using them pre and post
merge -- a whole bunch of small things are notably worse.

They said "great adoption" but it was actually forced (my previous company
held on as long to the old Firebase as we could), from things to poor naming
specs on export, base URL structures changing, the live-view able to handle
less data points and a number of other small things, it was a bit of a let
down.

Hoping this goes better.

------
zero-x
Best of luck, really dig the platform.

------
alex4Zero
The only thing I'm worry about is Digits. I hope Google won't close it

------
troymc
I guess they don't mean _this_ Fabric:
[http://www.fabfile.org/](http://www.fabfile.org/)

------
relics443
While Firebase is still awesome, there was a definite downgrade in support
when Google integrated them. Hopefully this will go better.

~~~
asciimike
Firebase team member here,

Anything specific you'd like to let us know about? Definitely agree that it
hasn't been the smoothest transition--it's super hard to provide 24/7 support
to hundreds of thousands of developers. Any feedback you can provide will help
us refine that process.

------
andy
Let's hope it doesn't end up like Adwhirl. :(

------
KayL
I used it in my all iOS development. Will it be 2nd class?

------
tn13
What does this mean for moPub ?

------
xugo
what about stripe ?

~~~
chambo622
What about them?

------
jondubois
Based on my experience with Firebase, it doesn't reduce complexity; it just
shifts it around and adds extra costs (both financial and performance costs)
to your system.

For any serious app, you still need to have a backend server on the side and
your Firebase service often becomes bloated and inefficient. Sometimes you
want to store the Firebase data inside your main DB as well and so you end up
with two sources of truth and Firebase ends up becoming a third wheel to your
project (just a bloated data transport layer).

It's not surprising that Firebase has been sliding in terms of popularity:
[http://www.alexa.com/siteinfo/firebase.com](http://www.alexa.com/siteinfo/firebase.com)

It's good for rapid prototyping/MVC but not for any serious use case.

I think the big lesson in the framework/devtools space is that the more
opinionated the tooling is, the less flexible it becomes and the fewer use
cases it covers.

~~~
asciimike
The approach Firebase takes can be summarized as, "make the 90% use cases
simple, and make the complicated 10% possible." Tradeoffs are a core
engineering concept, so I think this comes as no surprise to seasoned
engineers (the more cynical ones often phrase the question as "what's the
catch"). By partnering with Google Cloud Platform, we're working to make the
complicated 10% much easier (tradeoff here is lower cost/greater control vs
having to be more hands on with your infrastructure).

A great example of this is [Firebase
Storage]([https://firebase.google.com/docs/storage/](https://firebase.google.com/docs/storage/)).
We've made the 90% of file upload/download use cases easy, while making the
10% of use cases (lifecycle management, object versioning, advanced
processing) [accessible through
Cloud]([https://firebase.google.com/docs/storage/gcp-
integration](https://firebase.google.com/docs/storage/gcp-integration)). Stay
tuned for more, similar integrations in the future :)

As for the financial costs--you're paying someone else to build and manage
your infrastructure, so yes, it will cost more than buying raw infra. Again,
this is a tradeoff: is this more valuable to your product/users to answer
pages or build features? Depending on where you are in your product lifecycle,
YMMV.

(Disclosure: I work on Firebase)

~~~
kuschku
> As for the financial costs--you're paying someone else to build and manage
> your infrastructure, so yes, it will cost more than buying raw infra. Again,
> this is a tradeoff: is this more valuable to your product/users to answer
> pages or build features? Depending on where you are in your product
> lifecycle, YMMV

First, 2-3 orders of magnitude more expensive is quite a steep price to pay
for the featureset of Firebase.

Second, it’s only a good idea to use Firebase if you don’t plan on ever
migrating away – because that will be hell.

And third, Firebase is a massive engineering effort, and I’m surprised that
stuff actually works, considering how much work it is to try and replicate the
features I need myself.

On the other hand, somehow I feel like Firebase is just an example of the hell
we live in, one of the greatest development tools, and all of it is secret,
most not even patented, never will be open or free, and just being used to
force developers into a closed ecosystem of Google’s Cloud.

It’d be a lot nicer place if projects like this would be open, so people could
use it on their own systems (because I certainly won’t trust a company running
systems in a country ruled by Trump).

~~~
HodGreeley
Another option to check out is Couchbase Mobile. Open source, self-hosted
database with full offline functionality and a solid sync solution.

I think Firebase is pretty amazing. Have been a fan since I met some of the
team (I think it was at the 2011 Launch conference). Like anything, though,
there are tradeoffs.

Briefly, I'd say that there's overlap, with Couchbase Mobile tending to shine
toward the more complex end (including making the 10% much easier), and also
being extremely easy to use as a substitute for SQLite/Core.

(I work for Couchbase.)

~~~
kuschku
> All data is stored and transmitted as JSON – the embedded database, the
> database server, REST APIs, stream APIs, and batch APIs.

That’s likely going to become an issue with my usecase – even currently while
using a custom binary format on the net, and decoding with Java NIO, we’re
seeing ~80-90% CPU utilization on latest Android phones for ~4-5 seconds
during connection to sync the latest tenthousands to hundredthousands of
messages.

I doubt using Strings, and specifically JSON, will make that more performant.

(But I’ll definitely look into your code as inspiration for how to continue)

