Essa maravilha é possível através do MONO (virtual machine .net para "plataformas unix"). Como o iPhone tem uma arquitetura bem fechada e prioritária, a aplicação compilada final é gerada com código nativo, tendo imbutida nela a VM em um nível mais baixo.
Como todos sabem, a Apple possui uma política de inclusão de third-party runtime environments altamente restritiva, o que impossibilita a distribuição de apps que usem essa tecnologia, como o .NET e Java. Então como é possível rodar .NET no iPhone?
Graças a um processo chamado de Static Compilation. O Mono já havia criado uma maneira de gerar código nativo a partir do common intermediate language (CIL) gerado pelo .NET em código nativo no passado (AOT Ahead-OfTime compilation), com a intenção de ajudar a reduzir a velocidade do processo de inicialização e aumentar o compartilhamento de processos entre processos múltiplos. Porém, para manter ainda a portabilidade do código entre máquinas diferentes, um pequeno pedaço de código ainda se mantinha em JIT (Just-In-Time) compilation – esse método é a chave de sistemas de máquinas virtuais que geram código intermediário que durante a execução é convertido em código nativo.
Sendo assim, o processo gera o resultado final em código nativo ANTES da hora da execução, e isso diminui inclusive o tamanho da aplicação final (já que o framework deve ir junto com a App), que não precisa carregar os códigos para executar o JIT e interpretar o CIL – entretanto ainda acrescenta aproximadamente 6 mega do mono framework em si no tamanho da app final.
Hoje em dia, graças a Unity 3D, que utiliza mono, existem mais de 40 aplicações (na sua maioria jogos) na App Store que foram feitas em C# e que carregam o mono framework dentro. Seria ótimo se a Apple já incluísse isso no firmware, não? Imagine que se tivermos as 40 aplicações instaladas, são 40 vezes o mesmo framework ocupando espaço sem necessidade. O.o
Fontes:
