Probably because the most used form of interfaces is reference counted. ("smart pointer").
Oh! Okay! I was hoping I wasn't missing anything and it looks like I was, sort of. I'll have to watch out for that since I prefer malloc/free over RC.
Interface problems are largely due to RC. Mostly because most have a trial and error way of working, which usually aligns well with Pascal/Delphi, but this is an exception :-)
This because only interface references are
automatically refcounted and the corresponding object references are not. They have a ref count for interface usage (the last reference via an interface disappearing will deallocate), but object references does.
As manual vs refcounted goes, in general I'm pro manual allocation, but not a purist, IOW they will have to pry refcounting strings from my cold, dead hands :-)
If it's a success, I will definitely share the unit and it will be my contribution to putting another stake in the heart of Carbon. If it had been written in anything other than Pascal, wouldn't we all be Cocoaized by now?
Cocoa had a name of being buggy and having versioning problems for a long time. Also it was not a plain C app, so a lot of Objective C interfacing had to be arrange to make it practical. (you did check out the objective Pascal dialect didn't you?) . It also was an enormous amount of work, and little comparison material.
Carbon just worked, and was usable as fundament for long term libraries and frameworks. Even Adobe postponed the migration several times ( and eventually went with a cloud version)
Note that since development versions of Lazarus have a cocoa port, lazarus LCL is a form of GDI/cocoa abstraction already. Rebasing your framework on top of it could be worthwhilep.s. the cloud thing is a joke, I don't think that is related to cocoa.