Using a binary library is always a nightmare. That aspect in Cocoa is terrifying after Java. With all that openness I really don't understand why Cocoa is closed-source. They could open it with "read only" license, it's not like someone could get any benefit from it.
Perhaps for fear of private APIs being used/abused by 3rd party?
We can already do that with dissemblers and objective-c header creators.
It's the apple way, closed by default.
To make working with the assembly code easier, I've found Facebook's Chisel (specifically the "pinvocation" command) to be really useful: https://github.com/facebook/chisel
Chisel is awesome. pviews is another great command, it prints the view hierarchy along with the object addresses so you can easily send messages to a specific view. This is handy for changing properties during runtime, for example.
Reveal[0] is super useful for doing view introspection at runtime. Easily paid for itself.
I don't see why the debugging had to take place on 32bit binary. From experience, the debugger disassembly for 64bit is much more "readable" - as in much of the symbols called are spelled out a lot more, and accessing function arguments are much much more friendly - "po $arg1" instead of register math.
Hopper is capable of parsing 64bit disassembly and create pseudo code from that as well, if you need it.
Since when has Hopper been able to generate pseudocode for 64-bit ARM?
Author of the post here: this was my first serious foray into disassembly land and I remember one post pointing out that Hopper had a harder time with disassembling 64-bit slices. However, it appears that was wrong! About to add an update to the post.
x86-64; we are debugging on the simulator, remember?
Ive had performance issues with UIColour and NSColour in the past as well, specifically to do with colour space conversion in my case.