En un ordenador tiene sentido que elijas Google Chrome, Safari o Firefox según tus necesidades: cada uno tiene su propio motor y capacidades únicas que hacen que las webs funcionen de manera diferente. Pero en el iPhone no hay diferencias reales más allá de la estética o algunas funcionalidades. Da igual que cambies de Chrome a Firefox o Safari: el motor de navegación es exactamente el mismo, WebKit de Apple. Es como cambiar la carrocería de un coche manteniendo el mismo motor.

Precisamente para garantizar una competencia real entre navegadores en iOS, la Unión Europea aprobó la Ley de Mercados Digitales (DMA). Esta ley obliga a empresas como Apple a permitir que otros motores de navegador puedan funcionar en sus sistemas. Sin embargo, 15 meses después de la entrada en vigor de esta ley, ningún navegador rival ha conseguido utilizar su propio motor en iOS.

Esta situación ha generado un intenso debate entre reguladores, desarrolladores y la propia Apple, especialmente tras las declaraciones de Open Web Advocacy, una organización sin ánimo de lucro especializada en competencia web, que asegura que las condiciones actuales hacen "inviable" el desarrollo de navegadores alternativos.

Para entender la controversia, es fundamental aclarar qué está en juego. No hablamos de buscadores (Google, Bing, DuckDuckGo), que ya podemos elegir desde hace años en iOS. El tema es mucho más profundo: se trata de los motores de navegador.

El motor es el núcleo que interpreta y renderiza las páginas web. En ordenadores existen tres motores principales: WebKit (Safari/Apple), Blink (Chrome y derivados como Brave, Edge) y Gecko (Firefox). Cada uno tiene sus propias capacidades y rendimiento, por eso una web puede funcionar perfectamente en Chrome pero tener problemas en Safari.

Sin embargo, en iOS todos los navegadores están obligados a usar WebKit, sin excepción. Chrome, Firefox, Opera y cualquier otra aplicación de navegación son, en realidad, interfaces diferentes sobre la misma base técnica de Apple. Esto significa que no hay competencia real en cuanto a funcionalidad web en el iPhone.

La presión europea y la respuesta de Apple

La DMA, que entró en vigor en marzo de 2024, prohíbe a empresas como Apple imponer sus propios motores de navegador. El artículo 5(7) establece que las empresas no pueden "requerir a los usuarios finales que utilicen un motor de navegador web del guardián". Guardián es como se denomina a las empresas con una fuerte posición de dominio en el mercado.

Apple respondió creando el programa BrowserEngineKit, que permite técnicamente a Google, Mozilla y otros desarrolladores portar sus motores a iOS únicamente en la Unión Europea. La compañía argumenta que ha cumplido con sus obligaciones legales y que ha desarrollado "un programa que mantiene la seguridad y la privacidad en mente".

Kyle Andeer, vicepresidente legal de Apple, fue claro en un taller de la DMA en Bruselas: "Hemos creado un programa que permite a terceros como Google y Mozilla traer sus motores de navegador a la plataforma. Y, por alguna razón, han elegido no hacerlo".

De la teoría a la práctica

Sin embargo, desde la perspectiva de los desarrolladores, la situación no es tan sencilla. Open Web Advocacy ha identificado varios obstáculos que considera problemáticos:

• Aplicaciones separadas: los navegadores no pueden actualizar sus versiones existentes para incluir motores alternativos. Deben crear aplicaciones completamente nuevas para Europa, perdiendo a todos sus usuarios actuales en el proceso. Es decir, en la App Store tendría que haber un "Google Chrome global" y un "Google Chrome UE".
• Restricciones de testing: los desarrolladores web fuera de la UE no pueden probar sus sitios en navegadores con motores alternativos, algo que Apple sí permite para aplicaciones nativas. Por lo tanto, el desarrollo desde Estados Unidos se complica.
• Limitaciones geográficas: Apple no permite que estas funcionalidades se extiendan globalmente, limitándolas exclusivamente a la UE.

