Apple eliminará de su App Store aplicaciones que lleven tiempo sin actualizar

Archivado
1, 2
Hace algunos meses Apple extendía la pipa de la paz a los desarrolladores independientes con la creación de un fondo de compensación de 100 millones de dólares y nuevas condiciones en la App Store. Con estas medidas la firma de Cupertino quería congraciarse con los pequeños creadores, algunos de los cuales afirmaban sentirse discriminados. Ahora la compañía hace suyo el dicho de una de cal y otra de arena al anunciar que eliminará de la App Store las aplicaciones que lleven tiempo sin ser actualizadas.

Según señalan algunos desarrolladores, Apple está enviando e-mails en los que se explica que aquellas aplicaciones que no sean objeto de una actualización a lo largo de los próximos 30 días serán borradas de la tienda como parte del programa de mejora de la App Store. Aquellas que ya hayan sido instaladas en un dispositivo seguirán funcionando con normalidad, pero no será posible descargarlas de nuevo.

No está claro cuál es el límite, pero parece que las aplicaciones marcadas para su eliminación llevaban dos o más años sin actualizarse.

Además de suponer un problema fundamental de cara a la conservación de contenidos estrictamente digitales, que podrían desaparecer de un plumazo, la medida afecta de forma singular a los indies. Muchos desarrolladores de juegos no pueden permitirse el lujo de seguir actualizando sus antiguos lanzamientos, que ahora serán eliminados si no hacen un esfuerzo con el que no contaban. Son juegos que siguen siendo descargados y que funcionan aparentemente bien, a pesar de lo cual dejarán de existir en la App Store.



Apple no ha realizado declaraciones al respecto, aunque como señala The Verge, su página de información sobre las mejoras en la App Store expresa que la compañía está implementando un proceso de evaluación que le llevará a "eliminar aplicaciones que ya no funcionan como se esperaba, no siguen las normas de revisión actuales o están desactualizadas".

Por supuesto, queda la duda de por qué una aplicación que funciona bien debería ser actualizada... o considerarse desactualizada. Apple lleva borrando aplicaciones obsoletas desde hace muchos años, pero hasta ahora hablábamos de software que presentaba problemas de compatibilidad o rendimiento por no adaptarse debidamente a las versiones más modernas de iOS o que ya no seguía las últimas normas.

Fuente: The Verge
Es un tema complejo... si se desarrolló una app para el primer iPhone ahora mismo si se descarga en los más modernos va a dar problemas de todo tipo: resolución, fallos por usar funciones del SDK obsoletas...

Creo que la mejor solución sería dejar etiquetar los juegos sobre si son o no compatibles con los dispositvos más actuales, pero claro, a Apple no le interesa que su tienda se llene de juegos no compatibles con lo nuevo que sacan.
Me veo miles de apps con estos comentarios:
Patch Notes:
Now the app menu have 1 pixel in white
Es absurdo. Si una aplicación funciona y no tiene bugs que corregir, ¿por qué van a actualizarla?
@bainomamueles

Eso mismo he pensado yo.

Si algo funciona bien, ¿Qué necesidad tengo de modificarlo?
@bainomamueles
Porque su código puede ser vulnerable. A las nuevas aplicaciones se les exige un mínimo de seguridad.
Pasa lo mismo con GPlay.. hay que ir actualizando el sdk de la app para evitar problemas. Yo soy desarrollador de app para ios y android y lo veo normal
Esto pasa desde hace años ya.
Si un producto está terminado y no da ningún tipo de problemas de compatibilidad porque hay que actualizarlo? Ah claro, por cobrar la pasta de las updates of couuuurse [burla2] [burla2] [burla2]
neofonta escribió:@bainomamueles

Eso mismo he pensado yo.

Si algo funciona bien, ¿Qué necesidad tengo de modificarlo?

Que uses las novisimas funciones del novisimo ios 16 solo compatible con iphone 8 en adelante.
El que quiera usar un iphone con mas de cinco años de antigüedad que se pase a android
FEATHIL escribió:Si un producto está terminado y no da ningún tipo de problemas de compatibilidad porque hay que actualizarlo? Ah claro, por cobrar la pasta de las updates of couuuurse [burla2] [burla2] [burla2]


