Por qué los iPhone cierran primero las aplicaciones pesadas

Si tu aplicación está hecha con Flutter o React Native, es más probable que iOS la cierre mientras tu cliente todavía la está usando. No que falle. Que la cierre — en silencio, en segundo plano, y que luego le entregue al cliente una aplicación en blanco cuando vuelva.

Este es el coste menos entendido de elegir un framework multiplataforma, y no aparece en ningún informe de fallos. Así funciona, y esto es lo que te cuesta.

¿Por qué un iPhone cierra una aplicación en lugar de ralentizarla?

Cualquier otro ordenador que tengas resuelve quedarse sin memoria volviéndose más lento. Mueve lo que no has tocado hace tiempo al almacenamiento, deja todo abierto y sigue funcionando. Lento, pero no se pierde nada.

Un teléfono con iOS no hace esto con las aplicaciones. Cuando falta memoria, elige una aplicación y la termina. No hay aviso para el cliente ni ningún diálogo. La aplicación simplemente desaparece, y la memoria que ocupaba vuelve al teléfono.

Apple tiene un nombre para la cifra por la que juzga a tu aplicación. La llama tu huella de memoria, y explica cómo se cuenta en una sesión de la WWDC sobre memoria en iOS. Apple también documenta cómo leer los informes que dejan estos cierres, que es como los desarrolladores se enteran de que ocurrió.

La parte que importa comercialmente es la regla de selección. Las aplicaciones más pesadas se eligen primero.

Tu cliente no ve un fallo. Ve una aplicación que se ha olvidado

Esta es la parte que conviene imaginar, porque a quien le pasa no le parece un error.

Alguien está a mitad de tu proceso de compra. Cambia a su aplicación bancaria para leer el número de una tarjeta. Veinte segundos después vuelve — y tu aplicación se abre en la pantalla de inicio. El carrito está vacío. El formulario está en blanco. Puede que tenga que iniciar sesión otra vez.

No falló nada. iOS cerró tu aplicación en segundo plano para liberar memoria para la aplicación que estaba delante, exactamente como está diseñado. Tu sistema de informes de fallos no mostrará nada, porque no hubo ningún fallo.

Lo que te cuesta no es técnico:

• Carritos abandonados, en el peor momento posible — el cliente ya había decidido comprar
• Inicios de sesión repetidos, que es la queja más habitual en las reseñas de las tiendas de aplicaciones
• Tickets de soporte que dicen “no para de cerrarme la sesión”, casi imposibles de reproducir en el teléfono nuevo de un desarrollador
• Reseñas que dicen que la aplicación “nunca recuerda nada” — y esa reseña sigue ahí mucho después de que lo arregles

Es peor en iPhones antiguos y más baratos. Hay menos memoria que repartir, así que los cierres empiezan antes y ocurren más a menudo. Suelen ser los clientes que menos te puedes permitir perder, y nunca el teléfono en el que prueba tu equipo.

¿De cuánto más peso estamos hablando?

En la única prueba publicada en iPhone que construye la misma aplicación en Swift nativo, Flutter y React Native y mide las tres igual, un solo desplazamiento por una lista de 100 elementos añadió:

Hecha con	Memoria extra de un desplazamiento	Comparado con Swift
Swift nativo	9,74 MB	—
Flutter	25,33 MB	2,6× más
React Native	45,13 MB	4,6× más

SynergyBoat, agosto de 2025. Una aplicación de tarjetas de memoria construida de cuatro formas, iPhone 16 Plus, tres ejecuciones de cada una. El resultado de React Native también varió mucho entre ejecuciones — léelo como “aproximadamente entre cuatro y cinco veces”, no como exactamente 4,6.

Nadie ve su aplicación cerrada por 45 MB sin más. Ese es el punto que se pasa por alto. Ese es el crecimiento de una acción. Tu cliente desplaza una lista, abre un producto, vuelve atrás, desplaza otra vez — y se va acumulando durante la sesión.

La aplicación que crece más rápido llega antes al límite. En el teléfono más barato. En mitad de un proceso de compra.

¿Qué funciones no puedes construir en absoluto?

Dentro de tu aplicación, la memoria es una cuestión de grado — más pesada significa que la cierran antes. Fuera de tu aplicación es un muro.

Los widgets de la pantalla de inicio, las Live Activities de la pantalla bloqueada, las hojas de compartir y los teclados personalizados funcionan con un presupuesto de memoria mucho menor que tu aplicación. Los desarrolladores que se han topado con ese muro sitúan el límite de los widgets en torno a 30 MB. Esa cifra viene de informes de fallos publicados por desarrolladores, no de ninguna especificación de Apple, así que tómala como el orden de magnitud observado y no como un número publicado.

En cualquier caso es pequeño — lo bastante como para que la propia documentación de React Native advierta de que su uso de memoria “tiende a ser demasiado alto” para los más ajustados de estos presupuestos.

La consecuencia pilla tarde a los equipos, y conviene saberla antes de elegir: si los widgets o las Live Activities importan en tu producto, esa parte se escribe en Swift sin importar en qué construyas la aplicación principal. Un framework multiplataforma no elimina ese trabajo nativo. Lo desplaza — y ahora pagas por dos conjuntos de habilidades en lugar de uno.

¿Qué deberías hacer al respecto?

Nada de esto significa que multiplataforma sea la elección equivocada. Significa que la diferencia de memoria es un coste real con un nombre concreto, y que le corresponde estar en la decisión en lugar de descartarse de un gesto.

• Prueba en el teléfono más antiguo que pienses admitir, no en el más nuevo. Este problema es invisible en un iPhone nuevo y evidente en uno de hace cinco años
• Pregúntate si tu aplicación guarda algo que merezca la pena perder. Una aplicación de lectura que olvida por dónde ibas es una molestia. Un proceso de compra, una reserva o un formulario largo son ingresos perdidos
• Si hay widgets en la hoja de ruta, presupuesta Swift sin importar lo que elijas para la aplicación principal
• Si la eficiencia es el producto, este es el argumento para ir a nativo. Pesa más que la velocidad bruta. Piensa en audio en segundo plano, cámara, mapas, IA en el dispositivo y sesiones largas

Para la comparación completa, con todas las cifras que pudimos verificar y las condiciones en que se midió cada una, consulta Swift vs Flutter vs React Native: RAM y CPU, con fuentes. Para una comparación cara a cara: Swift vs Flutter o Swift vs React Native. Si quieres valorarlo sobre un producto concreto en lugar de en abstracto, habla con nosotros — trabajamos con las tres.