Apple убила 12-летнее Mac-приложение за одну ночь

Одно обновление macOS может стереть двенадцать лет работы над приложением. Никакого предупреждающего письма. Никакого периода устаревания. Просто системное обновление — и приложение перестаёт запускаться.

Этот паттерн повторяется с каждым крупным платформенным сдвигом Apple. Catalina убила 32-битные приложения. Apple Silicon сломал расширения ядра. Каждый переход оставляет за собой след из мёртвого инди-софта. Разработчики, стоящие за этими приложениями, сталкиваются с жёстким выбором: переписать с нуля, распространять вне App Store или уйти совсем.

Как Apple ломает приложения

Apple не поддерживает обратную совместимость так, как это делает Microsoft. Windows всё ещё запускает программы 2005 года. macOS — нет.

Самый разрушительный пример: macOS Catalina полностью отказалась от поддержки 32-битных приложений в 2019 году. Каждое приложение, не перекомпилированное как 64-битное, просто перестало работать. Согласно Charlotte Street Computers, это затронуло «все последующие версии macOS» — Catalina, Big Sur, Monterey и далее. Не было режима совместимости. Не было льготного периода. Бинарник либо запускался, либо нет.

Важный момент: Apple делала это и раньше. Mac OS X Lion в 2011 году прекратил поддержку всех приложений, написанных до 2006 года. Как отмечается в том же источнике, неосведомлённые пользователи столкнулись с «сотнями долларов на обновления», когда их софт внезапно перестал работать.

Масштаб поломок был немалым. Один бизнес обнаружил, что его критически важная POS-система несовместима, и был вынужден отложить переход на Catalina, пока не была найдена замена. Умножьте этот сценарий на тысячи инди-приложений и инструментов малого бизнеса.

Молот Apple Silicon

Переход с Intel на ARM добавил ещё один слой разрушений. Согласно обсуждениям в Apple Support Community, 32-битные приложения не запустятся ни на одном Mac с Apple Silicon, который требует как минимум macOS Big Sur. Слой трансляции Rosetta 2 справляется с большинством 64-битных Intel-приложений, но он «обрабатывает только приложения — не код, работающий на уровне системы/ядра». Расширения ядра и драйверы устройств требуют нативных версий для Apple Silicon.

Простыми словами: если приложение зависело от кастомных драйверов, аппаратных интерфейсов или низкоуровневого системного доступа, Rosetta 2 не могла его спасти. Разработчику приходилось переписывать эти компоненты с нуля.

Существуют инструменты для проверки совместимости перед обновлением. Бесплатная утилита Go64 от St. Claire Software сканирует установленные приложения на готовность к 64-бит. Но большинство пользователей не проверяют. Они нажимают «Обновить» и обнаруживают сломанный софт уже постфактум.

Распространённая ошибка: предполагать, что Rosetta 2 покрывает всё. Это не так. Любое приложение с компонентами уровня ядра, кастомными аудиодрайверами или аппаратными донглами может тихо сломаться на Apple Silicon.

Проблема коммуникации

Apple отказывается публиковать график поддержки программного обеспечения. Разработчики не получают никакой дорожной карты. Согласно Ars Technica, Apple прекращает поддержку старых Intel Mac «на годы раньше, чем это было в совсем недавнем прошлом», не сообщая о своих планах.

Это создаёт конкретную проблему для инди-разработчиков. Разработчик-одиночка, поддерживающий Mac-приложение, не может планировать многолетний рефакторинг, если график устаревания неизвестен. К тому моменту, когда Apple объявляет об изменении на WWDC, у разработчика может быть шесть месяцев — или меньше — до выхода следующей версии macOS, которая убьёт его приложение.

Анализ Ars Technica отмечает, что Apple необходимо решить проблему коммуникации, «чтобы владельцы Mac поздней Intel-эры не чувствовали себя обманутыми». То же самое касается разработчиков. Создание продукта на платформе без опубликованного жизненного цикла поддержки — это азартная игра.

Обновления Safari прекращаются для старой версии macOS одновременно с прекращением обновлений безопасности. Chrome, Firefox и Edge продолжают работать на гораздо более старых системах. Контраст разителен: веб-браузеры рассматривают обратную совместимость как преимущество, тогда как Apple рассматривает её как технический долг, подлежащий устранению.

Что происходит, когда ваше приложение умирает

Разработчик, потративший двенадцать лет на создание Mac-приложения, сталкивается с несколькими конкретными проблемами, когда Apple его убивает:

Потеря дистрибуции. Mac App Store удаляет приложения, не соответствующие требованиям текущего SDK. Архива нет. Пользователи не могут скачать старые версии. Приложение полностью исчезает из результатов поиска.

Потеря пользователей. Пользователи, обновившие macOS, теряют доступ к приложению. Откатиться назад непросто. Большинство не будет понижать версию операционной системы ради одного приложения.

