Сборка и подписание десктоп-приложения для macOS

Сборка и подписание десктоп-приложения для macOS

Ситуация: приложение собрано, но на современных версиях macOS (14+) Gatekeeper блокирует запуск. Пользователи сообщают: «не может быть открыт, так как Apple не может проверить его». Корень — отсутствие подписи кода и нотаризации. Без них Gatekeeper блокирует запуск, а обход через «Системные настройки» требует нестандартных действий, которые большинство пользователей не выполнят.

Решить это можно за 3–4 дня, если правильно настроить цепочку: сертификат Developer ID → entitlements → подпись → нотаризация → stapling. Мы делаем это под ключ для Electron, Qt, SwiftUI и других фреймворков. За 5+ лет опыта мы провели более 50 релизов для macOS — ни один не был заблокирован. Apple Notarization Guide

Плата за вход: сертификат Developer ID Application можно получить только при наличии подписки Apple Developer Program (стоимость $99/год). Сама нотаризация для разработчиков бесплатна.

Почему подпись кода критична?

Подпись кода — это цифровая подпись разработчика, гарантирующая целостность приложения. macOS проверяет её при каждом запуске. Без неё Gatekeeper блокирует приложение, пользователь вынужден вручную разрешать запуск через «Системные настройки» или терминал. Для корпоративных сред это неприемлемо: MDM-политики запрещают запуск неподписанных приложений. Нотаризация добавляет проверку Apple на вредоносный код. Обе процедуры обязательны для распространения вне Mac App Store.

Как подписать и нотаризовать приложение для macOS?

Процесс включает 2 обязательных этапа: Code Signing и Notarization. Сначала получаете сертификат Developer ID Application (требуется Apple Developer Account). Затем конфигурируете сборку с правильными entitlements. Ниже — минимальный конфиг для Electron.

// electron-builder.yml
mac:
  target:
    - target: dmg
    - target: zip
  icon:      build/icon.icns
  category:  public.app-category.productivity
  hardenedRuntime:   true
  gatekeeperAssess:  false
  entitlements:          build/entitlements.mac.plist
  entitlementsInherit:   build/entitlements.mac.plist
  identity: "Developer ID Application: Company Name (TEAM_ID)"

<!-- build/entitlements.mac.plist -->
<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
  <key>com.apple.security.cs.allow-jit</key><true/>
  <key>com.apple.security.cs.allow-unsigned-executable-memory</key><true/>
  <key>com.apple.security.cs.allow-dyld-environment-variables</key><true/>
  <key>com.apple.security.network.client</key><true/>
</dict>
</plist>

Какие entitlements нужны для Electron-приложений?

Electron требует 4 ключа: allow-jit (для V8), allow-unsigned-executable-memory (для JIT-компиляции), allow-dyld-environment-variables (для Node.js) и network.client (для HTTP-запросов). Без них приложение вылетит при старте или не сможет выполнять сетевые запросы. Сравните с entitlements для нативных SwiftUI-приложений: там обычно достаточно com.apple.security.app-sandbox и com.apple.security.files.user-selected.read-write.

Нотаризация и stapling

После подписи отправляем .dmg на нотаризацию через notarytool. Apple сканирует бинарники на вирусы и вредоносный код. Результат — нотаризационный тикет, который встраивается в файл командой stapler.

# Через notarytool (Xcode 13+)
xcrun notarytool submit AppName.dmg \
  --apple-id     "[email protected]" \
  --password     "@keychain:AC_PASSWORD" \
  --team-id      "TEAM_ID" \
  --wait

# Stapling (встраивание нотаризационного тикета в файл)
xcrun stapler staple AppName.dmg

Notarytool работает в 3 раза быстрее старого altool и имеет лучший уровень поддержки, так как активно развивается Apple.

Пошаговая настройка подписи в CI/CD

1. Получите сертификат Developer ID Application в Apple Developer Portal (сертификат типа Developer ID Application, не Development).
2. Экспортируйте сертификат в .p12 и сохраните в секретах CI (например, GitHub Secrets).
3. Настройте electron-builder или аналог с нужными entitlements (см. выше).
4. Добавьте шаг импорта сертификата в CI-пайплайн.
5. Настройте этап нотаризации с notarytool и stapling.
6. Протестируйте сборку на локальной машине и в CI.

GitHub Actions для macOS

- uses: actions/checkout@v3
- name: Import Certificate
  run: |
    echo "$MACOS_CERTIFICATE" | base64 --decode > certificate.p12
    security import certificate.p12 -P "$MACOS_CERTIFICATE_PWD" \
      -A -t cert -f pkcs12 -k ~/Library/Keychains/login.keychain

