feat(macos): preparar distribución versionada e instalación verificable

Cerrado
  • ¿Algo no está bien?
#118 4 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@egdev6 ya está trabajando en esto.

Desde el 16/10/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

status:approved type:feature
Pre-flight checks
  • I searched existing issues and found no duplicate.
  • I understand that this proposal requires product review before implementation.

El asistente revisó issues abiertas/cerradas y PR activas: #69/#112 aportan el bundle local y excluyen esta distribución; #117 cubre únicamente CI. El mantenedor confirmó expresamente la declaración de revisión de producto para ambas propuestas. No se aplica status:approved ni se asigna trabajo.

Problem to solve

La integración macOS Apple Silicon ya genera .app y .dmg localmente, pero el workflow Release sigue siendo Windows. Hace falta convertir ese bundle en una entrega versionada, trazable y realmente instalable desde una descarga, sin anunciar firma, notarización, actualizaciones automáticas o versiones de macOS no verificadas.

Proposed solution

Preparar la distribución verificable macOS reutilizando tauri.macos.conf.json y app:build:mac, tras completar #117. Separar las decisiones de confianza/distribución de la ejecución: acordar el nivel de entrega (preview sin firma frente a distribución Developer ID firmada/notarizada), el mínimo macOS y la política de instalación/actualización. Documentar los requisitos que deba proporcionar el mantenedor antes de configurar credenciales o habilitar publicación.

Para una descarga estable orientada a público general, se recomienda firma Developer ID y notarización con validación real de Gatekeeper. Si esos requisitos no están disponibles, el mantenedor debe decidir explícitamente entre aplazar la descarga Mac o una preview sin firma claramente identificada; no rebajar silenciosamente el criterio para cerrar la issue. El updater Tauri es un mecanismo separado de la firma Apple.

Affected area

Build or tooling

Scope and non-goals

Dependencias y coordinación

  • Depende de #117 completada y de un candidato integrado y validado. Refs #69, #45 y #112: no rehacer el port ni crear otro instalador local.
  • Antes de empezar, acordar con @barbatdev el reparto y la validación en Mac real. La mención no asigna ni presupone su disponibilidad.
  • La decisión del mantenedor es completar CI y distribución verificable antes de la próxima release que anuncie una descarga Mac. No obliga a publicar Linux ni amplía #105–#108.
  • #20 es firma Authenticode Windows, no autorización ni infraestructura de firma Apple.

Criterios de aceptación propuestos

  • Arquitectura ARM64, mínimo macOS objetivo y matriz realmente probada aceptados. El deployment target del binario no se presenta como rango funcional validado; Intel/universal fuera de esta entrega.
  • Política de entrega explícita: estable firmada/notarizada o preview sin firma aceptada como tal. Cuenta Apple Developer, certificados, servicio de notarización y sus costes/requisitos inventariados; nunca se solicitan valores privados en issues/logs.
  • Plan de empaquetado/publicación revisado: reutiliza el workflow existente cuando sea compatible, preserva Windows y parte de un SHA/versiones/notas validados; artefactos y checksums trazables al mismo candidato. Ejecución manual y borrador para revisión, sin release por un push o un merge ordinario.
  • Si se elige firma/notarización: verificar cadena/identidad, notarización y stapling según formato, y evaluación Gatekeeper sobre la descarga real. Secretos solo en el paso y contexto autorizados, nunca disponibles a PR de forks ni a fuentes no revisadas.
  • Instalar el .dmg descargado y mover/abrir la app desde su destino final en un Mac real, registrando SHA, versión y entorno; probar primera apertura con cuarentena y una actualización sobre instalación anterior cuando exista. No usar la eliminación de cuarentena como sustituto de validar una entrega firmada.
  • Smoke del artefacto final: widget/detalle/overlay, Spaces normales, permisos Keychain, login CLI, autostart, notificaciones y atajos, con datos sensibles excluidos. Limitaciones fullscreen y de versiones no probadas publicadas honestamente.
  • Updater macOS: decidir expresamente si queda deshabilitado/no soportado con actualización manual documentada, o remitir su implementación y validación a otra unidad. No prometer compatibilidad por tener minisign en Windows.
  • Notas de instalación/seguridad y release ES/EN describen exactamente los assets y las limitaciones; Windows y los gates de seguridad siguen verdes. La revisión final del mantenedor acredita el cierre antes de preparar/publicar la release anunciada para Mac.

Exclusiones y autorizaciones
No App Store, Linux, Intel/universal, rediseño NSPanel/fullscreen ni mejoras de dockeo #113. Esta issue no autoriza crear certificados, modificar secretos/protecciones, gastar una suscripción, ejecutar firma/notarización, crear tags, lanzar Release o publicar assets. Cada operación requiere su aprobación concreta; crear la issue tampoco autoriza implementación ni asignación. No se impone completar updater ni audio/i18n pendientes para validar el alcance acordado de esta entrega.

Alternatives considered

Publicar únicamente Windows y mantener el port Mac como código/bundle local: válido si se comunica así, pero no satisface el objetivo de una descarga Mac verificable. Subir el .dmg personal de un contribuidor: insuficiente sin trazabilidad y prueba del artefacto final. Fusionar todo con #69 o #117: duplicaría el bundle ya integrado y mezclaría CI sin secretos con distribución y credenciales. Se crea esta unidad separada con gates explícitos.

Lenguaje dominante
TypeScript
Estrellas
10
Forks
2
Merge medio
7 h 52 min
PR fusionados (30 d)
126

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de egdev6/quorb

Todos los issues de egdev6/quorb

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.