Os desenvolvedores das plataformas da Apple há muito tempo caminham no fio da navalha, equilibrando seu desejo de implementar recursos poderosos com a necessidade de garantir que essas ideias se enquadrem nos requisitos prescritos pela Apple limites.
Infelizmente, esses limites muitas vezes parecem ser alvos em movimento. Para dar um exemplo, a Smile Software anunciou recentemente que a Apple considerou recursos do popular TextExpander da Smile além do pálido e que, com isso, a Smile teria que revisar o aplicativo.
O papel da Apple como guardiã atraiu elogios ardentes e provocou fortes críticas. Embora o iOS tenha se tornado uma plataforma incrivelmente bem-sucedida, onde centenas de milhões de usuários devoram aplicativo após aplicativo em um ritmo inigualável pelos rivais do sistema operacional, surgiram problemas ao longo do caminho.
E à medida que o iOS continua a amadurecer, o controle firme da Apple em seu ecossistema móvel está começando a dificultar a evolução e o crescimento dos desenvolvedores que contribuíram significativamente para o sucesso da plataforma.
Jardim curado ou prisão bem cuidada?
Para os desenvolvedores, viver na gaiola dourada da Apple significa ter que lidar com uma longa lista de regras. Inicialmente, quando o pessoal de Cupertino encontrou seu equilíbrio, as restrições não eram em grande parte escritas, mas desde então foram codificado e disponibilizado para membros registrados da Apple's Developer Connection. A empresa até criou um “conselho de apelações” para ouvir casos especiais trazidos a ele por desenvolvedores cujos aplicativos caíram nas inevitáveis falhas das regras.
Na maioria das vezes, as regras funcionaram bem. A Apple quer que o iOS seja um jardim bem organizado nos arredores do Velho Oeste da Internet, e isso significou excluir alguns softwares ao longo do caminho. Para alguns tipos de aplicativos, a decisão é relativamente indolor: obviamente, ninguém quer que a App Store hospede software malicioso que tira vantagem dos usuários.
No entanto, para outros aplicativos - software que a maioria dos usuários gostaria de ter em seus telefones e tablets - a violação das regras da Apple pode ser um problema sério. No passado, a empresa ocasionalmente alterava seu livro de regras para acomodar necessidades inesperadas, mas esse processo desacelerou consideravelmente nos últimos dois anos. Ao mesmo tempo, o iOS deixou de ser uma plataforma projetada para ser usada em conjunto com desktops e laptops para ser uma plataforma que geralmente funciona sozinha.
Quando as regras vão mal
Veja o caso mencionado do TextExpander da Smile Software - um aplicativo que pode parecer inconsequente até começar a usá-lo e perceber quanto tempo improdutivo ele pode tirar do seu dia a dia rotina. TextExpander permite definir e recuperar rapidamente partes arbitrárias de texto, independentemente de sua complexidade.
No OS X, o TextExpander pode interagir com praticamente qualquer aplicativo. No iOS, o sandbox da Apple torna isso muito mais difícil, mas no passado os desenvolvedores do Smile contornaram o problema implementando um kit de desenvolvimento de software que outros programadores possam integrar fácil e rapidamente em seus próprios Programas.
Infelizmente, isso deixa um problema sem solução: aplicativos de terceiros ainda precisam sincronizar seu banco de dados de trecho de texto com o aplicativo TextExpander principal, que é difícil de realizar em um ambiente onde os programas são amplamente impedidos de conversar uns com os outros - ou mesmo de estarem cientes da presença uns dos outros no dispositivo.
Assim, o Smile teve que encontrar outra solução alternativa, que envolvia confiar nos lembretes integrados do iOS como um mecanismo de sincronização substituto. Depois de inicialmente permitir esse uso, a Apple acabou rejeitando-o como uma aplicação imprópria de uma tecnologia cujo objetivo principal é, afinal, ajudá-lo a compilar listas de compras.
Soluções alternativas não são soluções
Para ser justo, a Smile poderia adotar alternativas à maneira como fazia as coisas. Uma opção seria desenvolver um sistema baseado na Web que permitisse a sincronização pela Internet, evitando assim soluções alternativas estranhas que exigem colocar seu software à mercê da aprovação da Apple processo.
Por outro lado, tal revisão está longe de ser trivial, mesmo para uma empresa bem estabelecida como a Smile: a sincronização da Web é notoriamente difícil de implementar, leva a todos os tipos de complicações de privacidade e (é claro) só funciona se você estiver conectado ao Internet.
Em última análise, o maior problema com as regras da Aple, como a que foi contra o TextExpander, é que elas prejudicam os clientes. A Smile não é uma empresa desonesta tentando introduzir software malicioso na App Store; está legitimamente tentando tornar os usuários mais produtivos, oferecendo a eles um produto que eles gostam de usar e pagar.
De maneira mais geral, a incapacidade dos aplicativos iOS de funcionar em conjunto está se tornando cada vez mais problemática. As políticas da loja da Apple favorecem aplicativos baratos e altamente especializados; se você já passou algum tempo trabalhando com um shell Unix, sabe que esse modelo pode funcionar muito bem - se os aplicativos puderem facilmente canalizar conteúdo entre si. Sem essa habilidade, porém, você fica com situações como a aqueles que afetam o iWork, onde a fixação da Apple em simplificar tudo deixa os usuários coçando a cabeça.
Problemas de compra no aplicativo
Essa questão é apenas a ponta do iceberg. Em muitas outras áreas, o controle da Apple sobre seu ecossistema corre o risco de prejudicar seus usuários muito mais do que garantir a proteção de seus interesses. Considere as compras no aplicativo (IAPs), por exemplo, onde a Apple deseja ser o processador de pagamento preferido na App Store, exceto na verdade.
Os IAPs se tornaram um poço de regras e exceções. Os desenvolvedores podem usá-los para cobrar dos clientes, mas apenas para itens virtuais; as organizações não podem usar IAPs para coletar doações; e - como o criador do Instapaper, Marco Arment descoberto no ano passado—as empresas não podem usá-los para gerenciar assinaturas recorrentes, a menos que a empresa realmente publique a revista ou boletim informativo em questão. Além disso, a Apple não permitirá que os desenvolvedores usem seus próprios sistemas de pagamento, exceto em conexão com produtos físicos.
Essa abordagem pode ser apenas um incômodo quando faz parte da luta contínua de Cupertino com outros gigantes da tecnologia como Amazon e Google. Mas torna-se um grande problema quando limita o que os usuários podem fazer com seus dispositivos, como no caso de um sistema de notificação sensível ao tempo que para de funcionar porque os usuários se esqueceram de renovar suas assinaturas manualmente.
Hora de alguma mudança
Não estou sugerindo que a Apple elimine suas regras da App Store e dê as boas-vindas aos aplicativos à toa no ecossistema iOS. Além de ser uma proposta muito improvável, não parece desejável. Gosto da App Store e gosto do fato de haver uma barreira para entrar nela.
Por outro lado, acho que é hora da Apple descobrir como aliviar alguns dos pontos problemáticos mais urgentes que os desenvolvedores continuam encontrando. Como usuário, fico muito mais feliz se os desenvolvedores puderem se concentrar na criação de recursos melhores, em vez de ter que reinventar a roda para recursos como sincronização e comunicação entre aplicativos. E, como desenvolvedor, prefiro não perder meu tempo com coisas como criar meu próprio gerenciamento de usuários ou pagamento sistema, ou ser forçado a oferecer uma experiência inferior aos meus usuários por causa das políticas inconstantes que a Apple decide aplicar.
Esse problema está se tornando mais significativo porque o iOS está se tornando mais importante para seus usuários – e eles, por sua vez, estão desenvolvendo necessidades e demandas mais sofisticadas. A decisão da Apple de publicar seu livro de regras foi um grande passo para aumentar a transparência; agora é hora de tomar medidas adicionais para beneficiar os usuários que desejam depender do iOS como ambiente de trabalho principal.