Nove anos de experiência desenvolvendo um editor de texto para MacOS e iOS

O desenvolvedor Mihhail escreveu um artigo compartilhando como foi a experiência dele nos últimos 9 anos como desenvolvedor solo de um editor de texto para o MacOS e iOS.

Em 2015, ele era um desenvolvedor web full-stack, e decidiu desenvolver um editor nativo para MacOS. Isso significa que precisou aprender Xcode, AppKit, Objective-C, e nada tinha uso para o trabalho diário dele. Era uma stack totalmente diferente. O objetivo era criar algo bem simples e minimalista, e o resultado é esse:

Uma folha de papel.

O aplicativo foi lançado na Mac App Store em 2017 e a versão para iOS foi criada em 2019.

Por que nativo?

O objetivo dele era entregar a melhor experiência possível. Estava tentando competir com aplicativos de escrita altamente sofisticados, então, para começar, precisaria de algo leve e rápido. Além disso, existem mais maneiras de mexer com o aplicativo no nível nativo, para torná-lo único (especialmente quando se trata de texto). Não estava tentando atingir o número máximo de usuários nem diminuir o tempo de desenvolvimento e tinha todo o tempo do mundo.

Por que Objective-C?

Em 2015, o Swift estava apenas começando. O autor compilou um projeto Xcode vazio em Objective-C e outro em Swift e depois examinou os respectivos pacotes .app. O app Swift tinha todo o runtime do Swift incorporado – cerca de 5 MB, enquanto que o Objective-C era superleve – com dezenas ou talvez 100 KB no total. Isso foi o suficiente para convencê-lo a escolher o Objective-C.

O autor ressalta que, se você realizar esta experiência hoje, a diferença não será tão grande.

Dependências de terceiros

O aplicativo não tem nenhuma dependência de terceiros.

Isso significa que o autor consegue codificar apenas o que precisa para fornecer a experiência que deseja. Por exemplo, o parser de Markdown no Paper é personalizado porque o Paper suporta menos sintaxe Markdown do que o editor Markdown tradicional e completo. Além disso, pode realizar o parse com o nível certo de granularidade de metadados, o que torna a implementação de recursos como destaque e transformações de texto mais simples e eficientes.

Ele seguiu o mesmo caminho com a exportação .docx, passando várias semanas descompactando arquivos .docx gerados pelo Pages e Word, investigando os arquivos .xml contidos neles e, em seguida, escrevendo um conversor simples de Markdown para .docx. Acontece que o formato .docx é bastante simples, e agora ele tem o conhecimento e um módulo minúsculo e de fácil suporte que faz exatamente o que precisa.

Ele usou elementos nativos do AppKit e UIKit porque são atualizados automaticamente pela Apple, ajustáveis a várias características, compatíveis com versões anteriores e com garantia de funcionamento em todos os dispositivos. Além disso, os usuários já estariam acostumados com esses elementos da UI.

Caso nenhum componente de UI integrado seja adequado para implementar o recurso desejado, simplesmente não adiciono o recurso.

Funcionalidades pagas

Em 2015–17, as assinaturas ainda não eram algo generalizado na App Store. Pagar para baixar era (e é) comum, mas o autor não achou que alguém pagaria por um aplicativo desconhecido sem experimentá-lo, então o pagamento único freemium parecia a única opção. Ao mesmo tempo, ele não queria apenas criar uma barreira paga para os recursos ou implementar um período de testes (apenas as assinaturas tem essa funcionalidade integradas na App Store).

A solução foi oferecer apenas atualizações cosméticas como parte da oferta Pro – mudanças visuais em vez de recursos funcionais.

Essas mudanças cosméticas seriam testáveis por um período de tempo ilimitado. Os usuários poderiam testar os recursos para ver sua aparência e funcionamento e, em seguida, comprar a oferta Pro se achassem que os recursos valiam a pena.

É claro que era necessária uma medida que impedisse as pessoas de usar os recursos indefinidamente sem pagar. No início, era um cronômetro de 60 segundos que os incomodaria a comprar se pelo menos um dos recursos do Pro estivesse ativo. Isso provou ser muito chato, então ele mudou para considerar a quantidade de caracteres escritos.

Fazia mais sentido - tente tudo pelo tempo que quiser, sem distrações, mas assim que começar a usar o Paper para escrever, a cada algumas centenas de caracteres, você verá um pop-up.

O autor considera que isso funcionou porque, ao contrário dos recursos funcionais cujo valor está vinculado a uma ação momentânea específica, as atualizações cosméticas melhoram constantemente sua experiência de escrita. Você não pode colocar um recurso funcional por trás da mesma tentativa sem atrito descrita acima, pois o valor do recurso é totalmente realizado no momento em que a ação é executada. Por outro lado, permitir que os utilizadores apliquem alterações cosméticas acompanhadas por um mecanismo irritante dá uma amostra da experiência de escrita melhorada, mas limita o valor prolongado desta melhoria. Forçar a compra, mas sem limitar a capacidade de explorar tudo em seus termos antes de gastar o dinheiro.

Eu achei uma técnica bem interessante.

Precificação

O Paper começou com 2 pagamentos únicos de US$ 5 cada para 2 conjuntos de recursos Pro. Hoje, depois de muitas experiências, custa US$ 3 a 30 por mês ou US$ 50 a 200 vitalícios para um único conjunto (os preços variam de acordo com o poder de compra da região).

Primeiro, antes de mergulhar no mundo das assinaturas, ele experimentou pagamentos únicos. Começou a dobrar gradativamente o preço e observar se o valor total ganho aumentaria ou diminuiria. O tráfego da App Store dele era bastante estável, então sempre havia gente nova entrando pela porta que não sabia nada sobre os preços anteriores. Foi quando descobriu que as pessoas estavam dispostas a pagar até US$ 100 por um aplicativo de um desenvolvedor desconhecido. Tentou subir para US$200. Recebeu uma ou duas vendas e algumas reclamações ao longo de vários meses, então imaginou que US$ 200 era provavelmente o problema.

Depois de muita hesitação, decidiu apresentar as assinaturas. Elas funcionaram e hoje o Paper tem uma combinação saudável de pagamentos mensais, anuais e vitalícios, sendo as assinaturas a opção de pagamento padrão e promovida.

Ele ainda faz experiências com preços. Recentemente (quando escreveu o artigo) dobrou o preço mensal para novos assinantes em alguns países, mantendo o preço anual inalterado. Isto foi para incentivar a opção anual e reduzir a rotatividade de usuários pagantes (churn). Os resultados preliminares mostram que as pessoas continuam assinando, embora em menor número. Ainda assim, esta poderia ser uma mudança positiva tendo em conta o preço mensal mais elevado e as atualizações anuais, mas é preciso esperar para ver.

Outro teste que ele estava fazendo em países com renda mais baixa é para ver se a redução do preço tem algum efeito ou se as pessoas nesses países simplesmente não pagam pelo software (ou editores de texto), não importa o que aconteça.

Mais detalhes

No artigo o autor também fala sobre uma visão de negócio do Paper, a arquitetura do projeto em detalhes, código multiplataforma, depurações, o quão difícil é trabalhar com texto, detalhes que ele implementou, como coletava feedbacks e o lançamentos de novas versões. Também escreveu uma parte 2 e parte 3 com mais detalhes de implementação.