Solana Mobile In Depth

Solana Mobile no es un ledger separado ni un RPC especial. Es una pila de cliente y distribución para aplicaciones Solana centradas en Android: las billeteras y las dApps se comunican a través de un protocolo móvil estandarizado, las claves pueden residir en almacenamiento respaldado por hardware en dispositivos compatibles y el descubrimiento puede realizarse a través de una tienda creada para aplicaciones criptográficas en lugar de solo extensiones de navegador.

El escritorio y la web móvil siguen siendo importantes, pero los flujos nativos del teléfono cambian la superficie de integración. No existe window.solana. Los usuarios abandonan tu proceso para ir a una aplicación de billetera y regresan a través de intents. La firma puede estar limitada por datos biométricos y un elemento seguro. El envío a menudo se dirige a la Tienda dApp de Solana, además de (o en lugar de) solo Google Play.

Esta página es el paraguas de la sección para esa pila y la ruta de compilación de React Native con @solana/kit 7.0.0. Las páginas hermanas profundizan en cada rama.

Resumen

• Solana Mobile es una pila de productos centrada en Android donde las dApps autorizan y firman a través de Mobile Wallet Adapter, opcionalmente respaldadas por Seed Vault en dispositivos compatibles, regresan a través de deep links y tokens de sesión, y se distribuyen a través de la dApp Store (y canales estándar de Android) mientras construyen transacciones con el mismo kit/modelo RPC que los clientes web.
• Por qué es Importante: Tratar el móvil como "web responsiva con un botón de billetera" produce flujos de autorización rotos, sesiones perdidas después de saltos de billetera, almacenamiento inseguro de claves locales y revisiones fallidas de la tienda. Un mapa compartido de sesiones MWA, límites de confianza de Seed Vault y restricciones de lanzamiento/distribución previene esas clases de errores.
• Conceptos Clave: Solana Mobile Stack (SMS), Mobile Wallet Adapter (MWA), transact / authorize / reauthorize / deauthorize`, Seed Vault, elemento seguro, deep link / filtro de intent, token de autorización, dApp Store, Seeker / Saga, cliente de desarrollo Expo, @solana/kit.
• Cuándo Usar: Primera orientación antes de estructurar una dApp móvil; elegir MWA vs. custodia integrada; diseñar la experiencia de usuario de conexión/firma/retorno; planificar la seguridad dirigida a Seeker y la presentación a la tienda.
• Limitaciones / Compensaciones: La madurez de Android y MWA lidera iOS; Seed Vault depende del dispositivo/billetera; Expo Go no es suficiente para módulos MWA nativos; el alcance de la dApp Store es nativo de cripto, no a escala masiva de Play; los programas en cadena y el consenso Agave no cambian.
• Temas Relacionados: Fundamentos de Solana Mobile, MWA, construcción de una dApp móvil, deep links y sesiones, seguridad de Seed Vault y la dApp Store.

Fundamentos

Solana Mobile Stack es el nombre del producto para tres piezas que cooperan:

1. Mobile Wallet Adapter - el protocolo y los SDK que permiten a una dApp solicitar autorización y firmas de una aplicación de billetera sin incrustar claves privadas.
2. Seed Vault - almacenamiento de semillas y claves respaldado por hardware en dispositivos Solana Mobile compatibles, expuesto a través de billeteras que implementan la ruta segura.
3. dApp Store - un canal de distribución y descubrimiento para aplicaciones móviles Solana, especialmente aquellas dirigidas a hardware Seeker (y Saga anteriores).

Las marcas de hardware (Saga, Seeker) son dispositivos y ecosistemas, no nuevas máquinas virtuales. Las transacciones todavía llegan a los mismos clústeres a través de la misma superficie RPC que la web. Agave 4.1.1, Anchor 0.32.1 y @solana/kit 7.0.0 siguen siendo la pila orientada a la cadena; el móvil cambia cómo los usuarios firman y cómo envías el cliente.

Mobile Wallet Adapter es el contrato de integración. Tu aplicación presenta una identidad (nombre, URI, icono), solicita autorizar para un clúster, recibe cuentas y un token de autorización, y luego pide a la billetera que firme transacciones o mensajes dentro de una sesión limitada (comúnmente la utilidad transact). La UI de la billetera posee las hojas de aprobación y los prompts biométricos; tu aplicación posee los bytes de transacción serializados y el sendTransaction / confirmación posterior a la firma contra RPC.

Seed Vault es el límite de confianza para las claves en el hardware compatible. El material de la semilla permanece fuera de tu paquete de React Native y fuera del almacenamiento de aplicaciones ordinario. Cuando una billetera dirige la firma a través de Seed Vault, las claves privadas nunca se convierten en memoria de aplicación legible. Tu trabajo de seguridad es más estrecho y estricto: no inventes mnemónicos locales, protege los tokens de autorización y trata los bytes de transacción de red y los logs como lo suficientemente sensibles como para no volcarlos por completo en producción.

Deep links y sesiones son el pegamento del ciclo de vida. Autorizar y firmar a menudo cambian a otra actividad de Android (la billetera). Los filtros de intent correctos, los esquemas de retorno y reautorizar con un token almacenado deciden si los usuarios reingresan a una experiencia conectada o llegan a un callejón sin salida después de la aprobación. El inicio en frío (proceso de la aplicación terminado mientras el usuario está en la billetera) es un caso de primera clase, no un caso extremo.

dApp Store es cómo muchos usuarios de Solana Mobile encuentran e instalan aplicaciones. La presentación requiere artefactos de lanzamiento firmados, política de privacidad, afirmaciones de red honestas y una ruta MWA funcional en hardware de revisión. Es política de distribución y empaquetado, no una segunda blockchain.

Construir una dApp móvil generalmente significa React Native (a menudo Expo con un cliente de desarrollo personalizado para que los módulos MWA nativos se carguen), construcción de transacciones y RPC basada en kit, y MWA para conectar/firmar. Los monorepos pueden compartir clientes generados por kit con la web; solo la capa de adjuntar billetera diverge.

  Usuario en Seeker / Android
       |
       v
  Tu dApp (React Native + @solana/kit)
       |  construye bytes de tx sin firmar / mensajes
       |  transact() -> authorize / sign
       v
  Aplicación de billetera  ---- opcional ----> Seed Vault (elemento seguro)
       |  aprobación + firmas
       |  retorno de intent / deep link
       v
  Tu dApp reanuda sesión (token de autorización)
       |  sendTransaction + espera compromiso
       v
  RPC -> Clúster Agave (igual que la web)

Mecánicas e Interacciones

Ciclo de vida de la sesión MWA

Una secuencia mental productiva para cada pantalla que necesita una billetera:

1. Autorizar (o reautorizar con un token almacenado en caché) con metadatos de identidad completos y la cadena de clúster correcta para tu RPC.
2. Leer cuentas del resultado; almacenar la dirección pública para la UI y la selección del pagador de tarifas; almacenar el token de autorización en almacenamiento seguro, no en logs planos.
3. Construir mensajes de transacción con @solana/kit 7.0.0 de la misma manera que lo harías en la web: instrucciones, metadatos de cuenta, blockhash, pagador de tarifas.
4. Entrar en transact, firmar dentro del callback, salir de la sesión rápidamente (las UIs de billetera caducan con trabajo prolongado).
5. Enviar firmas a través de RPC HTTPS, luego esperar confirmed o finalized según el riesgo del producto.
6. Desautorizar y borrar el token al cerrar sesión o cuando reautorizar falla y fuerzas una autorización completa nuevamente.

La falta de coincidencia de clúster es el clásico fallo silencioso: autorizar para devnet mientras RPC apunta a mainnet-beta (o viceversa). Trata el clúster como un objeto de configuración compartido por MWA, RPC de kit y enlaces de explorador.

Deep links, intents y reanudación

Android mueve al usuario entre paquetes. Los filtros de intent de Expo app.json / prebuild y un esquema personalizado estable (o enlaces de aplicaciones verificados) son requisitos del producto, no pulido.

Maneja la reanudación en caliente (proceso vivo; restaura la UI pendiente), inicio en frío (proceso terminado; restaura el token, reautoriza, rehidrata la navegación), cancelación del usuario (rechaza limpiamente; ofrece reintentar) y token obsoleto (vuelve a la plena autorización). Prefiere el almacenamiento seguro de la plataforma para tokens de autorización sobre AsyncStorage plano.

Seed Vault y seguridad del lado de la aplicación

MWA ya mantiene la firma fuera de tu proceso cuando el usuario usa una billetera externa. Seed Vault fortalece eso en dispositivos compatibles al vincular claves a hardware seguro y datos biométricos mediados por la billetera.

Reglas del lado de la aplicación: nunca envíes frases semilla en bundles de JS o almacenamiento de aplicaciones; minimiza volcados completos de transacciones en logs; mantén cualquier par de claves del servidor fuera del dispositivo; el endurecimiento opcional incluye indicadores de captura de pantalla y detección de root para productos de alto valor.

Construcción y envío

# Estructura (ver opciones móviles actuales de create-solana-dapp)
npx create-solana-dapp@latest --mobile
 
# Expo: se requiere cliente de desarrollo personalizado para módulos MWA nativos
npx expo start --dev-client
 
# Artefacto de lanzamiento para envío a la tienda
eas build --platform android --profile production

Prueba MWA en dispositivos físicos temprano; los emuladores no representan la entrega de intents. La lógica en cadena todavía usa CLI, Surfpool y LiteSVM como la web; simula MWA en pruebas unitarias móviles. La presentación a la dApp Store necesita firma de producción, incrementos de versionCode, política de privacidad y una compilación que complete la autorización/firma en hardware de referencia. Doble vía: Play Store para alcance masivo; dApp Store para descubrimiento en Solana Mobile.

Consideraciones Avanzadas y Aplicaciones

Clientes de monorepo compartidos. Comparte constructores de instrucciones, tipos IDL y ayudantes de RPC entre Next.js y React Native; aísla MWA, deep links y almacenamiento seguro en la aplicación móvil para que las actualizaciones de Anchor 0.32.1 se mantengan alineadas.

Experiencia de usuario de sesión e identidad. Reautorizar para baja fricción; forzar autorización completa después de cambios de privilegios o sesiones fallidas. Un nombre de identidad estable, URI HTTPS e icono reducen la confusión de phishing y deben coincidir con los activos de la lista de la tienda. La reconexión silenciosa está bien para la experiencia de lectura; la firma de alto valor siempre debe sentirse deliberada.

Riesgo de iOS, redes y programas. Android-first es el predeterminado honesto hasta que tu matriz de billeteras cubra iOS; la web móvil puede tender puentes para usuarios intermedios. Diseña reintentos de RPC y esperas de compromiso para redes celulares inestables; la firma local no es liquidación. Las PDAs, los metadatos de cuenta y las reglas de CU son idénticos a la web; el móvil es una preocupación del cliente; las auditorías en cadena todavía dominan el riesgo del protocolo.

Conceptos Erróneos Comunes

• "Solana Mobile es una cadena o runtime diferente." Es un protocolo cliente, almacenamiento de claves de hardware y distribución. Los programas y las cuentas son el mismo modelo de Solana en clústeres Agave.
• "Puedo usar Expo Go como cualquier otra demo de RN." MWA necesita módulos nativos y un cliente de desarrollo personalizado (o flujo bare). Expo Go por sí solo no es la ruta de producción.
• "MWA es solo window.solana en Android." No hay inyección de extensión. Las sesiones, intents, metadatos de identidad y tokens de autorización son el contrato.
• "Almacenar la mnemónica en la aplicación está bien si está cifrada con un PIN." Prefiere billetera externa + Seed Vault. Las semillas en posesión de la aplicación amplían los modos de fallo de brecha y copia de seguridad.
• "Si la autorización tuvo éxito una vez, los deep links no importan." Cada firma puede salir de tu proceso. Las rutas de retorno y la reanudación en frío deciden si los usuarios completan el flujo.
• "La dApp Store reemplaza la higiene de lanzamiento de ingeniería." Todavía necesitas compilaciones de lanzamiento firmadas, versionado, política de privacidad y QA de dispositivos.
• "@solana/web3.js v1 es requerido para móvil." Prefiere @solana/kit 7.0.0 para nuevo trabajo con paquetes MWA que aceptan formatos de red de kit.

Preguntas Frecuentes

Relacionados

• Fundamentos de Solana Mobile - vista general de la pila y primeros ejemplos móviles
• Mobile Wallet Adapter (MWA) - API de autorización, firma y sesión
• Construcción de una dApp Móvil - React Native, Expo e integración de kit
• Deep Links y Manejo de Sesiones - intents, rutas de retorno, tokens de autorización
• Seed Vault y Seguridad - claves respaldadas por hardware y modelo de amenazas de la aplicación
• La dApp Store - empaquetado, metadatos y distribución

Versiones de la pila: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 y @solana/kit 7.0.0.