Frequently Asked Questions about RemObjects C# on Cocoa

Q: How does RemObjects C# for Cocoa work?

A: Let’s start by defining some terms. Technically speaking, RemObjects C# for Cocoa should be considered “RemObjects C# for the Objective-C Runtime”. The Objective-C Runtime is a “semi-managed” runtime environment for running applications, based on a lower-level C API and an object model defined by said Objective-C Runtime. The name might be a bit misleading, because technically, the runtime is not specific to the Objective-C language — much like the .NET runtime is not specific to the C# language, either.

So how does RemObjects C# fit into this?

RemObjects C# (for Cocoa) is a compiler that compiles code written in the C# language into objects for the Objective-C Runtime — in the same way that the Objective-C language compiler (Clang/LLVM, or earlier GCC) does. Objects defined in RemObjects C# “live” in the same objects space as those defined in Objective-C — including objects provided by Apple, or objects you or other developers would write in Objective-C yourself. Coming from a .NET perspective, this is just like objects written in C# (for .NET) and objects written in Visual Basic compile down to the same kind of object.

Once your code is running, there’s no technical distinction — and in fact the runtime cannot tell the difference — whether your objects were written in Objective-C, or RemObjects C# (or Oxygene). They are all “native Cocoa objects” (or native Objective-C Runtime objects, if you will).

So how does RemObjects C# interact with the Cocoa APIs? Is there a Bridge or a Mapping?

The answer to this lies in the above description, really. Because RemObjects C# compiles down to the same objects as Objective-C, the same kind of objects that make up the Cocoa and Cocoa Touch APIs, there is no bridging layer; there is no mapping between “C# Types” and “Native Types” — because no such distinction exists.

C# Classes are Objective-C classes. If you write “public class Foo: Object {}”, you are descending straight from NSObject (“Object” is just an alias). When you write “var b = new UIButton()”, you’re directly creating a UIButton instance, and storing its reference in x. There is no mapping that translates the “real” UIButton into what you see in C#, nor is there any mapping to translate instances of your Foo class to “real” Objective-C Runtime objects. They are one and the same.

This means that you have full access to all the APIs provided by Cocoa — and any third party code as well — from C#. If you hold an object of a given type, you can call any method that it implements. And you implement a class by, well, just implementing it.

But wait? How does .NET figure into this? This is C# after all!

Short answer: It doesn’t. You need to separate between .NET (the platform) and C# (the language). This should come natural, if you think about it, because .NET, right out of the box, supports a lot of languages, and C# is just one of them. The is nothing intrinsic to C# that ties it to .NET, just as there’s nothing in .NET that ties it to C#, really. (Although it might feel that way, because until now, C# was only available for .NET).

So with RemObjects C# (for Cocoa), there is no .NET. There is the C# language — with all its features and syntaxes you already know — and there are the Cocoa APIs.

That might seem a bit scary at first — after all, these are brand new APIs that you beckon — but you’ll find that Cocoa provides a neat class library (actually dozens of class libraries — “frameworks”, in Cocoa parlance) that is very powerful, and a joy to work with from C#.

What about common C# patterns, such as events or Reflection?

This really goes back to our previous question. If you think about it, many of these are not C# patterns, at all — they are .NET patterns. They are ways that the .NET framework is designed to be worked with — regardless of language.

Cocoa comes with many of its own patterns (for example, it mainly uses delegation, where .NET uses events, or it uses GCD — which is a powerful and awesome API for doing multi-threading that you will come to love — where .NET uses Tasks). Remember that RemObjects C# is a language for the Cocoa platform — not for the .NET platform. So in most cases you will be working according to the patterns that the Cocoa APIs are designed around — simply because the classes you are working with have been designed that way.

Of course when creating your own classes and libraries, there’s nothing stopping from you adopting any coding patterns you like, be they “Cocoa-like” or not. Remember — C# is just a language. How you use it is up to you, the developer.

What about LINQ?