La posición de Apple: seguridad ante todo

Apple mantiene que sus restricciones están justificadas por motivos de seguridad. Según la compañía, iOS fue "diseñado desde cero pensando en la seguridad y la privacidad", y WebKit ha sido una pieza fundamental de esa arquitectura durante 18 años.

Gary Davis, director senior legal de Apple, explicó en el taller: "Los motores de navegador son un vector de seguridad conocido. Podría sentarme aquí y leer una lista de 100 vulnerabilidades reales asociadas con motores de navegador".

Apple también argumenta que está "en un período de transición" y que continúa manteniendo conversaciones con Mozilla y Google para resolver las diferencias existentes.

En Applesfera

Apple ha empezado a recortar iOS 26 en Europa y ya tenemos la primera víctima

Los números detrás de la controversia

La organización Open Web Advocacy va más allá y sostiene que Apple conoce exactamente cuáles son las barreras, y ha elegido no eliminarlas. Según sus cálculos, Safari genera 20.000 millones de dólares anuales solo del acuerdo con Google, representando el 14-16 % de las ganancias operativas de Apple.

La resistencia de Apple no es solo técnica. Los números muestran por qué la compañía tiene intereses para mantener el control sobre los navegadores:

• Safari recibe 20.000 millones de dólares anuales de Google por ser el buscador predeterminado.
• Cada 1 % de cuota de mercado que pierda Safari equivale a 200 millones de dólares menos por año.
• La App Store generó 27.400 millones de dólares en 2024, y un mayor uso de aplicaciones web podría reducir estas cifras.

La Comisión Europea aún no ha emitido una evaluación formal sobre si Apple está cumpliendo efectivamente con la DMA. Sin embargo, el Reino Unido ya ha investigado este tema, y su regulador concluyó que "la evidencia que hemos visto hasta la fecha no sugiere que haya diferencias en el rendimiento de WebKit y los motores de navegador alternativos".

Por lo que estaríamos en otra situación similar a la última imposición de la UE sobre las apps de Teléfono y Mensajes. En iOS 26 se podrán utilizar apps de terceros para llamar por teléfono. Algo por lo que Apple ha tenido que trabajar para "desenlazar" algo tan esencial como la conexión de la tarjeta SIM, la gestión de cobertura y el establecimiento de llamadas.

La intención de la Unión Europea es buena. Si alguien elige Google Chrome en su ordenador, en parte es porque prefiere navegar con su motor específico, al que está acostumbrado desde el escritorio. Sin embargo, en el iPhone o en el iPad te encuentras con exactamente lo mismo: básicamente, es como una versión de Safari con otra interfaz.

Esta limitación se vuelve más importante cuando ahora el iPad se posiciona como un ordenador con las novedades de iPadOS 26. Muchos usuarios, incluido yo mismo, hemos tenido alguna vez problemas de compatibilidad con Safari que no aparecen en otros navegadores del escritorio. Tener acceso al motor de Chrome o Firefox podría resolver muchas de estas incompatibilidades.

El problema, como siempre, es que esta competencia sería exclusiva de la Unión Europea. Muchas empresas podrían considerar que no vale la pena el esfuerzo de desarrollar y mantener una versión separada solo para el mercado europeo, donde ni siquiera iOS es el sistema operativo predominante.

La pregunta que queda en el aire es si este enfoque regional puede generar la competencia real que busca la UE, o si simplemente creará un ecosistema dividido, e incluso con menos funciones, como sucede con iPhone Mirroring en Europa.

Fuente | Open Web Advocacy

En Applesfera | Nuevo iOS 26: novedades, cuándo sale, iPhone compatibles y toda la información sobre la nueva actualización

En Applesfera | Cómo instalar una beta de iOS 26 en el iPhone: paso a paso para hacerlo de una manera segura y oficial

