Since applications on the iPhone using MonoTouch are compiled to static code, it is not possible to use any facilities that require code generation at runtime.
These are the MonoTouch limitations compared to desktop Mono:
Unlike traditional Mono/.NET, code on the iPhone is statically compiled ahead of time instead of being compiled on demand by a JIT compiler. Mono's Full AOT technology has a few limitations with respect to generics, these are:
Generic virtual methods aren't supported, as it isn't possible to determine statically what method will be called in all circumstances. (Which is why C++ doesn't support virtual template methods, either.)
class HasGenericVirtualMethod { public virtual PrintValues<T>(params T[] values) { // ... } } // ... var a = new HasGenericVirtualMethod (); a.PrintValues (new[]{1, 2, 3, 4});
P/Invokes in generic classes aren't supported:
class GenericType<T> { [DllImport ("System")] public static extern int getpid (); }
Using Reflection's Property.SetInfo to set the value on a Nullable<T> is not currently supported.
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 is skipped), but for value types it crashes and burns rather quickly once you attempt to use it on the device.
Workaround: Manually implement the IEqualityComparer<TKey> (http://www.go-mono.com/docs/index.aspx?link=T%3aSystem.Collections.Generic.IEqualityComparer%601) interface in a new type and provide an instance of that type to the Dictionary<TKey, TValue>(IEqualityComparer<TKey>) constructor (http://www.go-mono.com/docs/monodoc.ashx?link=C%3aSystem.Collections.Generic.Dictionary%602(System.Collections.Generic.IEqualityComparer%7b%600%7d)).
Since the iPhone's kernel prevents an application from generating code dynamically Mono on the iPhone does not support any form of dynamic code generation. These include:
The lack of System.Reflection.Emit means that no code that depends on runtime code generation will work. This includes things like:
Important: Do not confuse Reflection.Emit with Reflection. Reflection.Emit is about generating code dynamically and have that code JITed and compiled to native code. Due to the limitations on the iPhone (no JIT compilation) this is not supported.
But the entire Reflection API, including Type.GetType ("someClass"), listing methods, listing properties, fetching attributes and values works just fine.
In standard Mono it is 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 that allows unmanaged code to call back into managed code.
In Mono these bridges are implemented by the Just-in-Time compiler. When using the ahead-of-time compiler required by the iPhone there are two important limitations at this point:
The following features have been disabled in Mono's iPhone Runtime:
We have only tested MonoTouch with iPhoneOS 3.0 and 3.1 and we do not know if it would work with older versions.
Currently MonoTouch does not bind the followoing Objective-C frameworks:
The .NET API exposed is a subset of the full framework as not everything is available on the iPhone. See the FAQ for a list of currently supported assemblies.