Skip to content(if available)orjump to list(if available)

Is it possible to write plain C iOS app in 2025?

Is it possible to write plain C iOS app in 2025?

73 comments

·April 14, 2025

I know this has been lately decaying.. most referenced are very old, such as this one: https://github.com/richardjrossiii/CBasediOSApp

Hence my question: Is it possible?

TazeTSchnitzel

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.

krackers

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.

arcticbull

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/

0x20cowboy

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.

TheNewAndy

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.

JKCalhoun

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

radiator

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?

lpribis

SDL2 + Lua is a pretty common combo. Lua is very easy to interface with and integrate.

beeflet

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?

TheNewAndy

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.

Asmod4n

SDL comes with a cross platform async socket API.

flohofwoe

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.

hyperbrainer

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

lupyro

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.

deadbabe

Any tutorial?

Frieren

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.

flessner

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.

fauigerzigerk

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.

irq-1

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.

anxman

Tauri v2 is very good

cruzcampo

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

ai-christianson

Why Kotlin?

okeuro49

JVM compatible, native UI.

p44v9n

ooh why?

flohofwoe

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

pjmlp

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.

krackers

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.

zer0zzz

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.

krackers

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.

saagarjha

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

quelsolaar

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/

msmshazan

This is insightful and helpful

enriquto

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.

throwaway2037

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.

abbadadda

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

Suppafly

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

edg5000

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.

anon6362

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

iainmerrick

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.

anon6362

There it is. True, it's very painful to wrap C++ code into C libraries (or requiring C calling conventions) where C++ isn't allowed.

Separately, I'm wondering if anyone uses Kotlin Multiplatform and how well that works for iOS development.

krackers

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

larusso

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.

krackers

I'd be curious if you can remember what differences there were. It's compatible with all C99 and C11 syntax I've tried

anshargal

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.