Программа от разработчика не проверена
Это муторно и требует больше работы, но это будет более надежно. Пользоваться можно открытыми версиями и компонентами из реестра. Топ самых востребованных и высокооплачиваемых профессий Поможет разобраться в актуальной ситуации на рынке труда. Если не обращаться в суд, можно доработать пакет документов или сам продукт, и повторно подать заявку, но только через год. При использовании этих функций у пользователя нет технических причин пытаться вручную восстановить транзакции.
На этом туториал по внедрению встроенных покупок исключительно на устройстве завершен. Пользователь может просмотреть список продуктов на выбор, приобрести продукт, разблокировать контент или опции в приложении, восстановить покупки, использовать разблокировку в расширениях приложения, а также приобрести продвинутые продукты в App Store. Все это было реализовано в приложении с помощью Swift с использованием преимущественно StoreKit 2, но частично StoreKit 1.
Такой тип реализации StoreKit может очень хорошо работать для некоторых типов приложений. Например, он может хорошо работать, если приложение предназначено только для платформ Apple и использует Universal Purchases.
Пользователи смогут приобрести IAP и получить ожидаемый контент или разблокировку опций в приложении. Однако, одна лишь аппаратная реализация StoreKit может быть не идеальной для некоторых типов приложений. Статус подписки не может передаваться между платформами в веб или другие нативные платформы.
Этот метод не дает разработчикам информации о поведении пользователей. Пользователи не могут быть уведомлены напрямую вне приложения по электронной почте или другими способами об ошибках выставления счетов или о кампаниях по возврату средств при отмене подписки. Во всей магии StoreKit 2 заключено множество данных и скрытых возможностей. В следующем разделе этого туториала мы расскажем немного о том, что нужно для реализации StoreKit 2 с помощью бэкенда пользовательского сервера.
Продолжайте читать, чтобы узнать, станет ли это лучшим решением для вас. В приведенных выше шагах мы реализовали приложение с полной подпиской без необходимости писать какой-либо код вне приложения, но это не единственный вариант.
В этой части туториала будет обсуждаться, как спроектировать веб-сервер для взаимодействия с сервером App Store и как связать приложение iOS с веб-сервером. Образец бэкенда будет написан на Vapor веб-сервере Swift с заглушенными функциями и маршрутами. Пользовательский бэкенд можно найти здесь.
Это сервис с соответствующим названием для связи с App Store по поводу встроенных покупок и подписок. Этот API можно использовать для получения истории транзакций клиента, просмотра статуса всех подписок с автопродлением, обновления статуса расходуемых IAP, поиска заказов, получения истории возврата средств и продление даты обновления подписки. Для большинства этих конечных точек требуется исходный идентификатор транзакции, который получается из объекта Transaction после совершения покупки через собственный API StoreKit 2.
Уведомления сервера App Store предоставляют возможность отслеживать события покупки в приложении в режиме реального времени с помощью прямых уведомлений из App Store. Для каждой продакшн-среды и среды песочницы можно задать разные URL-адреса.
Существует 15 различных типов уведомлений , которые будут отправлены из версии 2 уведомлений сервера App Store:. JWS используется для повышения безопасности и уверенности в том, что полезная нагрузка была отправлена из App Store. Полезная нагрузка уведомлений содержит:. Данные :. Информация о продлении. Информация о транзакции. Это самый простой способ выполнить сквозное тестирование соединения. До появления этого метода выполнить тест можно было, купив продукт либо в песочнице, либо в рабочем приложении.
Покупка продукта по-прежнему должна осуществляться с помощью Products. Приложение больше не будет полагаться на Transaction. Бэкенд запрашивает исходный идентификатор транзакции, чтобы иметь возможность получать историю транзакций из App Store Server API и сопоставлять обновленные транзакции из App Store Server Notifications для пользователя. Это дает преимущество возможности независимо проверить покупку, а также дает бэкенду концепцию подписки.
Наряду с публикацией транзакции после успешной покупки приложение также должно публиковать обновления транзакций, которые оно обнаруживает, наблюдая за Transaction. Это необходимо для покупок. Образец бэкенда Vapor получит новую конечную точку для публикации транзакции. Конечная точка должна выполнять все следующие действия:. Обратите внимание, что все обновления транзакций продление, отмена и т.
Это означает, что бэкенд может получать повторяющиеся транзакции из приложения и в режиме реального времени из App Store Server Notifications. Бэкенд должен быть в состоянии обрабатывать эту модель поведения. Сохранение цены вместе с транзакцией важно для понимания стоимости пожизненного LTV обслуживания клиента и принятия решений о расходах на привлечение пользователей.
Лучший способ сделать это — хранить общую сумму расходов пользователя в истории транзакций. Возможно вас удивит тот факт, что App Store Server не включает в транзакции цену или валюту продукта. Это означает, что приложению для iOS необходимо передавать цену продукта.
Объект Product в StoreKit 2 имеет свойства price числовое значение и displayPrice строковое значение , которые можно использовать для этой цели.
StoreKit 2 начиная с iOS 16 не имеет возможности напрямую получить валюту, используемую для покупки продукта. Отправка displayPrice дает бэкенду возможность вручную проанализировать валюту на основе символа в строке. Если ручного анализа валюты недостаточно, можно использовать StoreKit 1 для получения валюты из объекта SKProduct. Это муторно и требует больше работы, но это будет более надежно.
Приложение теперь зависит от пользовательского бэкенда, чтобы поддерживать актуальность всех подписок и транзакций. Бэкенд должен как можно скорее быть уведомлен о продлениях, отменах, проблемах с выставлением счетов и возмещениях, чтобы пользователь приложения не получал функции или услуги, за которые он не платит.
Это можно сделать двумя способами:. Хотя нет необходимости реализовывать и то, и другое, это позволит создать гораздо более прочный, надежный и заслуживающим доверия источник. Активация App Store Server Notifications - это лучшая практика и наиболее эффективный способ поддерживать актуальность статуса подписки и возмещенных транзакций.
Это гарантирует, что любая система, наблюдающая за App Store Server Notifications, будет соответствовать информации о транзакциях, которую Apple имеет в файле. Полезная нагрузка запроса декодируется в структуру Swift SignedPayload, которая представляет responseBodyV2. Структура содержит подписанную полезную нагрузку JWS. Подписанная полезная нагрузка декодируется с использованием корневого сертификата Apple в структуру Swift NotificationPayload, которая представляет responseBodyV2DecodedPayload.
Затем NotificationPayload отправляется в рабочую очередь для обработки транзакции вне основного процесса веб-сервера. Именно здесь будут выполняться обновления базы данных транзакций и прав доступа пользователей, а также здесь можно отправлять электронные письма или другие уведомления пользователям, чтобы сообщить им о любых проблемах с выставлением счетов, истечении срока действия или возможных предложениях по возврату средств. Полную модель SignedPayload можно найти здесь.
Одна из самых рискованных частей использования App Store Server Notifications — пропустить уведомления. Если сервер App Store не получает ответ или обнаруживает неверный HTTP-ответ на веб-запрос, он повторяет попытку отправить уведомление еще пять раз. Эти повторные попытки будут происходить через 1, 12, 24, 48 и 72 часа после предыдущей попытки. Наиболее вероятно, что это произойдет из-за перебоев в работе сервера или службы.
Если какая-либо из этих попыток будет пропущена, App Store Server API можно использовать для воспроизведения этих уведомлений, чтобы получить резервную копию. Существует более обширная документация о том, как включать, получать и отвечать на уведомления, которые выходят за рамки этого туториала.
Даже при использовании уведомлений в режиме реального времени, для надежной системы необходим периодический опрос App Store Server API на наличие обновлений транзакций. Обработка транзакций очень похожа на уведомления в реальном времени, но сложная часть этого подхода заключается в том, чтобы определить, как часто планировать эти вызовы API к серверу App Store.
Наиболее очевидным подходом было бы планирование подписок с автопродлением сразу после истечения срока их действия или продления. Статусы подписки также должны быть проверены перед их продлением, чтобы увидеть, не были ли они отменены, что позволяет предупредить пользователя о скором окончании обслуживания или попытаться вернуть пользователя с помощью какого-либо предложения.
Идеального момента для этого не существует, поскольку пользователь может отменить услугу в любое время. В начале этот опрос может быть нечастым и становиться более частым по мере приближения срока действия или времени обновления.
Опрос также необходимо будет перенести после периода продления, если возникнут проблема с выставлением счетов из-за льготного периода. Это позволяет пользователю сохранить обслуживание на несколько дней, если он сможет исправить свою платежную информацию.
Подписки без автопродления и нерасходуемые продукты также следует опрашивать на наличие обновлений. Несмотря на то, что у этих типов событий нет событий отмены или продления, пользователь может запросить возврат средств, что может привести к аннулированию доступа к услугам или контенту. Поначалу опрос кажется технически простым, но может быстро превратиться в сложный танец планирования, поэтому лучше всего использовать уведомления сервера App Store: Apple будет уведомлять только о тех вещах, которые меняются, и точном времени их изменения.
Доступные для покупки продукты будут возвращены API. Эти идентификаторы продуктов в идеале должны храниться в базе данных, чтобы их можно было легко настроить при изменении платного доступа к приложению. Любое решение здесь лучше, чем жестко запрограммировать идентификатор продукта в приложении, которое можно изменить только через обновление приложения. Собственный API StoreKit 2 скрывает множество тонкостей покупок и подписок в приложении, когда дело доходит до определения текущих прав.
Есть веские причины использовать только собственный API, но есть и другие причины использовать серверную часть для управления подписками, в том числе следующие:. Получайте уведомления в режиме реального времени об изменении статуса подписки и возврате средств. Разработка серверной реализации для обработки IAP с помощью StoreKit 2 становится экспоненциально более сложной по сравнению с чистой реализацией на устройстве.
Из-за этого эта часть руководства не будет полным пошаговым руководством по созданию собственного бэкенда подписки. Наша главная цель в RevenueCat — помочь разработчикам заработать больше денег. Мы делаем это, предлагая целую платформу мобильной подписки с собственными и кросс-платформенными SDK , чтобы максимально упростить интеграцию покупок в любом приложении. Нашим клиентам не нужно беспокоиться о различных собственных API-интерфейсах подписки или сложностях синхронизации статуса подписки с продлением, отменой и проблемами выставления счетов.
Несмотря на то, что мы хотели бы иметь всех в качестве клиентов, мы знаем, что иногда лучше создавать свои собственные, и в конце концов мы хотим, чтобы все разработчики преуспели. Поиск Настройки. Время на прочтение 34 мин. Автор оригинала: Josh Holtz. Пошаговое руководство по созданию рабочего примера приложения с подписками на SwiftUI. Оглавление Вступление Терминология Настройка App Store Connect Настройка файла конфигурации StoreKit Аппаратная реализация подписок с помощью StoreKit 2 в Swift Шаг 1: Список продуктов Шаг 2: Покупка продуктов Шаг 3: Подготовка к разблокировке встроенных опций Шаг 4: Разблокировка встроенных опций Шаг 5: Обработка приобретенных продуктов в офлайне Шаг 6: Восстановление покупок Шаг 7: Совместное использование активных покупок с расширениями Шаг 8: Обработка продлений, отмен, проблем с выставлением счетов и т.
Шаг 9: Проверка поступлений Шаг Поддержка встроенный покупок из App Store Завершение данного туториала по "аппаратной" подписке Реализация StoreKit 2 с помощью сервера Сервер App Store Проектирование системы Преимущества и компромиссы Заключительные заметки Терминология In-app purchases IAPs Встроенные покупки - это цифровые продукты, которые приобретаются для использования в приложении.
У Apple есть четыре типа IAP: Расходуемые - это продукты, которые можно приобрести один раз, несколько раз и в большом количестве. Настройка App Store Connect Первым шагом к добавлению встроенных покупок в приложение является создание продуктов в App Store Connect , - панели инструментов разработчика, используемой для размещения приложений в App Store.
Создайте новую встроенную покупку Выберите тип расходуемая или нерасходуемая и задайте название ссылки и ID продукта Заполните все метаданные цена, локализация, информация об отзывах Экран App Store Connect для добавления расходуемых и нерасходуемых встроенных покупок Настройка файла конфигурации StoreKit Настройка продуктов в App Store Connect может потребовать много работы: первый шаг в начале пути к встроенным покупкам и подпискам может показаться огромным.
Она также может быть использована для: Тестирования потоков покупок в симуляторе Тестирования потоков покупок в unit и UI-тестах Локальное тестирование при отсутствии сетевого подключения Отладка крайних случаев, которые сложно настроить или воспроизвести в среде песочницы Тестирование сквозных транзакций с отказами, продлениями, проблемами с выставлением счетов, рекламными и ознакомительными предложениями. В поле поиска Filter введите "storekit". Добавьте продукты необязательно В Xcode 14 добавлена возможность синхронизировать данный файл с приложением в App Store Connect.
Выберите тип встроенной покупки. Чтобы минимизировать количество уязвимостей, требуется проверка безопасности приложений. Проводится она не только в процессе разработки или после ее завершения. Этот процесс должен быть постоянным. За г. Общее число официально зарегистрированных дыр, эксплойтов, а также других угроз составило А ведь есть еще незарегистрированные. Прикладное программное обеспечение не стоит на месте. Для приложений регулярно выпускаются обновления, появляются дополнительные функции, модули.
А вместе с ними могут возникать новые уязвимости. Поэтому компании важно обеспечить контроль, организовать эффективную систему регулярной проверки защищенности программного обеспечения. DAST от англ. Dynamic Application Security Testing это динамическое тестирование.
Его еще называют тестированием методом черного ящика.
Используется для обнаружения уязвимостей в работающих приложениях. Работающая программа тестируется в боевой обстановке путем передачи в нее вредоносных данных, внедрения ошибок и с использованием других стрессовых инструментов. Отсюда вытекают сложности, из-за которых технология подходит не каждой компании.
Для такого тестирования нужно обеспечить выполнение программы, лучше ее отдельного экземпляра именно для теста. А это дополнительные вычислительные мощности, которые могут быть не у каждого. Кроме того, требуется тщательно продумать вероятные сценарии, реализовать их в ходе тестирования. На такое тестирование иногда требуется немало времени.
Тем не менее DAST достаточно распространенная технология. И первый шаг — убедиться, что вы нас самом деле доверяете автору приложения, а также источнику, откуда скачиваете сервис. Сохранять и устанавливать что-либо с посторонних, а тем более, сомнительных сайтов крайне нежелательно, есть риск, что ваши данные и информация о смартфоне попадет в руки злоумышленников. Если все действия относительно того, как доверять приложению на iPhone в настройках, совершены правильно, доступ к сервису откроется.
Но имейте в виду, что Apple не всегда приветствует сторонние источники, и при обновлении iOS может снова пометить источник, как ненадежный. В этом случае надо будет снова скачать и установить приложение, проделав все вышеописанные шаги еще раз.
Почему не приветствует — потому как, кроме чисто корпоративных программ, через отдельные источники могут распространяться приложения с тематиками, запрещенными в App Store. Как доверять приложению на iPhone, если не работает программа управления.
Такое тоже бывает.
Иногда, для корректного доступа к приложениям, нужно заново переустановить корпоративную программу. Делается это также через Настройки:. Перезагружаем устройство и ставим корпоративную программу по новой.
Также проблема может быть в старой версии программы. В этом случае также поможет установка обновления.
