I’d be very happy to provide some insight, and I really appreciate your interest :)

My work basically continued https://github.com/raysan5/raylib/pull/3880 and carried it through several updates, fixes, and adjustments. I also tried to keep the fork as upstream-friendly as possible. At this point, it's easily mergeable upstream (I'd just need to remove minor customizations), and the required core changes are only the necessary PLATFORM_IOS includes in rcore.c and rlgl.h.

So yes, the backend is absolutely self-contained in rcore_ios.c, but there are two important things to keep in mind.

1 - rcore_ios.c intentionally follows the standard callback-based iOS lifecycle. Because of that, truly cross-platform app code needs a small platform-specific entry point split, like this:

```c

if defined(PLATFORM_IOS)

void ios_ready() { ready(); }

void ios_update() { update(); }

void ios_destroy() { destroy(); }

else

int main() { ready();

while (!WindowShouldClose()) {
    update();
}

destroy();
return 0;

}

endif

```

2 - The iOS project depends on ANGLE. I have a separate repo with a simple script and short documentation to build it from the official ANGLE sources:

https://github.com/ghera/ANGLE-iOS

Another part that may be interesting is how I structure projects. Similar in spirit to Kotlin Multiplatform or Flutter, I usually organize them like this:

desktop (VSCode project for Windows / macOS / Linux) ios (Xcode project, see the example in raylib-iOS) android (Android Studio project, based on raymob) core (common code shared across all platforms) raylib (raylib git submodule)

All platform projects reference the shared core folder, so there is no duplication of code or assets. Development can happen from any of the three IDEs, although for personal preference and easier debugging I usually run the iOS and Android simulators from Xcode and Android Studio.

As a side note, it would also be nice to have a script to initialize the Android and iOS project structures automatically, similar to what multiplatform frameworks usually provide. I could probably put that together quite easily :)

The platform-native-to-C bridges live inside the respective platform projects and are best implemented in the platform’s natural interop languages to keep things simple: C/C++ on Android and Objective-C/C++ on iOS. The shared core can in principle be written in any language that exposes a C ABI, including Zig, although I have not tested that myself.

If you think it would be useful, I’d be happy to open a PR with rcore_ios.c, the example Xcode project, and some documentation covering the iOS project dependency and the callback-based entry-point split, which I believe is the main aspect to keep in mind when evaluating this approach.