Objective-C is designed in such a way that, generally speaking, anything you can do with Objective-C syntax can also be done with a simple C function call to one of the Objective-C runtime functions. So you can write an entire iOS app in pure C. However, the Objective-C stuff is a lot more pleasant to use if you use the syntax for it.
As others have mentioned, for something like a simple game (rather than a normal GUI application), SDL offers a convenient wrapper that allows you to avoid touching anything Objective-C-related yourself, so you could write an entire app using only the SDL API, which is pure C. A nice bonus of that approach is that it would then work on other platforms with zero code changes.
Another source of C wrappers is Apple themselves, as iOS has a number of C interfaces like CoreFoundation that reduce how much Objective-C stuff you have to directly interact with, but there's nothing like that for UIKit, and every iOS app has to use UIKit at least a little.
On macOS there used to be Carbon, which is technically gave a C API. It could technically be used (although they stopped supplying header files) until the 32-bit deprecation. Still, I think maybe as a legacy of that a lot of Cocoa APIs do have private Core* equivalents, so if you're willing to do a lot of reverse engineering it might be possible to skip even the objc runtime.
You can build command-line apps with CoreFoundation, and you can always use Metal and QuartzCore for drawing. [1] At least there Apple does the wrapping for you.
I’ve written a pure C Mac desktop app in 2024 that called the objective-c bindings directly. It is using a modified version of this library https://github.com/ColleagueRiley/RGFW
While I don’t think that library does iOS specifically, you can have a look at the code to see how you can call objective-c from c. Spoiler: doing so kind of sucks, and also the library code isn’t the most elegant thing I’ve seen.