Escribir código para la web

• Apple ofrece a sus clientes dispositivos seguros y con poca carga de administración, pero se llega a la conclusión empírica de que no crea el mismo nivel de interdependencia con los desarrolladores individuales
• El bug del modo oscuro/claro en la Búsqueda de Google se usa como ejemplo de que una molestia que no afecta los ingresos puede quedar abandonada durante mucho tiempo, más que como una falta de capacidad técnica
• El valor central de Apple está más en computadoras y dispositivos que los usuarios pueden usar sin gestión adicional que en el ecosistema de apps, y se considera que habría razones para comprar un iPhone o un iPad incluso sin apps
• La API de Apple Music esperada en 2016, ocho años después, todavía tiene bugs y restricciones de acceso, y hasta para una simple prueba requiere una cuenta de desarrollador de 100 dólares al año
• La plataforma web, que no pertenece a una sola empresa, es imperfecta y frágil, pero sigue siendo una opción realista para desarrolladores que quieren estar menos atados a la estructura de suma cero de una compañía específica

---

Apple es fuerte para sus clientes, pero no depende de los desarrolladores

• La idea central es que Apple claramente aporta valor a las personas que son sus clientes, pero tiene pocos motivos estructurales para preocuparse de la misma manera por los desarrolladores individuales
• La relación de dependencia fluye como Developer -> Apple, Apple -> Consumer, y se considera que casi no existe una dependencia inversa que vaya de Apple hacia los desarrolladores individuales
• Incluso si todos los desarrolladores dejaran de crear para las plataformas de Apple, Apple en general podría sobrevivir, porque su propuesta de valor central no depende de desarrolladores individuales
• La colaboración con “socios” desarrolladores empresariales puede ser necesaria, pero es un tema distinto de la dependencia respecto de desarrolladores individuales
• Algunas multinacionales ponen a los desarrolladores en el centro de su estrategia, pero se considera que Apple no es de ese tipo
• Después de aceptar esta distinción, resulta posible separar el gusto por los productos de Apple del deseo de desarrollar para Apple

El caso de Google: los bugs que no afectan los ingresos pueden durar mucho tiempo

• La Búsqueda de Google tiene un problema en entornos donde el sistema cambia dinámicamente entre modo claro y oscuro: la primera página de resultados aparece con el tema opuesto
  • De noche, cuando todo el sistema está oscuro, la primera página de resultados aparece clara y lastima la vista
  • Por la mañana, después de que la laptop vuelve al modo claro, los resultados de búsqueda aparecen con un fondo negro difícil de leer
• Este bug lleva años existiendo, y se considera poco probable que se corrija salvo que quede arreglado por casualidad durante una gran renovación
• La causa no se interpreta como que Google no tenga capacidad para arreglarlo, sino que no afecta los ingresos
• Quienes usan buscadores alternativos como DDG ya se fueron, y la enorme mayoría sigue atada a Google
• DDG se presenta como una opción favorable a la privacidad, pero la razón real de uso está en una UX simple que recuerda al Google inicial, resultados de búsqueda exacta de buena calidad y publicidad que no estorba
• Google no trata a los usuarios como un objetivo de teoría de juegos, y las interacciones hostiles hacia el usuario que aparecen cuando hay que usar productos de Google se aceptan como resultado de esa estructura

El valor central de Apple: computadoras seguras y sin carga de administración

• Alrededor de 2009, al elegir una computadora familiar, se juzgó que Windows era demasiado débil en seguridad en ese momento y que Linux requería soporte técnico constante
• Al final se preparó una computadora con OpenBSD, Firefox y juegos básicos, pero a cambio de seguridad, privacidad y baja carga de soporte, la usabilidad quedó muy limitada
• Después de usar una Mac de trabajo en una empresa de apps para iOS, se llegó a la conclusión: “esta era la computadora que quería para mi mamá”
• Se ahorró dinero para comprar una MacBook y, con el tiempo, el factor de forma usado por la familia pasó de la laptop al iPad, pero el mismo valor central se siguió cumpliendo
• Se considera que, incluso sin apps, un iPhone podría ser una compra posible para uno mismo y casi segura para la familia
• En el modelo de negocio de Apple, los desarrolladores no son un elemento indispensable; está bien que sean felices, pero no es una estructura que exija que lo sean
• Dentro de Apple hay personas que se preocupan por los desarrolladores e intentan mejorar las cosas, pero las acciones de la compañía en su conjunto pueden no ser consistentes

