I’m ejected and using Sentry, but just sentry-expo at the moment, so I’m missing native errors. I haven’t tried this yet, but was thinking that maybe the path of least resistance would be to create separate projects in Sentry- one using react-native-sentry (or heck, just plain old Sentry native and link it yourself) just for native errors, and the other using sentry-expo for JS errors. Not perfect, but at least I’d be getting all the errors. Jamming something in the middle of the ExpoKit build process is pretty hairy, but putting something on the end to upload symbols of whatever you need to do to support native error reporting shouldn’t be too bad.
I strongly suspect this all gets a lot more straightforward once the bare workflow fills out, supporting the ExpoKit features that are still missing (like OTA updates). I’m still glad I went with ExpoKit vs. plain old React Native (bare workflow wasn’t even on the horizon when we started, and we’re almost done with this release cycle), but the bits that are tightly coupled to the managed workflow build process can make customization weird sometimes. If you’re really early in your development cycle, you may want to switch to bare. If you need OTA updates, you would have to go without them for a bit, but it sounds like the plan is to release a unimodule for that, so it’ll be there at some point. A bare workflow project in theory makes it possible to use Microsoft CodePush for OTA updates for the time being, as well.