Потеря дохода. Подписочный доход падает до нуля за одну ночь. Приложения с разовой покупкой не генерируют новых продаж. Двенадцать лет накопленных отзывов, рейтингов и поисковых позиций в App Store исчезают.

Потеря кода. Если приложение зависело от устаревших фреймворков — таких как старый Carbon API, 32-битные библиотеки или удалённые системные сервисы — кодовая база может быть неремонтопригодной. Переписывание с нуля — единственный вариант.

Проверено на практике: разработчики, которые поддерживали и 32-битную, и 64-битную версию до выхода Catalina, пережили переход. Те, кто ждал, — нет.

Перестройка вне App Store

Mac App Store берёт комиссию 15–30% и навязывает ограничения песочницы. Когда Apple всё равно заставляет переписывать, многие разработчики пользуются случаем и уходят из магазина совсем.

Прямая дистрибуция через собственный сайт разработчика снимает ряд ограничений:

• Нет ограничений песочницы. Приложения, распространяемые вне магазина, могут получать доступ ко всей файловой системе, использовать расширения ядра (на Intel), свободно взаимодействовать с другими приложениями. Функции, которые песочница App Store блокирует — такие как общесистемные горячие клавиши, наблюдатели файловой системы или прямой доступ к оборудованию — становятся возможными.

• Нет задержек ревью. Исправления багов отправляются немедленно. Не нужно ждать три дня, пока App Review одобрит критический патч.

• Полный контроль ценообразования. Никаких 30% комиссии. Разработчики получают полную стоимость покупки. Пробные версии, бандлы и цены на обновления работают без ограничений Apple.

• Гибкость обновлений. Фреймворки вроде Sparkle позволяют приложениям обновляться самостоятельно вне магазина. Пользователи получают обновления быстрее.

Компромисс — это обнаружимость. App Store обеспечивает органический поисковый трафик. Прямая дистрибуция требует от разработчика самостоятельно формировать аудиторию через контент-маркетинг, социальные сети, сообщества разработчиков и сарафанное радио.

Важный момент: многие успешные Mac-утилиты — Alfred, Raycast, CleanShot, Bartender — распространяются напрямую. Mac App Store — не единственный жизнеспособный канал.

План миграции

Когда Apple убивает приложение, разработчики, которые успешно восстанавливаются, следуют определённому паттерну.

Шаг 1: Оцените ущерб

Определите, можно ли обновить кодовую базу или нужно полное переписывание. Проверьте каждую зависимость на совместимость с платформой. Запустите приложение под Rosetta 2, если нацелены на Apple Silicon. Используйте Go64 или «Информацию о системе» для выявления 32-битных компонентов.

# Проверка 32-битных бинарников в бандле приложения
lipo -info /Applications/YourApp.app/Contents/MacOS/YourApp

Если вывод показывает i386 без x86_64 или arm64, бинарник только 32-битный. Мёртв на Catalina и новее.

Шаг 2: Свяжитесь с пользователями

Прежде чем старое приложение умрёт, напишите каждому пользователю. Объясните ситуацию. Предложите путь миграции. Если новая версия готовится, укажите сроки. Если разработка прекращается, порекомендуйте альтернативы.

Разработчики, которые замолкают, теряют доверие навсегда. Прямое, честное письмо — «Apple изменила платформу, вот что мы делаем по этому поводу» — сохраняет отношения, даже когда новости плохие.

Шаг 3: Перестройте на актуальных фреймворках

Apple подталкивает разработчиков к SwiftUI, Combine и Swift concurrency. Переписывание — это возможность перейти на актуальные фреймворки, которые переживут следующий платформенный сдвиг.

// Современная точка входа Mac-приложения — жизненный цикл SwiftUI
@main
struct RebuiltApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        .commands {
            // Настройка меню
        }
    }
}

Нацеливание на последний SDK означает, что приложение будет работать нативно и на Intel, и на Apple Silicon без Rosetta. Универсальные бинарники покрывают обе архитектуры в одной загрузке.

# Сборка универсального бинарника для обеих архитектур
xcodebuild -scheme YourApp -destination "generic/platform=macOS" \
  ARCHS="x86_64 arm64" ONLY_ACTIVE_ARCH=NO build

Шаг 4: Настройте прямую дистрибуцию

Подпишите приложение сертификатом Developer ID. Нотаризуйте его через Apple. Распространяйте .dmg или .zip с сайта. Используйте Sparkle для автообновлений.

# Нотаризация приложения для распространения вне Mac App Store
xcrun notarytool submit YourApp.dmg \
  --apple-id developer@example.com \
  --team-id TEAMID \
  --password @keychain:notarytool-password \
  --wait

Нотаризация обязательна для того, чтобы Gatekeeper принял приложение на современных macOS. Без неё пользователи увидят предупреждающий диалог, через который большинство не станет кликать.

Шаг 5: Мигрируйте пользователей App Store

Это самая сложная часть. App Store не предоставляет механизма для прямой связи с пользователями. Варианты включают:

