Firebase-ios-sdk: FR: Crashlytics support on watchOS

[jroets]

Please add Crashlytics support to watchOS, so that we can get crash reports from Firebase Crashlytics for watchOS apps just like we can for iOS apps.

[ryanwilson]

cc @samedson

[jostster]

This would be VERY useful!

[capraMambrica]

Yes please! We are yet to find a good solution for this. Especially for Independent apps.

[TKBurner]

Thanks for the feedback folks. Right now we don't plan on introducing WatchOS support, but we'll be happy to track requests here. Thanks!

[mozeryansky]

As far as a request reason: our biggest crashers are actually within Firebase APIs. I'd love to be able to file bug reports for those :)
Does Google internally use the crash reports for APIs they maintain?

[TKBurner]

I appreciate the feedback. We are actually working on determining ways the Firebase team can receive crash reports for crashes in Firebase SDKs via Crashlytics. This will help our internal eng diagnose and track issues across our user set.

As far as WatchOS. We will keep an eye on this thread :)

[jostster]

@TKBurner Thanks for the update. As of now their isn't any crash reporting system like crashlytics for WatchOS. With wearable tech really gaining traction this could be very helpful for developers to find issues and allow the reporting of additional details about a crash that Xcode Crash Reporter doesn't provide.

[jostster]

For those looking for an alternative, although it is not actively maintained any longer, this could be helpful. It may also give some insight for the firebase team should they decide to support WatchOS. https://github.com/kstenerud/KSCrash

[hannesjung]

+1

[shaliko]

+1

[jostster]

A little update. I was able to get FirebaseCrashlytics to build for WatchOS and running in the Firebase watchos sample app. I seem to be having an issue though with the backend seeing the sample app as the watch extension appends a WatchKitExtension to the end of the bundleId. So this might require a bit of work to the backend?

For example my test app is com.ua.crashlyticstest.WatchKitApp downloading the GoogleService-Info.plist. While the base is com.ua.crashlyticstest. Structure is like this.

SampleWatchApp Project - com.ua.crashlyticstest
|- SampleWatchAppKitApp - com.ua.crashlyticstest.WatchKitApp
|- SampleWatchAppKitExtension - com.ua.crashlyticstest.WatchKitApp.WatchKitExtension

When the app runs, the bundleidentifier shows as com.ua.crashlyticstest.WatchKitApp.WatchKitExtension. While there is code in the crashlytics client to look for the prefix and allow it, the firebase site continually sits at Looking for client. I'm assuming that is specifically looking for com.ua.crashlyticstest.WatchKitApp instead of what the watch extension runs as which as WatchKitExtension appended to it.

@TKBurner do you know if this is the case?

[jostster]

After further debugging it appears the issue with it not activating on the backend is because the activation is done through the FirebaseAnalytics framework which is not ported to watchOS.

[jostster]

A little update I was able to finally get the application to auth on the backend. It seems the backend service was down for awhile and would randomly return 404 when getting settings. However the settings does seem to return firebase_crashlytics_enabled: false in the settings even though it says reports are being sent and dsym's uploaded. I did see 1 user connect about 12 hours ago but during my testing it is no longer showing them connecting.

Everything in the debug logs shows reports are being uploaded successfully, might just need some work on the backend to get watchos support now.

[TKBurner]

@jostster if you contact support we can manually enable Crashlytics. We'll need the bundle ID.

[jostster]

@TKBurner I was able to get things enabled but reports don't show up in the dashboard. Do you know if the backend blocks the display of extension bundleid's? The reports are recorded and uploaded fine. They are just like any other iOS crash report. If i could get the dashboard to show the reports I would be able to submit a PR for community watchOS support.

[TKBurner]

Can you share the debug output of the upload? Sanitized, of course.

[jostster]

xcode copy.log
Here you go @TKBurner if you need anything else, let me know.

[ekimia]

would love this!

[samedson]

@jostster looking back at this, it seems the issue you're running into is probably due to the following log line:

[Firebase/Core][I-COR000008] The project's Bundle ID is inconsistent with either the Bundle ID in 'GoogleService-Info.plist', or the Bundle ID in the options if you are using a customized options. To ensure that everything can be configured correctly, you may need to make the Bundle IDs consistent. To continue with this plist file, you may change your app's bundle identifier to 'com.<sanitized>.WatchCrashlytics.watchkitapp.watchkitextension'. Or you can download a new configuration file that matches your bundle identifier from https://console.firebase.google.com/ and replace the current one.

Is it possible to create a new app in Firebase with your full watch bundle ID, and include it for just the Watchos Extension?

