9 anos de desenvolvimento solo de um editor de texto da Apple

Artigo original ↗ Discussão no Hacker News ↗

A jornada de nove anos de um desenvolvedor solo construindo um editor de texto minimalista para Mac/iOS em Objective‑C provoca uma análise mais ampla sobre as compensações entre o desenvolvimento nativo da Apple e stacks web ou multiplataforma. Comentadores dissecam Swift vs Objective‑C, a maturidade do SwiftUI, compatibilidade retroativa e a aversão a dependências, ao mesmo tempo em que destacam como a atenção obsessiva a detalhes de UI, experimentos de precificação e suporte direto no app podem tornar viáveis pequenos apps indie pagos nas plataformas da Apple. No geral, o fio contrasta a estabilidade e o artesanato possíveis nos frameworks nativos da Apple com o apelo de iteração mais rápida e maior alcance na web.

Nativo vs Web e Estabilidade da Plataforma

  • Vários კომენტadores argumentam que o runtime da web é extremamente estável e quase totalmente compatível com versões anteriores; apps JS antigas normalmente continuam funcionando.
  • Em contraste, plataformas nativas da Apple são vistas como frágeis: atualizações do sistema operacional podem quebrar apps, o Swift não tinha estabilidade de ABI no início, e a Apple não faz backport de muitas APIs.
  • Outros observam que a troca de frameworks é um problema maior no Windows e na web do que na Apple, onde AppKit/UIKit são relativamente estáveis ao longo do tempo.

Objective‑C vs Swift e Ferramentas

  • Há um debate forte sobre a decisão de permanecer com Objective‑C.
  • Pontos pró-ObjC: código antigo ainda compila, tempos de compilação mais rápidos, ferramentas/debugger mais previsíveis, “baixo nível e hackeável”, bom para produtos de baixa manutenção.
  • Pontos pró-Swift: o Swift amadureceu, oferece mais segurança e expressividade, agora tem estabilidade de ABI, e a Apple está cada vez mais escrevendo novos frameworks e até partes do Foundation em Swift.
  • Alguns descrevem uma estratégia suave de migração gradual (adicionando módulos/testes em Swift a um app ObjC); outros não gostam da compilação lenta do Swift e de suas mensagens de erro ruins.
  • Há divergência sobre o futuro de longo prazo do ObjC: alguns o veem inevitavelmente marginalizado; outros acreditam que ele continuará profundamente embutido nos sistemas operacionais da Apple por muito tempo.

SwiftUI vs UIKit/AppKit

  • As experiências com SwiftUI são mistas a negativas: reclamações sobre mudanças frequentes (por exemplo, Combine → Observation), história ruim de navegação/estado, bugs nas previews e gargalos de desempenho em listas grandes.
  • Alguns dizem que SwiftUI é ótimo se você ficar no seu “happy path”, e que dá para descer para UIKit/AppKit em partes complexas, inclusive incorporando SwiftUI dentro de views clássicas.
  • Outros acham que o SwiftUI ainda fica muito atrás de UIKit/AppKit para apps sérios.

Detalhes de UX e Animação do Cursor

  • A animação suave do cursor é polarizadora: alguns a acham deliciosamente “buttery”, outros a consideram distrativa ou imprecisa em comparação com saltos discretos.
  • Muitos enfatizam que toques sutis e descobríveis (“fringes”) criam apego, confiança e uma sensação de capricho, especialmente em editores de texto.

Modelo de Negócio e Distribuição

  • O pop-up inicial de “Pro features” e o pedido de permissão de notificações são vistos amplamente como agressivos demais; o desenvolvedor planeja adiá-los.
  • Usuários apreciam a opção única “lifetime” e pedem um modo básico sem incômodos.
  • Um grande fio cobre compras corporativas: compras dentro do app não funcionam com MDM/Apple Business Manager, então empresas precisam de um SKU pago, sem IAP.
  • Após a discussão, o desenvolvedor cria uma versão separada, não listada, paga, “for business” na App Store para dar suporte a isso.

Site, SEO e Marketing

  • A longa página técnica é elogiada pelo design e clareza; ela foi feita manualmente com Tailwind e visuais customizados.
  • A barra de rolagem customizada ultrafina é amplamente criticada por ser inutilizável; o desenvolvedor a torna iterativamente mais larga e faz com que ela expanda ao passar o mouse.
  • O blog do site, orientado a SEO (listas como “Melhores apps de escrita…”), afasta alguns leitores; outros observam que é uma forma pragmática de conquistar usuários. São feitas sugestões para separar os artigos “reais” em um feed RSS distinto.

Economia Indie, Escolha de Plataforma e Dependências

  • Muitos celebram o polimento, o desempenho e a abordagem sem dependências de terceiros do app, atribuindo isso à profundidade de AppKit/UIKit.
  • Vários argumentam que os usuários da Apple ainda estão relativamente dispostos a pagar por apps indie de qualidade, ao contrário dos usuários típicos de Windows/Linux.
  • O app atualmente rende significativamente menos do que um salário europeu de tempo integral, então continua sendo um projeto paralelo, mas a receita está crescendo.
  • A discussão sobre lock-in vs alcance é intensa: alguns preferem focar em uma única plataforma para obter mais qualidade e menos dores de cabeça; outros defendem stacks multiplataforma (Flutter, React Native, Qt, Delphi, etc.) para alcançar mercados maiores, ao custo de “sensação nativa” e recursos.