O desenvolvedor que criou sozinho um editor de texto da Apple por 9 anos

9 anos de um desenvolvedor solo do editor de texto "Paper"

• Em 2015, ele era um desenvolvedor web full-stack comum e estava longe do ecossistema de desenvolvimento da Apple.
• Ao usar um Mac, passou a se interessar pelos apps de desenvolvedores independentes e, inspirado pelo iA Writer, um editor de Markdown simples e elegante, decidiu criar um app parecido.
• Para desenvolver um editor de texto nativo para Mac, começou a aprender uma nova stack tecnológica, incluindo Xcode, AppKit e Objective-C.
• Definiu o nome do app como Paper e, perseguindo um minimalismo extremo, desenhou o editor como um simples retângulo.
• Em 2017, lançou o app para Mac na Mac App Store e, em 2019, lançou a versão para iOS.

Por que escolheu um app nativo

• Ele escolheu um app nativo em vez de um app em Electron porque seu objetivo era oferecer a melhor experiência possível ao usuário.
• Apps nativos são leves e rápidos, além de oferecerem mais maneiras de implementar recursos únicos relacionados a texto.

Por que escolheu Objective-C

• Em 2015, quando o Swift ainda estava no início, ele compilou um projeto vazio do Xcode em Objective-C e outro em Swift, comparando os pacotes .app.
• O app em Swift tinha cerca de 5 MB por incluir o runtime do Swift, enquanto o app em Objective-C era muito leve, com algo em torno de 100 KB.
• Como queria um app distribuível mais leve, escolheu Objective-C.

Dependências de terceiros

• O Paper não tem dependências de terceiros.
• Ele construiu tudo por conta própria, garantindo uma pequena vantagem sobre os concorrentes.
• Por exemplo, o mecanismo de parsing de Markdown do Paper é personalizado e suporta menos sintaxe Markdown do que editores tradicionais.

Visão

• A visão inicial do Paper era ter os recursos centrais do iA Writer, mas em um pacote ainda mais elegante e minimalista.
• O foco era aumentar a concentração minimizando elementos que distraem o usuário.
• Com o tempo, o Paper encontrou seu espaço no mercado ao manter o minimalismo enquanto adicionava recursos gradualmente.

Arquitetura

• O código do Paper é composto por dois escopos: escopo da aplicação e escopo do documento.
• Para cada escopo, ele definiu um storyboard para descrever views e widgets e conectar os módulos dentro do escopo.
• Os módulos são classes em Objective-C responsáveis por partes das funcionalidades do app, agrupando a lógica em um único lugar relacionado a cada recurso específico.

Código multiplataforma

• AppKit e UIKit são parecidos, mas também diferem em muitos aspectos.
• Para lidar com essas diferenças, ele usou recursos de macros e categories do Objective-C.

Depuração

• No caso dos frameworks da Apple, é preciso ler a documentação em vez do código e usar breakpoints para analisar stack traces compiladas.

Recursos pagos

• Entre 2015 e 2017, assinaturas ainda não eram amplamente difundidas, e pagamentos únicos eram comuns nas app stores.
• Como queria oferecer recursos pagos de forma amigável ao usuário, disponibilizou como pagos apenas upgrades cosméticos, e não funcionais.

Precificação

• No começo, ele adotou um pagamento único de US$ 5 para cada um dos dois conjuntos de recursos Pro.
• Atualmente, o preço é um conjunto único por US$ 10 por mês ou US$ 100 vitalícios.
• Por meio de experimentos de preço, descobriu que usuários estão dispostos a pagar até US$ 100 por um app de um desenvolvedor ainda desconhecido.

Partes complicadas

• Editores de texto são complexos, e cada atualização do sistema operacional adiciona novas formas de inserção, atualização e interação com texto.

Gimmicks

• Ele adicionou recursos divertidos, como o bounce ao redimensionar a janela, inspirado no app Things.

Opinião do GN⁺:

1. Abordagem inovadora: É impressionante que o desenvolvedor tenha criado o Paper priorizando a experiência do usuário, mesmo sem experiência anterior em desenvolvimento de apps nativos. Isso mostra o quanto o design centrado no usuário é importante no desenvolvimento de software.
2. Aprendizado e crescimento: O processo de aprender uma nova stack tecnológica e, com ela, construir um produto pode inspirar até engenheiros de software iniciantes. Isso reforça que aprendizado contínuo e disposição para desafios são essenciais para crescer como desenvolvedor.
3. Importância da experiência do usuário: Um dos fatores de sucesso do Paper foi a atenção cuidadosa à experiência do usuário e o foco no minimalismo. Isso mostra como é importante entender o que os usuários realmente querem e refletir isso no produto.