• Выпустить финальное обновление в App Store, которое отображает уведомление о миграции со ссылкой на новую версию.
• Использовать существующие списки рассылки, рассылки новостей или историю обращений в поддержку.
• Опубликовать руководства по миграции на сайте приложения и в социальных сетях.
• Предложить бесплатные или со скидкой лицензии подтверждённым покупателям из App Store.

Распространённая ошибка: предполагать, что пользователи App Store сами найдут новую версию. Не найдут. Активная работа по информированию необходима.

Общий паттерн

Apple оптимизирует под продажи железа. Каждый переход macOS — PowerPC на Intel, Intel на ARM, 32-бит на 64-бит — делает новое оборудование более привлекательным, а старое — менее функциональным. Как отмечает Ars Technica, поддержка драйверов привязана к обновлениям ОС, и пользователи не могут обновлять драйверы GPU или оборудования независимо. Когда заканчивается поддержка ОС — заканчивается и поддержка оборудования.

Это осознанный архитектурный выбор. Он поддерживает платформу в подтянутом состоянии. Он также означает, что создание продукта на платформе Apple несёт в себе риск, которого нет при разработке для веба.

Разработчики, пережившие несколько переходов, разделяют общую стратегию: поддерживать платформонезависимую основную логику. Держать бизнес-логику в чистом Swift, Rust или C++, который компилируется где угодно. Ограничивать платформо-специфичный код слоем UI. Когда Apple меняет платформу, переписывать нужно только UI — не всё приложение целиком.

На практике приложения, которые отделяют своё ядро от слоя представления macOS, перестраиваются за месяцы, а не годы. Приложения, которые глубоко переплели бизнес-логику с AppKit или устаревшими фреймворками, сталкиваются с полным переписыванием.

Что разработчики могут сделать прямо сейчас

Попробуйте: проведите аудит архитектуры любого Mac-приложения на предмет платформенных зависимостей уже сегодня.

1. Запустите lipo -info для каждого бинарника в бандле приложения. Убедитесь в поддержке универсальных бинарников.
2. Проверьте все сторонние фреймворки на наличие нативных версий для Apple Silicon.
3. Выявите любое использование устаревших API с помощью предупреждений об устаревании в Xcode.
4. Настройте канал прямой дистрибуции — даже если приложение сейчас в App Store. Имейте запасной вариант.
5. Соберите приложение с ARCHS="x86_64 arm64" и протестируйте на обеих архитектурах.

Если работает — значит всё верно. Но проверяйте работоспособность на последней бета-версии macOS каждый июнь после WWDC. Именно тогда всплывают поломки.

Урок, извлечённый из того, как двенадцать лет работы исчезли за ночь, не в том, что Apple враждебна к разработчикам. Урок в том, что владельцы платформ оптимизируют под свои собственные приоритеты. Разработчики, которые считают любой единственный канал дистрибуции или версию платформы постоянными, строят на песке. Диверсифицируйте дистрибуцию. Изолируйте платформо-специфичный код. Общайтесь с пользователями напрямую. И всегда имейте план на случай, когда выйдет следующее обновление macOS.

Часто задаваемые вопросы

Как мигрировать существующих пользователей App Store на прямую дистрибуцию, если вас вынудили уйти с платформы?

Выпустите финальное обновление в App Store, содержащее уведомление о миграции и ссылку на версию для прямого скачивания. Предложите подтверждённым покупателям из App Store бесплатную лицензию на новую версию. App Store не предоставляет встроенного механизма для этого, поэтому внешние каналы связи — списки рассылки, социальные сети, форумы поддержки — критически важны.

Какие возможности открываются при выходе из песочницы App Store?

Прямая дистрибуция снимает ограничения песочницы на доступ к файловой системе, межпроцессное взаимодействие, расширения ядра (на Intel Mac), общесистемные горячие клавиши и управление фоновыми процессами. Приложения вроде записи экрана, менеджеров буфера обмена и системных утилит, как правило, не могут полноценно работать внутри песочницы.

Когда Apple удаляет функцию ОС, от которой зависит ваше приложение, какие варианты существуют?

Если функция удалена полностью, единственный путь — редизайн с использованием альтернативных API или иного подхода. Подача отчёта через Feedback Assistant в Apple может помочь, если удаление функции было непреднамеренным, но ответа не ждите. Участие в Apple Developer Forums и обращения через Technical Support Incidents иногда позволяют обнаружить недокументированные заменяющие API.

Набирает ли прямая дистрибуция вне App Store достаточную популярность, чтобы компенсировать потерю обнаружимости?

Для нишевых инструментов продуктивности и разработчиков — да. Такие приложения, как Alfred, Bartender и CleanShot, сформировали большую пользовательскую базу без App Store. Ключ — это контент-маркетинг, присутствие в сообществах и сарафанное радио. Для потребительских приложений, нацеленных на нетехнических пользователей, потеря обнаружимости значительна, и компенсировать её сложнее.