Expectativas y frustración con la API de Apple Music

• Alrededor de 2016, cuando se anunció la API de Apple Music en la WWDC, hubo grandes expectativas, pero en la práctica no ocurrió algo que “lo cambiara todo”
• El reproductor de música propio de Apple todavía se siente difícil de usar, y se considera que los reproductores alternativos probados suelen seguir un enfoque al estilo Spotify
• Se esperaba poder recrear una experiencia de reproductor musical personal como en la época de Justin Frankel de Winamp: rápida, fluida e interminable
• Con el catálogo musical de Apple, se pensaba que sería posible reproducir esa experiencia sin depender de la piratería como antes
• Cuando hubo tiempo libre, se creó un reproductor de música llamado Flowers y también se intentó escribir un tutorial para que otras personas pudieran crear sus propios reproductores
• Durante la implementación, ocho años después, se concluyó que la API sigue teniendo bugs y no es pública
  • Solo para probar la API hay que pagarle a Apple 100 dólares al año
  • El costo no es una tarifa por uso masivo, sino que también se exige para un simple acceso de prueba
  • Incluso usando una cuenta de desarrollador paga, solo se recibe una API limitada
• Si se escribe MusicKit.getInstance().developerToken en la consola del navegador del reproductor web de música de Apple, se puede obtener gratis un token raíz sin restricciones, por lo que el procedimiento para desarrolladores se considera poco razonable

La web es una plataforma compartida sin un único dueño

• La conclusión apunta a escribir código que se ejecute en la web
• La web es una plataforma compartida que no pertenece a una sola entidad, y se diferencia de las plataformas de empresas específicas en que incluso la buena voluntad puede arruinarse por incompetencia
• La plataforma web está en una situación frágil por los siguientes factores
  • Gobiernos que intervienen en exceso
  • Una estructura dominada por dos grandes navegadores
  • Un ecosistema de desarrolladores complejo
• No hay garantía de que la web siga prosperando, pero ha sobrevivido hasta ahora, y cuanto más tiempo sobreviva, mayor será la probabilidad de que siga prosperando
• Se dice que el código de workaround relacionado con la web que hubo que escribir recientemente se debió a un comportamiento peculiar de Safari
• Al mismo tiempo, Google está haciendo grandes cosas por la web, por lo que en este contexto se evalúa que cumple un buen papel

La relación con las empresas no se divide fácilmente en bien y mal fijos

• Así como no es útil clasificar a las personas de forma fija entre buenas y malas, también es difícil clasificar permanentemente a las empresas como buenas o malas
• Las empresas comparten atributos similares a las personas: inteligencia, personalidad, nacimiento, crecimiento y desaparición, y personalidad jurídica
• Así como no se puede vivir sin personas, tampoco se puede vivir sin empresas; aunque tengan rasgos inhumanos, la forma fractal de las organizaciones humanas seguirá existiendo
• Si no se encasilla a las empresas en categorías fijas de bien y mal, se puede relacionarse con ellas de manera más fluida
  • Cuando una empresa empuja a un juego de suma cero, se reduce la dependencia
  • Cuando permite una relación más simbiótica, se vuelve a participar
• Steve Jobs dijo en 1996 que las grandes, medianas y pequeñas empresas empezaban a ver la web como la red definitiva de distribución directa al cliente, una vía que evita intermediarios y va directamente del proveedor al consumidor

[GN⁺]

Opiniones en Hacker News

