bevy_log: Use os_log on iOS

[HackerFoo]

Objective

On mobile devices, it's best to use the OS's native logging due to the difficulty of accessing the console. This is already done for Android.

Solution

This PR uses Absolucy's tracing-oslog (ZLib license) for iOS in order to use Apple's os_log.

Changelog

• Change bevy_log to use Apple's os_log on iOS.

[IceSentry]

I don't have a way to test it but the code looks good to me other than that.

[alice-i-cecile]

I'm going to merge this optimistically; @HackerFoo please open a new issue or PR if you run into problems on iOS.

The code itself is good and well explained.

bors r+

[bors]

Merge conflict.

[james7132]

@HackerFoo sorry for dropping the ball on this, could you update this PR?

[alice-i-cecile]

Ping @HackerFoo: I'm leaving this in the milestone because it seems like the merge conflict should be easy.

[github-actions]

You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.

[cart]

Hmm multiple new conflicting build deps (due to an older version of bindgen). Not as bad as non-build deps, but also not great.

[alice-i-cecile]

@alice 🌹 Here’s a newer version. I’ll try to update the PR if I can: HackerFoo@b97063d

[alice-i-cecile]

I don't have the setup or expertise to validate this independently: adding Adopt-Me in the hopes that someone who does can chip in :)

[therealbnut]

@alice-i-cecile Hi, I thought this "S-Adopt-Me" PR would be a good first simple Bevy contribution. I've merged the latest main and made some changes to get it working. I've also tested it on an iOS device and it works as I believe it's expected to.

This is my branch: https://github.com/therealbnut/bevy/tree/use-oslog-for-ios

I believe I've preserved the PR's orignal intent after the merge conflict, but as the code is changed and simplified now it may be worth a quick look to check I haven't removed something by mistake.

It's also worth noting that the dependency this adds hasn't had bug fixes released in a few years, so we may want to consider one or more of:

1. a feature flag to opt-in, and it would also allow os_log on MacOS
2. merge as-is and have some (minor?) upstream bugs
3. hold off on this PR until a suitable alternative dependency arises
4. maintain our own implementation

Future work

In a follow-up PR it might be good to make the subsystem field have a better default value, like this one. That value can be retrieved programmatically if we bind another system API (Bundle.main.bundleIdentifier in Swift, or the C/ObjC equivalent for posterity). This would almost always be the correct value, while the current default is unlikely to ever be correct.

[alice-i-cecile]

Fantastic stuff: can you open a PR with those comments in a Questions for Reviewers section? I'll respond to your questions there, so the answers don't get lost. I'm in favor of a merge-as-incremental-improvement strategy, but I agree with your concerns about dead dependencies and have ideas to address that.

[therealbnut]

can you open a PR with those comments in a Questions for Reviewers section

Thanks @alice-i-cecile, I've made that PR here, I hope that's what you meant.

[richchurcher]

Closing in favour of #13364.

[therealbnut]

@richchurcher thanks for the reminder, my PR on the third-party library blocking #13364 was finally merged, so hopefully that fixes the security advisories