By using partial classes I can create libraries for every mobile platform that share a common interface. The component- / classdiagram below is a concept of this principle.

The light yellow blocks are generic code and the purple blocks are platform specific code, IOS in this case. A block is an project / assembly containing classes. You know the notation ;).

Top left is the partial class FontLoader that is used by the Logic class on the top right. The business project has a reference to the Util project (no linked file) and uses the Util.FontLoader.Load operation in the Business.Logic.DoSomething method.

Bottom right: an IOS project cannot have references to non IOS projects, so the Logic file is included in the project as a linked file. The same for the FontLoader file in the platform specific Util IOS project bottom left. Next to the linked FontLoader file I’ve added a FontLoader.IOS.cs file. (feel free to use other naming conventions) In FontLoader.IOS.cs I’ve implemented the partial method LoadFontReal with IOS specific code. The GUI IOS project has a reference to the Util IOS project.

Because of the same namespace for FontLoader in Util and Util.IOS the compiler will link the call to Util.FontLoader.LoadFont to the referenced Util.IOS implementation. This way I can keep my blocks in separate projects and reference them in stead of linking all the individual files needed.

Cons

• Identify commonalities between platforms. The method signature must match on all platforms.
• Not implemented partial methods just get skipped. (no build error)

Pros

• The Util project in this example has become a true block.
• Unittesting can be done with an unittest specific implementation of the block.