• Al principio decidí no aprender desarrollo móvil nativo y concentré todo mi tiempo limitado en la web; esta vez creo que fue la decisión correcta.
  Hoy se pueden crear cosas increíbles en el navegador y, en mi opinión muy personal, salvo Uber, Google Drive y quizá los juegos, la mayoría de las apps deberían haber sido web apps.
  Trabajé en la industria de medios, y en mi país, a principios de la década de 2010, fue una época en la que medios con poco dinero volcaban sus presupuestos en crear apps móviles; yo era el raro que se resistía a esa moda.
  Sabía que la mayoría de esas apps difícilmente tendrían buena calidad y que las empresas no iban a mantener actualizados sus frontends móviles de forma constante, y al final pasó exactamente eso.
  Ahora estamos atrapados en apps que casi no reciben mantenimiento, y la mayoría parecen reliquias de otra época; de hecho, lo son.

  • Entiendo que Google Drive funcione mejor como app nativa. Tiene que ofrecer un sistema de archivos virtual al sistema operativo y hacer cosas como sincronización en segundo plano.
    Pero no entiendo por qué Uber. Uber tiene, o tenía, un sitio móvil que maneja bien la solicitud de viajes y casi todo lo que hace la app, y no veo qué valor adicional le aporta al usuario la app nativa.
    Lo mismo aplica a la mayoría de los juegos móviles. Normalmente tienen gráficos simples que el navegador puede renderizar con rendimiento suficiente, y muchas veces recrean sus propios componentes de UI comunes, así que no usar botones nativos del sistema no cambia mucho.
    Una PWA también puede ofrecer suficiente almacenamiento para archivos locales y datos de juego. Claro que los juegos que llevan el sistema al límite son la excepción.
    No esperaría que juegos como Death Stranding o el remake de RE4 funcionen bien sin acceso directo a la aceleración gráfica nativa, y son demasiado grandes para cargarlos como una sola página web.
    Pero la mayoría de las apps móviles, incluso los juegos free-to-play de altos ingresos que podrían quedarse con un 30% más de ingresos si se pasaran a la web, no entran en esa categoría.
    Entonces, ¿por qué no apuntan a la web? Mi intuición es que los usuarios móviles fueron condicionados a buscar apps y juegos en las tiendas de apps, mientras que los usuarios de escritorio esperan que las apps se entreguen en el navegador, salvo algunas herramientas profesionales y juegos de alta gama.
    Al final, en gran medida es un problema cultural, y el soporte deficiente de Apple para PWA tampoco ayuda.
  • Ojalá la experiencia de desarrollo web no fuera tan frustrante. Ha mejorado mucho en los últimos 10 años, pero todavía se siente lejos de ser óptima comparada con los entornos de desarrollo nativo.
    Gran parte de la frustración viene de las herramientas, en particular de TypeScript; es difícil expresarlo de forma simple, pero he tenido que pelear mucho más con el sistema de tipos de TypeScript que en el mundo nativo.
  • En particular, las PWA creadas con enfoque offline-first se han acercado mucho más a una experiencia nativa que hace 5 años.
    Pero me preocupa si Google y Apple tienen incentivos para ayudar a mejorar las PWA hasta un nivel en el que puedan competir con las apps nativas. Si llegaran a ese punto, podría afectar sus ingresos.
  • ¿Por qué invertir tiempo en tecnologías de moda que cambian cada mes?
    Es mejor invertir tiempo en los componentes fundamentales del stack tecnológico.
  • Me agota tener el teléfono y la tablet llenos de apps basura. El estacionamiento de la zona tiene una app, la fotocopiadora de la biblioteca tiene una app.
    Todo eso podría resolverse con la web.

