Epic se burla del comercial más famoso de Apple como venganza al bloqueo de Fortnite de la App Store

La guerra entre Epic Games y Apple por el bloqueo de Fortnite de la App Store de iOS después de saltarse las reglas que prohiben hacer cobros directos dentro de las apps, está escalando muy pero muy rápido. Minutos después del bloqueo de Fortnite de la App Store de iOS, Epic Games, creadores de Fornite, anunciaron que estrenarán un corto dentro del juego llamado Nineteen Eighty-Fortnite. Una obvia parodia del comercial más famoso e icónico de Apple, con el que anunciaron la Macintosh original.

[#101 Zade]

#100 porque ese mismo codigo tiene que dar soporte a 2 sistemas diferentes con sus particularidades, tienes que bifurcar y hacer codigo especifico para cada uno que añaden conplejidad al proyecto (más que si lo haces directamente por separado usando directamente las apis del sistema sin depender de terceros). Por no hablar de que vas a rebufo de las novedades que cada sistema saca en sus apis nativas, por lo que o te haces un plugin nativo para soportarlas o esperas a que tu dependencia de turno lo haga.

“ la cruda realidad varios años después es que los ingenieros de Airbnb se veían obligados a mantener tres bases de código: una en React.js, otra con las implementaciones concretas para iOS y otra para Android. Por supuesto, cada actualización llevaba a volver a repetir este proceso por triplicado con sus diferencias entre versiones.”


No necesitas 100 millones de beneficio. Por medio millón al año puedes contratar un equipo nativo a cualquier consultora. O directamente contratar tu mismo a 2~4 desarrolladores, que te pueden salir por 60k (incluyendo gastos laborales) cada uno.

Esta claro que si eres panadero, pues se lo pides gratis a tu sobrino que hizo un cursillo de html5 y se cree la polla, pero si eres una empresa medianamente seria y tu app está en el centro de tu estrategia, ni te lo pienses, hazla nativa y ten el control de tu app

[#102 Escheriano]

Es muy fácil ir a por Apple, que es lo mediático, pero cuidado:

Google Play Store: 30% de comisión (15% para suscripciones de más de 12 meses).

Apple App Store: 30% de comisión (15% para suscripciones de más de 12 meses).

Samsung Galaxy Store: * Google Play Store: 30% de comisión (o según acuerdo).

Microsoft Store: 30% en juegos, educación, business y para dispositivos con Windows 8. 15% el resto.

Amazon App Store: 30% de comisión (20% para suscripciones de streaming).

Xbox: 30% de comisión.

PlayStation: 30% de comisión.

Nintendo: 30% de comisión.

Steam: 30% por debajo de 10 millones; 25% entre 10 y 50 millones; 20% por encima de 50 millones de dólares

[#103 --1479--]

#98 Similares pero no iguales, claro, claro...

[#104 AGlC]

pedazo de argumentación que has hecho ¿Las meninges bien? Cuidado no te las hayas lesionado.

[#105 Pitt]

#101 Pero es que insisto, el problema con Airbnb es que el motor estaba en pañales. Si coges un sistema híbrido que funciona mal incluso con las cosas básicas, pues es lo que pasa, claro.

¿Cuantas empresas hay en España que dispongan de medio millón al año para gastar en desarrollos? En 2019 había unas 70.000 empresas con +20 empleados, frente a más de 3.200.000 empresas con menos de 20, de las cuales casi 2 millones tienen 0 empleados.

Con esas cifras, para la mayoría de empresas meterse en un doble desarrollo es muy difícil. Si, que si eres un unicornio al que han inyectado 2 millones de euros y tu producto es una app te lo puedes permitir y evidentemente es más óptimo (que no más barato), pero la mayoría pues lo tienen chungo.

[#106 --654482--]

#89 Sé perfectamente lo que es GateKeeper (y en el artículo que te he adjuntado verás que el investigador dice que muchas apps del propio Apple se la saltan).

Así que el hecho de que cada vez que que ejecute un programa (incluso un simple script de comandos) mi ordenador se conecte con Apple para decirle lo que estoy ejecutando.. Es por mi seguridad ¿no?

Entonces, también debería de informar a la policía de a cada sitio que voy y sacar una foto de los mismos, ya que es posible que haya un atracador escondido en esa zona ¿no?

Los que cambiáis privacidad por seguridad no merecéis ni la una ni la otra.

[#107 --654482--]

#93 En el artículo dice que las webapp son permitidas (cosa que nunca he negado) pero son mutiladas para que prácticamente sean inservibles: Borrado de información cada quince días, imposibilidad de descargartelas de un sitio web que no la publique en su home, etc.

Seguramente el hecho Spotify, Telegram, Hey y unas cuantas más junto con la Comisión Europea estén abriendo un juicio contra Apple por monopolio debe ser porque se aburren ¿no?

ec.europa.eu/commission/presscorner/detail/en/ip_20_1073
www.indiatoday.in/technology/news/story/after-spotify-telegram-files-c

[#108 Zade]

#105 a ver, es que esas empresas de las que tu hablas son las que yo digo del panadero, que son la mayoría. Ahora bien, te sorprenderías de la de empresas del Ibex de las que facturan miles de millones de euros al año con presupuestos inmensos que van a hacer una app para usuarios finales y los muy inutiles, en la mayoría de los casos porque se lo dijo su cuñao, te exigen que les hagas la app hibrida y que les cobres la mitad de lo presupuestado (por tanto, se le da al becario que incluso tarda el doble o mejor se deja ir el contrato)

PD: Para muestra, al app de Naturgy. Menuda castaña de app con la de pasta que nos sacan a los usuarios...

[#109 --654482--]

#71 No voy a volver a pegar los artículos que ya he puesto, por favor leetelos y luego lo discutimos.

[#110 --654482--]

#75 ¿Has oído hablar de Flutter?
Con Flutter puedes hacer apps para IOS/Android/Linux/Windows/Mac y el rendimiento es prácticamente igual al nativo.

Lo mismo con LiveCode.

Esas dos plataformas compilan a C++

[#111 --527011--]

#76 Justo, yo trabajo con unreal, y no sé, creo que Epic se porta bien, a ver es una empresa y como tal saca pasta, pero por ejemplo no tenía que regalar Quixel, la podía haber comprado y seguir cobrando los casi 11k euros al año que te cuesta la licencia full. pero tienes todo el software, y un montón de shaders para hacer más shadres.

[#112 --527011--]

#70 Hombre comparar las apps de samsung con las de Iphone, no sé, No creo que Samsung le cobre nada a Netfilx HBO o Amazon de cada subscriptor, y es mas o menos eso lo que hace Iphone.

[#113 Zade]

#110 Si si, hemos hecho cositas con Flutter en mi empresa y pinta mucho mejor que las web apps e incluso que react native. Igualmente asi de primero lo usaría solo para apps sencillas (pero sin quitarle el ojo)

La otra alternativa que más me gusta (aunque también está pelín verde) es kotlin native. Se puede hacer el core en kotlin para ambas plataformas y luego la capa de UI (y otras capas externas) en Swift y Kotlin. Asi tienes lo mejor de ambos mundos sin dejar de usar las apis nativas.

[#114 --527011--]

#63 Llevas justo un año menos que yo, yo llevo con unreal desde unreal3 cuando era de pago.
Y un equipo como el de Epic te saca ese vídeo en 24 horas sin problema, de hecho puedes ver como montan enviroments más complejos en dos horas. Ahí no hay material nuevo, no han hecho un solo material, modelo, ni animación, Y supongo que tendrán a un par de cracks ahí dentro que controlen sequencer.
Y del render ni hablamos.

[#115 dudo]

#107 no, entras en la dir de la webapp y la añades a la home del teléfono, se crea un icono como si instalaras una app, y de ese modo no borra la información local a los 7 días

[#116 dudo]

#106 lo que dice el artículo es que catalina tarda muchisimo la primera vez que arranca porque notariza todos los ejecutables incluidos los scripts, esto lo hace solo una vez.

Luego mientras no se modifique el ejecutable o script no avisa a nadie, no hace tracking no llama a la policía ni al FBI

Incluso si eres desarrollador y estas desarrollando una app puedes hacer que tu app no se notarice hasta que esté completada.

Es un sistema automático para evitar que el código se adultere, y sólo se notariza la primera vez que se ejecuta algo nuevo, una vez notarizado no lo hace más, y lo puede hacer en local. No es necesario estar online para ejecutar un script.

[#117 --654482--]

#116 Se perfectamente lo que dice el artículo porque te lo he mandado yo, y me parece un atentado contra la privacidad el sistema de notarización,
No solo lo digo yo, sino que lo dice media Internet.

Apple no tiene porque llevar un recuento de cada Script o cada app que instalo / modifico en mi equipo,

Solo por eso, he regalado mi imac a mi mujer y he vuelvo a Linux.

[#118 dudo]

#117 y no le instalas linux a tu mujer en el mac?

[#119 --654482--]

#115 Pues el artículo no dice eso, pero además mira lo que dice otro tío que lleva 20 años haciendo apps y que es bastante pro-apple:

Right now, the biggest progressive web application limitation on iOS is the small cache capacity quota Apple imposes, ~50MB.

Because Apple assumes space on its devices is cramped, they aggressively throw unused items overboard to free up disk space.


If your PWA or any website for that matter, goes unused for a few days (we think it is roughly 14 days, it is not documented) the device will remove all cached assets associated with the origin. This includes IndexedDB, service worker cache, localStorage, etc.

This has made relying on cached assets a bit of an issue. The real problem lies when a user might try to load your PWA while they are offline for the first time in a month. The PWA won’t work, even if your service worker pre-caches all the required files for offline functionality.

This means you should also build in a check for purged cached assets in your service worker. I think just important is you should also include some sort of notice for your users if they expect the application to function offline.

Let them know the content they are caching now may not be available if unused for a long period of time. If they anticipate needing your app for offline usage try to plan ahead.

In theory your cached content could be purge by other browsers too, but they are not as aggressive. Providing a message to set user expectations can go a long way to curb potential issues down the road.

Yo no voy a hacer una app que un usuario no puede usar offline.

love2dev.com/pwa/ios/

[#120 --654482--]

#113 Sinceramente yo creo que Kotlin será fagocitado por Dart,
Básicamente por dos temas;

1) Dart es un lenguaje de programación "hecho en casa" y Google no quiere depender de JetBrains.
2) Kotlin usa la JVM por debajo y Oracle está sangrando a Google por el uso de sus librerías Java.

Ahora que tenemos FLutter, Dart se irá extendiendo mas y más.

De hecho, Dart es e lenguaje de programación oficial de Fucsia (el sistema operativo que sustituirá a Android).

[#121 --654482--]

#118 Me corta los huevos. Es macquera desde que tenía doce años.
Tiene dos portátiles Mac y ahora el Imac de 27

[#122 Zade]

#120 Bueno, Kotlin native por lo que tengo entendido no usa la jvm (de ahi lo de “native”) está basado en lvvm (como Swift) por lo que el rendimiento es mucho mejor y es lo que le permite compilar un framework de iOS.

Por otra parte creo que es Open Source, por lo que no debería ser un problema para Google

En cuanto a Dart, pues veremos a ver, no me desagrada, pero prefiero Swift/Kotlin que son primos hermanos (es más yo los “fusionaría” y acabaría con la discusión)

[#123 --654482--]

#122 No sabía que Kotlin ya estuviera desligado de la JVM, Eso abre muchas posibilidades.

Lo del Open Source es relativo, ya que JetBrains se reserva el derecho a crear nuevos estándares para Kotlin, es decir: El "comité" que decide hacía donde va el lenguaje lo decide JetBrains no Google.

Dart tiene varias cosas que son alucinantes: Compilación AOT, máquina virtual, posibilidad de sustituir completamente a JS en los navegadores (te ahorras el bregar con JavaScript), generación de ejecutables nativos para Windows / Mac / Linux / IOS y Android, poder usarlo como script de línea de comandos, como servidor en aplicaciones backend (como node.js), lenguaje de programación para sistemas embebidos, etc.

Es decir: Se puede hacer absolutamente de todo con el mismo y puedes programar lo que te de la gana (incluso aplicaciones frontend).

El problema es que ahora mismo hay prácticamente cero ofertas de trabajo para programadores de Dart y un ecosistema diminuto.

[#124 asenei]

#87 los juicios anti-monopolio en EE.UU. no funcionan así, básicamente tu convences (o compras) X senadores para que quieran meterse en el jaleo y una vez que tienes a los suficientes convencidos es el gobierno el que denuncia a la empresa. En realidad el tema es bastante barato, pero tiene que ser un caso claro y haber intención política para "castigar" a esa empresa, y los dos factores se están dando ahora mismo.

[#125 Pitt]

#108 Sí, en ese caso es absurdo tener una híbrida, especialmente si mucho de tu negocio se hace vía app. La de Naturgy pues bueno, si lo que hace (por lo que veo) es simplemente mostrarte datos de facturas y tal... Con una híbrida bien hecha no debería notarse apenas diferencia. Pero teniendo mucha pasta yo tiraría a nativa, claro.

[#126 --654482--]

#96 Te has quedado en el Dart 1.0 de 2011.
Has hecho una búsqueda en Internet y has leído lo primero que te ha salido.

Dart es nativo.

Dart tiene varias cosas que son alucinantes: Compilación AOT, máquina virtual, posibilidad de sustituir completamente a JS en los navegadores (te ahorras el bregar con JavaScript), generación de ejecutables nativos para Windows / Mac / Linux / IOS y Android, poder usarlo como script de línea de comandos, como servidor en aplicaciones backend (como node.js), lenguaje de programación para sistemas embebidos, etc.

Es decir: Se puede hacer absolutamente de todo con el mismo y puedes programar lo que te de la gana (incluso aplicaciones frontend).

El problema es que ahora mismo hay prácticamente cero ofertas de trabajo para programadores de Dart y un ecosistema diminuto.

[#127 --654482--]

#91 Estoy defendiendo a Dart. Trabajo con Dart.

[#128 Or3]

#45 Ya lo intentaron hacer y les salió como el culo.