nim can technically "compile to Obj-C" and produce loose method calls through
`{.importObjc.}`, [found here in the
docs](https://nim-lang.org/0.20.0/manual.html#implementation-specific-pragmas-importobjc-pragma).
however this interface is pretty much one-way: e.g. you can't subclass in pure
nim _this way_ , which is a huge bummer as AppKit/UIKit expects you to subclass
and override frequently; but to say you can't subclass at all in pure nim code
is wrong.
one of the critical things about using Obj-C is (aside from the official
Obj-C/Swift compilers themselves that have special less-than-documented
abilities, e.g. the static baked-in selector stuff for optimization) that
Apple/NeXT built its dynamic runtime interface through what is more or less
"just a C library." in fact: Dlang's Obj-C support [is very much built through
that C
API.](https://github.com/dlang/dmd/blob/319c18813157d5a34b558a4a680356e3fff0707c/compiler/src/dmd/objc_glue.d#L588)
at this point you would be transferring your concerns out of the compiler into
the DSL realm.
