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.

[1] https://developer.apple.com/metal/cpp/

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.

I would go for Kotlin Multiplatform if I needed a shared code-base these days.

Why Kotlin?

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.

I agree. https://tauri.app/start/prerequisites/

> 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.

Tauri v2 is very good

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.

Would it also be possible to write in both C and another (small, implementation written in C) higher level language? For example Lua or similar?

Would you be open to answering a few more questions about this? My email is in my profile or I could reach out to you if you provided a way.

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?

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.

SDL comes with a cross platform async socket API.

SDL does have a platform-agnostic render library for basic stuff, and you can integrate Metal into it pretty easily.

SDL2 is awesome. Just the right level of abstraction for me (not "all-in" like Unity, etc.).

Any tutorial?

There is this beautiful single-header library to write simple graphical programs in C, portably to standard unixes, macos, and windows:

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.

No, not really.

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.

Yes, technically it's possible by wrapping the ObjC runtime API, see solutions like these:

- 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).

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.

I don’t think it really works anymore, unfortunately.

It doesn't support ARC so it's not very useful.

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

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.

I remember having to set up an Ogre3D (A C++ 3D engine) project so I could compile it with XCode.

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.

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/

This is insightful and 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.

Here is the original StackOverflow question that inspired that GitHub project: https://stackoverflow.com/questions/10289890/how-to-write-io...

One of the other answers also explains how to write a MacOS app using pure C.

> “A Real Programmer would do this using ARM assembler.”

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.

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.

If you just need C instead of C++ then .m suffices, ojective-c is a strict superset of C.

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'd be curious if you can remember what differences there were. It's compatible with all C99 and C11 syntax.

Give it a shot. The project you linked to, despite being old seems like it'd get you most of the way there.

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.

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.

Did you like have a shared code logic in a separate dylib which you called into or was it a single binary?

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).

Modern ObjC is nowhere near the level of ugly that it once was. (And even then it was never that bad)

Not to mention you should probably opt for Swift first anyway, ObjC hasn’t been the default choice for quite some time now. ;P

I read about someone doing this in android. The C app wrote directly to the framebuffer. Absurdly small apk.

# Flappy Bird for Android, only C, under 100KB

https://news.ycombinator.com/item?id=41614663

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).

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.

Why do you focus on "performance" here?

Indeed, a programming language can't do wonders when the authors did not pay attention to algorithms and data structures.

Yeah. Many reasons your program might be too big or too slow still apply to C.

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.