Teléfono inteligente de fondo
9144
Google se acerca a Apple: Cómo un botón en su teléfono está cambiando el mundo
Dominik Bärlocher
Zúrich, el 13 de octubre de 2021
Google está en transición. Las aplicaciones en iPhones y iPads se construyeron recientemente con componentes de Apple. Pequeños cambios para los usuarios, pero Google ha logrado un gran éxito, incluso si está ayudando a la competencia.
Las aplicaciones de Google en iPhones y iPads deberían parecerse más a las aplicaciones de Apple.
Eso por sí solo no suena como una gran sensación, pero significa mucho. Porque detrás de la decisión de convertir las aplicaciones de Google en Apple-iger, hay mucho trabajo, política, resentimiento y pensamiento competitivo.
El cambio del desarrollo propio de Google a los componentes de Apple puede jugar a favor de la competencia, pero era muy necesario y valía la pena para Google.
Arquitectura de la aplicación: lo que sucede detrás de escena
Cada aplicación tiene un marco. En la construcción de viviendas, el marco sería el andamiaje sobre el que se construye la interfaz de usuario que ves y usas. Existen frameworks para backends y frontends. Solo las interfaces son importantes en este artículo, es decir, las interfaces de usuario y todo lo que ve el cliente. En aras de la simplicidad, simplemente llamaré a este «marco» a continuación.
El framework, su elección y sus peculiaridades, es una decisión de los administradores, no solo de los programadores.
Las aplicaciones en su teléfono inteligente se crean en un llamado marco de aplicaciones.
Google usa el marco de interfaz de usuario de Flutter.
Apple utiliza el marco de interfaz de usuario UIKit.
Estos dos marcos están integrados en los kits de desarrollo de software (SDK). Google lo llama Android Studio, Apple lo llama Xcode. Ambos SDK fueron inventados por los respectivos fabricantes y se desarrollan constantemente. Al construir una casa, esta sería la caja de herramientas, que contiene todas las herramientas para construir una casa.
Puede crear aplicaciones de Android con el SDK de Apple. Porque UIKit y Xcode funcionan con el lenguaje de programación Swift, que también se puede usar para aplicaciones de Android. Aunque Android funciona con Java, es compatible con casi todos los lenguajes de programación comunes del mercado.
En resumen: por lo tanto, es posible crear aplicaciones para iOS con habilidades de programación para Android. Y al revés también. Solo que esto tiene sentido en muy pocos casos. La razón de esto es menos tecnológica y más política.
La política detrás de la programación
Los SDK son gratuitos y de libre acceso. Los lenguajes de programación son de código abierto y de libre acceso. Eso promete la gran era de las aplicaciones. Un programa compatible con todo. Tecnológicamente, se allanaría el camino para que todo el mundo pudiera desarrollar y utilizar siempre aplicaciones nativas con todo el mundo.
Solo que ni Google ni Apple tienen mucho interés en que esto suceda.
Por supuesto, ambas empresas hablan de apertura y utilizan términos como "intuitivo". Pero eso solo se aplica al caso de que un programador de Android use Android Studio para programar para Android. Todo lo demás es como una solución. Una mirada a Flutter para desarrolladores de iOS muestra cómo se hace esto. Los términos difieren, las cosas funcionan de manera diferente y, en general, los programadores tienen que aprender el lenguaje de programación desde cero.
Ya no es "intuitivo" o "fácilmente accesible". Es extremadamente complicado incluso comenzar a administrar este puente en la práctica. Parece más fácil si un programador simplemente instala dos SDK y prácticamente escribe la aplicación dos veces. Pero eso requiere tiempo y recursos que solo tienen los estudios de programación más grandes. En realidad, todos los estudios de programación de aplicaciones, pequeños o grandes, se enfrentan a una elección:
Se deciden por una plataforma (iOS o Android) y prometen administrar también la otra plataforma algún día.
El estudio utiliza un marco híbrido para ayudar. No es obligatorio utilizar un marco nativo. Ionic es un marco tan híbrido. Flutter también puede ser híbrido, pero no puedes sortear Xcode.
El estudio compila la aplicación dos veces. Esto puede incluso ser más barato que con un enfoque híbrido.
Aquí es donde se encuentran la gestión y la eficiencia operativa. Los desarrolladores están construyendo algo que es de código abierto, pero la implementación real en la vida real es absurdamente complicada fuera de un marco establecido. ¿Se podría hacer esto fácilmente? Sí. ¿Se hará más fácil? No. Motivo: los componentes de sus propias plataformas deben desarrollarse más. Esto requiere recursos, tiempo y trabajo. Recursos que no se deben gastar en competencia.
Un ejemplo un poco menos abstracto: si Apple optimizara la exportación de Swifts para Android, la empresa con sede en Cupertino estaría trabajando para su gran rival, Google. Apple desperdiciaría los recursos de Apple desarrollando los de Google. Porque la propia Apple no tendría nada de eso. El mundo de la programación tal vez, pero Apple realmente no quiere trabajar para la competencia y es muy bueno creando y manteniendo áreas separadas para sí mismo.
Google Maps en iOS: Un bastardo, históricamente hablando
Con el auge del iPhone y el triunfo simultáneo de Android, no solo ha surgido una situación competitiva, sino también una necesidad. La necesidad de Youtube en iPhone, Google Maps y quizás Google Photos.
Google no quería mucho hacer eso porque quitaría una razón para que los usuarios de Apple cambiaran a Android. Pero la presión pública era demasiado grande. Así que las aplicaciones de Google se han abierto paso gradualmente en las plataformas de Apple. Al revés también. Apple ofrece un puñado de aplicaciones en Google Play Store, pero no hace ningún movimiento para portar iCloud a Android.
¿Por qué también? Si quieres iCloud, debes usar un iPhone.
Si quieres usar Google Drive, puedes usar prácticamente cualquier teléfono inteligente.
Ambas son decisiones políticas tomadas por los respectivos fabricantes. Y solo hay una cosa que decir sobre ambas decisiones: lo suficientemente justo. Las empresas no están obligadas a estar abiertas. Puede ser más deportivo ser abierto, pero nadie puede obligar a Apple a ser deportivo. Al igual que Google, no está obligado a estar presente en las plataformas de Apple. Desde un punto de vista legal, el desarrollo de software simplemente tiene que evitar el monopolio obvio. Mientras nadie pueda probar un monopolio, todo está bien.
En 2012, Google decidió ser la primera aplicación en migrar Google Maps a iOS. Al desarrollar la aplicación de Google para el ecosistema de Apple, el equipo dirigido por el líder de desarrollo Jeff Verkoeyen notó que a Apple le faltaban algunos elementos absolutamente esenciales para las aplicaciones de Google. Por lo tanto, el equipo recreó estos elementos, como cuerpos extraños, llamados componentes materiales en la jerga técnica. Por supuesto, son de código abierto. Así evitan Google y Apple la acusación de monopolio.
En otras palabras, la primera versión de Google Maps en iOS de Apple fue una mezcolanza. La aplicación mezcló las bibliotecas, los elementos de diseño y las funciones de Apple con los proporcionados por Google.
Así fue. Nueve años.
Componentes de material: en modo de mantenimiento desde julio
Pero eso cambiará en julio de 2021. Google pondrá los componentes materiales de iOS (los cuerpos extraños) en modo de mantenimiento. Esto significa que no se desarrollarán más hasta nuevo aviso, sino que solo se mantendrán. Si algo está roto, será reparado. Las filtraciones de seguridad están reparadas. Pero de lo contrario, los componentes materiales pueden morir con dignidad.
Este es un gran paso para Google, políticamente hablando. Porque en lugar de cargar sus propios componentes, Jeff Verkoeyen y su equipo confiarán completamente en los propios componentes de Apple en el futuro. Verkoeyen lo confirma en un hilo de Twitter.
Verkoeyen describe la situación que es inevitable en el desarrollo no conjunto de software. Los componentes materiales se desarrollan más y van en una dirección. Los componentes principales de Apple están evolucionando y van en una dirección diferente. El puente que tiene que construir Material Components es cada vez más grande.
A principios de 2021, el equipo de Jeff Verkoeyen se pregunta: ¿Aún hay que construir el puente?
Una mirada a lo que el SDK de Apple y sus componentes pueden hacer muestra: Apple ahora también puede hacerlo. Era hora de hacer algunas preguntas incómodas: ¿un simple cambio en una aplicación realmente necesita solicitar su propio componente de una biblioteca externa?
La respuesta fue clara: no. Muchos de los componentes materiales ya no son necesarios, ya que ahora los proporcionan los componentes principales de Apple. Los pocos componentes que deben cargarse adicionalmente recibirán más atención gracias al modo de mantenimiento de todos los demás componentes. Esto promete un desarrollo más rápido y eficiente de Google Apps en iOS.
Es muy posible que usted, como usuario, ni siquiera note este cambio. Esto es a pesar del hecho de que los elementos simples en Google Apps ahora se crean con el propio "UINavigationController" de Apple en lugar del componente de material "App bar".
Por supuesto, estos componentes de Apple no aparecerán en las aplicaciones de Google como si fueran creados por Apple. La propia identidad de marca de Google fluirá.
Conclusión: el dinero (y un poco de desarrollo) está antes que la política
La decisión de Google de trabajar con los componentes de Apple es un arma de doble filo. Pero muestra que la razón puede prevalecer. Porque pasar de los componentes propios de Google a los equivalentes de Apple le ahorra dinero a Google, pero al mismo tiempo le da a la competencia información, conocimiento y tal vez incluso código para mejorar algo que Apple no ha querido mejorar hasta la fecha. O que Apple no sabía que necesitaba mejorar.
Pero desde el punto de vista funcional, la decisión es razonable. El hecho de que algo fuera bueno o incluso necesario hace diez años no significa que todavía sea bueno o necesario hoy. Si Apple puede suministrar componentes que realicen la misma función que los de Google, entonces tiene sentido dejar que los desarrollos internos mueran con dignidad.
Google también ha causado un gran revuelo con el cambio. Los servicios que brindan las aplicaciones del gigante de los buscadores son queridos por todos los usuarios. Pero la crítica de que las aplicaciones en iPhone no se sienten tan bien como en Android o cómo se sienten las aplicaciones de Apple en iOS está justificada. Y con el cambio, es muy probable que quede obsoleto.
El gigante de los motores de búsqueda ahorra dinero, tiempo y se hace popular entre los usuarios. Un golpe directo.
El equipo de Verkoeyen tuvo que mostrar coraje. Porque admitir que diez años de trabajo ya no son necesarios no es poca cosa. Por un lado, se podrían perder posiciones en el equipo, por otro lado, Verkoeyen y compañía demuestran que la "falacia del costo hundido" se puede superar. O incluso tiene que ser superado. El hecho de que se haya invertido dinero y tiempo hasta ahora no significa que valga la pena seguir invirtiendo.
Para los usuarios, un interruptor en la aplicación puede cambiar. En la metáfora de la construcción de viviendas, sería material aislante en la pared. Para Google y Apple, sin embargo, el mundo acaba de cambiar un poco.