Desde hace semanas venimos anticipando que iOS 17.4 será una actualización histórica para usuarios de iPhone de la Unión Europea. Y es que es en el viejo continente donde recibiremos muchos cambios a causa de las nuevas normativas de la UE que, entre otras cosas, implica poder tener más tiendas de aplicaciones en iOS aparte de la App Store.

Otro de los cambios a los que Apple se ve obligada a implementar es en relación a la apertura a otros motores de navegación web. Como entusiasta de la tecnología en general y de la de Apple en particular, es una actualización que espero con ganas, aunque también me implicará renuncias que, por desgracia, no tienen pinta de revertirse en el corto plazo.

Abrir las puertas de la App Store es positivo (aunque te de miedo)

Una de las implicaciones que tienen las leyes europeas para Apple es que deben otorgar la posibilidad de descargar aplicaciones en lugares que no sean sólo la App Store. Finalmente no será descargándolas de Internet tal y como sucede en Android con las APK, sino que será abriendo la App Store a otras tiendas.

A consecuencia de esto, durante estas semanas he leído y escuchado a otros entusiastas quejarse de esta apertura de la tienda de iOS. Que llegue por imposición y no por iniciativa propia de Apple es un debate interesante, pero esto es totalmente distinto. La mayoría de las quejas vienen del lado de la privacidad y seguridad, pero lo cierto es que no tienen por qué implicar nada negativo. Es más, tu iPhone no cambiará en nada si tu no quieres. Todos seremos libres de instalar o no otras tiendas y, en consecuencia, aplicaciones que de forma normal no están en la App Store.

Yo como usuario creo que cuantas más opciones se nos den, mejor. Esto viene a fomentar la competitividad entre desarrolladores y aunque es cierto que no cualquiera podrá subir su propia tienda en la App Store por las exigencias económicas de Apple, estos sí podrán entrar en esas otras tiendas.

Estar ante un mar de incertidumbres es algo que me motiva. Porque sí, sabemos ya que algunas tiendas como la Epic Store llegarán a iOS con esta apertura. Sin embargo, hay aún muchas incógnitas acerca de qué tipo de apps nuevas aparecerán en iOS. Y eso me gusta. Poder explorar esas tiendas en busca de joyas ocultas, y siempre con precaución, es algo que siempre me interesará.

Usar otro navegador en el iPhone y que sea distintivo de verdad es otro puntazo

Otro de los puntos interesante y que ya adelantaba en la introducción son los relativos al navegador. Hasta ahora Safari viene por defecto, pero esto cambiará (si queremos) con iOS 17.4. La primera vez que abramos este navegador tras actualizar aparecerá una pantalla en la que se nos sugerirán varias opciones para usar como navegador predeterminado en el iPhone, incluyendo el propio Safari. Podremos elegir otro y automáticamente se descargará y se configurará como el que sale por defecto.

Safari ya no será el motor principal de otros navegadores (Imagen:Mariia Shalabaieva en Unsplash)

Aparte de esto, hay otras implicaciones que son positivas de cara a explorar los límites de la navegación en iOS. Y es que los navegadores ya no tendrán porque acogerse a WebKit, la API de desarrollo de exploradores webs en iOS y que hasta ahora es la única forma de cualquier desarrollador lance su app de navegación web para iPhone.

Sí, llevamos ya muchos años con opciones varias como Google Chrome, Opera o Mozilla Firefox entre otras muchas. Sin embargo, al tener todas el mismo motor de Apple, no dejan al final de ser una especie de Safari tuneado. Pueden añadir alguna opción extra y modificar algo la interfaz, pero en esencia es lo mismo.

Con iOS 17.4 ya podremos encontrarnos navegadores completos al gusto de cada desarrollador y eso podría abrir las puertas a tener navegadores móviles mucho más cercanos a lo que tenemos en escritorio. Véanse como ejemplo las extensiones, que ya están presentes ahora, pero de forma mucho más limitada que en un navegador de ordenador.

