Как сделать демо какао-приложение, которое работает только в течение ограниченного времени?

Я использовал множество демо-приложений cocoa, которые перестают работать через 3 дня или месяц или около того. Как они это делают? Каков наилучший способ? Кроме того, каковы ограничения?

3 ответов


(отказ от ответственности: я никогда не делал пробную версию раньше, только читал по этому вопросу и использовал кучу из них.)

ограничения все, происходят от того, что ничего в системе пользователя, пользователь может изменить. Итак:

  • Clever cheapskates может изменить исполняемый файл вашего приложения, чтобы заглушить или иным образом победить любую проверку вы делаете.
  • вы должны хранить количество используемого времени (или, более лениво, но не так удобно, дата, когда они начали использовать ваш приложение) где-то. Где бы вы ни хранили его, пользователь должен иметь возможность изменить его (так как ваше приложение работает как они), что означает, что если они найдут его, они могут сбросить часы.
  • это невозможно, если вы работаете в песочнице, если вы не храните вышеупомянутые данные отслеживания времени в пользовательских значениях по умолчанию или связке ключей, любой из которых также может быть на виду, или запросить право временного исключения для записи в любом месте файловой системы. Ограниченные по времени испытания не могут быть в приложении Магазин в любом случае, но если в будущей версии Mac OS X потребуется App Store или sandboxing, ваш лимит времени сломается, и мы можем только надеяться, что это не помешает пользователю полностью использовать ваше приложение.
  • есть также вопрос обработки платежей. Один из способов-продать приложение в App Store без какого-либо кода пробного исполнения и распространить отдельную сборку самостоятельно, которая всегда обеспечивает ограничение по времени. Если вы обрабатываете платежи самостоятельно, вам нужно сохраните запись лицензии пользователя в системе пользователя, и вам нужно проверить эту лицензию. Затем это становится уязвимым для той же проблемы: пользователь может подделать лицензию или "заимствовать" (например, загрузить с сайта warez) чью-то еще.

плюс, конечно, в том, что у пользователя есть некоторое количество времени, чтобы попробовать приложение бесплатно без необходимости кашлять какие-либо деньги, поэтому в конце этого времени (если ваше приложение хорошо и заполняет их потребности), они будут больше скорее всего, купит.