[maksymmalyhin]

Bundle ID validation was was slightly updated in Firebase 6.25.0 (#5126) so the error [Firebase/Core][I-COR000008] ... should not appear any more if you use a separate Firebase application for watchOS.

[jostster]

@samedson I am already using using the app id with com.<sanitized>.WatchCrashlytics.watchkitapp.watchkitextension in firebase.

@maksymmalyhin I will update to 6.25.0, however IIRC the method only displays a warning and doesn't prevent activation or report uploads. We are generating crash reports and uploading them successfully, they just don't show in the dashboard.

[samedson]

@jostster can you send out one more set of logs with Packaged report with id ...? We rotate logs after a week so we just need a new set.

[jostster]

@samedson I'm currently working to get my changes into the updated fork instead of keeping them local. Once that is done, I will generate new logs. I assume you were the one working with Julia requesting the logs?

[samedson]

That's right! We're talking through both channels. Sounds good 👍

[jostster]

@samedson Here are the logs. I had to start fresh but good news is, it seems alot of the changes I did between the original start of this ticket and now have been added into the repo already for watchOS support.
Report id 6b4a8a300a674828b404251ea90d9ab0
xcode_watchos_crashlytics.log
console_watchos_crashlytics.log

[samedson]

Ok looking at our logs, I believe the issue right now is our backend doesn't currently recognize watchos for the platform. To get you unblocked in the short term, can you try to send up ios as the platform? This includes crash reports and symbols uploads as well (eg. run upload-symbols -p ios ...).

Also is your fork public? Can I take a look at your changes?

[jostster]

@samedson the new report id is 2880ccbe17114c579e44c38aed677a12. I set the platform in FIRCLApplication.m to ios but it still doesn't seem to want to pass the activation stage or show in the crashlytics dashboard.

Currently I am uploading the upload-symbols as ios but before had FIRCLSApplicationGetPlatform() returning watchos

the repo is https://github.com/underarmour/firebase-ios-sdk/tree/feature/watchos-support I still need to go back through and make sure all the changes I made locally several months ago have been fixed, but this atleast is running in a simulator test application.

[samedson]

Hmm haven't seen anything that indicates why they're getting dropped - I'm going to try to get your branch running on my machine at some point to see if there's anything obvious. In the meantime, can you send me a zip of the reports and settings directory?

You can find them by:

• Run the app
• Look for a log that says [Firebase/Crashlytics][I-CLS000000] Root: <directory>
• Open the , and zip up the v5 folder, and upload it here

[jostster]

@samedson I emailed the zip file to Julia and asked her to forward it to you. There was some org id's in there and a cache key file I didn't think would be good to upload here.

[samedson]

A couple tips @jostster, looking at the zip

• Make sure you stop the Xcode debugger when you try to force a crash (this is unintuitive but Crashlytics can't register exception handlers because Xcode takes over). This is done by Building and running, stopping in Xcode, and then running the app via the simulator
• It might help to add a non-fatal call as well to see if those work via recordError

[jostster]

@samedson Yes, when I run the build to force a crash I run it on the simulator but don't run it through xcode, that way the crash is recorded and not blocked by the debugger. When I upload, I run it through the debugger to get the logs.

[samedson]

Ok then there seems to be a larger problem then. What I'm seeing is we aren't writing out any crash files, or non-fatal error files for that matter.

If you check out: https://github.com/firebase/firebase-ios-sdk/blob/master/Crashlytics/Crashlytics/Models/FIRCLSInternalReport.m#L25-L34:

• There are 3 types of crash files: exception, signal, and mach_exception. These correspond to different type of crashes.
• In addition, there are the custom_exception_a/b and errors_a/b swap files that get written when recordError or recordExceptionModel are called
• Without one of these types of files, Crashlytics won't display anything (because there was no "event" to show the metadata for)

For looking deeper at this this:

• You will find these files in the directory mentioned above [Firebase/Crashlytics][I-CLS000000] Root: <directory>. After causing a crash, but before re-running the app, these files will be under v5/reports/active/<report-id>/...
• Right now your zip did contain metadata, log_a/b, internal_incremental_kv, and binary_images, which is a good sign that writing out files is working.
• I think the next task is figuring out why the above crash files aren't written upon a crash or a non-fatal. It will probably be easiest to focus on non-fatal errors first (custom_exception_a/b and errors_a/b files).

[jostster]

@samedson I may have misunderstood you. Did you want me to trigger a crash, then send you the zipped v5 folder? I just sent you the v5 folder, without triggering a crash.

[samedson]

Ah if you could trigger a crash, then send the v5 folder, that would be awesome 👍

[jostster]

Sent it to Julia @samedson . I also added a recordError and triggered that as well.

[samedson]

Hey @jostster, circling back on this, I took a look at the zip you sent and found what's currently preventing WatchOS reports from being uploaded. Adding information here in case anyone wants to work on this:

• If you take a look at signal.clsrecord, you will see line-delineated JSON. The second line / JSON blob is "threads", and you will see it is missing a closing ]}. This usually indicates that getting the thread state failed after the crash happened.

