I want to integrate Crashlytics (3.9.3) into an internal library but I am faced with the following situation: One of our internal libraries we are using is already using TwitterKit(2.2.0) with Fabric (1.6.7). This means that it is already doing it's initialization using this method:
[Fabric with:@[[Twitter class]]]
Now, this means that we can't initialize Crashlytics the same way because Twitter initialization would not be taken into consideration, since "Fabric with" method is going to be ignored on subsequent calls.
I know that the best method would be to call fabric in the main app like this:
[Fabric with:@[[Twitter class], [Crashlytics class]]];
but in our case it's desired to not impact the applications that are already using the the old lib, and keep compatibility.
Now, would it be safe to replace the current Fabric Twitter initialization and add the Crashlytics initialization with legacy method like this?
// replace original with this with info taken from Info.plist
[[Twitter sharedInstance] startWithConsumerKey:consumerKey
consumerSecret:consumerSecret];
// in another place
[Crashlytics startWithAPIKey:@"a1b2c3..."];
Is fabric doing any other stuff under the hood except the above or is it just parsing the info.plist for the keys and initializing the frameworks? Should we worry about any issues? Tested it and seems to be working ok.
Also, I am aware that Twitter is no longer part of the newest Fabric, but we are using some older versions here.
What I've also noticed is that if we keep the "Fabric with Twitter" part unchanged and initialize Crashlytics with "startWithAPIKey" method, Twitter will not be initialized ok.
Mike from Fabric here. Your approach may work, but could cause many issues as we haven't tested any of the most recent versions of Fabric with that version of Twitter so you would be at risk of seeing strange SDK behavior.