Cross Platform


The design of both MonoTouch and MonoMac calls for the use of the native .NET string type for string manipulation in C# and other .NET programming languages and to expose "string" as the data type exposed by the API instead ot the NSString data type.

This means that developers should not have to keep strings that are intended to be used for calling into MonoTouch or MonoMac API in special types (MonoTouch.Foundation.NSString or MonoMac.Foundation.NSString), they can keep using Mono's System.String for all of the operations, and whenever an API in MonoTouch or MonoMac requires a string, our API binding takes care of marshalling the information.

For example, the Objective-C "text" property on a UILabel of type NSString, is declared like this:

@property(nonatomic, copy) NSString *text

This is exposed in MonoTouch as:

class UILabel {
    public string Text { get; set; }

Behind the scenes, the implementation of this property marshals the C# string into an NSString and calls the objc_msgSend method in the same way that Objective-C would.

There are a handful of third-party Objective-C APIs that do not consume an NSString, but instead consume a C string (a "char *"). In those cases, you can still use the C# string data type, but you must use the [PlainString] attribute to inform the binding generator that this string should not be marshalled as an NSString, but instead as a C string.

Exceptions to the Rule

In both MonoTouch and MonoMac we have made an exception to this rule. The exception to when we expose strings and when we expose NSStrings is done when the NSString method could be doing a pointer comparison instead of a content comparison.

This could happen when an Objective-C APIs uses a public NSString constant as a token that represents some action instead of comparing the actual contents of the string.

In those cases we have exposed NSString APIs and there are a minority of APIs that have this. You will also notice that we tend to expose NSString properties in some classes. We expose those NSString properties for items like notifications. Those are properties usually look like this:

class Foo {
     public NSString FooNotification { get; }

Notifications are keys that are used for the NSNotification class, when you want to register for a particular event being broadcast by the runtime.

For keys, you will usually see them like this:

class Foo {
     public NSString FooBarKey { get; }

Another place where NSStrings are exposed in the API is as tokens that are used as parameters to certain APIs in iOS or OS X that take NSDictionary objects as parameters. The dictionary typically contains NSString keys. MonoTouch by convention names those static NSString properties by adding the “Key” name.