Fabric was a much better analytics tool than Google Analytics.<p>It's better because:<p>Instant crash reporting reduces release time anxiety. iTunes and Google analytics need 24 hour collection period.<p>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.<p>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.
The title is a bit ambiguous. From my understanding, Google (Firebase) acquired Fabric from Twitter (not necessarily "joining").<p>Fabric is one of the top dev tools I use for iOS. I wonder what kind of change is in store...
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].<p>[1] <a href="https://news.ycombinator.com/item?id=11913828#11914620" rel="nofollow">https://news.ycombinator.com/item?id=11913828#11914620</a>
[2] <a href="https://news.ycombinator.com/item?id=11937756#11942293" rel="nofollow">https://news.ycombinator.com/item?id=11937756#11942293</a>
[3] <a href="https://news.ycombinator.com/item?id=12784274#12784473" rel="nofollow">https://news.ycombinator.com/item?id=12784274#12784473</a>
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.
Seems to me like the main value for Google is the data from all the apps that have Fabric SDK integration (e.g. Crashlytics).<p>Quote from the Fabric blog post <a href="https://fabric.io/blog/fabric-joins-google" rel="nofollow">https://fabric.io/blog/fabric-joins-google</a><p>"Fabric has grown to reach 2.5 billion active mobile devices".
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.<p>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.<p>[0]: <a href="https://sentry.io/" rel="nofollow">https://sentry.io/</a>
What does this mean for Twitter Digits? Will their free SMS authentications continue?<p>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.
Silly me - I was concerned they somehow acquired the Fabic python library.<p><a href="http://www.fabfile.org/" rel="nofollow">http://www.fabfile.org/</a>
So weird to see the mostly dead <a href="http://crashlytics.com" rel="nofollow">http://crashlytics.com</a> 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.
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.
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.
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.<p>It strikes me as being about as smart as Sears selling off the Craftsman brand. At least, to me, this feels self-defeating.
I'm happy that Crashlytics will live on, as that was something I was concerned about in light of Twitter's recent poor performance.<p>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.
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.
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).
Unlikely that we'll see improvements in Fabric services for a while... presumably, engineering resources will be focused on integrating with Firebase :(<p>Anyone recommend alternatives for Crashlytics and Digits?
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.<p>Crashlytics is their killer feature. The rest is mediocre. Hopefully Google will improve it. I'm not holding my breath.
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.<p>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.<p>Hoping this goes better.
I guess they don't mean <i>this</i> Fabric: <a href="http://www.fabfile.org/" rel="nofollow">http://www.fabfile.org/</a>
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.<p>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).<p>It's not surprising that Firebase has been sliding in terms of popularity: <a href="http://www.alexa.com/siteinfo/firebase.com" rel="nofollow">http://www.alexa.com/siteinfo/firebase.com</a><p>It's good for rapid prototyping/MVC but not for any serious use case.<p>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.