¿Cómo reutilizar código entre apps? Una base común para mis juegos, con casos reales
Si vas a tener más de una app (varias marcas, varios productos, versiones por rubro), la segunda no debería costar lo mismo que la primera. Qué se comparte, qué no, y lo que sale mal cuando copiás de más.
Reutilizar código entre apps significa construir una base común (inicio de sesión, usuarios, pagos, publicidad, diseño, sincronización) y escribir desde cero solo lo que hace única a cada app. Bien hecho, la segunda app cuesta una fracción de la primera: Killer Sudoku Play reutilizó la mayor parte del código de Sudoku Play, y lo nuevo fue solo lo que la hace distinta.
Te cuento cómo armé esa base para mis juegos, qué se puede compartir y qué no, y lo que salió mal cuando copié de más. Si tenés varias marcas, varios productos o querés una versión de tu app para cada rubro, la lógica es la misma.
¿Cuánto se reutilizó en cada app?
| App | Base | Reutilizado | Qué fue nuevo |
|---|---|---|---|
| Killer Sudoku Play | Sudoku Play | La mayor parte | Tablero con jaulas, cálculo de combinaciones y generador de puzzles Killer |
| Block Drop Play | Infraestructura común de los juegos | Buena parte | Motor de piezas que caen y rotan |
| Color Match Drop | Block Drop Play | Poco | Motor de evolución de colores, biomas y audio generativo |
| Color Sudoku Play | Sudoku Play | Mismo servidor y estructura | Sistema de colores y un diseño visual completamente propio |
Cuanto más distinta la mecánica, menos se reutiliza.
¿Qué se puede reutilizar y qué no?
La regla que uso: se comparte todo lo que el usuario no percibe como "el producto"; se hace a medida lo que lo distingue.
- Se reutiliza: inicio de sesión con Google y Apple, perfiles de usuario, sistema de amigos, sincronización sin conexión, publicidad, suscripciones, stores base, sistema de diseño, reportes de errores e idiomas (español e inglés).
- Se reutiliza con adaptación: pantallas que muestran datos parecidos, como estadísticas, rankings o la tienda de temas.
- No se reutiliza: el motor del juego (o, en un negocio, la lógica propia de cada rubro) y los componentes de la pantalla principal.
- Nunca se copia: la identidad. Nombre, ícono, capturas, identificadores de anuncios y códigos de productos tienen que ser propios de cada app.
¿Cómo se reutiliza sin romper lo que ya funciona?
El riesgo de compartir componentes es que, para adaptarlos a la app nueva, termines modificando los originales y rompiendo la app anterior. En Killer Sudoku Play usé un patrón "puente": una capa intermedia traduce los datos del Killer al formato que esperan los componentes de Sudoku Play, sin tocarlos. Así reutilicé casi todo escribiendo muy poco código nuevo.
Con el contenido pasó algo parecido. Generar miles de puzzles Killer con solución única desde cero es costoso, así que un script armó las jaulas sobre las soluciones ya verificadas de Sudoku Play y clasificó la dificultad automáticamente. Reutilizar no es solo código: también datos, contenido y procesos.
¿Varias apps pueden compartir el mismo servidor?
Sí, y es donde más se ahorra. Todos mis juegos usan un solo servidor con una sola base de datos. Los usuarios y las amistades viven en un espacio común, y cada juego tiene su propio espacio con sus tablas, vistas y funciones, aislado de los demás. El usuario se registra una vez y usa la misma cuenta en todas las apps; en Block Drop Merge y Color Match Drop, la lista de amigos es la misma que en Block Drop Play.
Y se puede elegir qué compartir: Killer Sudoku Play comparte la experiencia y los niveles con Sudoku Play, pero las monedas y las rachas son independientes. Esto lo pensé desde la primera app: el espacio común de Sudoku Play ya estaba preparado para varios juegos. Cómo elegir dónde guardar los datos de una app lo comparo en qué servidor conviene para una app.
¿Qué sale mal cuando copiás de más?
Tres cosas me pasaron. Primero, en Block Drop Play el código reutilizado traía claves de almacenamiento y códigos de compra de otros juegos: dos apps en el mismo celular podían pisarse los datos. Revisé todos los archivos afectados y renombré todo con un prefijo propio.
Segundo, en Block Drop Merge quedaron los identificadores de anuncios de Block Drop Play y un ícono genérico, y Apple la rechazó por "spam". Tercero, Color Sudoku Play compartía tanto con Sudoku Play que Apple la consideró demasiado parecida, y tuve que rediseñarla entera. Los tres casos, con cómo los resolví, están en por qué Apple rechaza una app. La lección: reutilizá el código, nunca la identidad.
¿Qué significa esto para tu negocio?
Si tenés varias marcas, una franquicia con locales que quieren su propia app, o una solución que querés ofrecer a distintos rubros, conviene pensarlo como una base más capas. La base (usuarios, pagos, notificaciones, panel de administración) se construye una vez; cada marca o rubro suma su identidad visual y sus funciones propias.
Eso tiene dos consecuencias en el presupuesto. La primera app cuesta algo más, porque hay que construirla pensando en que se va a reutilizar. Las siguientes cuestan bastante menos, porque la mayor parte ya existe. Los rangos generales están en cuánto cuesta hacer una app y los plazos en cuánto tarda desarrollar una app. Y ojo con las tiendas: Apple mira con lupa las apps hechas en serie, así que cada versión tiene que tener identidad y contenido propios.
¿Cuándo no conviene reutilizar?
Cuando las apps se parecen solo en la superficie. Color Match Drop reutilizó poco de Block Drop Play: forzar más habría significado deformar componentes pensados para otra mecánica. También cuando la reutilización te obliga a mantener funciones que la app nueva no necesita. La base común tiene que ser chica y estable; si cada app nueva te obliga a cambiarla, deja de ser una base.
Killer Sudoku Play: una app nueva sobre una base que ya existía
Killer Sudoku Play reutiliza la mayor parte de Sudoku Play: modo aventura, duelos 1 contra 1, sistema de amigos y funcionamiento sin conexión. Lo nuevo fue el tablero con jaulas, el cálculo de combinaciones y los puzzles Killer generados sobre soluciones ya verificadas. Comparte cuentas y experiencia con Sudoku Play, con monedas independientes, y está publicado en la App Store.
Ver Killer Sudoku Play¿Dónde está la historia completa?
Cómo encadené las primeras apps y en cuánto tiempo lo conté en cómo publiqué mis apps como desarrollador independiente. Las decisiones técnicas de cada motor de juego están en cómo hacer un juego para el celular.
Preguntas frecuentes
¿Cuánto código se puede reutilizar entre dos apps?
Depende de cuánto se parezcan. En mis juegos, entre dos Sudokus se reutilizó la mayor parte; en un juego de bloques, buena parte de la infraestructura común; y entre dos juegos con mecánicas muy distintas, bastante poco.
¿Qué partes de una app se pueden reutilizar?
Todo lo que no es el corazón del producto: inicio de sesión, usuarios, amigos o contactos, sincronización, pagos, publicidad, diseño base, reportes de errores e idiomas.
¿Varias apps pueden compartir el mismo servidor?
Sí. Mis juegos comparten una sola base de datos: los usuarios y los amigos están en un espacio común, y los datos de cada juego en espacios separados, con permisos independientes.
¿Apple acepta apps que comparten código?
Sí, compartir código no es el problema. El problema es que se vean casi iguales o arrastren restos de otra app, como identificadores o íconos. Eso puede terminar en un rechazo por la guideline 4.3.
¿Conviene planificar la reutilización desde la primera app?
Sí. Hacer reutilizable la primera app lleva algo más de trabajo, pero es lo que después permite lanzar las siguientes en una fracción del tiempo.
¿Tenés varias marcas o productos y estás pensando en más de una app? Contame qué querés lanzar y te ayudo a definir qué va en la base común y qué en cada app, antes de gastar dos veces.