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.
Yes. And many are when you require a common code-base for iOS, Android, and other devices. (But C++ is used more commonly)
Video games are the ones that do this by default. It would be close to impossible to have feature parity by coding a game for iOS in Swift, for Android in Java, for Steam in C++, etc. Unreal or Unity will have C/C++ code-bases with very light integration layers to do system calls.(The payment system may have code in Objective-C, for example, but mostly a wrapper for convenience reasons)
The other extreme is to just use webapps in an electron wrapper. But electron itself is build in C++.
My guess is that most developers are going to use the default Java/Swift combination for mobile development because that is what each company taught in their websites. I would prefer, thou, that engineers were more inclined to use opensource solutions to create common interfaces and avoid vendor lock-in. But cool events and free tutorials are hard to beat.
Before settling on Electron, I recommend exploring Tauri. It's more lightweight, it's better with sandboxing and it allows dropping down to Rust when performance is critical.
It's more lightweight because it doesn't include a browser engine. The obvious downside is that there is more room for compatibility issues. I'm not sure it's worth it.
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.
The game was 2d, and I just used the stuff in SDL_render.h for doing the graphics.
SDL2 has input stuff built in, so that is easy.
I didn't need networking for my game, so I didn't have it, but networking is not particularly difficult to do cross platform (I'm assuming iOS lets you just use the "normal" sockets API?)
I also used SDL2 for the sound stuff, which was mostly playing back prerecorded things, but also a little bit of stuff synthesized on the fly.
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.
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).
Yes, it's basically writing a nibless objective-c application but manually translating all invocations to objc_msgsend yourself. You're not going to be able to avoid the objective-c runtime though.
Clang has a pretty cool flag to compile objc to c. I believe it exists for Apple to port their few apps to windows (eg iTunes), but I suspect it could be used to build a pure c environment as well.
That is very cool, I think it's `-rewrite-objc`. Presumably it still needs to be linked to the objc runtime. It says it lowers to C++ instead of C though, now I wonder what pieces cannot be implemented using pure c.
Yes, Objective C is built on some deep C calls you can call directly. I was a part of a project that built an automatic wrapper generator for C. Check it out at https://felixk15.github.io/posts/c_ocoa/
I made RGFW, which calls Objective-C MacOS's API functions in Pure C.
BUT I would also like to mention a project a friend and I made called Silicon. Silicon is a single-header C wrapper around the Pure-C calls, which makes it far more convenient to use.
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 Document folder through an Objective-C call though.
The benefit of using C/C++ is that you are not writing 100% vendor locked code, only the HAL portion that interacts with some of Apple's Obj-C APIs will be platform-specific.
For example, if you write Linux-HAL then you can run your code, at least for testing, locally. And of course it opens the door to an Android port.
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.
It‘s a superset of ANSI-C. One needs to be carful to mention this. I‘m not aware that this had changed and also added some small grieve back in the days for me. But I sadly can‘t remember anymore what didn‘t work for me.
I think it was specifically in .m files. Obj-c is using ANSI-C (c89) which lacks certain features and keywords. Mixing with c99 files is of course possible. Maybe that was also an issue in older versions of clang.
I haven't run into such issues intermingling C11 features in a .m file. Possibly you just needed to set the right compiler flags, or it was a bug in older versions of clang.
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.
I think a better question is - could people practically write macos/ios apps without xcode.
I remember the feeling I first got (decades ago) when moving from C to objective C.
Having an xcodeproj was like the camel's nose under the tent, and then you couldn't go back. And you frequently had a big mess going forward when the next xcode version came out and it wouldn't work.
I wrote an app that has minimal Objective C that then just calls C++ code. You can either add .cpp files to your project, or if I recall correctly, you can just define C++ functions in your obj c files. In my app, Objective C just sets up the UI and then it calls C++ functions to do calculations. Not exactly your question, but might be helpful.
Well, you could basically do any llvm supported language.
I remember a few years ago I tried creating a DSL just for fun and the sake of testing on iOS.
You can create a frontend of whatever language you want for llvm so it’d translate it to llvm-ir.
You just need a small wrapper in objective c to make it work.
Recently I have built a iOS network extension by porting fd.io vpp to Darwin platform, though the UI part is written by SwiftUI. But the core is written using good old C and dns component is written using rust with hickory library, I was considering using c-ares but wanna get a try with rust.
So I think if UI stuffs can be written using C it then can build app using pure C.
Yes. It is absolutely possible.
We have been including for more than 10 years a pure C web server on some of our apps that is currently 100% compatible for both Android and iOS
Ha I ported my c solitaire program (uses SDL2) to iOS a couple years ago and it was pretty smooth. I didn't know or think this was unusual, but I suppose most people would not start an iOS app this way.
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).
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).
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.
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.
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.
[1] https://developer.apple.com/metal/cpp/
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.
Video games are the ones that do this by default. It would be close to impossible to have feature parity by coding a game for iOS in Swift, for Android in Java, for Steam in C++, etc. Unreal or Unity will have C/C++ code-bases with very light integration layers to do system calls.(The payment system may have code in Objective-C, for example, but mostly a wrapper for convenience reasons)
The other extreme is to just use webapps in an electron wrapper. But electron itself is build in C++.
My guess is that most developers are going to use the default Java/Swift combination for mobile development because that is what each company taught in their websites. I would prefer, thou, that engineers were more inclined to use opensource solutions to create common interfaces and avoid vendor lock-in. But cool events and free tutorials are hard to beat.
> Tauri requires various system dependencies for development on Linux. These may be different depending on your distribution ...
> WebView 2 is already installed on Windows 10 (from version 1803 onward) ...
> iOS development requires Xcode and is only available on macOS.
I think I had one objective C file in there for calling a library function I needed, but otherwise I just wrote C code.
SDL2 has input stuff built in, so that is easy.
I didn't need networking for my game, so I didn't have it, but networking is not particularly difficult to do cross platform (I'm assuming iOS lets you just use the "normal" sockets API?)
I also used SDL2 for the sound stuff, which was mostly playing back prerecorded things, but also a little bit of stuff synthesized on the fly.
But SDL3's has its own 3D API now which (I assume) wraps Metal on iOS.
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.
- 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).
https://github.com/ColleagueRiley/RGFW.git
It was discussed recently around here: https://news.ycombinator.com/item?id=42217535
The macos backend is a neat hack, written in pure C.
BUT I would also like to mention a project a friend and I made called Silicon. Silicon is a single-header C wrapper around the Pure-C calls, which makes it far more convenient to use.
https://github.com/eimamei/silicon
I no longer use it in RGFW because I wanted to remove the extra dependency.
One of the other answers also explains how to write a MacOS app using pure C.
For some reason it required a bit of objective C for it to work with opengl.
I sold my macbook about 2 years later, around 2015.
The benefit of using C/C++ is that you are not writing 100% vendor locked code, only the HAL portion that interacts with some of Apple's Obj-C APIs will be platform-specific.
For example, if you write Linux-HAL then you can run your code, at least for testing, locally. And of course it opens the door to an Android port.
Separately, I'm wondering if anyone uses Kotlin Multiplatform and how well that works for iOS development.
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.
I remember the feeling I first got (decades ago) when moving from C to objective C.
Having an xcodeproj was like the camel's nose under the tent, and then you couldn't go back. And you frequently had a big mess going forward when the next xcode version came out and it wouldn't work.
You can create a frontend of whatever language you want for llvm so it’d translate it to llvm-ir.
You just need a small wrapper in objective c to make it work.
So I think if UI stuffs can be written using C it then can build app using pure C.
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).
Not to mention you should probably opt for Swift first anyway, ObjC hasn’t been the default choice for quite some time now. ;P
https://news.ycombinator.com/item?id=41614663
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).
Although I think it really depends on how you structure your program.