Desde cuándo pagan los desarrolladores por publicar actualizaciones?? O lo has dicho por decir??
Huele a querer forzar aún más la obsolescencia de los modelos antiguos, que en algunos casos no podrán ejecutar las versiones nuevas de estas aplicaciones
Torres escribió:
FEATHIL escribió:Si un producto está terminado y no da ningún tipo de problemas de compatibilidad porque hay que actualizarlo? Ah claro, por cobrar la pasta de las updates of couuuurse [burla2] [burla2] [burla2]


Desde cuándo pagan los desarrolladores por publicar actualizaciones?? O lo has dicho por decir??


En iOS hay que pagar 100 euros al año para mantener las apps en la tienda (incluso si no la actualizas e incluso si la app es gratis y sin publicidad). Por actualizar propiamente no hay que pagar más, si no pagas la quitan directamente.

En Android no, solo pagas al darte de alta en vez de anualmente y son 20 o 30 euros no recuerdo ya, de ahí que sea más fácil encontrar apps muy obsoletas en la tienda, mantenerlas ahí no tiene coste.
Esto no es nuevo. Lo hacen desde hace muchísimos años.
@mocelet ok por eso.., el compañero decía que había que pagar para publicar una actualización y eso no es así...
mocelet escribió:
Torres escribió:
FEATHIL escribió:Si un producto está terminado y no da ningún tipo de problemas de compatibilidad porque hay que actualizarlo? Ah claro, por cobrar la pasta de las updates of couuuurse [burla2] [burla2] [burla2]


Desde cuándo pagan los desarrolladores por publicar actualizaciones?? O lo has dicho por decir??


En iOS hay que pagar 100 euros al año para mantener las apps en la tienda (incluso si no la actualizas e incluso si la app es gratis y sin publicidad). Por actualizar propiamente no hay que pagar más, si no pagas la quitan directamente.

En Android no, solo pagas al darte de alta en vez de anualmente y son 20 o 30 euros no recuerdo ya, de ahí que sea más fácil encontrar apps muy obsoletas en la tienda, mantenerlas ahí no tiene coste.


Pues tenia entendido que esos 99$ dólares anuales era por tener que actualizar las aplicaciones no por mantenerlas en la tienda. Si no hay que pagar por actualizar:... si es como dices entonces no se trata de un afán económico el hecho de quitar apps (estarían perdiendo dinero) sino mas bien otras causas como comentan mas arriba como seguridad y demás.
Hay que obligar a actualizar las apps (aunque no lo necesiten) así de paso hacen que no funcionen en los dispositivos más viejos y a hacer que la gente se actualize si o si.

PD. en Ios/Android no cobran por actualizar apps, en otros sectores (como en juegos de consola) si cobran y/o dependiendo de ciertas cosas cobran por la certificación necesaria para que se publique.
Apple con sus políticas de mierda, una vez más [+risas]
mocelet escribió:
Torres escribió:
FEATHIL escribió:Si un producto está terminado y no da ningún tipo de problemas de compatibilidad porque hay que actualizarlo? Ah claro, por cobrar la pasta de las updates of couuuurse [burla2] [burla2] [burla2]


Desde cuándo pagan los desarrolladores por publicar actualizaciones?? O lo has dicho por decir??


En iOS hay que pagar 100 euros al año para mantener las apps en la tienda (incluso si no la actualizas e incluso si la app es gratis y sin publicidad). Por actualizar propiamente no hay que pagar más, si no pagas la quitan directamente.

En Android no, solo pagas al darte de alta en vez de anualmente y son 20 o 30 euros no recuerdo ya, de ahí que sea más fácil encontrar apps muy obsoletas en la tienda, mantenerlas ahí no tiene coste.


A parte de pagar la licencia de desarrollador de Apple, en según que casos puede ser necesario pagar licencias de las herramientas de desarrollo con las que se hacen las aplicaciones.

Por ejemplo, una aplicación hecha con Qt. Necesitarías volver a pagar al menos un mes de la licencia comercial y eso para un único desarrollador serían 362$, que maldita la gracia.
DavET está baneado por "Saltarse el ban con un clon"
Menuda panda de fascistas y elitistas ... [boma] [bye]
ALEDEKAI escribió:Pasa lo mismo con GPlay.. hay que ir actualizando el sdk de la app para evitar problemas. Yo soy desarrollador de app para ios y android y lo veo normal


Eso no es cierto lo único que exige Google play Un binario de 64bits para los dispositivos de 64bits pero puedes seguir dando apoyo a Android 2.3 sin problemas .

Para android 2.3 "@TargetApi(Build.VERSION_CODES.GINGERBREAD)" en tu parte de java .

