Home » Noticias » Apple Coding News #7 (10/03/2017)
News #7

Apple Coding News #7 (10/03/2017)

De los nuevos formatos que tiene el podcast de Apple Coding, las noticias han supuesto todo un descubrimiento para mucha gente que en pocos minutos, puede ponerse al día de todo lo acontecido durante las semanas en el mundo del desarrollo. Pequeñas cápsulas que permiten estar al día de todo lo sucedido. Pero hay gente que a lo mejor prefiero leerlo más que oírlo, por lo que vamos a realizar este formato en dual a partir de ahora. Haremos los boletines de noticias en la web y lo añadiremos al podcast para que podamos elegir una u otra forma de acceder a la información. Dos formas diferentes de consumir (o lo que se conoce como formato transmedia).

Cambios en el App Store relacionados con los tiempos de prueba en suscripciones

Sin duda, Apple apuesta en el futuro por las suscripciones de apps, mucho más allá de los servicios. Recordamos que uno de los servicios más aplaudidos en la última WWDC fue el anuncio de la posibilidad de usar las suscripciones también para otro tipo de apps que no fueran exclusivamente servicios (como Netflix o periodismo). En este caso, incluso los videojuegos pueden acogerse a una suscripción que puede ser mensual, trimestral, semestral o anual.

Cambios en el App Store

El cambio ha venido ahora cuando Apple acaba de anunciar que amplia las opciones de periodos de prueba antes de pasar a pagar por la suscripción en la app. De esta forma, ahora podemos optar por períodos de 3 días de duración, 1 semana, 2 semanas, 1 mes, 2 meses, 3 meses, 6 meses o 1 año, con opción de auto-renovación de la suscripción.

Sin duda, una incorporación muy interesante. Por cierto, también saltó la noticia que no podrían editarse las descripciones de las apps sin enviar un update, pero parece que era un bug y ahora puede volver a hacerse sin problema. Falsa alarma.

Swift, top 10 en el índice TIOBE

Swift ya es TOP 10 en el índice de popularidad de lenguajes TIOBE, en el recién publicado índice para el mes de marzo. Durante todo el año 2016 estuvo en el puesto 16 y en los últimos meses ha dado una subida espectacular, pasando a ser uno de los 10 lenguajes más populares en la red, a nivel de recursos, cursos, artículos, etc.

índice TIOBE Marzo 2017

Según la empresa TIOBE, la que elabora estos índices, esta subida es muy positiva pero consideran que es probable que no suba más allá debido a la limitación actual de ser un lenguaje pensado solo para desarrollo en una única plataforma. Argumento que no tiene mucho sentido, teniendo en cuenta que Swift en código abierto puede ser usado en otros sistemas y que, poco a poco, la parte de servidor está teniendo cada vez más fuerza y repercusión. Así que, si me permite la gente de TIOBE, creo que Swift tiene aun que subir muchos peldaños.

Teclados ocultos en el iPad

Ya hablamos en su día de estas funciones que aun no están disponibles en el iPad referentes a los teclados. Parece que de nuevo, Steve Troughton-Smith ha hecho de las suyas y ha conseguido activar los nuevos teclados ocultos del iPad desde la propia app Swift Playgrounds.

Teclado flotante en iPad

Sólo tenemos que entrar en el GitHub del propio Steve y descargarnos el Swift Playgrounds que activa esta funcionalidad, pulsando aquí. De hecho, no solo él, otro desarrollador a partir de esa prueba ha habilitado otro teclado completo con atajos para copiar y pegar, entre otros, como opciones de arrastrar en teclado avanzado.


Sin duda, tenemos buenas sorpresas que llegarían con iOS 11, supuestamente. Estos nuevos teclados le darán aun más productividad al iPad.

Las ventanas flotantes, rechazadas por Apple

No hace mucho, hablamos sobre una interesante librería llamada PanelKit, que permite poner ventanas flotantes en una interfaz en iPad y que luego estas se puedan pegar como paneles a los bordes de la pantalla. Esto ha dado lugar a que, de nuevo, Steven Troughton-Smith haya intentado hacer un experimento: subir al App Store una app sencilla con ventanas flotantes sobre un escritorio vacío, a ver qué dice Apple.


¿La respuesta? Que no está permitido. No se puede crear una interfaz que no ocupe toda la superficie de la pantalla y que muestra un “escritorio vacío” en algunas zonas. Apple obliga (por ahora) a que todos los desarrollos (aunque usen varias distribuciones de ventanas) estén obligatoriamente completas y no haya partes que se queden sin contenido. ¿Cambiarán su forma de pensar algún día? Yo apuesto a que sí.

