Xamarin/mono IOS Limitations

http://developer.xamarin.com/guides/ios/advanced_topics/limitations/

Since applications on the iPhone using Xamarin.ios be compiled to static code, it's not possible for use any facilities T Hat require code generation at runtime.

These is the Xamarin.ios limitations compared to desktop Mono:

Limited Generics Support

Unlike traditional mono/.net, code on the IPhone was statically compiled ahead of time instead of being compiled on demand by a JIT compiler.

Mono ' s full AOT technology have a few limitations with respect to generics, these is caused because not every possible gen Eric Instantiation can determined up front at compile time. This was not a problem for regular. NET or Mono runtimes as the code was always compiled at runtime using the Just in time C Ompiler. Poses a challenge for a static compiler like Xamarin.ios.

Some of the common problems that developers run into, include:

Generic subclasses of Nsobjects is limited

Xamarin.ios currently has limited-creating generic subclasses of the NSObject class, such as no support for GE Neric methods. As of 7.2.1, using generic subclasses of nsobjects is possible, like this one:

1 2 3

class Foo<T> : UIView { [..]}

While generic subclasses of nsobjects is possible, there is a few limitations. Read thegeneric subclasses of NSObject document for more information

P/invokes in Generic Types

P/invokes in generic classes aren ' t supported:

1 2 3 4

class GenericType<T> { [DllImport ("System")] public static extern int getpid ();}

Property.setinfo on a Nullable Type was not supported

Using Reflection ' s property.setinfo to set the value on a nullable<t> are not currently supported.

Value types as Dictionary Keys

Using a value type as a Dictionary<tkey, tvalue> key is problematic, as the default Dictionary constructor attempts to use Equalitycomparer<tkey>. Default. Equalitycomparer<tkey>. Default, in turn, attempts to use Reflection to instantiate a new type which implements the Iequalitycomparer<tkey> Interface.

This works for reference types (as the Reflection+create a new type step was skipped), but for value types it crashes and b Urns rather quickly once you attempt to use it on the device.

workaround: Manually implement the Iequalitycomparer<tkey> interface in a new type and provide an instance Of this type to the Dictionary<tkey, Tvalue> (iequalitycomparer<tkey>) constructor.

No Dynamic Code Generation

Since the iphone ' s kernel prevents an application from generating code dynamically Mono on the iphone does no support any form of dynamic code generation. These include:

• The System.Reflection.Emit is not available.
• No support for System.Runtime.Remoting.
• No creating types Dynamically (No Type.GetType ("MyType ' 1")), although looking up existing types (Type.GetType ("System.String") For example, works just fine).

• Reverse callbacks must is registered with the runtime at compile time.

System.Reflection.Emit

The lack of system.reflection. Emit means that no code this depends on runtime code generation would work. This includes things like:

• The Dynamic Language Runtime.
• Any languages built on top of the Dynamic Language Runtime.

• Remoting ' s transparentproxy or anything else, would cause the runtime to generate code dynamically.

  Important: Confuse Reflection.Emit with Reflection. Reflection.Emit is about generating code dynamically and has that code jited and compiled to native code. Due to the limitations in the IPhone (no JIT compilation) This is not supported.

But the entire Reflection API, including Type.GetType ("SomeClass"), listing methods, listing properties, fetching Attribu TES and values works just fine.

Reverse Callbacks

In standard Mono it was possible to pass C # delegate instances to unmanaged code in lieu of a function pointer. The runtime would typically transform those function pointers into a small thunk this allows unmanaged code to call back I Nto managed code.

In Mono these bridges is implemented by the Just-in-time compiler. When using the Ahead-of-time compiler required by the IPhone there is the important limitations at this point:

• You must flag all of your callback methods with the Monopinvokecallbackattribute

• The methods has to be static methods, there are no support for instance methods.

No Remoting

The Remoting stack isn't available on Xamarin.ios.

Runtime Disabled Features

The following features has been disabled in Mono's IOS Runtime:

• Profiler
• Reflection.Emit
• Reflection.Emit.Save functionality
• COM Bindings
• The JIT engine

• Metadata Verifier (since there is no JIT)

. NET API Limitations

The. NET API exposed is a subset of the "full" framework as not everything are available in IOS. See the FAQ for a list of currently supported assemblies.

In particular, the API profiles used by Xamarin.ios does don't include system.configuration, so it's not possible to use Ext ernal XML files To configure the behavior of the runtime.

Xamarin/mono IOS Limitations