• La razón por la que Apple no se preocupa por los desarrolladores es que, como ellos mismos explicaron, creó del lado de los usuarios algo parecido a un culto dentro de un jardín cerrado.
  Si los desarrolladores no crean productos para esa plataforma, pierden la mitad del mercado o más.
  En mi trabajo principal, creando juegos móviles en un estudio pequeño dentro de una gran empresa, tenemos que pelear constantemente con Apple no solo por cuestiones técnicas, sino también por políticas y aprobaciones.
  Pero es difícil imaginar lanzar un juego móvil que no tenga forma de ejecutarse en iOS, así que no queda otra que ajustarse.
  En muchos sentidos, la estrategia original de Microsoft para PC fue exactamente la opuesta. Cuidaba a los desarrolladores y ofrecía una enorme cantidad de documentación, ejemplos y herramientas.
  Las empresas de esos desarrolladores tenían incentivos para crear, promocionar y vender software para Microsoft, y la ola de desarrolladores individuales produciendo software para Windows creó el sistema operativo de escritorio que todavía domina hoy.

  • Durante 15 años he escrito software profesionalmente, pero nunca he escrito una sola línea de código para dispositivos Apple, y no pienso hacerlo en el futuro.
    Contribuir al ecosistema de Apple es una elección, no una obligación. Los desarrolladores que contribuyen al ecosistema de Apple participan activamente en la situación actual.
  • Creo que es porque Apple es una empresa de hardware y usa software para atraer consumidores, mientras que Microsoft es una empresa de software y usa hardware para atraer consumidores.
  • Apple no obliga a los desarrolladores a hacer nada. Los desarrolladores crean apps para esa plataforma porque los consumidores quieren gastar dinero allí.
    Apple logra esto tratando mal a los desarrolladores o, más precisamente, impidiendo que los desarrolladores traten mal a sus clientes.
    Se parece a la forma en que presiona con fuerza a los proveedores, pero al final se creó un ecosistema saludable y próspero, y los desarrolladores y proveedores siguen ofreciendo apps allí.
  • Esto me parece algo distinto de la situación que describe el autor. Creo que el autor se enfocaba en servicios que tienen sentido en cualquier contexto y donde el móvil es solo uno de varios puntos de acceso.
    Cosas como redes sociales, apps de citas, Reddit o Stack Overflow. No servicios que dependen de la experiencia móvil, como Uber, que necesita seguimiento de ubicación, o juegos móviles diseñados para jugarse en movimiento.
    Si el negocio no depende de la experiencia móvil, se puede ofrecer el servicio sin una app nativa.
    Los usuarios móviles también pueden acceder desde el navegador móvil y, aunque quizá no sea la experiencia ideal, sigue siendo una opción.
    Creo que el punto central es: si la plataforma móvil no es indispensable ni tu servicio depende de ella, no desarrolles para esa plataforma.
  • Me da curiosidad saber qué cosas frenó Apple en relación con los juegos móviles.

