Before you start make sure you familiarize yourself with the Launcher and ContentManager tools and make sure you can build your application on Windows first!

Also make sure you have a Marketplace License and a Xamarin MonoTouch License, without it you cannot do any of the following steps. In order to deploy to a device (AdHoc) or build an AppStore version of your application you also need to be a registered Apple iOS Developer!


First of all make sure your project is targeting at least v0.9.4 (see the Launcher - Windows section).

Next go to the Project Settings -> iOS Universal settings page in the ContentManager and setup your Build Settings:

Note: All settings on this page are private and will only be used for you. If another user wants to build your project (e.g. Blocks in this example) he has to setup ALL these things for himself.

  • For the first time setup (registering as an iOS developer, setting up your certificates, AppID and devices) check the extra section below.
  • Currently the process is not automated yet (we plan to do that in the future, also the more people asking us in the Forum, the more we will simplify the process). Please go through all the custom steps here and upload your .p12 and .mobileprovision files accordingly to the 'iOS Universal' Device Settings as shown on the above screenshot. Also make sure your Signing Information (just your username at the iOS Provisioning Center) and the Signing Password (to open the .p12 file) are set! Development, AdHoc and AppStore all work the same way, but you need to upload different certificates and mobileprovision files for them. We recommend using AdHoc files as it makes testing easier via a weblink (see below).
  • Don't forget to set the Product Identifier (the same one you have setup for your iOS App ID).
  • AppStore: If you use an AppStore distribution certificate you should enable this box to make sure an AppStore version of your application is being build. You should obviously test if the non-AppStore (AdHoc) version works fine locally because you cannot test the AppStore version yourself. You will need to upload the build result file to the AppStore yourself!
  • Debug Mode costs much more performance on mobile devices and should only be used when you run into trouble to output more data into the log. Ask us to help debugging problems.
  • Finally and most importantly you need to setup all framework keys to whatever frameworks you want to use (e.g. MonoTouch, AdMob, OpenFaint, etc.). Without a valid MonoTouch key the build server will not allow you to build (see your email you get after purchasing MonoTouch from Xamarin).
  • If you need help, please write us your exact Project, Username, Device and copy your Launcher output (right mouse button -> Copy all). DO NOT post your sensitive information in the forum and never post your framework keys or signing information to others (not even us). Those are private and should always stay with you (they will be stored RSA encrypted in your Build Settings and we cannot restore them without your username and password, which is obviously also private to you).


Once you are done don't forget to save your DeviceSettings and head over to the Launcher tool (which you can do by right clicking on your project in the ContentManager).

Select iOS Universal and make sure everything else is correctly setup (you could try building your application on Windows first to make sure everything works just fine).

Now click Start Build Service and watch the magic unfold. Since this is still in beta problems might occur at many levels (settings failing, rules failing, compiler errors and warnings, packaging or signing problems, etc.). Please send us your Launcher logs (just right click on the output and select 'Copy All Messages'). You can either post this in the Forum or write us an email. The Launcher log will not contain your private keys or information, just the general settings and what went wrong. Thanks!

Launch on Device

  • When you did use a development certificate you will get back an .ipa file (zipped file with .app directory in the Payload directory) you can upload to iTunes to be synced onto your iOS device. You can upload the .ipa file by dragging it onto the libraries section of iTunes, then press Apps -> Sync to get it onto your connected device. Make sure you have selected your new app or use "Automatically sync new apps", which is on by default. We included the mobileprovision file in the app so it will be installed as well (if in trouble, delete it from your device first).
  • AdHoc builds (default) will give you a link to a private website you can use directly on your iOS device to download and install the AdHoc build you just created. Additionally you get a link to the AdHoc .ipa file you can install yourself with iTunes (like for development) or use to upload to other tools (like TestFlight).
  • For AppStore builds you will only get back a .ipa. file you can use to upload to the AppStore using iTunes Connect - Manage Your Applications.
    Note: This is not tested well in v0.9.5 yet, please always test with an AdHoc build first and contact us if something goes wrong when uploading your application.
Tip: If you want to see the console log for your connected iOS device in Windows you can download the iPhone Configuration Utility for Windows and click on the Console tab for your device. It also shows all the configuration and provisioning profiles installed on your device.

