What is Monobjc bridge ?
The Monobjc bridge is a collection a .NET libraries that enabled a .NET application to use the OS X native libraries such as Cocoa, WebKit, etc. The native libraries are exposed through a set of class that makes their use very easy, because no native code is involved. The Monobjc bridge goal is to ease the access of the major OS X native libraries.
Why using Monobjc bridge ?
The .NET programming languages (especially C#) are very popular. The .NET runtime provides a lot of built-in functionalities and a lot of .NET libraries are available to build very quickly an application. So, if you want to leverage the power of .NET and use the OS X specific libraries such as Cocoa, the Monobjc bridge is the appropriate tool.
How Monobjc bridge works
The Monobjc bridge provides .NET wrappers for Objective-C types exported by various OS X frameworks. This mechanism allows any .NET applications to access the OS X frameworks as if they were .NET libraries. In addition, .NET class can be exported to the Objective-C runtime to be transparently called within native code. The Monobjc bridge takes care of all the machinery behind.
What kind of API does the Monobjc bridge exposes ?
The Monobjc bridge exposes all the major OS X frameworks such as Cocoa, WebKit and Quicktime. Any .NET application can access these frameworks as if they were .NET libraries and leverage the power of OS X frameworks in a simple way.
Why does Monobjc bridge come in several versions ?
The Monobjc bridge comes in several versions, because of its support for several OS X versions. The assemblies versionned 10.7 only contains wrappers for OS X 10.7 API, and so on. If you want to target both OS X 10.7 and higher, you should develop your application with the 10.7 assemblies.
What is the difference with the
Windows.Forms port included in Mono ?
The Windows.Forms port included in Mono is focused on cross-platform ability to run .NET code that relies on the Windows.Forms UI. This port relies on the mapping of the Windows.Forms UI to OS X UI using native API. The Monobjc bridge takes a different approach: it provides a direct access to the OS X UI API as the RubyCocoa and PyObjc projects do.
What is the difference with the GTK driver included in Mono ?
The GTK driver included in Mono is focused on cross-platform ability to run .NET code that relies on the GTK# UI (based itself on GTK). This port relies on the mapping of the GTK UI to OS X UI using native API. The Monobjc bridge takes a different approach: it provides a direct access to the OS X UI API as the RubyCocoa and PyObjc projects do.
How can I help Monobjc ?
The best way to help Monobjc is to use it, so you can spot what is working, what is broken or what is missing. Your feedback is important to us.
When I donate money, how is it used ?
The donations are used for: the hosting fees (150 Eur/year), the graphics, software and coding tools and the testing hardware.
Which license does Monobjc bridge uses ?
The Monobjc bridge is licensed under two different licenses; all the .NET code (the API wrappers) is licensed under a MIT/X11 license. The native runtime is licensed under the GNU Lesser General Public License v3.0 or later.
Why the Monobjc bridge is using the LGPL license ?
The runtime part of the Monobjc bridge is using the LGPL license to ensure a widespread adoption of the technology. The LGPL has all of the restrictions of the GPL except that you may use the code at compile time without the derivative work becoming a GPL work. This allows the use of the code in proprietary works. The LGPL license is completely compatible with the GPL license.
Where can I get more informations about the LGPL license ?
For more information on the LGPL, you can visit the Free Software Foundation's FAQ: http://www.gnu.org/licenses/gpl-faq.html.
Can I use the Monobjc bridge in an other Open Source project or product ?
You can freely modify, extend, and improve the Monobjc project source code in an other Open Source project. The LGPL requires that all changes must be made available if the combined work is distributed. For more information on the LGPL, you can visit the Free Software Foundation's FAQ: http://www.gnu.org/licenses/gpl-faq.html.
Can I use the Monobjc bridge in a commercial product ?
You can freely modify, extend, and improve the Monobjc project source code in a commercial product. The LGPL requires that all changes must be made available if the product is distributed. For more information on the LGPL, you can visit the Free Software Foundation's FAQ: http://www.gnu.org/licenses/gpl-faq.html.
If I redistribute my Monobjc based application as a native binary, what are the licenses that apply ?
The Monobjc building tools generate an application bundle that is compliant to both licenses of Mono and Monobjc. The Monobjc bridge permits the binary embedding into the generated binary. As long as you comply with the LGPL license, there is no problem.
What is the minimum version of OS X to run Monobjc bridge ?
The Monobjc bridge requires at least OS X 10.7.
Does Monobjc bridge works with Lion (OS X 10.7) ?
Yes, it works on OS X 10.7. The bridge automatically detects the proper runtime to use.
Does Monobjc bridge works with Mountain Lion (OS X 10.8) ?
Yes, it works on OS X 10.8. The bridge automatically detects the proper runtime to use.
Does Monobjc bridge works with Mavericks (OS X 10.9) ?
Yes, it works on OS X 10.9. The bridge automatically detects the proper runtime to use.
Does Monobjc bridge works on 64 bits hardware ?
Yes, it works on both 32 and 64 bits Intel platforms.
What are the requirements for Monobjc ?
The only requirement is to have a Mono runtime installed. If you consider doing some development with Monobjc, you will need the Apple Xcode Developer Tool, mainly for the Interface Builder application and the GCC/LLVM compiler.
Does Monobjc needs X11 ?
No, it does not. Monobjc only relies on standard OS X technologies and it does not use X11 at all.
Which frameworks are available through the Monobjc bridge ?
The list of the exported frameworks is available here. More framework will be added in the future.
What the limitations of the Monobjc bridge ?
Yes, the Monobjc bridge has some limitations. See this page for details
Can I use the Monobjc bridge in C#/VB.NET/MC++/F#/My Language ?
Yes, you can. As long as the language is supported by the .NET runtime (i.e. can be transformed into IL), there is no limitations other than those of the language.
How do I develop my own application ?
At the moment, the MonoDevelop IDE is the recommended solution.
How do I package my own application ?
A to show how to do this.
How do you create the user interface ?
Like any other Cocoa application, with the Interface Builder tool. Refer to the and the Programming Guide for more informations on how to use the XIB/NIB files generated by this tool.
How can I redistribute my Monobjc based application without requiring Mono installation ?
A to show how to do this.
Is there an Interface Builder integration ?
The Monobjc NAnt Tasks give a basic level of integration, by providing a way to generate source code that contains IBOutlet/IBAction mapping from a XIB or a NIB file. You create your GUI under the Interface Builder tool, and then run the custom task to get a ready to use source code. See for more details.
Is there an XCode integration ?
Not for the moment, but it is planned. A C# plugin is available (Do a Google search for it) but it only provides basic functionality (no code completion).
I found a bug. What should I do ?
You should report it in the tracking system. Please indicate all the informations that can help.
What is the planned release cycle for Monobjc bridge ?
A new release of Monobjc bridge is planned every month or every two months (6 to 10 releases a year). Each release may contains API enhancements, bug fixing, new features or anything valuable. The Monobjc bridge can be seen as a sort of continuous project (perpetual enhancement), focused on functionalities, ease of development and stability.
Why creating Monobjc bridge instead of re-using/re-writing/contributing to XXX ?
At first, it was the way we envision when we started to work on the bridge. After all, some projects were around for many years and seem pretty good. But there were things like the lack of documentation, the existing code, no means to simply debug the bridge, poor APIs, etc, that promotes the fact that eventually a new clean-room bridge implementation was needed. So we started to code from scratch a brand new engine by using the concept of parallel hierarchies between .NET and Objective-C and dynamically generated proxies.