- name: Build and Sign
  run: npm run build:mac
  env:
    APPLE_ID:          ${{ secrets.APPLE_ID }}
    APPLE_ID_PASS:     ${{ secrets.APPLE_ID_PASS }}
    APPLE_TEAM_ID:     ${{ secrets.APPLE_TEAM_ID }}
    CSC_LINK:          ${{ secrets.MACOS_CERTIFICATE }}
    CSC_KEY_PASSWORD:  ${{ secrets.MACOS_CERTIFICATE_PWD }}

Universal Binary (Intel + Apple Silicon)

Universal binary — это сборка, содержащая обе архитектуры (x86_64 и arm64). Она работает нативно на M1/M2/M3 без Rosetta 2. Это обязательное требование для App Store и многих корпоративных сред. Экономия производительности: без universal binary вы теряете до 30% на Apple Silicon.

# electron-builder автоматически создаёт universal binary
npx electron-builder --mac --universal

Что входит в настройку под ключ

Дополнительно: настройка автоматического обновления (Sparkle, Electron auto-updater), white-label подпись, работа с Apple Developer Enterprise Program.

Типичные ошибки

• Использование сертификата Apple Development вместо Developer ID — подпись только для отладки.
• Пропуск hardenedRuntime: true — нотаризация не пройдёт.
• Неправильные entitlements для Electron — падение при старте.
• Отсутствие stapling — пользователи увидят предупреждение, если нет интернета.
• Забыли про universal binary — потеря производительности на Apple Silicon.
• Сертификат Developer ID Application не подходит, если вы ошиблись типом (нужен именно Developer ID, а не Development).
• Нотаризация не проходит, если не включён hardenedRuntime.
• Приложение падает при старте — проверьте entitlements: для Electron обязательны allow-jit и allow-unsigned-executable-memory.
• Stapling не срабатывает, если файл повреждён — выполните stapler сразу после notarytool.

Опираясь на наш опыт, мы рекомендуем тестировать нотаризацию на каждом релизе. Даже замена версии Electron может сломать entitlements.

Сроки и гарантия

Базовая настройка занимает 3–4 рабочих дня. Мы гарантируем, что приложение пройдёт нотаризацию и будет запускаться на macOS 10.14 и новее. Свяжитесь с нами, чтобы настроить подпись за 3-4 дня и избежать блокировок Gatekeeper. Получите консультацию по вашему проекту — мы поможем избежать типичных ошибок и сэкономить время.

Мы регулярно сталкиваемся с ситуацией: «Сайт не открывается» в 3 часа ночи — и выясняется, что disk full на VPS, потому что логи nginx не ротировались полгода. Или сервер лёг под нагрузкой в день запуска рекламной кампании, потому что на shared хостинге стоял лимит в 50 одновременных соединений. Настройка хостинга и деплоя — это не про «где дешевле», это про то, что происходит в момент, когда что-то идёт не так. Наша команда помогает избежать таких инцидентов, проектируя инфраструктуру с учётом реальных паттернов нагрузки.

Когда выбирать Vercel и Netlify?

Vercel создан под Next.js — деплой в один push, preview deployments для каждого PR, автоматический CDN, Edge Functions, ISR без конфигурации. Для фронтенд-проектов и JAMstack это оптимальный выбор: нет операционной нагрузки, time-to-deploy измеряется минутами.

Ограничения реальные: Vercel Serverless Functions запускаются в us-east-1 по умолчанию (latency для Европы +80–100ms), Function timeout 300 секунд на Pro, Bandwidth 1TB/месяц на Pro. Для тяжёлого backend — нужны воркеры или отдельный сервер.

Netlify ближе к статике и Edge Functions на базе Deno Deploy. Build minutes — основное ограничение на бесплатном тарифе.

Почему Docker — основа предсказуемого деплоя?

«Работает на моей машине» — классика. Docker решает это через контейнеризацию окружения. Но плохой Dockerfile создаёт новые проблемы.

Типичная ошибка: копировать всё в образ без .dockerignore, получать 800MB образ вместо 80MB. node_modules внутри образа весит столько же. Правильно: multi-stage build.

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["npm", "start"]

Итоговый образ: 180MB вместо 1.2GB. Время сборки CI сокращается из-за layer caching — если package.json не изменился, слой с npm ci берётся из кэша.

Docker Compose для локальной разработки и простых продакшен-сценариев: приложение + PostgreSQL + Redis в одной конфигурации. Для production на одном сервере — вполне рабочий вариант, если нет требований горизонтального масштабирования.

Подробнее о контейнеризации — Wikipedia: Docker.

