Mac всегда отличался от своего близкого родственника iOS, особенно в отношении того, что пользователю можно и нельзя запускать в своей системе. Даже после появления Apple Silicon компания Apple чётко дала понять, что Mac остаётся Mac, и его по-прежнему можно хакать, даже при запуске на новой архитектуре.
Для программистов это значит, что при разработке для платформы Mac у нас есть выбор: мы можем распространять приложения независимо, за пределами Mac App Store, только через Mac App Store или сочетать оба варианта.
Данная статья стала результатом моих размышлений на эту тему. Она задумывалась как руководство по аспектам, которые нужно знать при распространении приложений для Mac за пределами App Store, а не как подробное описание конкретных действий. Надеюсь, что представленная здесь информация поможет новичкам снять завесу тайны с этого процесса, а описание моего собственного процесса будет полезно в качестве опорной точки.
App Store и прямое распространение: плюсы и минусы
Все эти варианты имеют свои достоинства и недостатки. Начнём с того, что некоторые приложения для Mac просто невозможно будет распространять через Mac App Store. Примером этого может послужить моё приложение AirBuddy, которому для обеспечения глубокой интеграции с беспроводными устройствами Apple необходимо запускать системный агент и использовать приватные API, что в App Store запрещено. То же самое относится и ко многим другим видам приложений, которые просто не смогут работать в условиях ограничений «песочницы» Mac.
Для тех же, у кого выбор есть, я составил список плюсов и минусов выпуска в Mac App Store или независимого распространения.
Плюсы Mac App Store
- Компания Apple занимается за вас распространением, продажей и лицензированием.
- Большинству пользователей проще найти и установить приложение.
- Есть вероятность попасть в рекомендации Apple и стать известным большему количеству покупателей.
- Можно использовать такие функции, как вход с учётной записью Apple, недоступные для приложений, распространяемых вне Mac App Store
Минусы Mac App Store
- Нужно платить Apple долю 15% или 30% от всех продаж. Это зависит от того, сколько заработали за год все ваши приложения.
- Каждое обновление, даже самое мелкое, обязано пройти процесс App Review с вероятностью отказа по произвольным причинам.
- Из-за строгих требований «песочницы» невозможно раскрыть весь потенциал macOS.
- Невозможно выпускать платные обновления.
Плюсы прямого распространения
- Можно выпускать обновления в любой момент без необходимости ожидания проверки и не боясь, что их отклонят
- Раскрывается весь потенциал macOS с системными расширениями, демонами, выходом из «песочницы», приватными API и многим другим.
- Повышение процента продаж.
- Реализация платных обновлений или других бизнес-моделей, недопустимых в App Store
- Возможность жить без постоянного страха, что твоё приложение внезапно станет проблемой для Apple и появится угроза его удаления из App Store
Минусы прямого распространения
- Нужно заниматься лицензированием, распространением и обновлениями (вы увидите, что это не так сложно)
- Не так просто реализовывать расходные (consumable) и постоянные (non-consumable) покупки внутри приложения (нет StoreKit)
- Нельзя использовать некоторые сервисы Apple, например, вход с учётной записью Apple (другие сервисы, например, CloudKit, работают нормально)
Примечание о Catalyst и SwiftUI
С появлением Catalyst стало появляться множество новых приложений для Mac, поскольку теперь намного проще взять готовое приложение для iPad и портировать его на Mac. Приложения, портированные на macOS через Catalyst, необязательно выпускать в App Store, даже если оригинал под iOS находится там.
Кроме того, на данный момент не существует TestFlight для macOS (одно из моих пожеланий на 2021 год), поэтому если вы хотите распространять бета-сборки приложения, созданного Catalyst, то это необходимо делать за пределами Mac App Store, и это не сильно отличается от распространения приложения в продакшене.
Многое из описанного в статье применимо и к Catalyst-приложениям — в конце концов, это же приложения для Mac, однако части приложений потребуется дополнительный хакинг — Apple препятствует использованию всех возможностей AppKit непосредственно из Catalyst-приложения. Однако немного потрудившись, можно заставить Catalyst-приложение использовать многие функции Mac, в том числе поддержку AppleScript и другие возможности.
При разработке SwiftUI-приложений для Mac в процессе распространения не должно быть серьёзных отличий, потому что в SwiftUI-приложении мы можем использовать все функции macOS API без хаков, требуемых для Catalyst-приложений.
Распространение
Распространение приложения состоит из двух аспектов: из самой загрузки, сохранения и скачивания двоичного файла приложения и его обновлений, а также из создания пакета, который будет работать у ваших пользователей.
Хостинг
Первым серьёзным шагом, позволяющим вашему приложению для Mac попасть в руки пользователей без App Store — выбор способа распространения его двоичного файла. Отсутствие App Store означает, что вам придётся хостить двоичные файлы приложения и обновлений где-нибудь в Интернете, дав пользователям ссылку на скачивание.
Реализовать это можно множеством разных способов. Для приложения в open source можно использовать релизы на Github и даже хостить update feed приложения в репозитории Github. Именно так я распространяю приложение WWDC для macOS.
В случае коммерческих приложений я использовал Backblaze B2 для хранения двоичных файлов приложений, дельта-обновлений и update feed, проксируя все запросы через Cloudflare, чтобы у меня был собственный домен для скачивания/обновлений, а также чтобы при необходимости добавлять на сервер фильтрацию, кэширование и логику.
B2 — чрезвычайно доступный провайдер (я редко плачу больше 1 доллара в месяц). Большинство приложений для Mac невелико по размерам, поэтому даже если ваше приложение активно скачивают, маловероятно, что вам придётся много платить за объём хранилища/трафик. Ещё одним популярным вариантом являются бакеты Amazon S3, но его панель управления повергает меня в ужас, поэтому я предпочитаю B2, который намного проще (и дешевле).
Пока я не автоматизировал этап публикации релизов своих приложений, поэтому для загрузки нового релиза я просто использую Transmit как клиент для моих бакетов B2. Кстати, прежде чем мы доберёмся до загрузки релиза на сервер, есть ещё один важный этап: получение нужного файла для загрузки.
На правах рекламы
Если вам нужен сервер в России для отладки или размещения проектов, то вам прекрасно подойдут наши эпичные серверы. Создание собственной конфигурации в пару кликов, посуточная тарификация серверов, антиDDoS уже «в коробке», удобная панель управления. Лучше один раз попробовать!
Подтверждение и упаковка
При экспорте архивированного приложения из Xcode у нас есть два основных варианта распространения: App Store Connect и Developer ID. Для распространения приложений без App Store мы будем использовать Developer ID.
Ту же учётную запись разработчика, которую вы используете для распространения приложений через Mac App Store, можно использовать и для подписывания приложений при распространении приложений по Developer ID. Сам сертификат отличается, но Xcode автоматически сгенерирует и установит его, если вы ещё этого не сделали в процессе экспортирования архива.
С момента выпуска macOS Catalina все приложения, распространяемые напрямую среди пользователей должны проходить проверку Apple, в противном случае они по умолчанию не запустятся. Процесс проверки заключается в передаче приложения компании Apple, которая выполняет автоматизированный контроль зловредного ПО и «штампует» ваш двоичный файл специальной сигнатурой, позволяющей ему запускаться. Это не процедура App Review, а автоматизированная проверка, предотвращающая распространение таким способом зловредного ПО. Кроме того, она позволяет Apple пометить как зловред единственный двоичный файл, а не весь аккаунт разработчика на случай, если он когда-нибудь окажется скомпрометированным.
Возможность проверки двоичного файла непосредственно в Xcode organizer зависит от способа упаковки, выбранного для распространения приложения. Нельзя просто закачать папку
.app на сервер и позволить пользователям её скачивать, её нужно превратить в неструктурированный файл. Проще всего это сделать, упаковав приложение в zip, и распространять его как файл zip, однако, по моему опыту, распространение приложения в виде файла DMG значительно снижает количество просьб о помощи со стороны пользователей.Вероятно, вы уже видели DMG при загрузке файлов Mac. Это образы дисков, монтируемые macOS при двойном нажатии в Finder. Они также могут содержать графические инструкции о том, что нужно перетащить приложение в папку Applications. Это упрощает жизнь пользователю и снижает вероятность того, что этот пользователь запустит приложение из папки Downloads или другого произвольного места.
Если вы собираетесь распространять своё приложение в виде DMG, то вам достаточно просто экспортировать его, выбрав в Xcode опцию Developer ID без проверки (notarization), а затем выполнить проверку самого DMG. В Xcode нет опции экспорта в DMG, поэтому придётся воспользоваться сторонним инструментом. Мне нравится работать с create-dmg. Кроме того, я создал и распространяю в open source инструмент dmgdist, автоматизирующий процесс создания, загрузки и штампования DMG, что позволяет одной командой получить готовый к распространению образ.
Для распространения приложения в виде файла zip процесс подготовки проще: после выбора в Xcode Developer ID выберите опцию загрузки (upload). Будет создана проверенная версия приложения, которую затем можно будет упаковать в zip и распространять.
Обновления приложений
Ещё один аспект App Store заключается в том, что он занимается обновлениями приложений. Когда мы загружаем новую версию в App Store Connect и она проходит проверку, пользователям становится доступным обновление в App Store. Нам нужно каким-то образом воссоздать этот процесс для приложений, распространяемых напрямую.
Самый лучший (и популярный) способ — использовать Sparkle. Он существует уже много лет и стал практически официальным способом распространения обновлений приложений для Mac, продаваемых вне Mac App Store.
Сейчас Sparkle как бы живёт двойной жизнью. Можно использовать или «легаси»-версию Sparkle, или более современную ветку «v2», в которую включено множество улучшений, например, возможность обновлять используемые в «песочнице» приложения. Я по-прежнему пользуюсь «легаси»-версией, потому что она мне знакома, а интеграция более современной версии всё ещё кажется немного сложной. Не надо чинить то, что не сломано.
Процесс генерации обновления приложения обычно происходит следующим образом: проверяем, что с каждым обновлением версия приложения становится больше, создаём пакет в соответствии с описанным выше (Sparkle понимает zip, DMG и пакеты установщика), а затем используем инструмент
generate_appcast для обновления feed. После этого загружаем дельты, пакет новой версии и обновлённый AppCast feed на выбранный хостинг, после чего пользователи увидят новую версию, проверив обновления внутри приложения.Это может показаться сложным и определённо требует практики, но после настройки процесса он оказывается совершенно беспроблемным (на мой взгляд, гораздо лучше, чем работа с App Store Connect).
Зарабатываем деньги за пределами Mac App Store
Если вы хотите распространять своё приложение для Mac вне App Store, то есть вероятность, что в какой-то момент вы захотите зарабатывать на нём. Как и в App Store, можно использовать множество разных бизнес-моделей, но наиболее популярной при прямой продаже покупателям является старая добрая модель «плати вперёд»: пользователь платит за скачивание приложения, регистрирует его при помощи лицензионного ключа и получает обновления бесплатно, по крайней мере, в течение какого-то периода времени.
Ещё одна популярная бизнес-модель для приложений, распространяемых вне App Store — это модель подписки, при которой пользователи ежемесячно или ежегодно платят какую-то сумму, чтобы продолжать использовать приложение. По выбору бизнес-модели можно написать целое руководство (или серию руководств), поэтому в этом я вам не помощник. В этом разделе я буду подразумевать, что используется модель «плати вперёд», которую я выбрал для своих приложений.
Чтобы вам заплатили за ваш продукт, нужен какой-то магазин, в который приходят пользователи, узнают о приложении и покупают его (если повезёт). Хорошим вариантом для новичков является сайт Gumroad, предлагающий страницу магазина, обработку платежей, хостинг и лицензирование. Когда я выпустил первую версию AirBuddy в январе 2019 года, то использовал Gumroad, и он сослужил мне очень хорошую службу, продав в течение года десятки тысяч копий приложения.
Однако изначально Gumroad не проектировался для продажи ПО, поэтому ему не хватает гибкости, имеющейся у других сервисов. После выпуска моего нового приложения FusionCast и AirBuddy 2.0 я перешёл на Paddle, который теперь занимается обработкой платежей и лицензированием моих приложений.
Ещё один вариант — просто использовать сервис платежей, что-нибудь типа Stripe или FastSpring, или же обрабатывать заказы и заниматься лицензированием самостоятельно. Таким образом вы получите оптимальную гибкость, хотя придётся больше работать и скорее всего понадобится платить за дополнительные сервисы (например, для отправки электронных писем).
Я бы сказал, что если вы стремитесь подзаработать, продавая приложения для Mac за пределами Mac App Store, то лучшим вариантом является Gumroad, поскольку этот сайт сделает за вас практически всё и вам даже не придётся создавать сайт для приложения. Однако если вы продаёте приложения как компания или это ваш основной источник дохода, то бОльшую гибкость обеспечит профессиональное решение, имеющее меньше ограничений, например, Paddle.
Лицензирование, защита от копирования и пиратство
Возможно, распространяя приложения Mac напрямую, вы озаботитесь пиратством: любой сможет взять двоичный файл вашего приложения и запустить его, не заплатив за лицензию, только если вы не задействуете какую-нибудь защиту от копирования.
Хоть это и так, я пришёл к выводу, что разработчикам, особенно инди, не стоит тратить любое существенное количество времени на создание защиты от копирования. Да, некоторые люди украдут вашу работу, но они в любом случае не заплатили бы, поэтому время, потраченное на беспокойство об этом или на встраивание в приложение сверхпродвинутой DRM — это время, которое можно было бы потратить на устранение багов и разработку новых функций. Кроме того, подобные практики в конечном итоге чаще наказывают законных пользователей, чем препятствуют пиратству (достаточно взглянуть на множество примеров подобного из отрасли разработки игр).
В первой версии AirBuddy вообще не было никакой защиты от копирования, даже простейшей формы регистрации для ввода лицензионного ключа. Я нашёл в Интернете несколько спираченных копий (разумеется, некоторые из них были заражены), но не увидел признаков того, что приложение пиратит большой процент пользователей, и мои показатели тоже этого не отражают. В версии 2 я использую Paddle SDK для регистрации при установке приложения, но на этом всё.
Приложения, распространяемые через Mac App Store, тоже не имеют автоматической защиты от пиратства: необходимо вручную проверять чек App Store, чтобы убедиться в легальности копии. Большинство кодов верификации чеков тривиально взламывается, поэтому приложение, распространяемое через Mac App Store, защищено от пиратства не сильнее, чем приложение, распространяемое напрямую.
Маркетинг
Я добавил этот раздел в первую очередь для того, чтобы сказать: нет серьёзных различий в маркетинге при прямом распространении приложения для Mac и при распространении через Mac App Store. В наши дни простой выпуск приложения в App Store практически ничего не значит, потому что низка вероятность того, что пользователи просто органически обнаружат совершенно новое приложение без внешней информации.
При распространении через App Store можно пропустить этап создания веб-сайта, так как в качестве основной «витрины» можно использовать страницу в App Store, но даже в этом случае я считаю, что большинство приложений выиграет от наличия отдельной лэндинг-страницы.
Маркетинг приложений сам по себе может быть темой для ещё одного руководства, но в целом можно порекомендовать использовать любые доступные вам каналы, особенно если у вас уже есть подписчики (в Twitter, Instagram, TikTok и т.д.). Отправка своего приложения (с бесплатной лицензией) веб-сайтам и людям, занимающимся обзорами приложений для Mac, тоже может стать отличным способом повышения популярности. Также можно использовать платную рекламу в социальных сетях, подкастах и изданиях.