La parte negativa es que diremos adiós a las webapps

Como siempre, no hay nada perfecto. Y ni siquiera para mí que recibo con buen ánimo todas estas novedades hay excepción. Con el punto anterior también llega el fin del soporte a las PWA, siglas en inglés de las Aplicaciones Web Progresivas conocidas también como webapps. Estas están presentes en prácticamente cualquier dispositivo, incluyendo los iPhone (aunque pronto dejen de estar).

Si desconoces lo que es, es en cierto modo una especie de "mini app" que corre vía web. Es ideal para desarrolladores sin recursos suficientes para crear una aplicación, teniendo más fácil su creación vía web con ciertas ventajas frente a una página web convencional. Incluso se pueden recibir notificaciones push, algo que Apple introdujo con iOS 16.4.

En Applesfera

Un Copilot de Apple: Gurman lleva la IA de iOS 18 hacia las herramientas de desarrollo

Para el usuario también tiene sentido al no tener que descargar una app y con ello lograr incluso liberar espacio del iPhone. Además se pueden añadir a la pantalla de inicio del iPhone como si fueran una app más, y pese a correr con Safari de fondo, no se abren directamente en el navegador. Sin embargo, esto está a punto de cambiar.

Pues bien, como ya sabíamos, las webapps dejarán de tener soporte. El hecho de cada desarrollador de navegadores web vaya a usar su propia arquitectura es algo que imposibilita que Apple pueda dar soporte a webapps (ni siquiera si se usa Safari). Así lo comunicó la propia compañía en una nota de su sitio web para desarrolladores.

En mi caso personal reconozco que cada vez usaba menos webapps, pero seguía teniendo alguna que otra que deberá desaparecer de mi pantalla de inicio. Y es que desde que actualicemos a iOS 17.4 dejarán de ser operativas. Si bien es posible que en el futuro regresen, ya se advierte como algo complejo a nivel de implementación por parte de Apple. La alternativa será añadir los favoritos a la pantalla de inicio, aunque no es lo mismo.

En Applesfera | Eliminar el fondo de una foto en iPhone, iPad y Mac nunca fue tan fácil (y sin tener que instalar nada)

En Applesfera | ¿Cuántos años de actualizaciones le quedan a mi iPhone? Así podemos saberlo

Con la llegada de iPadOS 13, primera versión de software propia para iPad, se abría un nuevo camino de posibilidades para unas tablets que cada vez iban avanzando más en hardware. No obstante, en estos tres últimos años no hemos vuelto a ver un cambio tan grande en el sistema y buena prueba de ello es iPadOS 15. Todavía no sabemos cómo será el nuevo iPadOS 16 que Apple presentará en la WWDC22, pero a buen seguro que este sistema es de los que más expectación levanta en estas semanas previas.

El hype se empieza a elevar ahora tras conocerse varios indicios que apuntan a una de las novedades más demandadas por parte de los usuarios y que en cierto modo asemejaría el software de los iPad al de los Mac. Nos referimos a la posibilidad de poder redimensionar ventanas, lo cual iría intrínseco en la posibilidad de tener ventanas flotantes. No está confirmada esta funcionalidad, pero hay quien ha encontrado referencias a ello en el código de WebKit.

El código de WebKit señala abiertamente el "modo multitarea"

Que el código abierto de WebKit sea plenamente accesible desde GitHub permite que desarrolladores y curiosos puedan investigar a fondo el que es el motor principal de navegadores como Safari. Precisamente eso es lo que hizo Steve Troughton-Smith, quien afirmó en Twitter haber encontrado referencias a un modo multitarea en iOS.

En Applesfera

Widgets interactivos, ventanas y mantener la esencia en iPadOS 16: la lista de deseos de los editores de Xataka y Applesfera