https://developer.android.com/reference ... SION_CODES

Otra cosa es que muy pocos desarrolladores desconozcan esto y les salga más rentable eliminar el "soporte" antiguo cuando actualizan un SDK en android.

"Este trato" en Apple y IOS no lo tienes te obliga a "Matar el soporte antiguo" aunque quieras actualizarlo muchas veces y no hay vuelta atrás en terminos de compatibilidad y en la preservación de software porque o bien el mínimo SDK ya no admite los primeros dispositivos xD .
LonK escribió:Apple con sus políticas de mierda, una vez más [+risas]



Políticas de mierda obligar a actualizar apps? Mira que hay políticas de mierda en apple (no incluir cargador... [hallow] ), pero mantener la tienda con las apps actualizadas me parece un acierto.
Sinceramente, lo veo bien.


Si una persona no ha cambiado de iPhone en 8 años, tampoco te va a dar beneficios en tu app.

Osea, no se cambia el iPhone 6 y crees que va a gastar en micropagos de tu app que no la actualizas desde hace 2 años? Vas listo...
MaXiMu escribió:
ALEDEKAI escribió:Pasa lo mismo con GPlay.. hay que ir actualizando el sdk de la app para evitar problemas. Yo soy desarrollador de app para ios y android y lo veo normal


Eso no es cierto lo único que exige Google play Un binario de 64bits para los dispositivos de 64bits pero puedes seguir dando apoyo a Android 2.3 sin problemas .

Para android 2.3 "@TargetApi(Build.VERSION_CODES.GINGERBREAD)" en tu parte de java .

https://developer.android.com/reference ... SION_CODES

Otra cosa es que muy pocos desarrolladores desconozcan esto y les salga más rentable eliminar el "soporte" antiguo cuando actualizan un SDK en android.

"Este trato" en Apple y IOS no lo tienes te obliga a "Matar el soporte antiguo" aunque quieras actualizarlo muchas veces y no hay vuelta atrás en terminos de compatibilidad y en la preservación de software porque o bien el mínimo SDK ya no admite los primeros dispositivos xD .


En mi experiencia... Yo utilizo el sdk minimo 21. Lo tenia mas bajo y siempre habia quejas de cuelgues y apps que se cierran solas. En mi opinion.. lanzar apps en dispositivos de menos de 1gb de ram no compensa. Quien tiene android 2.3 hoy dia xD?
MaXiMu escribió:Otra cosa es que muy pocos desarrolladores desconozcan esto y les salga más rentable eliminar el "soporte" antiguo cuando actualizan un SDK en android.


Depende... si la app usa bibliotecas de compatibilidad (lo más típico en Android), desde la migración a las extensiones AndroidX ya ni siquiera soportan Android 2.3.3 y lo mínimo es Android 4.0.

El TargetApi o los flavours de Gradle están bien para habilitar nuevas funciones, pero si toda la app depende de bibliotecas que ya no soportan versiones antiguas estás vendido.
Google va a hacerlo (con matices), pues Apple también.
Me parece buena idea. Es una forma de limpiar la Store de Apps sin soporte
Si es para seguridad esta bien, pero a nivel conservacion espero que tenga alguna alternativa para respaldar apps importantes que no es como android donde consigues la apk e instalas.
Estoy a favor de la medida. Hay un porrón inmenso de apps que llevan años en la store sin ningún tipo de actualización.

Actualizaciones que son necesarias por simples motivos: seguridad, optimización y funcionalidad.

Con esto salen ganando clientes y desarrolladores.
Adios Mushihimesama y Mushihimesama Futari. Tiene cojones
Estoy harto de bajar apps que se cierran o no abre en iPhone 13 pro por ejemplo, qué sentido tiene tener una app 6 años sin updates y evidentemente sin soporte

@MaXiMu Por mucho que pongas esa variable hay cosas que no van en 2.3 porque el sdk no tenía esa función

Enfocó a hay apps de pago sin updates que no funcionan y ni avisan que no van
Y después cocinamos a Microsoft cuando deja de actualizar windows 7.

No lo veo mal lo que hace Apple, pero podrian existir mejores formas de hacer limpieza o validar si una app aun sigue siendo segura y compatible.
nxname escribió:Y después cocinamos a Microsoft cuando deja de actualizar windows 7.

No lo veo mal lo que hace Apple, pero podrian existir mejores formas de hacer limpieza o validar si una app aun sigue siendo segura y compatible.