• Hace unos años me metí de lleno a aprender Swift y desarrollo nativo para iOS, pero nunca pude acostumbrarme a usar Xcode.
  La UI/UX de Xcode era tan horrible que cuesta describirla, y tenía que estar abriendo y cerrando paneles todo el tiempo para hacer clic en íconos que ni siquiera estaban agrupados de forma intuitiva.
  Cuando abría un panel, otro se minimizaba a la fuerza, y sentía que en la práctica una décima parte del tiempo se iba en “manejar paneles”.
  Parece que los diseñadores de Apple querían crear un IDE visualmente bonito y minimalista, no un IDE con poca fricción para desarrolladores.
  Pero un IDE no tiene por qué ser minimalista; debería permitir que cada desarrollador lo personalice y lo deje tan desordenado como quiera según lo que intenta construir.
  Si uno imagina una mesa de trabajo física en un garaje, Visual Studio te deja ensuciar y personalizar el espacio de trabajo todo lo que quieras, mientras que Apple se siente como si te exigiera guardar cada herramienta anterior en una caja antes de tomar la siguiente.
  A eso me refiero con manejar paneles, y me da curiosidad si otros desarrolladores también lo sienten así.

  • Esto me llega muchísimo, y la razón exacta por la que intenté varias veces hacer desarrollo nativo para Mac/iOS y lo dejé fue el IDE.
    La idea de priorizar la forma por encima de la función me ayudó a poner en palabras qué era lo que no me gustaba de Xcode.
    Llevo más de 10 años en el ecosistema de JetBrains y tiene sus defectos, pero nunca sentí que JetBrains no intentara hacer que el IDE funcionara como yo quiero.
  • Estoy de acuerdo en que la usabilidad de Xcode es realmente espantosa. Es increíblemente lento y se crashea tan seguido que no pasaría una revisión de la App Store.
    Pero lo que realmente me hizo alejarme de crear apps nativas para plataformas de Apple fue la combinación de bugs y falta de documentación.
    La última vez que lo usé, hace un año, SwiftUI no estaba en un estado adecuado para su propósito, e incluso bibliotecas más maduras muchas veces tenían muy poca documentación.
    También es difícil saber qué está obsoleto.
    En mi trabajo, las ventajas de una app nativa desde la perspectiva del usuario son pequeñas para empezar, y se reducen sobre todo a un almacenamiento local más confiable.
    Si la productividad es mucho menor que al crear una webapp, es difícil justificar el costo y el riesgo adicionales de depender de la benevolencia de una especie de monarca monopolista.
  • Creo que varía bastante según el estilo de desarrollo y el entorno al que estés acostumbrado.
    Xcode no me molesta en absoluto, pero el muy elogiado Android Studio basado en IntelliJ me irrita constantemente.
    Visual Studio también tiene limitaciones igual de frustrantes y raras. Por ejemplo, no entiendo por qué no se puede usar cursiva en el resaltado de sintaxis.
    Con los editores pasa lo mismo. VS Code tiene pequeñas cosas molestas que Sublime Text o TextMate no tienen.
  • De acuerdo. Cada vez que intento encontrar algo como Build Output o Project Settings, que en otros IDE se encuentra fácilmente, me pierdo enseguida y tengo que buscar en Google cómo abrir ese panel.
  • En lo personal, Xcode es a la vez excelente y terrible. Cuando estoy en VS Code lo extraño, pero cuando estoy dentro de Xcode lo detesto; no sé si tiene sentido.
    Se siente como uno de esos IDE pesados de antes: cuanto más te adaptas a él, más cómodo se vuelve, pero al mismo tiempo queda la sensación de que no tienes el control.
    Si Apple se hubiera preocupado, seguramente podría haberlo hecho al menos la mitad de ágil que VS Code, aunque no llegara al mismo nivel, y sin duda podría ser mejor que ahora.
    Solo el pésimo soporte de key bindings de Vim ya me enfurece. Por ejemplo, no se pueden repetir la mayoría de las acciones como c o r.
    No sé si en ese momento usaste SwiftUI o peleaste con los storyboards de UIKit, pero lo segundo es la peor experiencia y no se la recomendaría ni a mi peor enemigo.
    SwiftUI todavía está en una etapa temprana y tiene cosas por pulir, pero en comparación se siente como el futuro.

• Hace tiempo tuve que configurar una cuenta de desarrollador de Apple para que una de las apps de nuestro municipio apareciera como propiedad nuestra.
  No sé por qué no hizo falta con las otras apps, pero en todo caso había que hacerlo y fue una experiencia bastante horrible.
  Primero necesitaba una cuenta de Apple, y como no quería usar mi cuenta personal tuve que crear una cuenta nueva de trabajo.
  No se podía crear una “cuenta de organización”, así que quedó vinculada a mi persona, y por suerte tenía un iPhone viejo que estaba por descartarse y pude usarlo.
  Después esperé varios días a que Apple verificara mi identidad, lo que en la práctica consistió en que Apple llamara por teléfono a la persona que yo había puesto como mi jefe para que confirmara que era así.
  Espero que hayan investigado más, pero no estoy seguro; además, el inglés de las personas que llamaron era incluso peor que el nuestro, así que como mínimo fue ridículo.
  Luego tuve que configurar el pago, porque por alguna razón hay que pagar para tener una cuenta de desarrollador de Apple.
  Parece una suma que ni se notaría en el presupuesto total de una ciudad de 60 mil habitantes, pero al ser una suscripción extranjera y no ofrecer Apple una forma de procesarla como una compra B2B fácilmente registrable ante la autoridad fiscal local, terminaba siendo revisada todos los años.
  Además, el pago solo podía hacerse con tarjeta de crédito, y como las tarjetas corporativas también están vinculadas a una persona real, hacía falta alguien encargado de renovarlo.
  La gente cambia de trabajo, y para cambiar el propietario tienen que comunicarse Apple y una persona real, así que pueden imaginar lo divertido que fue.
  Esto fue hace unos años, así que puede que haya cambiado, pero de las más de 300 soluciones de TI empresariales con las que he tratado, ninguna fue tan espantosa como Apple.
  Para ser justos, soy desarrollador, así que tampoco sé por qué me encargaron esto, y no sé si en operaciones de TI este tipo de cosas es más común.

  • Hoy probablemente sea aún peor. Siguen agregando obstáculos para que no puedas publicar apps en el “ecosistema”.
    La excepción es si eres una gran empresa estadounidense que puede manejar el papeleo fácilmente.
  • Sigue igual. Al configurar la cuenta de desarrollador quedé atrapado en un bucle de errores en el iPhone, y el soporte no entendía qué estaba pasando hasta que, unos 6 meses después, de repente empezó a funcionar.
    Sigue siendo aleatorio. Puede funcionar de inmediato, o si tienes mala suerte y te toca un bug aleatorio de este proceso, fallar durante mucho tiempo.
  • Tengo entendido que gobiernos y organizaciones sin fines de lucro pueden quedar exentos de la cuota de membresía del Developer Program de $99.
    No sé cuándo empezó, pero no es algo muy reciente.
  • Si lo hicieran hoy, quizá sería mucho más fácil desde el lado de compras corporativas. Hoy en día es común emitir números de tarjeta virtual de un solo uso por servicio.

