Apps Móviles que Sobreviven en el Mundo Real

Por defecto Flutter o React Native para la mayoría de apps — un solo codebase, 40-60% más barato, iteración rápida. Ve nativo (Swift + Kotlin) cuando: (1) rendimiento / animaciones son el producto (juegos high-end, video editing, AR), (2) necesitas acceso muy profundo a APIs nativas desde el día uno, (3) la cadencia de update es tan alta que la cola de review App Store te bloquearía (raro). Para 80% de apps B2B y B2C, cross-platform es la respuesta correcta en 2026.

Apple App Store: típicamente 24-48 horas, ocasionalmente una semana si te rechazan y necesitas atender feedback. Google Play: típicamente 24 horas para updates, 1-7 días para primera submission. Incorporamos timing de review en el plan de lanzamiento y tenemos una checklist de motivos comunes de rechazo (privacy labels, reglas in-app purchase, design guidelines) que aplicamos antes del envío.

Arquitectura offline-first desde el día uno. Base local (SQLite vía Drift en Flutter, Room en Android, Core Data en iOS) es la fuente de verdad. UI lee de la BD local siempre. Un sync engine en background empuja/jala deltas al backend cuando hay red disponible, con reglas de resolución de conflictos integradas. Es difícil de retrofittear — lo diseñamos desde el inicio cuando offline está en scope.

Anticipamos los más comunes: privacy labels (declarados upfront), guideline 5.1 consentimiento recolección de datos, uso de in-app purchase para bienes digitales, sin enlaces rotos, sin contenido placeholder. Cuando ocurre rechazo, respondemos con cambios de ingeniería (no solo apelaciones) — habitualmente de vuelta en cola en 24h. Aproximadamente 8 de cada 10 de nuestras submissions pasan el primer review.

Sí — la mayoría de clientes contrata un retainer con bolsa de horas, rotación on-call para spikes de crash, OTA updates mensuales para fixes no-nativos, revisión trimestral App Store del rendimiento ASO. Algunos clientes toman 100% ownership en el lanzamiento y nos llaman para releases mayores. Ambos modelos funcionan.

Sí — y lo hemos hecho más de una docena de veces. La Fase 1 es una auditoría: calidad de código, decisiones de arquitectura, deuda técnica, funcionalidades inacabadas, acceso a la cuenta App Store, completitud del código fuente. La auditoría produce una recomendación 'continuar tal cual / refactorizar partes específicas / reconstruir'. La mayoría del tiempo continuamos y refactorizamos incrementalmente; casos ocasionales necesitan rebuild, en cuyo caso reutilizamos el design system y la presencia App Store.