Deployment Versions

  • Development, which is a bit easier to test locally and is usually used for debugging. You need a development certificate and .mobileprovision file linking to it (see above). This is usually used locally and for debugging because it is quicker to test, but it is not really useful with the Delta Engine because you do your testing and debugging on Windows already. This option is used if you upload a development certificate and mobileprovision file.
  • AdHoc Distribution, good for testing with others and building the release version, needs different certificate (distribution) and different .mobileprovision file than for Development. Other than that very similar to Development, but you can build a IAP file for Over the Air distribution via a weblink. If you upload a distribution certificate and AdHoc mobileprovisioning file, this process is used. This is the default and recommended way to build apps via the Launcher!
  • AppStore, this is the final version you will build to upload to the Apple AppStore. It works the same as AdHoc, but needs a different AppStore .mobileprovision file. This version won't run on any of your devices. Only after it is available in the AppStore users can get your app (if Apple approves it). To enable this check the AppStore/Installer checkbox in the iOS Device Settings screen (see above), but make sure to test your app as AdHoc before as approval from Apple can take 2 weeks and you don't want to go through the process multiple times because of some minor issues.

Extra Features

Currently the following set of Framework Keys are supported to customize your application:
  • MonoTouch: Your Mono for Android license, must always be set and must be valid (we can revoke this at any time when we detect fraud).
  • SupportOlderDevices: By default iOS builds support only newer iOS devices since iPhone 3GS (from 2009), which allows better optimizations that are important for games. If you want to support even older devices (iPhone 2G and 3G from 2007 and 2008) you can use this key and specify the devices you want to support (usually just set to 'All' or 'iPhone3G').
  • ImproveBuildSpeed: Similar to SupportOlderDevices different build options are used, which cut down the build times a bit. This can be useful for iterating quickly and if you don't have any performance problems. Additionally this removes some build steps which are more important for AdHoc builds, you should only use this with development certificates. You can also try to combine this with LinkMode = 'None', but the decreased build time you gain might be overshadowed by a bigger binary file that has to be send to the device, so you need to test it out if it makes sense in your project. Unlike SupportOlderDevices this setting is ignored for AppStore builds.
  • AdMob, OpenFeint, InAppPurchases are also implemented, follow the same instructions as on the Android Development Guide. Might need some custom setup and testing for each project. You can also upload a 'openfeint_offline_config.xml' file (this file is only used on iOS, not on Android) as Custom Project content (and other files) if you need different settings and more customization.
  • LinkMode: Like Mono for Android by default MonoTouch also links everything tightly together and will remove all code that is not called by your app. Due the dynamic nature of the Delta Engine this does not work very well with the Delta assemblies or any code calling it because classes are created and linked on demand at runtime, not at compile time. However due the EngineTypeList system we already know which types are available to use for an application. You can add your own types there as well using the ContentManager. If you still have issues with types being removed you need at runtime you can use this setting (set the value to 'None' to disable linking, you can also set it to 'OnlyStrip' to prevent linking, but allow stripping, which removes unused assemblies).
  • IOSSDKVersion: By default each platform device settings defaults to the latest SDK that works. You can however set different SDK with this key. If you run into trouble be sure to contact for help and to make sure the selected SDK exists and works for your application. Currently defaults to '5.1'.
  • ExtraIOSPlistData: This key lets you specify extra data for the generated Info.plist file. This is highly technical and specific to iOS, please refer to the Plist_iOS_SDK_documentation and ask in the Forum for help for specific things you want to accomplish. Example:
  • ExtraCommandLineOptions: With this key you can specify extra command line options for the packager. There are many different options available, please ask in the Forum for specifics. One example is to force building a debug build with "-debug" as the value. Separate multiple values with space. Most options need a - or -- in front of them.
  • Obfuscation is not needed or used on iOS because a binary file is produced (as opposed to Android, Windows or Windows Phone 7, where you still have .NET assemblies).
  • Debug builds usually make no sense unless you have access to an Mac with iOS development tools installed so you can test out debuggable simulator builds. You can also just specify -debug via the ExtraCommandLineOptions to force your device build to be in debug mode, but we currently have no plans to support debugging directly over our tools. If you have a company license, you can contact us for setting up a debuggable project you can work on with a Mac and an experienced iOS developer.


You can upload Icons to your project by putting png images in your ProjectSettings folder via the ContentManager. iOS uses the following icon sizes (at least one of these has to be uploaded or the build system will use the fallback Delta Engine icons for your project), it makes sense to upload them all or let them be generated from bigger icon size:
  • 29x29 pixels: iPhone (optional), for display in Spotlight search results
  • 48x48 pixels: iPad (optional), for display in Spotlight search results. Also used for Android medium dpi. For iPhone this size is controversial! Apple’s docs actually say the icon is 50 px, but then there’s this note: The final visual size of this icon is 48 x 48 pixels. iPhone OS trims 1 pixel from each side of your artwork and adds a drop shadow. Be sure to take this into account as you design your icon. How weird!
  • 57x57 pixels: iPhone Icon (optional alpha, size 57x57)
  • 58x58 pixels: iPhone 4 (optional), for display in Spotlight search results
  • 72x72 pixels: iPad, for the application icon (optional alpha), also used for Android hdpi (high resolution devices)
  • 114x114 pixels: iPhone 4, for the application icon (optional alpha), make sure your icon shines on the iPhone 4 Retina Display.

