Não é segredo algum que eu sou fã do produtos da Apple. A grande maioria das vezes que uso algo deles a única coisa que penso é como uma empresa tão grande consegue propagar um nível de qualidade tão alto para todos os seus produtos (software e hardware) e tento aprender um pouco com isto.

Fase inicial: susto!

Porém, no lançamento do iPhone OS 4.0 (que achei fantástico) uma coisa me assustou muito. A cláusula 3.3.1 do TOS do SDK da Apple, que resumindo é: Só vamos aceitar apps em Obj-c e derivados de C++, além de apps em Javascript que usam o Webkit.

A minha primeira reação foi: “que p&@#ra é essa?” . Eles vão acabar com as plataformas PhoneGap, Rhodes, MonoTouch e outras? Não faz sentido.

Honestamente eu duvido que eles vão negar apps em Titanium e PhoneGap pois a própria cláusula defende estas tecnologias. São tecnologias que basicamente empacotam uma web app feita em HTML5+CSS3+JS no componente WebView (que utiliza o >Webkit<) de forma que possa ser compilada e vendida na App Store. Você também ganha acesso a várias api’s como GPS, câmera e etc.

As outras plataformas como o Flash CS5 com certeza estão fora e não serão mais aceitas na App Store.

Fase 2: pensamento.

Todos que acompanham o meu trabalho sabem que gosto muito dos produtos da Adobe, principalmente a plataforma Flash. Apesar de achar que ela possui diversas falhas de arquitetura (não vou detalhar isto agora) e não é de longe um produto genial como por exemplo Ruby, Smalltalk ou até Obj-c. No entanto, é fato que o Flash é muito bom para criar experiências ricas na internet.

Para web não levanto a bandeira de nada para frontend pois na minha opinião as coisas estão engatinhando. Mas para desktop a coisa é um pouco diferente.

Nos últimos 8 meses tenho dedicado boa parte do meu tempo em pesquisar plataformas para desenvolvimento desktop. Acho que testei praticamente tudo, desde Titanium e QT até Adobe AIR. E a minha opinião final é que nenhuma destas tecnologias é algo como o Rails.

Quando digo como Rails me refiro a uma plataforma onde uma equipe de 2 pessoas consiga desenvolver algo extremamente bem feito, fácil de manter, estável, com uma experiência fantástica e em curto prazo. Todos falham em algum ponto crítico e todas são multi-plataforma.

Fase 3: experiência de usuário e exigência.

Dependendo do grau de exigência que você tem para seus projetos, simplesmente não existe multi-plataforma. Eu poderia listar várias coisas que não gosto em Adobe AIR ou Titanium por exemplo. Mas o mais claro é que produtos multi-plataforma para desktop destroem a experiência do usuário e entregam algo que a pessoa não espera.

Ou você acha legal uma app em Java ter a interface totalmente diferente das nativas do Mac ou do Windows? Outro exemplo é o Kindle For Mac, sem palavras, um lixo. Ao tentar ler um livro nesta coisa a última idéia que me vem a cabeça é que eu estou usando uma aplicação Mac. Todos os atalhos são diferentes, os ícones são diferentes, as posições das coisas são diferentes.

Eu, como usuário, não dou a mínima se é caro manter 3 versões diferentes da aplicação. Apenas espero que ela funcione como eu espero ou é melhor que ela nem exista.

Você acha que sua mãe e seu irmão querem ter que re-aprender onde ficam as coisas cada vez que abrem uma aplicação nova? Não!

E eu passei por este problema ao tentar encontrar algo para desenvolver para dispositivos móveis. Algo que fosse portável para iPhone e Android. O resultado foi que tudo que eu tentei usar criava um Frankstein e um das lados, ou seja, a app ficava com cara de iPhone e não tinha nada de Android e vice-versa.

Eu não gastaria meses em um produto onde eu não consiga entregar uma experiência excelente então a minha opção foi abandonar o conceito multi-plataforma e focar em iPhone. Nada de Phonegap também pois você perde muito tempo tentando emular o comportamento de apps nativas e ainda fica com algo a desejar.

E quando anunciaram o Flash CS5 com suporte para apps iPhone o que logo me ocorreu (e que depois comprovei ser verdade) é que era apenas mais uma ferramenta que vai entregar aplicações com problemas como citei acima (Frankstein’s).

Fase 4: não sei mais se a Apple está errada.

Depois de pesquisar tanto entrei de cabeça no desenvolvimento Mac em Obj-c e MacRuby. MacRuby para quem não conhece é a própria implementação da Apple da linguagem Ruby e que é totalmente compatível com Cocoa e os demais frameworks para o Mac.

A única palavra sobre os meus estudos da plataforma Mac são: um produto genial! O Interface Builder por exemplo é sem dúvida a melhor ferramenta que conheço para criar interfaces gráficas sem gerar código bagunçado (ex.: Dreamweaver, Delphi For PHP e etc).

O XCode é bem legal e eu pessoalmente odeio IDE’s. A documentação da Apple é simplesmente excelente, com centenas de vídeos, manual bem escrito de todas as classes, forums internos, suporte e etc. E todas as ferramentas são gratuitas (já paguei pelo Mac mas o ponto aqui é outro, no Windows você pagou pelo S.O. e ainda paga pela licença da ferramenta de desenvolvimento).