• A veces olvidamos lo abierto que era originalmente la web/www, y lo abierta que sigue siendo en general si se la compara con el “ecosistema de apps” monopolizado por Apple y Google
  Claro que existe la “nube”, pero nada te impide alquilar un servidor y alojar ahí lo tuyo
  Si no funciona bien, lo sacas de ahí y alquilas otro servidor. Puede haber efecto de dependencia y no ser fácil, pero no es imposible
  Si vemos el ecosistema de apps en conjunto, solo hay 2 opciones y, literalmente, dependes de su buena voluntad
  Personalmente, jamás apostaría todo un negocio a una sola “app”. Si la audiencia realmente lo exige, podría tener una app como pequeño complemento, pero nada más
  Odio los productos que me obligan a usar una app en dispositivos móviles. Preferiría que volviera algo como m.website.com, y quiero evitar por completo todo el ecosistema de apps

  • Si esos 2 son los que estoy pensando, uno de ellos es un agujero negro de soporte al cliente con un martillo de destierro
    De la noche a la mañana, por cualquier motivo o sin motivo alguno, puedes terminar en una situación de “tener que rogar ayuda en la portada de HN”
    Rezo para que la nueva tendencia de sideloading en la UE genere exigencias similares en EE. UU., pero al mismo tiempo sé bien que eso solo será posible si hay suficiente gente que sepa y le importe qué significan “jardín cerrado” o “sideloading”

• La web es excelente en teoría, pero como el entorno del navegador ofrece demasiado solo lo básico, no resulta una plataforma de apps muy atractiva si estás acostumbrado a una experiencia de desarrollo con baterías incluidas como la de las plataformas de Apple
  En macOS, incluso las apps potentes y pulidas pueden desarrollarse con un número de dependencias y subdependencias que se cuenta con los dedos de una mano, e incluso sin ninguna si haces un poco de esfuerzo
  En cambio, una webapp equivalente termina con decenas o cientos de dependencias para cubrir los vacíos de funcionalidad
  Por ejemplo, no veo por qué el navegador no podría ofrecer una vista nativa de listas/tablas que recicle celdas de forma eficiente usando nada o muy poco JavaScript
  No es raro tener que desplazar cientos o miles de elementos sin que el dispositivo se trabe o se quede sin memoria
  AppKit, UIKit, SwiftUI, Android Framework, Compose y probablemente también Flutter manejan bien esto de forma predeterminada, pero en el navegador hay que traer una biblioteca o escribir código propio para una funcionalidad tan básica
  Si a eso le sumamos la gestión de paquetes y los problemas generales de tooling, el mismo problema de fondo persiste obstinadamente aunque las soluciones vayan y vengan

  • Siento que la experiencia de desarrollar con Electron es mucho mejor que desarrollar para la UI de Apple
    También he hecho bastantes apps para iOS/iPad desde hace 15 años
    Lo bueno de la web es que normalmente hay una biblioteca o framework que se ajusta a lo que necesitas. Electron es un ejemplo
    Del lado de Apple muchas veces no hay buenas bibliotecas, y SwiftUI tiene demasiados bugs
    React simplemente funciona bien y conceptualmente es más simple. El data binding bidireccional es una mala idea
    Apple tiene la idea de que hace todo más simple, pero en la práctica muchas veces lo vuelve más engorroso y difícil
  • Como la web se creó pensando en documentos, se asume que el archivo HTML ya contiene todos los datos que se van a mostrar
    La tabla ya viene rellenada desde el servidor con los datos necesarios y en el orden correcto
    Por eso no hace falta reciclar celdas ni filas, y aunque haya miles de filas, los datos ocupan kilobytes y funciona con agilidad
  • Flutter tiene su propio motor de renderizado, así que sus API integradas son bastante potentes
    Si se consideran alternativas como WebAssembly y Flutter, la falta de funciones nativas del navegador ya no debería ser un problema
  • No entiendo cuál es el problema con JavaScript