Para corroborar este dato, el desarrollador adjuntó un enlace a GitHub en el que efectivamente se aprecia esa clara referencia a un modo multitarea que, posteriormente, fue corroborado por un ingeniero de Apple en otra actualización del código en GitHub. Evidentemente, tal y como advierte también Troughton-Smith, esto no tiene por qué acabar quedándose en una función de multiventana real en el futuro, pero cierto es que nunca habíamos visto tales referencias.

El hecho de que este código apunte a iOS no quiere decir que pudiera ser una novedad exclusiva para los iPhone. De hecho podría ser compartido tanto por estos como con los iPad, dado que el código de WebKit es el mismo en ambos casos. Sin embargo, a la par que nos imaginamos un nuevo estilo de ventanas flotantes en iPadOS, también podemos emocionarnos con la idea de poder usar pantalla dividida en los iPhone. Aunque quizás hacernos a la idea de ambas funciones es crecerse demasiado en optimismo.

Por tanto, volvemos a dirigir todas las miradas en el próximo 6 de junio. Será este día en el que comience la WWDC 2022 en una keynote inaugural en la que, salvo sorpresa mayúscula, veremos presentados todos los nuevos sistemas operativos de Apple. Saldremos por fin de dudas acerca de todo lo nuevo de iPadOS 16 y, ojalá, confirmaremos si esta función de redimensionar ventanas viene de serie con esta versión.

Vía | 9to5Mac

Hoy mismo os hemos comentado cómo el código fuente de WebKit nos ha sugerido que iOS 12 puede seguir siendo compatible con el iPhone 5s, pero por lo visto no es lo único que nos va a soplar. Desde 9to5Mac leemos que ese mismo código también tiene escondidas referencias a un modo oscuro para macOS.

Sí, no hablamos de iOS si no de macOS. Se ha visto que, desde marzo, el código de WebKit puede llegar a cambiar la apariencia de ciertos elementos de una web dependiendo de unos parámetros que le dé el sistema. Y esos parámetros pueden ser un cambio de color hacia el modo oscuro, para que así las webs con fondo claro cambien.

Del modo oscuro discreto a algo mucho más global

macOS ya tiene un dark mode, pero se limita a oscurecer los menús y algún elemento suelto más del sistema. Desde la versión de El Capitán hay un modo oscuro más amplio que da libertad a los desarrolladores para poder utilizarlo, pero el modo del que habla la noticia de hoy sería mucho más extendido. Y ya hay algunos experimentos con macOS Sierra:

Dark Safari #macOS pic.twitter.com/UyA48tlxRE

— Guilherme Rambo (@_inside) 11 de julio de 2016

De momento no hay referencias directas a un modo oscuro, aunque también podemos pensar en esa unión de plataformas de desarrollo que hay prevista para las próximas versiones de los sistemas operativos. Si una aplicación de iOS puede tener un modo oscuro sin problemas y lo que se desarrolle en iOS se va a poder ejecutar en macOS... quizás esto sea el simple ejercicio de adaptar esos cambios de colores en el motor de WebKit. Veremos si finalmente es lo que creemos o finalmente es otra función.

En Applesfera | Concepto de iOS 12 con Dark Mode

Ademas de los tests de velocidad, una de las pruebas mas importantes para los desarrolladores web es el test de rendimiento de los navegadores. Estos tests tienen como referencia Speedometer, un test de rendimiento que pone a prueba diferentes tareas típicas de un navegador web para finalmente darle una puntuación. Speedometer fue creado por Apple en 2014, ahora llega Speedometer 2.0, adaptado a las tecnologías actuales.

Speedometer se ejecuta desde el navegador, y no es más que una ejecución de múltiples tareas (480 en total) para medir el tiempo que tarda cada una de ellas y proporcionar un informe detallado de ello. Puedes ejecutar tú mismo este test en tu navegador, pero dado que seguramente utilices Safari o Chrome en su última versión, tus resultados serán similares a los del resto. Y es que Spedometer no depende tanto del usuario final como del desarrollador del navegador web. Es decir, es un test enfocado a la comunidad WebKit que crear y diseña nuevas tecnologías para la web y nuevos navegadores.

