When I did Objective-C applications with C++ business logic, I recall our company's rule was to keep Objective-C code totally separate from the C++ code, in separate files, different headers, even different static libraries if possible--really quarantine them from each other. Then have a single, standalone, hideous Objective-C++ file that served as the smallest possible interface between the two. It's the only way we could keep sane. This was a trauma response from a previous project where no such discipline was maintained, and people just causally intermixed C++, Objective-C, C, and Objective-C++ willy-nilly all over the code, with now predictable results.

This is the best way for having a objc and c++ in same project.

I work on a decade-old codebase where we freely mix C++, Obj-C++ and Obj-C as it makes sense and I can't say it's ever been an issue. Obj-C++ has some oddities, but on the whole mixing obj-c and c++ features works totally fine and I've never encountered a reason to want to separate them.

jviotti, the reason BOOL was not changed to bool sooner was because it would break ABI compatibility. So on Mac for example, they had to wait until the x86_64 to arm64 to finally do it.