Как настроить Nginx как reverse proxy?

Nginx перед приложением — стандарт для VPS и выделенных серверов. Основные функции: SSL termination, gzip, static files, rate limiting, upstream балансировка.

Конфигурация, которую часто делают неправильно: worker_processes auto — количество процессов равно числу CPU. worker_connections 1024 — это 1024 на каждый воркер-процесс. При 4 CPU и 1024 connections = 4096 одновременных соединений. Для высоконагруженного сайта нужно worker_connections 4096 и настройка keepalive_timeout 65.

Для статических ассетов с хешем в имени файла:

location ~* \.(js|css|woff2|png|webp)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

immutable сообщает браузеру: не проверяй этот файл даже при hard refresh. Правильно работает только с content-hashed именами файлов (что делает Vite/webpack по умолчанию). Документация — Wikipedia: Nginx.

AWS: гибкость и сложность

EC2 + Auto Scaling Group — классика для горизонтального масштабирования. AMI с предустановленным приложением, Launch Template, ASG с min/desired/max instances, Application Load Balancer. При CPU > 70% на 3 минуты — scale out, при CPU < 30% на 15 минут — scale in. Health check через ALB исключает нездоровые инстансы из ротации.

ECS Fargate — контейнеры без управления EC2. Деплой Docker-образа, задаёте CPU/память (512 CPU units = 0.5 vCPU, от 512MB памяти), Fargate запускает. Дороже Lambda, но нет cold start и нет timeout-ограничений. Подходит для long-running процессов, WebSocket-серверов, тяжёлых воркеров.

RDS для PostgreSQL с Multi-AZ: автоматический failover за 1–2 минуты при падении primary. Read Replicas для масштабирования чтения. RDS Proxy для connection pooling — Lambda-функции не умеют держать долгосрочные соединения, прокси буферизует это.

Kubernetes: когда это оправдано

K8s добавляет значительную операционную сложность. Оправдан, когда: несколько команд деплоят независимые сервисы, нужна тонкая настройка ресурсов на сервис, canary deployments и blue/green без простоя — требование.

AWS EKS, GKE или managed k8s от Hetzner (дешевле). Helm charts для стандартных сервисов. Horizontal Pod Autoscaler по CPU и custom metrics (RPS через Prometheus).

Для большинства стартапов и средних проектов — Kubernetes избыточен. ECS или Fly.io дают 80% возможностей при 20% операционной сложности.

Мониторинг и alerting

Сервер без мониторинга — это ожидание инцидента. Минимальный стек: Prometheus + Grafana (или Grafana Cloud для managed), alerting на disk > 80%, memory > 85%, CPU > 90% за 5 минут, error rate > 1%. Uptime через Better Uptime или Upptime (self-hosted).

Logs: Loki + Grafana или CloudWatch Logs Insights. Структурированные JSON-логи (winston, pino) — обязательно, иначе поиск по логам превращается в боль.

Что входит в настройку хостинга

• Аудит текущей инфраструктуры и профилирование нагрузки
• Выбор целевой архитектуры (VPS, AWS, serverless, Kubernetes)
• Настройка CI/CD pipeline (GitHub Actions, GitLab CI) с автоматическим деплоем
• IaC через Terraform или Pulumi (инфраструктура как код)
• Конфигурация Nginx, SSL-сертификаты, HTTP/2, brotli
• Мониторинг и алертинг (Prometheus + Grafana, PagerDuty)
• Документация runbooks и обучение команды

Дополнительно: пишите, если нужна миграция с текущего хостинга или интеграция с внешними сервисами.

Процесс работы

1. Аудит текущей инфраструктуры (2–5 дней)
2. Выбор целевой архитектуры с обоснованием по нагрузке и бюджету (1–3 дня)
3. Настройка CI/CD pipeline (GitHub Actions, GitLab CI) (2–5 дней)
4. IaC через Terraform или Pulumi (3–10 дней)
5. Настройка мониторинга и alerting (2–5 дней)
6. Документация runbooks и обучение команды (1–3 дня)

Наш опыт — 7 лет на рынке, более 50 проектов, гарантия работоспособности после деплоя.

Сроки

• Базовый деплой на VPS с Docker + Nginx + CI/CD: 1–2 недели.
• Настройка AWS инфраструктуры с Auto Scaling, RDS, CDN: 3–6 недель.
• Миграция на EKS с нуля: 6–12 недель.
• Настройка Vercel/Netlify для JAMstack: 3–5 дней.

Стоимость рассчитывается индивидуально в зависимости от сложности и объёма работ. Получите консультацию — оценим вашу архитектуру за один день.