Apple ha publicado un detallado artículo explicando todos los cambios de esta nueva versión de Speedometer. La primera versión es de 2014, y desde entonces han cambiado muchas tecnologías en los navegadores. Ahora hay más APIs, nuevas bibliotecas de Javascript, nuevos dispositivos... Según Apple:

En los últimos tres años, un número creciente de sitios han sido escritos usando React – una biblioteca Javascript para crear interfaces de usuario. Derivados como Preact e Inferno también han ganado popularidad. Speedometer 2.0 incluye aplicaciones web implementadas con estas librerías.

¿En qué te influye a ti como usuario esta nueva versión de Speedometer? Te influye de manera indirecta, pues se trata de una importante aportación a la comunidad de WebKit. ¿Y qué es WebKit? La plataforma que sirve como base para muchos navegadores, entre ellos Safari y muchos otros pequeños navegadores. En definitiva, una herramienta para que los desarrolladores web creen mejores apps para el usuario.

Más información | WebKit y Speedometer 2.0
Vía | The Mac Observer

De acuerdo con el blog oficial de WebKit, en iOS 10 se han realizado una serie de cambios importantes en el navegador de Apple. Por ejemplo ya no tendremos que pulsar sobre un GIF para que comience a reproducirse como en iOS 9, y tampoco tendremos más videos molestos que se reproducirán automáticamente al cargar una web.

Esta mejora en vídeos se suma a la de los GIFs, que ahora podrán utilizar la etiqueta "video" en Safari y ser tratados como vídeos por el navegador. De hecho desde hace un tiempo muchos proveedores de GIFs utilizan la etiqueta "video" para categorizarlos ya que supone un tratamiento mejor en la codificación de la imagen.

Una cuestión de ahorro

Como bien ha indicado Apple en más de una ocasión, lo que buscan con Safari en iOS es conseguir un ahorro tanto de consumo de datos como de energía. Es por es que a la hora de reproducir un vídeo automático este no lo hará mientras no sea visible en la pantalla. Por lo que si no está el marco del vídeo en la pantalla ni lo oiremos ni se cargará. De la misma manera, en cuanto nos desplacemos y desaparezca el marco de la pantalla de nuevo se pausará la reproducción.

Con los GIFs al utilizar la etiqueta "vídeo" pasará algo muy similar, y es que estos no interferirán en la carga de la web mientras no estén a la vista del usuario en la pantalla. Así que para el usuario final lo que encontraremos será una mejor experiencia de navegación debido a que se cargará tan solo lo que nos interesa. Además de que esto mejorará levemente la autonomía de los dispositivos.

Más información | WebKit

Aunque Joe Belfiore midió al máximo sus palabras durante la presentación oficial de Project Spartan, el nuevo navegador web que tomará el relevo a Explorer en Windows 10, lo cierto es que el vicepresidente ejecutivo de sistemas operativos de Microsoft no puede negar la evidencia: WebKit se ha convertido en el estándar de facto en los motores de renderizado web y seguir atados por la compatibilidad con versiones anteriores de Explorer es un lastre.

"Un nuevo motor de renderizado que ha sido creado para ser compatible con el modo en que se escribe la web hoy día", aseguró Belfiore rápidamente antes de pasar a la siguiente característica, sabiendo perfectamente que bien podríamos sustituir la última parte de esta sentencia por una sola palabra, WebKit. Y atentos porque aquí no estamos hablando de seguir los estándares del World Wide Web Consortium -W3C-.

Historia de una ida y una vuelta

Veréis. Los estándares son buenos; ofrecen unos cimientos a los desarrolladores web para que podamos escribir nuestro código una única vez y esperar los mismos resultados en cualquier navegador que apueste por ellos. El problema es que los organismos de estandarización como el propio W3C son lentos y tediosos, con constantes tiras y aflojas entre los principales jugadores del sector.