No i hace validar nada una app de hace 6 años no es segura
ALEDEKAI escribió:
En mi experiencia... Yo utilizo el sdk minimo 21. Lo tenia mas bajo y siempre habia quejas de cuelgues y apps que se cierran solas. En mi opinion.. lanzar apps en dispositivos de menos de 1gb de ram no compensa. Quien tiene android 2.3 hoy dia xD?


Si no actualizas y no separas el código por versión del sistema operativo claro al final dejará de funcionar pero si tienes el control que hace cada versión y funciones desde una versión mínima a otra es mucho más difícil que deje de funcionar.
También cada aplicación es un mundo y como esté de programada y cuántas funciones utilizas dependientes de versiones de android más nuevas que sean difíciles de llevar a versiones más antiguas.

mocelet escribió:
MaXiMu escribió:Otra cosa es que muy pocos desarrolladores desconozcan esto y les salga más rentable eliminar el "soporte" antiguo cuando actualizan un SDK en android.


Depende... si la app usa bibliotecas de compatibilidad (lo más típico en Android), desde la migración a las extensiones AndroidX ya ni siquiera soportan Android 2.3.3 y lo mínimo es Android 4.0.

El TargetApi o los flavours de Gradle están bien para habilitar nuevas funciones, pero si toda la app depende de bibliotecas que ya no soportan versiones antiguas estás vendido.


PPSSPP el emulador de PSP sigue soportando Android 2.3 y sin problemas
https://github.com/hrydgard/ppsspp/pull/15001

Utilizamos
minSdkVersion
targetSdkVersion
Para que se puede seguir compilando desde nuestro SDK.
En muchas de las entradas para que se compile en ese modo hasta día de hoy no nos hemos encontrado con problemas graves fáciles de resolver. Algún día caera el soporte nunca digas nunca pero es un capricho del autor seguir soportando al antiguo Sony Xperia Play

Al igual que no puedes dar soporte armv6 y Mips más allá del NDK 17 si utilizas el NDK oficial pero eso no te impide sacar un binario para esos dispositivos

También hay ports del NDK con versiones del gcc que google nunca implementó en su NDK original entre otras cosas .

Es lo bueno de un SDK/NDK open source que no dependes mucho de las decisiones de google :p

@berny6969 ppsspp sigue funcionando en Android 2.3 y funcional hasta Android 12.
@MaXiMu puede ser q esa App si vaya pero la gran mayoría no funcionarán con tu variable que yo la uso también por compatibilidad al compilar un apk pero si el sdk de 2.3 no tiene una funcion ni va a ir, para apps que no usen nada extraño nuevo pues seguro que irá

Y si usas framework de terceros tampoco va a ir supongo

Igual solo Para que el desarrollador compruebe sus apps y las actualize por seguridad me parece bien esa medida
No me parece bien.
¿Para qué van a actualizar algo que no tiene fallos?
En mi caso me perjudicará porque tengo activada la opción que las aplicaciones que hace tiempo que no uso se desinstalen de forma automática para no ocupar espacio, pero siempre quedan listas para reinstalar en caso de necesidad.
Si desaparecen de la store no será posible volverlas a instalar.
MaXiMu escribió:PPSSPP el emulador de PSP sigue soportando Android 2.3 y sin problemas


Claro, pero ese proyecto no es representativo, no usa la interfaz de usuario de Android para nada y probablemente no integra ningún servicio como notificaciones push, pagos in-app ni nada del estilo.

Criminal escribió:Si desaparecen de la store no será posible volverlas a instalar.


No sé cómo lo hará Apple, Google sí dijo que las apps antiguas se ocultarán de la Play Store pero que cualquier usuario que la haya instalado antes va a poder seguir instalándola sin problema. Lo que se evitará es que nuevos usuarios puedan instalarla.
Por supuesto, medida de mierda de una empresa multimillonaria sin la más mínima lógica, decenas de comentarios en EOL defendiendo la medida y a la empresa. Muy correcto todo, así toman tan alegremente las empresas medidas así de asquerosas y así nos va como usuarios, cada vez comiendo con sistemas más restrictivos y con peores opciones.
Hace mucho que vienen haciendo esto, pero mucho. Solo que antes, con la migración a 64bits pues había excusa, pero ahora ya huele.

Supongo que quieren pulir de un plumazo aplicaciones viejunas y cosas así…
berny6969 escribió:@MaXiMu puede ser q esa App si vaya pero la gran mayoría no funcionarán con tu variable que yo la uso también por compatibilidad al compilar un apk pero si el sdk de 2.3 no tiene una funcion ni va a ir, para apps que no usen nada extraño nuevo pues seguro que irá