В конце пробного периода, у вас есть выбор, что происходит:

  • заблокировать пользователя из приложения полностью.
  • вырезать функции. Желудь это.
  • пусть они открывают документы, но не сохранить или распечатать. (Вы можете блокировать скриншоты, но тогда удачи в обработке отчетов об ошибках.)
  • пусть они сохраняют или (если применимо) печатают, но каким-то образом ухудшают часть или весь документ. Для визуальных творений, таких как изображения, водяной знак может работать. Для аудио вы можете ограничить частоту дискретизации чем-то неприятным, например 20 кГц или меньше. (Здесь есть случай иметь свой собственный формат, который вы всегда обрабатываете без потерь, и только ухудшающий экспорт в общие форматы, такие как TIFF, JFIF или AIFF. Деление делает это.
  • просто пилить их. (Может сочетаться с любым из вышеперечисленных.)
  • пилить их и поставить задержку на способность пользователя уволить его. Вы даже можете увеличить задержку дольше пользователь идет без оплаты.

одна хорошая альтернатива пробному периоду - иметь отдельную "бесплатную" версию с меньшим количеством функций (или с рекламой). Это особенно распространено в обоих магазинах приложений.

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

вы также можете установить ограничение на количество запусков. Это так же просто реализовать, как дней с первого использования, но не наказывает только играть с приложением один раз.

некоторые пользователи просто не будут платить. Некоторые пользователи сделают практически все, чтобы не платить.

таким образом, вам нужно найти баланс. Вам необходимо предоставить базовый уровень трудность такова, что самые ленивые скряги не могут просто defaults write com.example.yourapp DaysSinceFirstUse -int 0 и продолжайте использовать свое приложение навсегда, не делая ваше приложение настолько обременительным, чтобы попробовать (гораздо меньше платить) , что они этого не делают.

Так вот некоторые вещи не чтобы делать:

  • попытка обеспечить равенство между именем пользователя в его лицензии (введенной при покупке) и его именем в его учетной записи или в адресной книге. Есть дюжина различных способов написать любой имя, а некоторые люди имеют несколько имен (через брак, псевдонимы, законные изменения имен,несколько языков, фэндом Star Trek и т. д.), так что это или что-то вроде этого-фиктивная проверка, которая расстроит более законных пользователей, чем отпугнет пиратов.
  • держите данные пользователя в заложниках. См. мой пункт выше о достоинствах проприетарного формата, который вы всегда обрабатываете без потерь. Если вы всегда ухудшаете вывод во время пробной версии, сделайте это абсолютно ясным перед запуском приложения "это диалог "пробная версия".
  • требуется подключение к интернету. Не у всех есть один (который может подключаться к произвольным серверам), и не у всех есть один все время. Учитесь у игровой индустрии: не отчуждайте своих пользователей.
  • установите любое программное обеспечение для защиты авторских прав, которое работает в фоновом режиме и / или находится в отдельном месте от вашего приложения. Пользователи будут справедливо ненавидеть вас за это.

Как to сделать это, вот что я рекомендую:

  • реализовать проверку" дней фактического использования". Это может быть точкой продажи. Это согревает мое сердце, когда суд явно говорит, что использует этот вид проверки.
    • Я бы сказал, хранить его в часах. При запуске, получить текущее количество часов от того, где вы храните его. Добавьте два часа и запишите его обратно (чтобы пользователь не мог принудительно выйти из приложения, чтобы победить это). При выходе добавьте реальное количество часов с момента запуска к первоначально прочитанному номеру и запишите исправленный номер.
  • храните его в невидимом файле в Службе поддержки приложений. Зашифруйте его (опять же, вы хотите победить случайное пиратство), но не тратьте слишком много времени на его защиту. Помните, что ваше приложение должно содержать все, чтобы как зашифровать его (отслеживать), так и расшифровать (выполнить проверку), поэтому достаточно решительный (и образованный) скряга может сломать это независимо от того, что вы делаете.
  • при запуске, получить текущее количество часов из любого места, где вы его храните, и проверьте, превышает ли он лимит. (Если вы принимаете мое предложение добавить два часа сразу, сделайте это после вы тестируете против предела.) 30 дней 30×24=720 часов. Если это превышает лимит, примите меры, срок действия которых истек.
  • если вы продаете программное обеспечение самостоятельно, используйте симметричное шифрование открытым ключом для файла лицензии. Я думаю AquaticPrime это. Вы шифруете лицензии с помощью своего закрытого ключа и распространяете открытый ключ в приложении, который использует открытый ключ для расшифровки и проверки лицензии. Практически нерушимый. Вы отправляете файлы лицензий клиентам по электронной почте, используя адрес электронной почты, который они предоставляют при покупке. (Скажите им, что они получат лицензию по электронной почте, чтобы они не вводили придуманный адрес.)
    • если вы это сделаете, убедитесь, что вы тестируете ввод лицензии, как до окончания судебного разбирательства, так и после его окончания.
    • сделать пробную проверку, только если нет лицензии.
  • если вы можете продать свое приложение в App Store, я рекомендую вам просто сделать это. Если вы хотите также распространять пробную версию самостоятельно, сделайте это без лицензионного кода, поэтому пробная проверка просто происходит безоговорочно. Версия App Store, конечно, не нуждается (и не должна иметь) пробную проверку.
  • смотреть на это. (Примечание: он предварительно датирует оба магазина приложений Apple.)

В общем, они сохраняют количество дней / часов / все, что используется где-то, например, в пользовательских настройках приложения.

поскольку довольно легко изменить пользовательские значения по умолчанию приложения, Некоторые пишут простой хэш в файл, который должен соответствовать количеству используемых дней. Если нет, они заканчивают сборку прямо тогда и там, потому что пользователь, очевидно, просто испортил эту настройку. Другие хранят несколько копий количества дней, используемых счетчиком. Если один отсутствует, они восстанавливают его на основе наименьшего числа в одном из других мест.

хорошие местоположения-это невидимые файлы в местах, которые пользователь не ожидал бы, возможно, названные так, чтобы они выглядели похожими на файл другим приложением или системным файлом. Но будьте осторожны, чтобы не засорять файлы в файловой системе, которые затем дают другое приложение, они выглядят как плохое имя. Также стоит рассмотреть возможность записи ресурса в вилку ресурсов файла, где большинство людей больше не смотрят в эти дни (один из код файлы! Другое приложение или система может заменить их файл и лишить вас информации,или может использовать тот же тип ресурса и вызвать столкновение).

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

некоторые разработчики приложений вместо этого генерируют лицензионный ключ, который имеет срок действия в нем и заставить приложение отказаться от запуска без действительного лицензионного ключа. Есть хорошая статья Аллана Одгаард о том, как подписать данные с помощью OpenSSL (убедитесь, что вы используете LibreSSL или CommonCrypto.рамки в эти дни, которые очень похожи), чтобы получить срок действия для вашего пользователя, не имея возможности редактировать его:http://sigpipe.macromates.com/2004/09/05/using-openssl-for-license-keys/


основываясь на ваших идеях, я сделал короткое доказательство концепции в Java, используя криптографию эллиптической кривой, чтобы создать UUID при запуске, а затем подписать этот UUID с ECC для создания регистрационного ключа. Код здесь, Если кто-то захочет.1