Microsoft, Apple, Google... todos tienen en común el deseo de ir más lejos, de introducir antes que los demás cambios y novedades que hagan posibles cosas como gradientes, fuentes web, animaciones o transformaciones 3D, y con las nuevas hojas de ruta con actualizaciones mayores cada año la W3C sencillamente no puede ni tan siquiera soñar con estar a la par. Así es como surgen, entre otras cosas, etiquetas y propiedades específicas de cada motor.

En el pasado Microsoft se metió a si misma en un callejón sin salida implementando los estándares de la época de un modo poco menos que tosco e introduciendo un buen número de etiquetas propietarias que ningún otro navegador soportaría. Mozilla Firefox y el motor Gecko nacieron en 2004 como una respuesta a esta situación, popularizando el concepto de un componente aparte del propio navegador y reutilizare por otros, y aunque Apple llevaba desde 1998 trabajando en WebKit, no sería hasta el año siguiente cuando liberarían su código fuente.

Con la llegada de iOS, WebKit adquirió un papel protagonista en la explosión de los dispositivos móviles y con el apoyo de Google y la popularidad de Chrome en los escritorios, la hegemonía de este motor web se hizo patente. Microsoft había perdido su posición de fuerza, y SU estándar, el estándar de Explorer, se había convertido en la excepción.

WebKit sin WebKit

Perdida la guerra, el siguiente paso lógico habría sido unirse al bando ganador, ¿no?. Desafortunadamente nada es tan sencillo, y menos ahora que WebKit se ha desdoblado con la salida de Google del proyecto para crear su propia versión, Blink. Ambos, WebKit y Blink, siguen siendo de código abierto, pero cada uno está profundamente controlado por un rival diferente de Microsoft y las decisiones que adoptan no siempre van en beneficio global del proyecto, sino muy ligados a los planes específicos de cada compañía.

Spartan es la solución al problema de Microsoft: abrazar WebKit sin ceder el control

Los chicos de Redmond deciden tomar el camino difícil. En los últimos años Microsoft ha ido modificando Trident, el corazón de Explorer, para añadir las extensiones de WebKit y visualizar correctamente la inmensa mayoría de páginas que se crean hoy día. El problema es que seguían soportando también sus antiguas extensiones por motivos de compatibilidad, y claro, el resultado conjunto se resentía.

Por ese motivo Microsoft ha optado por una solución divergente para acercarse a WebKit definitivamente sin rendirse a él: Mantener por un lado Explorer sin dar la espalda inmediatamente a los usuarios que necesitan acceder a páginas diseñadas para este, pero acompañarlo de un segundo navegador con una versión modificada de su motor que rompe todo lazo con el pasado e introduce los cambios necesarios para terminar de clonar la implementación y extensión de los estándares web que hacen WebKit/Blink.

Al final, Project Spartan parece un buen paso adelante en términos de navegación web para Microsoft, y uno de los aspectos centrales sobre los que la compañía tratará de reinventarse, una vez más, con el lanzamiento de Windows 10. No lo tienen fácil para volver a ser relevantes, pero si algo hemos aprendido en la historia reciente de la tecnología es que nada es imposible y todos tienen oportunidades si saben aprovecharlas.

En Applesfera | 8 cosas de Windows 10 que sonarán a los usuarios de Apple y otras 8 que nos gustaría ver en el futuro
En Xataka Windows | Microsoft decidió no adoptar WebKit en Spartan para evitar depender de Google

Muy buenas noticias para los desarrolladores: Apple acaba de deshacerse de un defecto que llevaba tiempo arrastrando desde modernizando WebKit en iOS 8 y permitiendo que cualquier aplicación que cargue una página web pueda hacerlo con el mismo rendimiento que Safari. Para mí, era una de esas cosas que consideraba incomprensibles.

