MacOS support

[kchilton]

From the README: The Metal/OSX backends have been excluded for now as the Objective-C code in them looks like it would probably make life painful. Please provide feedback if there is a use-case for these.

Here is the requested feedback: Yes, there is a use-case for supporting C applications on MacOS.

When Apple follows through and finally drops OpenGL support, the use case will be to provide the best method by which IMGUI can be deployed from a C source application on an up-to-date Mac. Support for Dear IMGUI Apple/OSX/Metal backend development based on the Objective-C implementation can begin at any time, since that backend works for the C++ sources.

The resolution will provide bindings for standard C (not objective-C) source code integration, examples, documentation, and test support for Dear IMGUI in the MacOS environment.

[ocornut]

When Apple follows through and finally drops OpenGL support,

First of all, OpenGL (in particular the subset we use of it) being relatively simple, it feels pretty much impossible that it can ever be fully "dropped" since it can be emulated on Vulkan and Metal. If Apple doesn't support it, third-party easily can.

While in theory we'd all agree it'd be nice to have those Metal/OSX backends exposed by dear bindings,

• C++ sources can already perfectly be used already. In particular if the context is to use in Obj-C apps, it's not like the developer would be stuck with a C only compiler?
• Wrapping a backend manually is fairly easy, so if someone needs C function they can create the wrapper manually, there are only about ten one-liner function to create.

I believe this seems like a highish-investment low-benefit effort for what have would have reasonably workarounds, so IMHO unlikely to be worth the development focus, compared to other things.

[kchilton]

Apple dropped Carbon. Apple still does not officially support Vulkan -- it is Khronos who is pushing that solution. Before Apple completely disabled it, Carbon was the easy solution for native UI applications on Mac written in pure C. That decision by Apple forced many applications to either be forced to drop Mac market or to significantly refactor code. Developers using C++ or other code bases have no problem if Apple scraps OpenGL entirely, because all of the frameworks they use have Metal support. Even developers using IMGUI have no issues if their app is in C++. Bindings for Rust and other languages are available for IMGUI on Metal as well. I don't believe there is any question as to whether Apple can eliminate OpenGL. The question is what those of us who have pure C applications available for MacOS will use for a UI going forward. If CIMGUI and Dear Bindings do not provide this as a tier 1 offering, then this makes IMGUI less attractive than the no-brainer-to-adopt it should be.

C++ sources can already perfectly be used already.

Sorry, I am confused by this. It was my understanding that Dear Bindings was intended to enable C sources to use IMGUI. The issue is that IMGUI uses Objective-C for the metal backend, but the application in view here is pure C. If the app is C++ source, Dear Bindings is not used. The use cases are applications in pure C which the developer would like to provide on MacOS using IMGUI as a cross-platform UI solution.

Wrapping a backend manually is fairly easy, so if someone needs C function they can create the wrapper manually, there are only about ten one-liner function to create.

This is true. Thousands of app developers could each implement their own 10 one-liner functions for this, or there could be a backend in a C bindings library to provide those 10 function wrappers for IMGUI. I suppose the request in this issue is to provide them from here in this project because I understood this the right place for all that which allows C-based applications to use IMGUI, where the functions will track the development of IMGUI, and be available for developers along with the testing, documentation, and examples to support IMGUI use by C applications on MacOS and all the other platforms.

Using a raylib backend for IMGUI (which is also not here) works on MacOS, because Ray already supports Metal, but then the developer needs to additionally track raylib changes and maintain those bindings. MoltenVK also provides a gasket to make Vulkan work on Metal, but then the developer needs to drag that along, too. It is my understanding that the point of having different backends for IMGUI should be to reduce, not increase, the number of layers and libraries needed to deploy an app that includes IMGUI. Adding dependencies adds complexity. I understand that this requires some investment here, but it does not seem to have low benefit for app developers who are expecting to have cross-platform apps. At the end of 2025, MacOS represented around 13% of the global desktop and laptop operating system market, compared to Windows at 66% and Linux at less than 4%. As a focus, Metal should be right behind Android, WinUI3/Win32, and iOS, and certainly ahead of any SDL or Vulkan, and for only ten one-liner functions, the investment seems rather low. Yet in the README, Windows and Linux have "Building examples" sections, but none for MacOS.

I realize this is a long-term issue needing some thought, planning, and hopefully some volunteers to help. I think we all agree that IMGUI is a great resource. This is just one issue among several, but it is not unimportant for people like me who have to support MacOS.

[ocornut]

Sorry, I am confused by this. It was my understanding that Dear Bindings was intended to enable C sources to use IMGUI.

Yes. My suggestion was referring to the fact that the build pipeline will already include an Obj-C supporting compiler, so there's no hard constraint against sneaking a bit of C++. You are correct that binding for other languages are likely to rely on C bindings.

Thousands of app developers could each implement their own 10 one-liner functions for this, or there could be a backend in a C bindings library to provide those 10 function wrappers for IMGUI.

I am of course favorable to it. But my guess (and it is merely an intuition, not being the main developer of dear bindings) that the Metal/OSX backends were omitted because they are causing parsing/context issues specific to Obj-C and/or specific to the fact the headers are exposing two variants. But maybe Ben will show up and declare this solved in an hour of work/hacking. Or if you are willing to put on the work PR are welcome.

(PS: best to call this library "Dear ImGui" as uppercase IMGUI tends to refer to the general paradigm.)

[ShironekoBen]

Personally I'd be surprised if Apple dropped basic OpenGL compatibility simply because I don't see a huge motivation for them to do so, and a very obvious downside in the form of compatibility with a large body of applications (although I also admit that it wouldn't be the first time that Apple have done something like that).

That said, I'm not against supporting Metal - just that as Omar says the amount of work involved may be significant. Dear Bindings is primarily a conversion tool, so to handle it properly isn't just a question of writing those ten function stubs but of extending the parser and DOM to understand ObjC concepts and thus be able to convert the header automatically.

So my immediate question would be "is this a use-case where ObjC headers are required, or would supporting the IMGUI_IMPL_METAL_CPP C++ path be sufficient?". If it's the latter then it looks from a quick scan of the headers that there isn't anything that isn't already supported by the parser in there, and thus we could probably do some hackery with removing the #ifdef'd ObjC parts to get something that was digestible by the current system.

Also, just to address this point as it seems there may be some confusion:

Yet in the README, Windows and Linux have "Building examples" sections, but none for MacOS.

That's not quite the case - there's a section titled "Building examples on Linux/OSX" which details running samples on OSX. It's just that Metal as a backend is not supported, so they use SDL instead, which is the same as the situation on Linux. Given the number of backend/platform combinations, the goal isn't really to provide a comprehensive set of samples for every possible situation, but enough that people have something "close enough" they can use as a springboard to get to the precise setup they want.