Good question. LINQ is one of those features where it’s really hard to argue whether it’s a language feature (it is, for sure — but then it’s not unique to C#, almost every .NET language has it) or a platform feature (it kind of is too, because its implementation is based on certain APIs being available in the .NET platform types).

We decided that LINQ was so important (and so nice) a feature, that we wanted to make it available on Cocoa (and Java) as well — no matter where you come down on the platform vs. language question.

So RemObjects C# comes with an implementation of the “Standard Query Operators” (these are the extension methods defined by the .NET platform that make LINQ work), allowing you to seamlessly use LINQ language syntax with Cocoa collection classes (such as NSArray, and NSFastEnumeration).

What about Memory management

RemObjects C# adopts Automatic Reference Counting (ARC) as the memory management model. Remember, the objects you create on RemObjects C# are compiled to pure Objective-C objects so they work within the confines of the Objective-C Runtime — which happens to be reference count based. RemObjects C# purposefully does not try squeeze in any kind of Garbage Collection model on top of that, as that would defeat the purpose of being a native citizen on Cocoa.

You will find that in general, you will not see much difference in the kind of code that you write under ARC than you would under .NET's (or Java’s) GC model. Mostly you just play with your objects and don’t worry about their lifetime too much, and the (rather sophisticated) reference model of the Objective-C Runtime, along with the compiler’s ARC, will take care of things for you. RemObjects C# does introduce storage modifiers (just like Objective-C itself) that allow you to take deeper control where needed, via the strong, weak and __unretained keywords.

RemObjects C# also has support for the (rarely needed) manual declaration of Auto-Release Pools via the using (__autoreleasepool) syntax.

What about access to lower-level APIs?

C#, traditionally, is fully object oriented — that means everything is an object. Cocoa, not so much. While most of the modern Cocoa APIs used day-to-day are object oriented, there are still a lot of C-based APIs around — especially when dealing with lower-level or more esoteric APIs. CoreFoundation is one such framework of C APIs you will most likely come into contact with if you do any serious Cocoa development.

RemObjects C# adds full support for calling these C-based APIs (a.k.a. “plain non-object functions”) seamlessly and just as you would expect — you just call ‘em. It also adds support for implementing the occasional global function, should that be needed to interact with a C-based API that needs a C-function callback.

What about Cocoa-specific language idioms?

We mentioned above how the Objective-C Runtime and the Objective-C language really are two separate concept, and not strictly tied together. However, there are a couple of platform and API features in Cocoa that are bound to language features specific to the Objective-C language. In order to make RemObjects C# fit in well and natively with Cocoa, we have allowed a couple of small extensions to the language for this.

RemObjects C# adds support for Multi-Part Method Names, both for calling and implementing methods, in a way that naturally integrates and expands how methods are used and defined in C#. Many, if not most, Cocoa APIs are designed this way, and making these methods callable natively and in a fashion that stays true to C#’s nature was important to us.

Cocoa also has the concept of optional vs required interface methods. On .NET (and Java), if a class implements an interface, that means it provides implementations for all methods of this interface. Not so on Cocoa: on Cocoa, some (or all) methods of an interface can be marked as optional, and classes can choose to implemented them or not. This extends to RemObjects C#. When implementing an interface, optional methods can be omitted. When declaring interfaces, the [Optional] attribute can be used to mark members as optional.

Finally, RemObjects C# supports the type-dafe declaration of Objective-C selector literals, using the __selector keyword.

Can I reuse my existing .NET code?

The honest and blunt answer is: probably not. RemObjects C# is really not about taking your exiting .NET app and just rebuilding it for iOS (or Android). There are other frameworks out there that allow you to do this, but that’s not what we intended RemObjects C# for.

RemObjects C# is for writing new iOS (or Mac, or Android) applications, using the language you love — C# — but also using the APIs provided by the platform vendor. And trust us, the Cocoa APIs are great, and a pleasure to work with, once you get to know them. They really don’t need abstraction, and shoe-horning them into a “.NET mindset” is doing them a disservice.

So, does that mean I cannot share any code between platform?

Of course not. We understand that many developers want to create their applications for multiple platforms — for example iOS, Android and Windows Phone, in case of mobile apps.

RemObjects C# is not designed to (or encourages you to) create one application that runs everywhere, but it certainly aims to help you write versions of your application for each platform. Of course sharing some code — usually mostly back-end “business logic” kind of code – is a big part of that.

Because each platform's APIs are pretty different, even down to the lowest level (say, what methods you will find on a String, or how a Dictionary works), RemObjects C# includes Sugar, a library of base classes that makes it easy to write shared code, without giving up the ability to easily interact with platform-specific APIs in your platform-specific code. We encourage you to check out more about this on the Sugar page, and in the Docs.

More Questions?

This FAQ is driven by customer questions. If you find anything we forgot to covert, or see any concerns you might have about using RemObjects C# on the Cocoa platform not addressed here, please let us know.