This is the design I came up with for storing and running methods that are created with ClassBrowser. The colour scheme is views in green, controllers in black, models in blue and all the nonsense computers make you do that doesn't solve your problem in red :-). In this case, that's persistence: the user's objects, being outside users of the system, are also in red as neither models, views nor controllers.

The notes I've made next to the user object show that my first thought on how to run the dynamic methods was broken. The idea was to use -forwardInvocation: so that the object has its invocation with the arguments set up, which would make it easy to populate the LLVM runFunction() call. That can't work, because you then can't override a compiled class's behaviour in a ClassBrowser subclass, nor can you implement -forwardInvocation: inside ClassBrowser.

What I think we need instead is a pair of functions, which I'll whimsically call id objc_msgRun(id, SEL, ...); and void objc_msgRun_stret(id, SEL, ...); for now. These are responsible for looking up the method, setting its arguments, running the bitcode, and delivering the return value (which will be fun in the stret case). When a method is added to a class in ClassBrowser, register the appropriate function from this pair with the runtime. When a method is removed from a class in ClassBrowser, disconnect this function. It's probably harder than the -forwardInvocation: route but should actually work, which is in its favour.

Here's a thread about dealing with struct returns in LLVM.