Cómo un modelo de IA de 115 MB tumbaba Safari en el iPhone

Gabriel Maglia — Sat, 24 Oct 2026 22:41:23 +0000

Hace unos meses empecé un proyecto personal: PhotoCut, un editor de fotos que quita el fondo con IA sin subir la imagen a ningún servidor. Todo corre en el navegador: la IA, el recorte y la exportación.

La idea salió de una molestia concreta: los removedores de fondo gratis que encontraba suben tu foto a sus servidores y después te cobran la descarga en buena calidad. Quería uno que no hiciera ninguna de las dos cosas.

Les cuento cómo está armado y, sobre todo, los problemas que no vi venir.

Cómo funciona por adentro

El recorte con IA usa onnxruntime-web dentro de un Web Worker, para no congelar la interfaz.
Dos modelos según el equipo:
- En computadoras con una GPU que el navegador puede usar (WebGPU), corre BiRefNet-lite en fp16. Pesa unos 115 MB y recorta con mucho detalle.
- En celulares y equipos sin GPU, corre u2netp sobre WebAssembly. Pesa 4,6 MB.
El refinado de bordes es un motor GrabCut que escribí en Rust y compilé a WebAssembly.
La primera vez se descarga el modelo y queda en caché. Después del primer recorte, la app funciona hasta sin internet.

Para comprobar que la foto no sale del navegador, medí una sesión completa: 93 peticiones de red y ninguna lleva la imagen. Cualquiera lo puede verificar abriendo la pestaña Red (Network) mientras recorta.

El bug: Safari en iPhone recargaba la página

Todo andaba perfecto en mi Mac. Hasta que lo probé en un iPhone 13: tocaba «Recorte IA», bajaba el modelo... y la página se recargaba sola. Sin ningún error en la consola, sin excepción, nada.

La hipótesis

iOS 26 trae WebGPU activado en Safari, y la GPU del iPhone cumple las condiciones que yo chequeaba (adapter de hardware, shader-f16, suficientes storage buffers). Entonces el código decidía: «hay GPU apta → uso BiRefNet».

El problema es la memoria. El modelo de 115 MB se carga más de una vez: el buffer descargado, la copia dentro del runtime de ONNX y los buffers en la GPU, que para imágenes de 1024×1024 suman cientos de MB. iOS tiene un límite de memoria por pestaña, y cuando lo pasás mata el proceso (lo que en iOS se llama jetsam). Safari simplemente recarga la página.

Y como el proceso muere, no hay ningún error que el código pueda atrapar. Mi lógica de respaldo («si BiRefNet falla, uso u2netp») nunca llegaba a ejecutarse. Peor: al recargar no quedaba registro del intento, así que se reiniciaba cada vez.

La prueba

Antes de tocar código, una prueba de dos minutos: en el iPhone, Ajustes → Safari → Avanzado → Feature Flags, desactivar WebGPU. Sin WebGPU el código elige u2netp... y el recorte anduvo perfecto. Hipótesis confirmada.

La solución, en dos capas

Regla de dispositivo: en celulares y tablets se usa siempre el modelo chico, aunque haya WebGPU. Ojo con el iPad, que se presenta como Mac en el user agent: la pista es navigator.maxTouchPoints > 1. Y ojo con los Web Workers, que no tienen maxTouchPoints ni screen: el hilo principal calcula «es móvil» y se lo pasa al worker.
Marca anti-bucle: antes de abrir el modelo grande, guardo en IndexedDB una marca de «intento en curso» (IndexedDB sí existe dentro del worker; localStorage no). Si el recorte termina bien, la borro. Si la página se recarga y la marca sigue ahí, el siguiente intento va directo al modelo chico. La marca vence a los 7 días, por si fue un cierre casual de la pestaña.

La segunda capa existe porque la primera puede fallar con algún dispositivo que no anticipé. Ningún equipo debería quedar recargándose para siempre.

La lección: los tests en el WebKit de Playwright pasaban todos, porque en la Mac no hay WebGPU en ese contexto. Un iPhone real encontró en dos minutos lo que ningún test veía.

Bonus: Safari y el WebP que en realidad es PNG

Uno de los presets exporta stickers de WhatsApp: WebP de 512×512, de menos de 100 KB.

En Chrome y Firefox, canvas.toBlob(cb, 'image/webp', calidad) funciona. En Safari no tira error: te devuelve un PNG. Si nombrás el archivo según el formato que pediste, terminás entregando un PNG llamado .webp.

Lo que hice:

Detecto una vez si hay WebP nativo: codifico un canvas chiquito y miro blob.type.
Si no hay, cargo libwebp compilado a WebAssembly (unos 110 KB) en un worker dedicado, solo en ese caso. Los usuarios de Chrome nunca lo descargan.
El nombre del archivo sale del tipo real del blob, nunca del que pedí.
En los tests con WebKit verifico que los bytes empiecen con RIFF....WEBP.

Lo que aprendí

Correr IA en el navegador ya es viable, pero el límite real no es la velocidad, es la memoria en celulares.
Un proceso que muere no avisa. Si tu lógica de respaldo depende de atrapar un error, no te va a salvar de un jetsam.
Probá en dispositivos reales. Los emuladores y los navegadores de testing no tienen los mismos límites.

Probalo

PhotoCut es gratis, sin cuenta y sin marca de agua, y el código es abierto (MIT). El sitio tiene publicidad de Google para pagar el hosting; esos scripts hacen sus propias peticiones, pero ninguna lleva la foto.

👉 App: https://www.photocutapp.com/editor/
👉 Código: https://github.com/gabiMaglia/PhotoCutOnline

Me encantaría saber cómo anda en sus celulares, sobre todo en equipos de gama baja. ¡Cualquier crítica es bienvenida!

Lo que hice: - Detecto una vez si hay WebP nativo: codifico un canvas chiquito y miro `blob.type`. - Si no hay, cargo libwebp compilado a WebAssembly (unos 110 KB) en un worker dedicado, solo en ese caso. Los usuarios de Chrome nunca lo descargan. - E

Gabriel Maglia — Sat, 24 Oct 2026 22:34:27 +0000

DEV Community: Gabriel Maglia