Y si usas framework de terceros tampoco va a ir supongo

Igual solo Para que el desarrollador compruebe sus apps y las actualize por seguridad me parece bien esa medida


Quizás porque nosotros utilizamos entradas por versión y se duplica un poco el código equivalente es decir separamos la API por versión en la que se utiliza controlando con varias funciones
Obviamente se puede romper si utilizas una entrada que no existe y no separas el mínimo compatible .

similar a esto para el modo de alerta del dialogo .

@TargetApi(Build.VERSION_CODES.HONEYCOMB)
   private AlertDialog.Builder createDialogBuilderWithTheme() {
      return new AlertDialog.Builder(this, AlertDialog.THEME_HOLO_DARK);
   }

   @TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
   private AlertDialog.Builder createDialogBuilderWithDeviceTheme() {
      return new AlertDialog.Builder(this, AlertDialog.THEME_DEVICE_DEFAULT_DARK);
   }

   @TargetApi(Build.VERSION_CODES.JELLY_BEAN_MR1)
   private AlertDialog.Builder createDialogBuilderWithDeviceThemeAndUiVisibility() {
      AlertDialog.Builder bld = new AlertDialog.Builder(this, AlertDialog.THEME_DEVICE_DEFAULT_DARK);
      bld.setOnDismissListener(new DialogInterface.OnDismissListener() {
         @Override
         public void onDismiss(DialogInterface dialog) {
            updateSystemUiVisibility();
         }
      });
      return bld;
   }

   @TargetApi(Build.VERSION_CODES.M)
   private AlertDialog.Builder createDialogBuilderNew() {
      AlertDialog.Builder bld = new AlertDialog.Builder(this, android.R.style.Theme_DeviceDefault_Dialog_Alert);
      bld.setOnDismissListener(new DialogInterface.OnDismissListener() {
         @Override
         public void onDismiss(DialogInterface dialog) {
            updateSystemUiVisibility();
         }
      });
      return bld;
   }


@Mocelet Es cierto que no utiliza la GUI estandarizada .mucho del código ya viene escrito en C/C++ + ffmpeg para la codificación de audio y video .
Creo lo que más crítico del código que me acuerde son los popups ventanas que salen cuando hay un error y el control de permisos y los modos de Escritura legacy para sistemas antiguos y sistemas nuevos otro hablo de memoría

El único requisito para Android Ocultarse en Play Store es que no tener soporte para 64bits si actualizas para 64bits o que no soporte todavía android 4.1 o superior mientras se repecte eso puedes seguir dando soporte a sistemas operativos anteriores o arquitecturas no soportadas por el NDK actual .

También te dejan poner apk por dispositivo o versión de android para tener tu un mejor control .

Edit : Faltas
Splatoon escribió:Es un tema complejo... si se desarrolló una app para el primer iPhone ahora mismo si se descarga en los más modernos va a dar problemas de todo tipo: resolución, fallos por usar funciones del SDK obsoletas...


La propia App Store debería de tener un sistema que detecte para que versión del sistema operativo se hizo esa App, y por lo tanto no aparecer o avisar de alguna manera cuando se vaya a instalar.

Ejemplo, yo tengo un iPhone 6, y algunas aplicaciones ya no me deja actualizarlas o instalarlas por no tener la última versión del iOS, pues lo mismo pero para aplicaciones mas antiguas, no creo que sea un tema tan complejo en pleno 2022...
Google también está haciendo algo similar en Google Play.
Darkcaptain escribió:
Splatoon escribió:Es un tema complejo... si se desarrolló una app para el primer iPhone ahora mismo si se descarga en los más modernos va a dar problemas de todo tipo: resolución, fallos por usar funciones del SDK obsoletas...


La propia App Store debería de tener un sistema que detecte para que versión del sistema operativo se hizo esa App, y por lo tanto no aparecer o avisar de alguna manera cuando se vaya a instalar.

Ejemplo, yo tengo un iPhone 6, y algunas aplicaciones ya no me deja actualizarlas o instalarlas por no tener la última versión del iOS, pues lo mismo pero para aplicaciones mas antiguas, no creo que sea un tema tan complejo en pleno 2022...