De este modo, cuando todo el mundo use iOS 8, cualquier aplicación que cargue una página web desde un panel (y sin cambiar a Safari Mobile) no tendrá ninguna barrera para hacerlo con la misma rapidez que con el navegador nativo. Y eso también son buenas noticias para los navegadores de la competencia como Google Chrome, que también podrán gozar del máximo rendimiento posible en iOS.

Esto es un punto más de esta "apertura" que Apple ha hecho hacia los desarrolladores. Hemos pasado de tener varias barreras para todos los que tienen aplicaciones de terceros a una apertura que hasta ahora sólo atribuíamos a Android: interacción entre aplicaciones, teclados de terceros, todos los recursos del sistema accesibles... y lo mejor de todo es que seremos nosotros los principales beneficiados.

Vía | 9to5Mac
En Applesfera | iOS 8 ahora sugerirá aplicaciones de acuerdo a localización

La optimización y el aumento de velocidad de los motores JavaScript se ha convertido en uno de los principales campos de batalla de los navegadores web. El motor Nitro de Apple vivió su momento de gloria tiempo atrás poniendo a Safari al frente pero Google logró adelantarlo por la derecha con su V8 y ahora la manzana parece estar decidida a devolvérsela.

Y es que los últimos cambios registrados en WebKit, el proyecto de software libre mantenido por Apple y sobre el que se construye Safari, otorgan a su motor de JavaScript una inyección de rendimiento que lo hacen significativamente más rápido que Chrome en algunos benchmarks, brillando especialmente a la hora de ejecutar código no optimizado para asm.js, el subset especial de JavaScript desarrollado por Mozilla para interpretar código C y C++.

El secreto esta mejora se esconde en el denominado FTLJIT, un set de cambios que utilizan el compilador LLVM como sistema JIT (just-in-time) y que aunque aún se encuentra en fase experimental, ya es posible activarlo en la última Nightly Build de Safari recurriendo al Terminal.

¿Será esta una de las novedades de Apple para OS X 10.10 o queda aún demasiado trabajo por delante como para su presentación en la inminente WWDC 2014? Con una ventana de lanzamiento que, de repetirse lo del año pasado, tendríamos que situar alrededor de octubre, desde luego más les vale aplicarse.

Vía | MacRumors

Todavía vemos a los MacBook Pro con pantalla retina como algo nuevo y caro, pero es cuestión de tiempo para que este tipo de pantallas lleguen al resto de ordenadores de Apple (tanto el resto de portátiles como en las pantallas de sobremesa). Y aunque ya hay algún apaño en marcha, la web tiene que prepararse para este salto de resolución que ya están empezando a adoptar incluso en la competencia.

Por eso, el motor Webkit ha añadido soporte para gráficos que cambian de forma dinámica dependiendo del dispositivo que estemos usando, cubriendo desde un smartphone hasta la pantalla más grande de un ordenador de sobremesa. Todo depende de la cantidad de pixeles reales que se usen para mostrar un punto en la pantalla: Apple lo multiplica por dos (cosa que ya nos deja margen de sobra para que la retina humana no distinga los pixeles), pero se podría multiplicar incluso por cuatro en pantallas con una densidad de pixeles muy alta. Es, básicamente, un "multiplicador de resolución".

Lo importante aquí será ver si los desarrolladores se apuntan a adaptar sus páginas web a estas nuevas altas resoluciones. Implica más trabajo, gastar más espacio en los servidores y por lo tanto utilizar más tráfico. Pero hay señales que no se pueden ignorar, como la absoluta dominación del iPad en el tráfico de internet de los tablets, dispositivo que lleva una pantalla retina desde el año pasado.

Lo más probable es que veamos esta novedad en la versión de Safari que llegará junto a OS X Mavericks. Mientras tanto, la competencia opta por desviarse del camino original de Webkit para utilizar Blink, un motor derivado que quiere optimizar la navegación creado originalmente para Chrome y que ha llamado la atención de Opera y de Adobe.

Vía | AppleInsider2