La respuesta corta
Una app de marca que vende en varios países no es una app traducida. Es una app en la que casi todo varía por mercado: el catálogo, el precio, la disponibilidad, los métodos de pago, los textos legales, la fiscalidad y hasta qué se puede afirmar de un producto.
La decisión que ordena el proyecto entero: una sola app para todos los mercados, o una por mercado. Y la respuesta por defecto —una sola— exige que el modelo de datos esté preparado desde el primer día, porque convertir una app de un mercado en multipaís a posteriori es prácticamente reescribirla.
Es lo que hicimos para ISDIN: una app mCommerce en Flutter desplegada en ocho mercados, Estados Unidos incluido, con catálogo, programa de puntos y comercio electrónico en una sola aplicación.
El pago: la regla que hay que conocer antes de diseñar
Para una app de retail, esta es la línea que separa lo que puedes hacer de lo que no. Las directrices de revisión de Apple lo dicen literalmente:
«Si tu app permite comprar bienes físicos o servicios que se consumirán fuera de la app, debes usar métodos de pago distintos de la compra dentro de la app para cobrar esos importes, como Apple Pay o la introducción tradicional de una tarjeta de crédito.»
Traducido: el carrito de tu tienda no pasa por la compra integrada. Se cobra con Apple Pay o con tarjeta, como en cualquier comercio.
El matiz que cambia el proyecto: si además vendes algo digital que se consume dentro de la app —una suscripción a contenido, una funcionalidad premium— eso sí entra en el régimen de compra integrada, con su comisión y sus reglas. Muchos productos de marca acaban teniendo las dos cosas, y conviene tener claro desde el principio en qué lado cae cada una. El tema tiene su propia conversación en bienes digitales, iOS y Stripe.
Lo que varía por mercado, y hay que modelar
Esta lista es el corazón del diseño de datos:
| Dimensión | Qué cambia |
|---|---|
| Catálogo | Qué productos existen en ese país. Casi nunca es el catálogo completo |
| Precio | Por mercado y por divisa, no por conversión automática |
| Impuestos | Precio con o sin impuestos según el país, y tipos por categoría |
| Disponibilidad | Stock por mercado, y productos temporalmente no vendibles |
| Contenido regulado | Lo que se puede afirmar de un producto varía por país |
| Textos legales | Privacidad, condiciones, derecho de desistimiento |
| Métodos de pago | Los locales importan más que los globales |
| Envío y devoluciones | Plazos, costes y operativa |
Y una consecuencia práctica que sorprende: un mismo producto puede tener nombre distinto en dos países. Si el modelo asume que el nombre pertenece al producto y no a la combinación producto-mercado, ese es exactamente el punto por donde revienta.
Idioma y mercado no son lo mismo
El error más repetido: usar el idioma del dispositivo para decidir el mercado.
- Un usuario en Estados Unidos con el teléfono en español compra en Estados Unidos, en dólares, con su catálogo y su fiscalidad.
- Un usuario en España con el teléfono en inglés compra en España, en euros.
Es decir: el mercado lo decide el usuario —o el país de la tienda desde la que descargó, como punto de partida— y el idioma es una preferencia independiente. Mezclarlos produce el bug más caro de este tipo de producto: pedidos con precios del país equivocado.
Y hay que diseñar el caso del viajero: alguien que se muda o pasa una temporada fuera. ¿Cambia de mercado? ¿Qué pasa con su carrito, sus puntos y su histórico de pedidos?
Las tiendas también son por territorio
- Fichas por territorio: textos, capturas y palabras clave se localizan por país, no solo por idioma. Es donde se gana descubrimiento y es trabajo recurrente.
- Disponibilidad de la app país a país.
- Clasificación por edad y requisitos legales que varían.
- Un lanzamiento por mercado, no todos a la vez. Es la forma de aprender sin quemar el mercado principal.
Lo que se subestima
- El contenido. Ocho mercados son ocho catálogos que alguien tiene que mantener. Si no hay un proceso claro de quién publica qué y cuándo, la app se llena de fichas incompletas y eso se ve.
- La gobernanza. Cada país quiere su excepción. Sin alguien que decida qué es común y qué es local, la app acaba siendo ocho apps dentro de un binario.
- El rendimiento del catálogo. Miles de referencias con imágenes, por mercado. La estrategia de descarga y caché es una decisión de arquitectura, no un detalle.
- Las pruebas. Probar ocho mercados no es probar uno ocho veces: hay combinaciones de moneda, impuesto y método de pago que solo se dan en uno.
Antes de estimar
- ¿Cuántos mercados en el lanzamiento y cuántos en el plan a dos años?
- ¿El catálogo y los precios salen de un sistema único o de uno por país?
- ¿Qué entidad legal vende en cada mercado?
- ¿Hay contenido digital de pago, además del producto físico?
- ¿Quién decide qué es común y qué es local?
La quinta no es técnica y es la que más determina si el proyecto se mantiene sano después del primer año.
Es lo que hacemos en apps de retail para empresa y en digitalizar una marca de consumo: construir un producto que escala a más mercados sin multiplicar el equipo.
Fuente, consultada el 14 de agosto de 2026: App Review Guidelines, sección 3.1.3(e).