General Information

  • iPhone 2G, 3G, 3GS Screen Size: 480x320
  • iPad 1 & 2 Screen Size: 1024x768
  • iPad 3 Screen Size: 2048x1536 (Retina)
  • iPhone 4, 4S Screen Size: 960x640 (Retina)


  • iPhone2G, iPhone3G: 128 MB (often less than 50 MB free, in some cases only 15 MB free), not supported by Apple anymore!
  • iPhone3GS, iPod3, iPad 1: 256 MB
  • iPhone4, iPhone4S, iPod4, iPad 2: 512 MB
  • iPad 3: 1024 MB
For more information see:

SDK Versions

  • iPhone2G = iPod1G - 1.0 to 3.1.3
  • iPhone3G = iPod2G - 2.0 to 4.2.1
  • iPhone3GS = iPod3G - 3.0 to 5.1
  • iPhone4 = iPod4G - 4.0 to 5.1
  • iPhone4S - 5.0 to 5.1
  • iPad - 3.2 to 5.1
  • iPad 2 - 3.2 to 5.1
  • iPad 3 - 5.1 to 5.1
Device 2.0 2.1 2.2 2.2.1 3.0 3.1 3.1.2 3.2 4.0 4.2 5.0 5.1
iPhone2G/iPod1G X X X X X X X - - - - -
iPhone3G/iPod2G X X X X X X X X X X - -
iPhone3GS/iPod3G - - - - X X X X X X X X
iPhone4/iPod4G - - - - - - - - X X X X
iPad - - - - - - - X X X X X
iPad 2 - - - - - - - X X X X X
iPad 3 - - - - - - - - - - - X

First Time Setup

This section is only needed for the first time you setup your iOS Developer Account and create your AppId and setup your iOS devices for the mobileprovision files you want to use. This all works on Windows, but is a bit easier on the Mac. This process can be painful for the first time, ask in the Forum for help if you run into trouble.
  • For iOS deployment you will need a valid signing developer key, a signed and valid certifcate file and the product identifier, which all has to be setup in the iOS Provisioning Portal. In order to setup your certificate you need an Apple iOS Developer Account!
  • If you have not done this before please read the Obtaining your iOS Development Certificate, Assigning Apple Devices to your Team, Creating your App ID and Creating and Downloading Development Provisioning Profiles Tutorials!
  • As written in the tutorial link above you need to create a CertificateSigningRequest, turn that into a .pem certificate and export it as a .p12 certificate (with the signing password). On windows this is a bit tricker, but explained in the custom steps links above.
  • Make sure your iOS device you want to test on is entered in your iOS Provisioning Portal account prior to creating a .mobileprovision file, where you obviously want to include your iOS device so you can test your app. To copy the 40-letter Device Identifier (UDID) click on the Serial Number in iTunes and then copy with Ctrl+C, now enter this in the Devices section of the iOS Provisioning Portal.
  • Setup at least one App ID in the iOS Provisioning Portal. For testing you can use the same App ID several times and for different projects, but obviously you should create one AppID per AppStore product you want to build. You can also use a wildcard at the end, which can be useful if you just want to test several applications, e.g. com.mycompany.*
  • Next you need a Provisioning Certificate for building your application. The Provisioning Profile needs to point to your previously created App ID and you must have valid Developer Certificates and Devices setup to enable deployment on them (see Tutorials links above).
  • Now download the created Provisioning File (.mobileprovision) and upload it in the iOS Universal Build Settings (see above).


The Delta Engine was originally started with just the iPhone in mind (back in 2009, our first "Proof of concept" already worked after a few weeks, but I would not call it an "Engine") and it was our first platform we supported. Soon we learned that the limitations of iOS are not really fun to work with and building content, long compiling cycles and testing took a lot of time, so we wanted to improve this process and will continue to do so in the upcoming years. In 2010 we developed and released ZombieParty, an iPad game with 4 simple sub games and local multiplayer. We also released that game to iPhone, Android, Windows Phone 7, PC and use it as an more complex example game together with our flagship product SoulCraft.

Currently (v0.9.5) the feature set is still pretty limited (mostly 2D content types, focus on 2D games), but tried to automate the whole process as much as possible. At this time Xamarin (MonoTouch) is still the underlying technology, but as a Delta Engine developer you will not come in contact with it (except that you need a license for testing and deploying your applications from them). Like for all non-Windows platform you will need a Marketplace License to build applications via the Launcher. Please go to the Marketplace site to learn more about licensing.