objective-c is an ugly thing. a main reason i dont develop for macos.
It's the better 'OOP extension' to C than C++ though ;)
Apart from the unfamiliar method call syntax it's actually a decent language extension once you understand what problems it wants to solve, and the killer feature of ObjC is that it doesn't mess with C semantics (which means ObjC part of the language is always automatically compatible with the latest C standard, while the 'C subset' of C++ is forever stuck in the mid-90s).
There is Objective-C++ (.mm extension), which I used extensively, where you have what is essentially a C/C++ implementation file, but you can use types and syntax from Objective-C, e.g. allowing you to call iOS APIs (UI, bluetooth, etc). Disk acccess can be done directly without objective C. Also network access. It is surprisingly unrestricted. This was a year or two ago. You need to get a path string to the app's Do…
Objective-C is a C superset, while Objective-C++ is a C++ superset, where C++ is a mostly C superset. You're not really buying anything using Objective-C++ by adding another form of OOP, except perhaps for interop with C++.
It’s the interop that’s a big deal. The platform is Obj-C (or was, now it’s Swift), most useful non-iOS-specific libraries are C/C++, being able to use Obj-C++ to glue everything together is really convenient. Vastly easier than e.g. JNI on Android.
Definitely. Just find a use case where you need the performance
Since ObjC(++) is a true superset of C (or C++), you can just write the performance-sensitive parts in C or C++ anyway. ObjC is only needed when talking to (most) macOS/iOS operating system APIs.
If you just want to write C and are ok linking to stuff that is in other languages, then I used SDL2 for my game which I wrote in C and is on the app store. It was a very pleasant experience, and if I were doing an iOS thing again, I would likely do something similar. I think I had one objective C file in there for calling a library function I needed, but otherwise I just wrote C code.
Just SDL2? Do you have access to OpenGL or some sound library as well? and if so what library are you using? How do you handle input and networking?
You have an OpenGLES 3.0 C API on iOS but it's deprecated (still working fine though).
But SDL3's has its own 3D API now which (I assume) wraps Metal on iOS.
Definitely. Just find a use case where you need the performance
There is basically no real reason to write an iOS app in C. It won’t perform significantly better.
It really depends on how much ObjC features you use in the performance-sensitive parts of your code base.
If you build your entire code around the ObjC object model and not just the parts that talk to operating system APIs you might see a performance hit since ObjC method calls are simply more expensive than a direct C function call (especially since C function calls can often be inlined)., and even setting or getting an ObjC object property involves a method call.
But since ObjC is also a complete C there's really no point in using more ObjC OOP features than really needed (e.g. just for talking to iOS/macOS framework APIs).
Obj-C apps are not deprecated yet, so the approach in that GitHub repo must still work. That app is indeed written in C, but a big chunk is about building Obj-C classes and using other Obj-C objects - so it’s not quite C. You won't get much performance benefits or additional flexibility this way.
C is Turing-complete, so you can technically write anything in it. But on iOS, you'd need to build your own C library for application-level Apple SDKs, since Apple doesn't provide one. For simple apps (like small games or toy utils) - a minimal wrapper in Objective-C or Swift could be just a few hundred lines.
You will notice that everyone that is replying that you can, also mentions that actually you have to make use from the Objective-C runtime from C.
So for all pratical purposes you will be writing an Objective-C application, manually writing the code that the Objective-C compiler used to generate when it was originally designed as a macro pre-processor generating C code at StepStone.
The way iOS is designed the bottom layer for userspace applications is Objective-C, not pure C UNIX style, and using the C APIs from the Objective-C runtime hardly changes that, you will be calling into the Objective-C runtime one way or the other.
There is basically no real reason to write an iOS app in C. It won’t perform significantly better.
It really depends on how much ObjC features you use in the performance-sensitive parts of your code base. If you build your entire code around the ObjC object model and not just the parts that talk to operating system APIs you might see a performance hit since ObjC method calls are simply more expensive than a direct C function call (especially since C function calls can often be inlined)., and even setting or gettin…
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 GU…
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.
Yes, it's still technically possible to write an iOS app in plain C in 2025 — but with caveats. You’ll need to wrap your C code in a minimal Objective-C or Swift layer to satisfy UIKit/AppKit requirements and Xcode’s project structure. Apple’s SDKs are built around Obj-C/Swift, so things like UI, lifecycle, and event handling need some glue code.
The CBasediOSApp repo you linked is still a good starting point, but expect to adapt it for modern toolchains and signing requirements.
Realistically, you'd write most logic in C (e.g. a game engine, parser, or core library) and interface with minimal Obj-C or Swift for the UI.
Anyone trying it in 2025 will likely be doing it for fun, education, or embedded-style constraints — not App Store production unless there’s a really good reason.