feat: Support for iOS & macOS using Cocoa SDK integration

[limbonaut]

This PR brings Sentry Cocoa SDK integration as a backend on macOS and iOS platforms. This switches macOS builds to utilize Sentry Cocoa as well.

Build system manages Sentry Cocoa package, reading modules/sentry-cocoa.package file, downloading the corresponding package with dynamic framework from GitHub Releases, extracting and processing it. It also updates it if the version changes in the .package file. Dependency update should be trivial to add.

The build system takes the respective slices from the Sentry Cocoa XCFramework and puts them in the project/. For macOS, it also flattens the framework, so we don’t have any problems with symlinks on Windows and with Godot Engine. Framework is linked dynamically.

This PR also includes a simple system for custom options. GodotCPP tends to complain about those – so there is a workaround for that too. A new option is added to generate iOS framework from iOS build artifacts: generate_ios_framework=yes|no

Local build instructions

Build macOS libs:

scons target=editor debug_symbols=yes
scons target=template_release debug_symbols=yes 

Build iOS libs:

scons platform=ios target=editor arch=arm64 ios_simulator=no
scons platform=ios target=editor arch=universal ios_simulator=yes generate_ios_framework=yes

All unit tests passed on macOS. Due to limitations of the unit test framework, can't run tests on iOS. However, there are separate mobile tests which I ran via demo project – all succeeded.

Known issues and limitations

1. Script source context is not available: Add support for script source context on iOS and macOS #295
2. Local variables are not available: Add support for local variables on macOS & iOS #296
3. Scene tree information is not available (aka view hierarchy): Add support for scene tree info on macOS & iOS #297
4. CI doesn't make proper iOS builds yet. It does compilation, but does not generate XCFramework yet. Follow-up: ci: Build iOS artifacts #291
5. Debug output is not routed to Godot console yet. You can see it in a terminal app. It's also quite noisy. Send debug output to Godot console on Apple platforms #298
6. Godot generates runtime errors when OS.get_memory_info() is called on iOS – so I disabled it on iOS: Fix memory information in device context on iOS #299

[jpnurmi]

Could we have some basic unit tests for rfc3339_timestamp_to_microseconds and microseconds_to_rfc3339_timestamp? A separate PR could also be a welcome option to offload some parts of this rather heavy PR and get things going. :)

[limbonaut]

@jpnurmi The tests we maintain are in GDScript, which don't have direct access to such methods; however, we test them indirectly via:

sentry-godot/project/test/suites/test_event.gd

Lines 28 to 45 in efbdb39

	func test_event_timestamp() -> void:
	var event := SentrySDK.create_event()
	assert_str(event.timestamp).is_not_empty()
	# Example of how to format a timestamp:
	var unix_time: float = Time.get_unix_time_from_system()
	var dt: Dictionary = Time.get_datetime_dict_from_unix_time(unix_time)
	var date := "%04d-%02d-%02d" % [dt.year, dt.month, dt.day]
	var time := "%02d:%02d:%02d" % [dt.hour, dt.minute, dt.second]
	var fractional: float = unix_time - int(unix_time)
	var micros := int(round(fractional * 1000000))
	var timestamp := "%sT%s.%06dZ" % [date, time, micros]
	event.timestamp = timestamp
	# Test timestamp equality by comparing only up to milliseconds precision.
	# This avoids test failures due to microsecond-level rounding differences that can occur on some platforms.
	assert_str(event.timestamp.left(23)).is_equal(timestamp.left(23))

We could expand such tests to include various formats in RFC3339 and also test some edge cases. Extracting these functions into separate PR make less sense as they only used with cocoa sdk, and we wouldn't be able to test them unless we introduce another testing layer, just for internal C++ stuff.

[limbonaut]

@jpnurmi Almost forgot, I’ve been working on a dedicated SentryTimestamp public API class some time ago. I stopped working on it, as I’m not entirely sure if we really need it, so I’d love to hear your thoughts. It actually has a pretty comprehensive test suite :)
One of the limitations it tries to overcome is lack of dedicated datetime/timestamp type in GDScript. This is all we have in Godot: https://docs.godotengine.org/en/latest/classes/class_time.html

UPDATE:

• See feat: Intoduce SentryTimestamp class to improve timestamp handling #286

[limbonaut]

Timestamp functionality is taken care of by #286. So, this PR doesn’t deal with it anymore.

[jpnurmi]

Looks good! Thanks for splitting off the timestamp changes. 🙏

[jpnurmi]

Are these "noop" builds anymore?

[jpnurmi]

Oh no, switching to Cocoa didn't help with that 🙁

libc++abi: Pure virtual function called!
/Users/runner/work/_temp/f74de61c-e6cf-42b0-8d86-f03e8521ab5d.sh: line 3: 1754 Abort trap: 6 ${GODOT} --headless --path project/ --import --verbose
Error: Process completed with exit code 134.

https://github.com/getsentry/sentry-godot/actions/runs/16770287480/job/47484472250?pr=266

[limbonaut]

Oh no, switching to Cocoa didn't help with that 🙁

Aww shame, cant even pin it to a commit as it's so flaky.

[limbonaut]

Are these "noop" builds anymore?

They are not, but I'd like to address it in a separate PR as it needs more than renaming – we also need to generate an xcframework from 2 libs in a post-process job.