El uso de librerías de inyección de código como Rollout.io están prohibidas

Ha sido otra de las noticias de la semana: de pronto, y sin previo aviso, Apple ha empezado a rechazar todas las aplicaciones que usan una librería rollout.io. ¿Y qué es esto? Pues bien, es una librería que lleva funcionando un tiempo, y que permite inyectar cambios en el código de una app de forma dinámica, sin tener que actualizar la misma.

El proceso es sencillo: integramos la SDK, subimos la app y si tenemos algún problema o fallo, podemos crear un paquete que actualice partes concretas del código, firmarlo, enviarlo por push a todas las instalaciones de nuestra app y que ese código se actualice automáticamente. Una librería práctica, con soporte de Objective-C y Swift, pero que va diametralmente en contra de una de las reglas más claras de Apple: no cambiar el código de una app sin pasar por una nueva revisión. Hasta ahora, parece que Apple ha sido laxa con esta librería porque entendía que solo permitía cambios menores que no alteraban la funcionalidad de la app, pero de pronto parece que han visto que esto no es así y que sí puede permitir hacer cambios mayores e incluso suponer un problema de seguridad.

En realidad, esta librería no rompe como tal la norma de Apple pues no modifica el binario (si lo hiciera, la firma dejaría de ser válida y la app no funcionaría). Lo que hace es usar un núcleo en Javascript que añade lógica a los parches y obliga a nuestra app a ejecutar métodos alternativos que se han cargado como si fueran recursos de la propia app (que insistimos, no modifican el binario). Una SDK que (según la compañía) ya usan más de 50 millones de dispositivos con apps instaladas del mismo y que ahora, Apple, ha decidido que NO cumple con las normas que “en teoría” sí cumplía.

Norma App Store

Como puede verse, Apple dice claramente que la app “contiene código que está diseñado específicamente para cambiar el comportamiento de la misma o su funcionalidad, posteriormente a la aprobación en el App Store“. Según dicen en la nota que están recibiendo todos los desarrolladores que suben su app con esta librería, “El código, combinado con una fuente remota de recursos, puede facilitar cambios significativos en el comportamiento de la app comparado a cuando fue inicialmente revisada para la App Store”. Y añade: “…esto tiene el potencial de cargar librerías privadas, métodos privados y permite futuros cambios funcionales“. Algo que, obviamente, Apple no permite.

La compañía ha emitido un comunicado en el que dice que cumple con los más altos estándares de seguridad, que su librería permite cambios mínimos sobre la funcionalidad (parchear en vivo una app), que sus servicios están protegidos contra cualquier ataque “man in the middle” (uno de los miedos de Apple) y que no van a parar y seguirán trabajando para llevar esta funcionalidad a Android o permitir otras formas de ayudar a los desarrolladores aunque no sean en la actual fase de post-producción, la cual Apple les ha cerrado sin posibilidad de negociar.

A mi, personalmente, me parece bien que Apple no permita esto. Soy desconfiado por naturaleza y por muy bien que esté hecha la SDK (que no lo dudo) nadie me puede garantizar que tenga un agujero de seguridad y efectivamente, el sistema permitiera un despliegue en que alguien modificara la inyección de código y cambiará algo en mi app. Además, los procesos de la App Store están para algo y ahora mismo son pocos los días que hay que esperar para una aprobación, a veces incluso solo horas.

Pero sin duda, ha sido unos de los temas más polémicos de la semana y que ha abierto la puerta a pensar qué otras posibles tecnologías podrían ser prohibidas por Apple. La respuesta es simple: cualquiera que cambie la funcionalidad de la app inyectando cambios (aunque no alteren el binario) sin que ellos mismos lo supervisen. Porque insistimos, esta librería podría tener un zero-day que nadie conociera, y Apple no se puede arriesgar a ello.

Final

Y con esto cerramos el boletín de esta semana. Esperamos que les haya puesto al día y cualquier comentario, ya saben que estaremos encantados de contestarlos.

Un saludo y Good Apple Coding.

Acerca de Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Otras recomendaciones

Portada Vídeo News

Apple Coding News llega a YouTube

Los boletines de noticias de Apple Coding llegan a YouTube. Descúbrelos y disfruta la mejor forma de seguirnos y estar al día. La más completa. Una forma única de no solo oír las noticias del mundo del desarrollo como nadie más te las cuenta, también podrás descubrir todos los detalles detrás con el apoyo visual del formato que solo YouTube permite. Una nueva experiencia Apple Coding.