feat: build macOS SDK as a dylib from sentry-cocoa

[vaind]

closes #693 - finally found a working solution that's reasonably integrable into Unity build - using a dylib, letting Unity add it to the project, and accessing the content dynamically, using dlopen()/dsym().

Replaces #703 which was deemed too complicated as well as limited (required users to export to xcode).

TODOs:

• PoC - calling an exposed c-api init() from SentryInitialization.cs, hard-coded DSN, got an issue to sentry.io - https://sentry.io/organizations/sentry-sdks/issues/3083605658/?project=5439417&query=is%3Aunresolved
• bridge code (expose as the necessary objective-c code as C-APIs so we can call from C#)
• initialize (at runtime), after Unity is loaded
• Integration test in CI - after Chore: parallel smoketest build #686 is merged
• Symbol upload
• anyone some ideas how to improve the App section - e.g. "App Build", "Build Type" - it's likely set in SentryCrashIntegration.m in sentry-cocoa but not sure how to influence the content...

Issue samples:

• https://sentry.io/organizations/sentry-sdks/issues/2677827744/?project=5439417&query=is%3Aunresolved
• https://sentry.io/organizations/sentry-sdks/issues/3235146941/?project=5439417&query=is%3Aunresolved
• https://sentry.io/organizations/sentry-sdks/issues/3235150078/?project=5439417&query=is%3Aunresolved

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 3dd16f3

[bruno-garcia]

@philipphofmann or @brustolin could either of you take a look at the Objective-C code in here please? Just in case you have some suggestions on something that can be improved or could be an issue.

[bruno-garcia]

30% through, gotta get back to it

[bruno-garcia]

There's no ARC available? I haven't seen CFBridgingRetain used with ARC so wondering why we need this here

[vaind]

CFBridgingRetain is used specifically with ARC - I had to change that (from plain void* casts) because of some compilation issues. I'm glad if someone with good objective-c understanding has a look but to my limited knowledge, this should be OK - we want to take ownership of the pointer here, keeping the value in memory, later in SentryNativeBridgeStartWithOptions it's transferred back and left to ARC to free as needed.

[bruno-garcia]

So no way we can add the header and use the actual types? I assume not since you went with this approach.

[vaind]

I couldn't get it to work. That being said, maybe there's a way, I just don't know it :)

[vaind]

The Objective-c code looks good to me. I would only suggest, instead of calling performSelector multiple times with the same selector, create a helper function to do it. Then, instead of using @try-catch, you could check if the object can perform the given selector like so:

if ([SentrySDK respondsToSelector:@selector(configureScope:)] )

I've added void SentryConfigureScope(void (^callback)(id)) but kept try-catch because it wasn't just for that selector but also for the block content

[philipphofmann]

I'm not sure if we chose the right approach here. Maybe @vaind it would be best to pair up on this via a call and look into the code.

[Swatinem]

lgtm in general, though I have some open questions

[Swatinem]

The comment above is a bit misleading. I thought Unity had some magic matching of paths that see .iOS as a suffix and will only use this file on iOS?

And the iOS version of SentryNativeBridge.m returns 0 here, so will never initialize the SDK?

As a third question: Unity will guarantee that this is only called once, in a threadsafe way? (since the underlying native functions are not threadsafe)

[vaind]

I'll move the comment to the function - Init() itself is only called when on macOS.

I thought Unity had some magic matching of paths that see .iOS as a suffix and will only use this file on iOS?

kinda, there are meta files to specify which platforms you want the file/assembly to be used for - src/Sentry.Unity.iOS/ shares the vast majority of the code for both iOS and macOS now so it's used on both and has minor runtime differences in call paths based on the platform. The whole folder (csproject) will be renamed later, just didn't want to add unhelpful change-sets to an already large PR.

And the iOS version of SentryNativeBridge.m returns 0 here, so will never initialize the SDK?

Never called, doesn't matter what it returns, just need some return value for the code to compile, because the symbol needs to be there due to the DllImport in C#

As a third question: Unity will guarantee that this is only called once, in a threadsafe way? (since the underlying native functions are not threadsafe)

No, but it's only called once, during the app init, with the code that does the call coming as part of the Unity package so it's under our control to some extent. Of course, users could manually call the same init method in parallel in multiple threads if they really wanted to (for whatever reason...), but that's not the intended way to work with the package and a broader topic because other platform implementations don't try to prevent that either. So it didn't feel like the best time to try to do something about that here. Maybe we could later change that or at least make sure the docs warn the code isn't thread safe.

[philipphofmann]

I added a few comments.

[vaind]

Thanks everyone for the reviews.

@bruno-garcia please merge if you're done reviewing

[bruno-garcia]

This will get merged today unless we get some tips from an Objective-C wizard

[bruno-garcia]

This will get merged today unless we get some tips from an Objective-C wizard

[philipphofmann]

This will get merged today unless we get some tips from an Objective-C wizard

I wouldn't call myself a wizard. Just a normal dev 😁

[philipphofmann]

Thanks, @vaind, for your patience and replying to all my questions. LGTM 🚀