• No creo que sea cierto que los desarrolladores no le aporten nada a Apple
  Si el iPhone no tuviera apps de terceros, Apple habría vendido muchos menos teléfonos
  En teoría, muchas apps podrían trasladarse a la web, pero aun así sigue siendo cierto que las apps de terceros hacen que valga mucho más la pena tener un iPhone
  Cuando hay competencia real, los fabricantes de sistemas operativos se esfuerzan mucho por atraer desarrolladores. Basta recordar el viejo video de Ballmer diciendo “developers developers developers”
  Porque saben que los desarrolladores agregan valor a la plataforma e influyen en la elección de los consumidores
  El problema hoy es que no hay competencia significativa
  Sean cuales sean las reglas de Apple, los desarrolladores tienen que ofrecer algo para iPhone, y Apple puede estar tranquila porque casi no hay posibilidad de que se consolide una tercera plataforma móvil
  Apple lo sabe y, mediante políticas estrictas, ha invertido brutalmente la situación
  Aunque los desarrolladores cumplen un papel enorme en hacer que valga la pena tener un iPhone, Apple cobra un impuesto sobre todos los ingresos como si les estuviera haciendo el favor de permitirles acceder a los clientes de iPhone
  Esto es abuso de posición de mercado y, como dice el blog, no hay mucho que se pueda hacer salvo distribuir por la web
  No es perfecto, pero fuera de la regulación es la única alternativa significativa, y Apple no tiene motivos para renunciar por voluntad propia a los miles de millones de dólares en ingresos que obtiene gravando a los desarrolladores de apps, así que hará todo lo posible por evitar la regulación
  Espero que la web gane fuerza como forma de evitar reglas abusivas de distribución de apps

• Todos los días pienso en lo maravillosa que es la web, y en lo triste que es que Apple haya intentado arruinarla tanto como pudo al empujar a los desarrolladores a crear apps para iOS en lugar de webapps
  Si no hubiera existido la App Store, la web sería mucho mejor
  Habría más diversidad en el consumo de contenido, las fuentes de redes sociales, las recomendaciones algorítmicas y las experiencias digitales
  La web funciona en todas partes, y además tiene muchas API excelentes para crear aplicaciones inmersivas/de próxima generación como WebXR
  Pero si alguien crea una app WebXR en su propio sitio y la vende, Apple no gana dinero con eso, así que Apple nunca promueve ese tipo de webapps
  A largo plazo, la web no muere. Las empresas llegan, extraen ganancias y desaparecen, pero la web no muere