Porém, mais fantástico é a linguagem e seus frameworks. O Obj-c a primeira vista assusta pois a sintaxe é bem diferente de Java, C++ ou JS (bem mais parecido com Smalltak). No Entanto logo que se acostuma percebe como é uma linguagem sólida e poderosa que bate de frente com tecnologias de alto nível como Ruby e Smalltak. Além de ser uma tecnologia que evolui a mais de 20 anos.

Ao aprender Obj-c fica óbvio o porque da qualidade do OSX. A linguagem é simplesmente fantástica, com estruturas poderosas como Key Value Coding e Metaprogramação, tudo isso sem perder performance, permitindo a criação de animações complexas com Core Animation em conjunto com ferramentas como Quartz.

E o melhor de tudo isso é que todos os recursos são condizentes. Chega a ser difícil criar uma aplicação Cocoa (framework padrão para desenvolvimento Mac e iPhone) que saia dos padrões do que estamos acostumados da experiência de usuário no Mac.

Fase 5: minha exigência começa onde termina minha preguiça.

Conversando com um amigo que defende o Flash CS5 compilar apps iPhone ele disse que tempo é dinheiro e que se já sabemos Flash e AS3 então é bobeira ter que aprender Obj-c/Cocoa. Descordo totalmente, se algo vai ser um Frankstein e você vai ter que passar muito tempo simulando a experiência padrão em um aparelho e criando um monstro em outro então eu prefiro aprender a plataforma correta.

Se plataforma correta for sólida, fácil de manter e acessível a equipes de 3 pessoas então a minha opção como desenvolvedor e empreendedor é sem dúvida esta plataforma. E a plataforma da Apple é assim (ainda acho que falta mais foco em TDD mas isso é porque sou um cara de Ruby).

Acredito ser melhor gastar 3 ou 4 semanas de estudo intensivo para ter uma visão correta de uma plataforma nativa para criar algo realmente bom do que ser preguiçoso inicialmente e gastar meses tentando simular a experiência desejável em uma fábrica de Frankstein’s.

A única exceção ao 3.3.1

Jogos deveriam ser a única exceção. Na minha opinião a Apple deveria colocar mais um parágrafo dizendo que jogos não se aplicam ao 3.3.1.

Todos sabem a complexidade técnica para criar um jogo (eu venho da plataforma Flash antes dessas história de RIA virar moda). Até em Flash, que á pouco tempo não envolvia complexidades como 3D, é muito difícil criar uma engine de física por exemplo.

Agora imagine criar uma engine de verdade como Unreal. Imaginem o custo para isto, vai muito além da maioria dos projetos de software. Uma empresa que investe em algo assim não pode focar em apenas uma plataforma.

E para experiência do usuário eles estão mais que corretos em serem multi-plataforma. Um jogo não deve seguir nenhum padrão como um aplicação de produtividade deve. Cada interface para um game deve ser diferente, os atalhos não devem ser iguais, as janelas são diferentes e etc.

Por isso não faz nenhum sentido aplicar o 3.3.1 em jogos.

A exigência em excelência da Apple

Para quem só usa os produtos da Apple e nunca precisou estudar suas tecnologias a fundo não tem a idéia que a empresa propaga a qualidade extrema em todas ferramentas. Não é apenas criar um produto final bonitinho. Tudo é perfeito, desde a documentação ao criador de interfaces até chegar ao produto final como Mac e iPhone.

A forma como a empresa tem encarado o seu dispositivo móvel (plataforma com limitações de recursos como memória e processamento) tem sido bem interessante. Lançando todas as “features” aos poucos, enquanto a mídia e os “boateiros” bombardeiam o produto dizendo que ele falta isso e aquilo.

No entanto, quando lançam a funcionalidade que “faltava” ela vem de uma forma muito bem feia. Vejam o copiar e colar do iPhone, as pastas e o tão falado “multi-tasking”. Um sinal de preocupação em fazer tudo sempre da forma mais bem feita possível e uma preocupação muito além do que estamos acostumados.

Então, do ponto de vista da empresa, não acredito que banir os Frankstein’s seja apenas uma tentativa de criar um monopólio e vencer a concorrência no braço.

Conclusão

Não tenho certeza se o que a Apple fez é correto do ponto de vista comercial ou de marketing. Mas para o usuário como o meu pai ou minha mãe acredito que seja positivo. Eu me belisco antes de dizer isto (principalmente porque defendo tecnologias opensource como Ruby e Rail), mas também acredito ser positivo para nós como desenvolvedores de apps de produtividade, principalmente se estivermos preocupados em entregar uma experiência fantástica mas coerente.

Se existe um caminho melhor do que definir uma regra dessas eu não sei. Mas não estou nada preocupado pela Apple restringir o restante pois como pretendo desenvolver algo de qualidade para Mac/iPhone já estou focado em Obj-c/Cocoa já tem um bom tempo.

Outros posts interessantes:

• Why Apple Changed Section 3.3.1
• Steve Jobs’ response on Section 3.3.1