It is been a while since I blogged about Monobjc. Some people may have thought that the project was in sleep (or worst dead), but it is not.
I work on Monobjc on my spare time, which means that the project does not go as fast as I would. And as the last six months have been quite harsh for me on the business side, I spent very few hours on the Monobjc project. But, now that the situation is back to normal, I can dedicate more resources to the project.
In this post, I will try to summarize the current state and the future of the project.
I am working on the next iteration of the Monobjc project now for eight months. It can be considered a very long time, but the current design has proven to reach its limits when I was working on two new main features: categories and 64 bits support.
As for now, the Monobjc project is lacking on the following points:
- The support for PowerPC architectures is broken since Mono 2.6. I spent a lot of time to figure why Monobjc crashes on Mono 2.6 when it was working perfectly on Mono 2.4. Note that this issue is bound to PowerPC only.
- The support for 64 bits systems. Now that experimental build of Mono can be built, it would be great to have access to the power of 64 bits architecture in Monobjc applications.
- The support for categories is missing. Even so it does not seem important, I think it is a really handy feature to add to subclassing and composition. It works the same way as extension methods in .NET.
- The support for blocks. This addition from Mac OS X 10.6 is used extensivly in the new APIs.
- A proper set of tools, including a decent MonoDevelop plugin set.
A New Design
The PowerPC issue and the 64bits support are part of the same approach. The current design, mostly managed code, is too hard to debug or to alter in order to support a new architecture properly. So I sat down and though about the most efficient architecture that would allow a transparent support of 32/64 bits architectures and maybe solve the PowerPC support issue. I came to the conclusion that the managed side of the bridge was too clumsy.
The design I came to will be based on a custom Mono runtime, containing the Monobjc extensions (messaging, bridging, class registration, etc). It is close to what you can find in others Cocoa/XXX bridges like RubyCocoa or PyObjc. With that design, the managed code of the bridge is greatly reduces as well as the manipulation of the native structures. The diagram below summarized the idea:
What does it means for every developpers ? Well, almost nothing. The tooling part of Monobjc will take care of the custom runtime and the changes are minor. This leads to a painless migration when transitionning to the new design.
More Unit Tests
While working on the categories, I realized that the Monobjc project was not tooled enough for regression and unit testing. The current state of the unit tests is pretty awful, so the next iteration of the project will focused on a better support for unit and regression testings.
Flexible Wrapper Generation
For almost three years, I used several tools to generate the Cocoa wrappers, which involves scapping sources, fixing it by hand to have a decent result. But when dealing with new classes, it is not sustainable anymore. That why I decide to rethink entirely the wrapper generation. This is an ongoing work, but the result can be seen by cloning and building the monobjc-generator project on GitHub.
MonoDevelop Integration
The current state of MonoDevelop integration is pretty light. The plugin set was created by Eric Butler but its maintenance requires a lot of work, and the project is now considered D.O.A. Speaking of proper tools, the MonoDevelop plugin set will be of course part of it.
What about MonoMac ?
As stated in this post, the choices will favor developers. The Monobjc project remains dedicated into providing the best .NET/Objective-C bridge, along with a proper tooling. What is important to me is to provide a complete toolchain that enable developers to focus on their application instead of the development process.
Conclusion
That is all for now. I hope that my fellow readers will find this information useful. I am eager to get some feedback on that and on the Monobjc project in general.