• Apple ofrece miles de API que facilitan el desarrollo para sus plataformas, creó su propio lenguaje de programación que se integra bien con ellas y también tiene un IDE totalmente integrado que funciona con ambos.
  Sí, “amigo”. No les importas a menos que desarrolles para su plataforma.
  ¿Y quién podría culparlos? Todo lo anterior representa inversiones enormemente caras y de largo plazo.

  • Te faltó mencionar que bloquean todo lo que no sean esas herramientas.
    Intenté desarrollar una app directamente en macOS sin usar Swift ni las herramientas de Apple, y fue un dolor enorme.
    Abandonaron y congelaron la versión de OpenGL hasta un punto difícil de explicar salvo como una forma de empujar sus propias herramientas.
    Incluso cargar una DLL externa era casi imposible.
    Cualquier cosa multiplataforma tiene que bajar al ecosistema de herramientas de Apple, como convertir Vulkan a Metal.
    macOS es un caso más raro y especial que cualquier distribución de Linux.
    Es sorprendente lo fácil que es desarrollar en Windows. Del lado de Microsoft, casi todo es multiplataforma.
    Nada de lo que mencionaste de Apple te permite trabajar de forma independiente de la plataforma.
    En cambio, Windows soporta sus propias tecnologías como DirectX, pero también permite ejecutar Vulkan, OpenGL, etc. directamente.
  • Yo también tengo una postura bastante positiva sobre el desarrollo para Apple y me gusta Xcode. Al menos desde SwiftUI; Interface Builder nunca pude dominarlo.
    Pero es significativo que el autor haya entrado por trabajar en una app de música. Las API de audio de Apple son un completo desastre.
    Media Player, AVPlayer, Core Audio, AVFoundation, AVAudioEngine, etc.: parece que equipos rivales, remontándose hasta la época de NeXT, usaron cada uno sus propias bibliotecas y, de alguna manera, todas sobrevivieron hasta la era del iPhone.
    Durante los confinamientos por COVID pasé unos tres meses intentando hacer un reproductor Shoutcast/Icecast, y fue realmente doloroso.
  • Apple no desarrolló esas API por buena voluntad. Es una estrategia de encierro.
    Hicieron prácticamente imposible escribir código nativo multiplataforma que corra en iOS, y han hecho todo lo que pueden dentro de los límites políticos para que las web apps no puedan competir con las apps nativas.
  • Con ese criterio, me preocupa que Oracle pueda ganar fácilmente como la empresa que más cuida a los desarrolladores. Al fin y al cabo, ha hecho inversiones enormemente caras y de largo plazo.
  • No hacía falta crear un lenguaje propio. Eso también forma parte del efecto de encierro.

• Me gusta la actitud sana del autor frente a las grandes empresas. Es una habilidad básica de supervivencia moderna.
  Si pudiera decidir libremente, me gustaría no tener que instalar ninguna app en el iPhone o el iPad, pero las restricciones de la plataforma lo vuelven necesario en la práctica.
  Vi que la web app de X/Twitter en Safari no reproducía videos, incluso después de desactivar Lockdown Mode para X.
  Me gustaría saber si eso es culpa de Apple por crear inconsistencias en la plataforma o si es una intención de X para hacer que los usuarios instalen la app.
  Me especializo en deep learning y LLM, pero siempre he disfrutado también el desarrollo web.
  Lo que me frena es que las herramientas son demasiado complejas.
  Aun así, alguien que conozco ha escrito bastante sobre ClojureScript + Dart, así que quizá lo pruebe.
  Quisiera encontrar un stack simple para web apps que pueda aprender en unos días y que tenga buen soporte; agradecería recomendaciones.

  • Es mejor ignorar los textos que buscan el “stack perfecto”. El stack perfecto no existe, y tampoco es imprescindible para lanzar software excelente que los usuarios reales valoren.
    Gran parte del desarrollo web consiste en conocer bien el navegador, y web.dev es un recurso excelente.
    Después, aprende React + TypeScript. El nuevo react.dev también es bueno.
    React no es perfecto, pero como paradigma para crear UI es tan bueno que Apple lo imitó al crear SwiftUI.
    Toma Vite y empieza a programar.
    Lo que más recomendaría es estudiar bien esos recursos. Hay que empezar desde la primera página de la documentación y seguirla con calma hasta el final.
    Eso sí, no hay mucho que puedas aprender en solo unos días. El trabajo de frontend es difícil por buenas razones.