9 años de un desarrollador en solitario de un editor de texto de Apple

Artículo original ↗ Discusión en Hacker News ↗

La trayectoria de nueve años de un desarrollador en solitario construyendo un editor de texto minimalista para Mac/iOS en Objective‑C provoca una mirada más amplia a las compensaciones entre el desarrollo nativo para Apple y los stacks web o multiplataforma. Los comentaristas desmenuzan Swift frente a Objective‑C, la madurez de SwiftUI, la compatibilidad con versiones anteriores y la evitación de dependencias, al tiempo que destacan cómo la atención obsesiva a los detalles de la interfaz, los experimentos de precios y el soporte directo dentro de la app pueden hacer viables las pequeñas apps indie de pago en las plataformas de Apple. En conjunto, el hilo contrapone la estabilidad y la artesanía posibles en los frameworks nativos de Apple con el atractivo de iterar más rápido y alcanzar a más usuarios en la web.

Nativo vs Web y estabilidad de la plataforma

  • Varios comentaristas sostienen que el runtime web es extremadamente estable y casi totalmente compatible con versiones anteriores; las viejas apps JS suelen seguir funcionando.
  • En contraste, las plataformas nativas de Apple se perciben como frágiles: las actualizaciones del SO pueden romper apps, Swift carecía de estabilidad ABI al principio, y Apple no retroporta muchas APIs.
  • Otros señalan que el cambio de frameworks es un problema mayor en Windows y la web que en Apple, donde AppKit/UIKit son relativamente estables con el tiempo.

Objective‑C vs Swift y herramientas

  • Hay un debate fuerte sobre la decisión de seguir con Objective‑C.
  • Puntos a favor de ObjC: el código antiguo sigue compilando, tiempos de compilación más rápidos, herramientas/debugger más predecibles, “de bajo nivel y modificable”, bueno para productos de bajo mantenimiento.
  • Puntos a favor de Swift: Swift ha madurado, ofrece mejor seguridad y expresividad, ahora es ABI-estable, y Apple está escribiendo cada vez más frameworks nuevos e incluso partes de Foundation en Swift.
  • Algunos describen una estrategia de migración gradual sin fricciones (añadiendo módulos/tests de Swift a una app ObjC); otros no soportan la compilación lenta de Swift y sus malos mensajes de error.
  • Hay desacuerdo sobre el futuro a largo plazo de ObjC: algunos creen que quedará inevitablemente relegado; otros piensan que seguirá profundamente incrustado en los SO de Apple durante mucho tiempo.

SwiftUI vs UIKit/AppKit

  • Las experiencias con SwiftUI son mixtas o negativas: quejas sobre cambios frecuentes (p. ej., Combine → Observation), mala historia de navegación/estado, bugs en las previsualizaciones y cuellos de botella de rendimiento para listas grandes.
  • Algunos dicen que SwiftUI es genial si te mantienes dentro de su “camino feliz”, y que puedes bajar a UIKit/AppKit para las piezas complejas, incluso incrustando SwiftUI dentro de vistas clásicas.
  • Otros sienten que SwiftUI todavía está muy por detrás de UIKit/AppKit para apps serias.

Detalles de UX y animación del cursor

  • La suave animación del cursor divide opiniones: a algunos les parece deliciosamente “mantecosa”, otros la encuentran distraída o imprecisa comparada con saltos discretos.
  • Muchos enfatizan que los toques sutiles y descubribles (“fringes”) crean apego, confianza y una sensación de artesanía, especialmente en editores de texto.

Modelo de negocio y distribución

  • La ventana emergente temprana de “funciones Pro” y el aviso de permisos de notificaciones se consideran demasiado agresivos; el desarrollador planea retrasarlos.
  • Los usuarios valoran la opción única “de por vida” y piden un modo básico sin nagging.
  • Un hilo importante trata sobre compras corporativas: las compras dentro de la app no funcionan con MDM/Apple Business Manager, así que las empresas necesitan un SKU de pago, sin IAP.
  • Tras la discusión, el desarrollador crea una versión separada, no listada, de pago “para empresas” en el App Store para soportar esto.

Sitio web, SEO y marketing

  • La larga página de texto técnico recibe elogios por su diseño y claridad; está hecha a mano con Tailwind y visuales personalizados.
  • El scrollbar personalizado ultrafino es criticado ampliamente por ser inutilizable; el desarrollador lo ensancha iterativamente y hace que se expanda al pasar el cursor.
  • El blog del sitio orientado al SEO (listicles como “Best writing apps…”) desagrada a algunos lectores; otros señalan que es una forma pragmática de conseguir usuarios. Se sugieren separar los artículos “reales” en un RSS distinto.

Economía indie, elección de plataforma y dependencias

  • Muchos celebran el pulido de la app, su rendimiento y su enfoque de cero dependencias de terceros, atribuyéndolo a la profundidad de AppKit/UIKit.
  • Varios argumentan que los usuarios de Apple siguen estando relativamente dispuestos a pagar por apps indie de calidad, a diferencia de los usuarios típicos de Windows/Linux.
  • La app actualmente gana bastante menos que un salario europeo a tiempo completo, así que sigue siendo un proyecto secundario, pero los ingresos están creciendo.
  • Se debate el encierro vs alcance: algunos prefieren centrarse en una sola plataforma para obtener mayor calidad y menos problemas; otros defienden stacks multiplataforma (Flutter, React Native, Qt, Delphi, etc.) para llegar a mercados más grandes a costa de “sensación nativa” y funciones.