[woung717]

A maioria dos documentos de desenvolvimento da Apple não é muito amigável, então é preciso vasculhar bem a documentação... e, quando ainda faltam informações, muitas vezes a situação acaba sendo ter que fuçar as interfaces do SDK... nesse sentido, é algo que inspira respeito.

[ndrgrd]

Eu fiquei me perguntando o que seria um upgrade "cosmético", mas no original está visual changes. Usa-se mesmo a palavra "cosmético" nesse sentido? Foi a primeira vez que vi isso.

[geeker]

Como o neo é um bot de IA, acho que acabou saindo uma tradução mecânica kkk

[apkas]

O original parece ser um cosmetic upgrade.

[cosine20]

Então algo como uma melhoria estética parece mais interessante...

[ragingwind]

Parece ser um desenvolvedor que serve como modelo.

[GN⁺]

Opiniões do Hacker News

• "Os detalhes cuidadosos nas bordas é que parecem mágica"

  • Os usuários podem não perceber os detalhes minuciosos do app no começo, mas acabam descobrindo essas coisas com o tempo.
  • Esses recursos extras feitos com cuidado fazem o usuário passar de simplesmente gostar do app para amá-lo.
  • Isso transmite a sensação de que o desenvolvedor entende os usuários e de que o produto é bem cuidado.
  • Cita o app Procreate como exemplo, elogiando o fato de a interface do usuário (UI) ser simples, mas ainda assim cheia de recursos ocultos que podem ser descobertos.

• "Um ótimo texto baseado em 15 anos de experiência como desenvolvedor de apps iOS"

  • Menciona que foi uma boa decisão insistir no desenvolvimento nativo, evitar dependências de terceiros e usar Objective-C.
  • Mudou para Swift, mas às vezes sente falta das vantagens do Objective-C.
  • Diz que baixou e testou o app, e gostou das pequenas pistas na barra de menu.

• "A possibilidade de desenvolvimento com poucas ou nenhuma dependência nas plataformas Apple"

  • Graças à riqueza e profundidade de AppKit/UIKit, é viável criar apps polidos sem elementos de terceiros.
  • Comenta que, mesmo em comparação com outros frameworks, como Qt, os frameworks da Apple seguem competitivos.

• "A evolução do Swift e especulações sobre componentes embutidos na plataforma ou otimizações binárias"

  • Desde o Swift 5, houve estabilização da ABI (Application Binary Interface).
  • Afirma que a decisão de usar apenas Swift desde 2014 está funcionando bem.
  • Sobre SwiftUI, acha que ainda há muito a evoluir antes de substituir UIKit/AppKit.

• "Desconfiança na escolha de dependências e a importância do aprendizado"

  • Expressa resistência a adicionar pacotes e bibliotecas externas antes mesmo de escrever o código.
  • Elogia a abordagem do autor de transformar as desvantagens do ecossistema Apple em uma experiência positiva de aprendizado.

• "Pedido de materiais de estudo e recomendações sobre AppKit e desenvolvimento para Mac"

  • Menciona que está tendo dificuldade para encontrar informações sobre desenvolvimento para Mac.
  • Explica que a documentação mais recente da Apple é insuficiente e que a documentação antiga também não foi atualizada para Swift, o que o deixa dependente do autocompletar do Xcode.

• "Respeito pela atenção aos detalhes e pelo espírito artesanal"

  • Elogia muito a atenção minuciosa e o capricho do autor, dizendo que o texto é bonito e inspirador.

• "Uma menção curiosa ao gesto de girar para desfazer"

  • Comenta que o gesto lembra as cenas do protagonista de "Doutor Estranho" voltando e avançando o tempo.

• "Elogios ao minimalismo do blog e do app"

  • Expressa a alegria que sente ao usar o app que criou, e diz que sente algo parecido ao usar vim-motions ou Neovim.

• "Surpresa com a falta de acesso ao código do SDK no ecossistema de desenvolvimento Apple"

  • Demonstra estranheza com o fato de ser necessário olhar diretamente para código assembly e pede confirmação sobre isso.