Sería una buena solución, o incluso por defecto ocultar al usuario los juegos obsoletos hasta que no los busque o active la opción de "quiero juegos no optimizados para mí dispositivo".
Me parece perfecto, no entiendo los comentarios que critican esto. Aunque la app funcione bien, dejarla un tiempo sin actualizar por parte del desarrollador puede ocasionar problemas de seguridad.
la noticia es correcta?

A mi hace más de un año que me llegan estos avisos y algunas app ya me las han "descatalogado"

Por otra parte, los que la hayan comprado SI pueden volver a descargarla

De todas formas me parece normal, apps compiladas con el sdk de ios 1,2 o 3 ni arrancan ya
Ha si hacen limpieza…
blackorwhite escribió:@bainomamueles
Porque su código puede ser vulnerable. A las nuevas aplicaciones se les exige un mínimo de seguridad.

Y si no lo es también la borran. El baremo no puede ser antigüedad y solamente la antigüedad, pues eso no indica nada. Una App puede ser antigua pero estar bien hecha, ergo no tener fallas. Si ese es el caso, pues que esa sea la causa de la eliminación con el aviso de que se actualice para cubrir la falla de seguridad, pero no es el caso.

Esto es el día a día del desarrollo en móvil, cada día se sacan una chorrada que obliga a actualizar todo lo anterior. Cuantas más publicaciones tengas, más trabajo reiterativo que se acumula con cada tontería que se sacan de la manga. A los devs de móviles se les maltrata demasiado.

Y si una App no funciona bien en una versión de dispositivos, pues que no aparezca en la tienda como compatible y listo.
darksch escribió:
blackorwhite escribió:@bainomamueles
Porque su código puede ser vulnerable. A las nuevas aplicaciones se les exige un mínimo de seguridad.

Y si no lo es también la borran. El baremo no puede ser antigüedad y solamente la antigüedad, pues eso no indica nada. Una App puede ser antigua pero estar bien hecha, ergo no tener fallas. Si ese es el caso, pues que esa sea la causa de la eliminación con el aviso de que se actualice para cubrir la falla de seguridad, pero no es el caso.

Esto es el día a día del desarrollo en móvil, cada día se sacan una chorrada que obliga a actualizar todo lo anterior. Cuantas más publicaciones tengas, más trabajo reiterativo que se acumula con cada tontería que se sacan de la manga. A los devs de móviles se les maltrata demasiado.

Y si una App no funciona bien en una versión de dispositivos, pues que no aparezca en la tienda como compatible y listo.


Puede estar bien hecha, pero si el lenguaje que usen tiene vulnerabilidades... Por ponerte un ejemplo con swift:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=swift
zenit19 escribió:
darksch escribió:
blackorwhite escribió:@bainomamueles
Porque su código puede ser vulnerable. A las nuevas aplicaciones se les exige un mínimo de seguridad.

Y si no lo es también la borran. El baremo no puede ser antigüedad y solamente la antigüedad, pues eso no indica nada. Una App puede ser antigua pero estar bien hecha, ergo no tener fallas. Si ese es el caso, pues que esa sea la causa de la eliminación con el aviso de que se actualice para cubrir la falla de seguridad, pero no es el caso.

Esto es el día a día del desarrollo en móvil, cada día se sacan una chorrada que obliga a actualizar todo lo anterior. Cuantas más publicaciones tengas, más trabajo reiterativo que se acumula con cada tontería que se sacan de la manga. A los devs de móviles se les maltrata demasiado.

Y si una App no funciona bien en una versión de dispositivos, pues que no aparezca en la tienda como compatible y listo.


Puede estar bien hecha, pero si el lenguaje que usen tiene vulnerabilidades... Por ponerte un ejemplo con swift:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=swift

Pero eso será si usa funcionalidades afectadas por las vulnerabilidades. El caso es que no se distingue nada, se va a saco con la antigüedad como única norma. Seguro que tendrá vulnerabilidades la versión incluso de hace un mes, así que tenían que darle esos 30 días a todas las apps de la store, si fuera sólo por eso.

No sé, que retire MS de la tienda de Xbox todo lo de Xbox 360, que fue una consola exploiteada. O Steam todo lo que sea o funcione para algo anterior a Windows 10 (y ya estamos dando manga ancha), que son SSOO ya sin soporte de seguridad, y puede traer vulnerabilidades.
@Alejo I en el email pone otras razones aparte de ls antigüedad curiosamente las obviaste y fuiste a la que te intereso para los clickbait curioso no?
69 respuestas
Archivado
1, 2
Volver a Tecnología