• If you look at sdk.log, this confirms the issue, as you will see an error line, ERROR [FIRCLSProcessRecordThread:393] unable to get thread state. This brings you to this line in the codebase: FIRCLSProcess.c.

This is most likely failing because we have compiler macros that return false here, and skip the call to thread_get_state. This likely means thread_get_state is unavailable in watchOS, but it might be good to double check. If it is unavailable in watchOS, we'll need to find an alternative way to get the thread state.

[jostster]

@samedson Thanks so much for the assistance. You are correct that watchOS doesn't have access to thread support. I have fixed the file format issue and was able to successfully see crash reports in the dashboard! There are a few limitations like mach exceptions that watchOS are not able to catch and signal crashes, but this should atleast help people find some crash errors within code.

I will submit a PR for watchOS support for Crashlytics!

[samedson]

That's incredible - looking forward to it!

[choli]

This looks all nice and amazing. Now when I upgrade the FirebaseAnalyticsBinary and FirebaseCrashlyticsBinary to 6.32.0 with carthage update, then I don't get any watchOS framework, it tells me, "Building for watchOS Simulator, but the linked and embedded framework 'FirebaseCrashlytics.framework' was built for iOS + iOS Simulator."
If I try with CocoaPods, which we don't use, then it says "[!] The platform of the target WatchTest Extension (watchOS 7.0) is not compatible with Firebase/Crashlytics (6.31.1), which does not support watchOS."
SPM is beta only and it says it doesnt support watchOS at all.
So how can I get this to run in my Watch Extension? Thanks a lot 👍

[paulb777]

@choli Thanks for the report. Currently we only support watchOS via CocoaPods.

Also it looks like we did not properly update the Firebase pod to represent that. We'll fix that problem in 6.33.0. In the meantime, watchOS can be accessed with pod 'FirebaseCrashlytics' (without the slash) and pod update.

[jostster]

Note there appears to be another issue that I am looking into regarding watchOS signal crashes. https://github.com/firebase/firebase-ios-sdk/issues/6434

[choli]

@paulb777 Thanks for the quick response, I will try that right away. Is there a roadmap to add this to carthage/SPM anytime soon? I don't see any Carthage projects that I could contribute on?

[paulb777]

Thanks @jostster. I created #6435 for the proper Firebase pod support.

@choli Our Carthage support is binary only and we're not likely to add watchOS support there. We'd like to add it to SPM, but have not yet found a good way in SPM to manage the partial set of products in https://github.com/firebase/firebase-ios-sdk/blob/master/Package.swift that support watchOS currently.

[jostster]

@paulb777 is there anything in particular causing watchOS to not be supported with carthage? We too use carthage, so would find it beneficial so that we don't have to incorporate another package manager into our deploy process.

[paulb777]

@jostster It's primarily a matter of prioritization.

• CocoaPods and SwiftPM have substantially higher demand.
• We'd rather focus on expanding watchOS coverage across Firebase versus increasing package manager support.
• Questions about Carthage longer term viability with SwiftPM rapidly gaining share and issues like https://github.com/Carthage/Carthage/issues/2799 remaining open for over a year.

Even with those factors, we'd still consider a PR that adds watchOS binary build support for .frameworks and .xcframeworks to https://github.com/firebase/firebase-ios-sdk/tree/master/ZipBuilder.

[jostster]

Thanks @paulb777 I can take a look at ZipBuilder if I have time. I'm guessing it just needs support in ZipBuilder/FrameworkBuilder.swift for the watchOS Arch? Is there other places that need to be edited such as automated scripts to trigger the watchOS builds or will adding the proper architecture in ZipBuilder enable watchOS Crashlytics for carthage?

[paulb777]

@jostster Here's a rough idea of what would need to be done:

• Build the right architecture slice
• Construct the properly structured .framework and .xcframework
• Handle products that don't support watchOS
• Verify and update documentation at https://github.com/firebase/firebase-ios-sdk/tree/master/ZipBuilder for both json-driven and release builds