[HN Gopher] Is it possible to write plain C iOS app in 2025?
___________________________________________________________________
Is it possible to write plain C iOS app in 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?
Author : iMario
Score : 141 points
Date : 2025-04-14 16:21 UTC (4 days ago)
| Suppafly wrote:
| Give it a shot. The project you linked to, despite being old
| seems like it'd get you most of the way there.
| simonhfrost wrote:
| Definitely. Just find a use case where you need the performance
| wruza wrote:
| Why do you focus on "performance" here?
| pineaux wrote:
| Presumably because C = performance?
|
| Although I think it really depends on how you structure your
| program.
| tialaramex wrote:
| Yeah. Many reasons your program might be too big or too
| slow still apply to C.
| pjmlp wrote:
| Indeed, a programming language can't do wonders when the
| authors did not pay attention to algorithms and data
| structures.
| saagarjha wrote:
| There is basically no real reason to write an iOS app in C. It
| won't perform significantly better.
| flohofwoe wrote:
| 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).
| wruza wrote:
| https://www.mikeash.com/pyblog/performance-comparisons-of-
| co...
| flohofwoe wrote:
| 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.
| krackers wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I don't think it really works anymore, unfortunately.
| astrange wrote:
| It doesn't support ARC so it's not very useful.
| johntitorjr wrote:
| I read about someone doing this in android. The C app wrote
| directly to the framebuffer. Absurdly small apk.
| mdp2021 wrote:
| # Flappy Bird for Android, only C, under 100KB
|
| https://news.ycombinator.com/item?id=41614663
| TheNewAndy wrote:
| 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.
| beeflet wrote:
| 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 wrote:
| 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 wrote:
| SDL comes with a cross platform async socket API.
| flohofwoe wrote:
| 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 wrote:
| SDL does have a platform-agnostic render library for basic
| stuff, and you can integrate Metal into it pretty easily.
| JKCalhoun wrote:
| SDL2 is awesome. Just the right level of abstraction for me
| (not "all-in" like Unity, etc.).
| deadbabe wrote:
| Any tutorial?
| radiator wrote:
| 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?
| lupyro wrote:
| 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.
| seiferteric wrote:
| 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.
| msmshazan wrote:
| Did you like have a shared code logic in a separate dylib which
| you called into or was it a single binary?
| throwaway2037 wrote:
| 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 wrote:
| > "A Real Programmer would do this using ARM assembler."
| mintflow wrote:
| 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.
| edg5000 wrote:
| 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.
| krackers wrote:
| If you just need C instead of C++ then .m suffices, ojective-c
| is a strict superset of C.
| larusso wrote:
| 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 wrote:
| I'd be curious if you can remember what differences there
| were. It's compatible with all C99 and C11 syntax I've
| tried
| anon6362 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| quelsolaar wrote:
| 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 wrote:
| This is insightful and helpful
| TazeTSchnitzel wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| uwagar wrote:
| objective-c is an ugly thing. a main reason i dont develop for
| macos.
| Klonoar wrote:
| 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
| flohofwoe wrote:
| 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).
| flohofwoe wrote:
| 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).
| anshargal wrote:
| 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.
| pjmlp wrote:
| 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.
| SonuSitebot wrote:
| 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.
| Frieren wrote:
| 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 wrote:
| 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.
| anxman wrote:
| Tauri v2 is very good
| fauigerzigerk wrote:
| 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 wrote:
| 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.
| cruzcampo wrote:
| I would go for Kotlin Multiplatform if I needed a shared code-
| base these days.
| ai-christianson wrote:
| Why Kotlin?
| p44v9n wrote:
| ooh why?
| enriquto wrote:
| 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.
| hwpythonner wrote:
| 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.
| jokoon wrote:
| 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.
| david422 wrote:
| 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.
| snadal wrote:
| 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
| m463 wrote:
| 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.
___________________________________________________________________
(page generated 2025-04-18 23:01 UTC)