Author here! We write Objective-C++ to connect existing Objective-C code (that uses BOOL) to C++ (where we want to just expose `bool`), which got us into this fun rabbit hole :)
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.
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.
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.
This is the best way for having a objc and c++ in same project.