Whether that's better than writing ObjC directly is another question, think of ObjC as a convenient syntax sugar wrapper around macOS/iOS APIs which you only need in those parts of your application that talk directly to operating system APIs.
If you just want do to simple 'game-y stuff' (3D rendering, audio, low level touch input) you can also check out the Sokol headers (shameless plug): https://github.com/floooh/sokol, or I guess SDL will work too (especially with the new GPU API in SDL3) - at least the sokol header implementation code needs to be compiled as ObjC on macOS/iOS though (e.g. pass `-x objective-c` to Clang), since the macOS/iOS specific code paths are written in ObjC.
For the general case or when you need to access OS frameworks that are not wrapped by 3rd-party libraries:
If your app is mainly C code, have a thin layer of ObjC code that sits on top of the system ObjC APIs and which exposes a C API to the rest of the application.
Don't just tunnel every ObjC call through to C, instead wrap small feature blocks in ObjC and expose those features through a much simplified C API.
E.g. a hybrid C/ObjC application with only the necessary amount of ObjC code for talking to OS APIs, and all the 'business logic' in C (or another language, like C++, Zig or Rust).
- https://github.com/garettbass/oc
- https://github.com/mitchellh/zig-objc
Whether that's better than writing ObjC directly is another question, think of ObjC as a convenient syntax sugar wrapper around macOS/iOS APIs which you only need in those parts of your application that talk directly to operating system APIs.
Also Apple is maintaining a C++ Metal API wrapper now (ok, technically that's not C): https://developer.apple.com/metal/cpp/
If you just want do to simple 'game-y stuff' (3D rendering, audio, low level touch input) you can also check out the Sokol headers (shameless plug): https://github.com/floooh/sokol, or I guess SDL will work too (especially with the new GPU API in SDL3) - at least the sokol header implementation code needs to be compiled as ObjC on macOS/iOS though (e.g. pass `-x objective-c` to Clang), since the macOS/iOS specific code paths are written in ObjC.
For the general case or when you need to access OS frameworks that are not wrapped by 3rd-party libraries:
If your app is mainly C code, have a thin layer of ObjC code that sits on top of the system ObjC APIs and which exposes a C API to the rest of the application.
Don't just tunnel every ObjC call through to C, instead wrap small feature blocks in ObjC and expose those features through a much simplified C API.
E.g. a hybrid C/ObjC application with only the necessary amount of ObjC code for talking to OS APIs, and all the 'business logic' in C (or another language, like C++, Zig or Rust).