Uma das premissas seria disponibilidade de ferramentas para o desenvolvimento de aplicações para o mercado corporativo. Mas o que eu acabei descobrindo é a falta de ferramentas para este tipo de aplicações:

• O método padrão de criação de XML’s para a plataforma Mac OS X foi simplesmente esquecido, na documentação só são explicadas maneiras de se interpretar XML’s mas nenhuma forma de cria-los com facilidade. Descobri “fora da documentação” a.k.a jailbreak, que o firmware do iPhone vem com a libxml2, então pude usar uma interface que eu construí em C++ para criação de XML’s similar ao DOM.
• Não existe processamento de SOAP nativo na plataforma, o utilitário que vem com o Xcode esta quebrado mesmo para o Leopard, assim também tive de construir um client SOAP que irei em breve liberar aqui para quem precisar. Batizado de SoapBeer

No geral eu tenho gostado de programar em Objective C e a API é interessante, impossível comparar com o Windows Mobile ou o pseudo-sistema operacional Symbian, mas sempre há o que melhorar, não?

Um dos meus projetos será o desenvolvimento de uma aplicação para iPhone, então me senti compelido a ler toda a documentação disponível sobre ele.

A parte que mais me encantou realmente foi a linguagem que a Apple escolheu para acesso aos seus Frameworks, o Objective C.

Além de ter todas as características do C e C++, permitindo inclusive utilização de objetos e classes dos mesmos, ele implementa a parte que falta do C++ em termos de orientação de objetos.

Dos aspectos mais interessantes tá a questão de objetos não publicarem métodos, ou seja nenhum objeto conhece o método que irá receber a informação de outro objeto, ele ao contrário envia uma mensagem para o objeto e solicita que o receptor pertinente a ela a receba, caso o objeto em tempo de execução não tenha este receptor, ele pode optar por despachar a mensagem para outro objeto que a tenha, isto torna a linguagem extremamente poderosa, pois um objeto pode ser dinamicamente construído em runtime, e receber uma mensagem sem que seja linkado estaticamente como pré requisito no C++.

Dá para construir uma classe pai que envie genericamente informação e solicitar que todos os objetos herdem ela, assim mesmo que um objeto não saiba o que fazer com a informação ele saberá que alguém tem como fazer e poderá despachar para qualquer outro objeto, somando a arquitetura distribuída de chamadas remotas, temos um sistema de orientação a objeto distribuído em tempo de execução já pronto para utilizar.

Ainda conta com Garbage collector, Interfaces, Auto construção de Setters e Getters, Protocolos e muito mais!

Ah e para não parar por ai, tudo é Thread Safe e existem tags especificas para tratar Spin Locks…

Referência: The Objective-C 2.0 Programming Language