restore purchases что это значит
Что означает» восстановить покупки » в покупках в приложении?
Я действительно не понимаю эту идею. Должен ли я предоставить кнопку восстановления для пользователя? Какой метод должен вызывать этот метод? Что будет делать restore?
3 ответов
обычно вы восстанавливаете покупки с помощью этого кода:
не все типы покупок в приложении могут быть восстановлены.
вы получите сообщение об отклонении от apple только потому, что продукт, который вы зарегистрировали для покупки inApp, может подпадать под категорию необновляемых подписок и расходных продуктов. Этот тип продуктов не будет автоматически возобновляемым. вам нужно иметь явную кнопку restore в вашем приложении.
для другого типа продуктов он автоматически восстановит его.
пожалуйста, прочитайте следующий текст, который очистит вашу концепцию об этом:
после того как транзакция была обработана и удаляется из очереди, ваш приложение обычно никогда не видит его снова. Однако, если ваше приложение поддерживает типы продуктов, которые должны быть восстановимыми, необходимо включить интерфейс, позволяющий пользователям восстанавливать эти покупки. Этот интерфейс позволяет пользователю добавлять продукт на другие устройства или, если оригинал устройство было стерто, чтобы восстановить транзакцию на исходном устройстве.
магазин комплект обеспечивает встроенный функциональность для восстановления проводки для non-потребляемые продукты, автоматическ-возобновляемые подписки и свободно подписки. Для восстановления транзакций приложение вызывает метод restoreCompletedTransactions очереди платежей. Очереди оплаты отправляет запрос в App Store для восстановления транзакций. В return, App Store генерирует новую транзакцию восстановления для каждого транзакция, которая была ранее завершена. Операции восстановления свойство originalTransaction объекта содержит копию оригинала торговая операция. Приложение обрабатывает транзакцию восстановления с помощью получение исходной транзакции и ее использование для разблокировки приобретенный контент. После Store Kit восстанавливает все предыдущие транзакции, он уведомляет наблюдателей очереди платежей, вызывая их paymentQueueRestoreCompletedTransactionsfinished: метод.
если пользователь пытается приобрести восстанавливаемый продукт (вместо используя реализованный вами интерфейс восстановления), приложение получает обычная транзакция для этого элемента, а не транзакция восстановления. Однако, потребитель не поручен снова для этого продукта. Ваш приложение должно обработать эти проводки одинаково к исходная транзакция. Номера-продление подписки и расходных материалов продукты не восстанавливаются автоматически магазином Kit. Не возобновляя однако подписки должны быть восстановлены. Восстановление этих продуктов, транзакции необходимо записывать на собственном сервере, когда они приобретенные и предоставить свой собственный механизм для восстановления этих транзакций к устройствам пользователя
Это как дополнительная функция.
Если вы не предоставите его, когда пользователь попытается приобрести непотребляемый продукт, AppStore восстановит старую транзакцию. Но ваше приложение будет думать, что это новая сделка.
Если вы предоставите механизм восстановления, ваш менеджер покупок увидит восстановленную транзакцию.
Если приложение должно различать эти параметры, вы должны предоставить функциональность для восстановления ранее приобретенных продуктов.
Что означает «restore purchases» in In-App purchases?
Я не совсем понимаю эту идею. Должен ли я предоставить пользователю кнопку восстановления? Какой метод должен вызывать этот метод? Что будет делать восстановление?
3 ответа
Я знаю, что собираюсь спросить что-то, что может показаться немного странным, но все же спрашиваю Я разрабатываю приложение, которое имеет функцию покупки в приложении, я интегрировал код, но для тестирования мне нужно создать тестовую учетную запись под iTunes connect. Во время R&D я узнал.
При реализации функций покупки в приложении должен ли я обслуживать опцию restore purchases для пользователя, или эта функция только optional/suggested?
Обычно вы восстанавливаете покупки с помощью этого кода:
Не все типы покупок в приложении могут быть восстановлены.
Вы получите сообщение об отказе от Apple только потому, что продукт, который вы зарегистрировали для покупки inApp, может попасть в категорию невозобновляемых подписок и расходных продуктов. Этот тип продуктов не будет автоматически возобновляться. в вашем приложении должна быть кнопка явного восстановления.
для других типов продуктов он автоматически восстановит его.
Пожалуйста, прочтите следующий текст, который прояснит ваше представление об этом :
После того, как транзакция была обработана и удалена из очереди, ваше приложение обычно никогда не видит ее снова. Однако, если приложение поддерживает типы продуктов, которые необходимо восстановить, необходимо включить интерфейс, позволяющий пользователям восстанавливать эти покупки. Этот интерфейс позволяет пользователю добавлять продукт на другие устройства или, если исходное устройство было стерто, восстанавливать транзакцию на исходном устройстве.
В настоящее время я разрабатываю версию basic приложения iOS. В какой-то момент в будущем я хочу добавить функциональность, которую я хочу сделать доступной в качестве покупки в приложении. Какие шаги я должен предпринять, чтобы убедиться, что смогу расширить свое приложение позже? (Примечание: Я.
Я хочу не автоматически возобновляемые подписки в Google In app purchases. Согласно Google Docs, подписки на приложения автоматически возобновляются, что означает, что они будут продлены после указанного времени. Я хочу не автоматически возобновляемые подписки. Итак, что я сделаю, так это отменю.
Является ли это дополнительной функциональностью.
Если вы не предоставите его, когда пользователь попытается приобрести непотребляемый продукт, AppStore восстановит старую транзакцию. Но ваше приложение будет думать, что это новая транзакция.
Если вы предоставите механизм восстановления, то ваш менеджер по закупкам увидит восстановленную транзакцию.
Если приложение должно различать эти параметры, то вы должны предоставить функциональность для восстановления ранее приобретенных продуктов.
Похожие вопросы:
Я видел некоторые вещи о том, что Apple отвергает ваше приложение, если вы не предлагаете опцию restore purchases. Я никогда не видел этого в приложении, но, конечно, я сам не очень много покупаю в.
Я работаю с Amazon In-app-purchases для Android на flash, используя собственные расширения. Итак, я реализовал поток покупок в песочнице ( я использовал их файл InAppSDK-SandboxData.json для.
Я знаю, что собираюсь спросить что-то, что может показаться немного странным, но все же спрашиваю Я разрабатываю приложение, которое имеет функцию покупки в приложении, я интегрировал код, но для.
При реализации функций покупки в приложении должен ли я обслуживать опцию restore purchases для пользователя, или эта функция только optional/suggested?
В настоящее время я разрабатываю версию basic приложения iOS. В какой-то момент в будущем я хочу добавить функциональность, которую я хочу сделать доступной в качестве покупки в приложении. Какие.
Я хочу не автоматически возобновляемые подписки в Google In app purchases. Согласно Google Docs, подписки на приложения автоматически возобновляются, что означает, что они будут продлены после.
Я разрабатываю приложение, которое имеет in-app-purchases с подписками (пользователь может купить ежемесячную / годовую подписку). Как я могу получить уведомление о действиях, связанных с подпиской.
можно ли протестировать in-app-purchases для тестирования разработки без учетной записи разработчика? Я не могу получить доступ к sanbox и функциям, не будучи участником разработчика в itunes.
iOS in-app purchases: часть 2: Инициализация и обработка покупок
Всем привет, меня зовут Виталий, я основатель Adapty. Мы продолжаем цикл статей, посвещенных встроенным покупкам в iOS приложениях:
В нашем блоге также есть туториалы для Android, React Native и Flutter, заходите, чтобы найти что-то полезное.
В данной статье мы разберем создание простейшего пейволла (платежного экрана), а также инициализацию и обработку покупок, настроенных нами на первом этапе.
Создание экрана с подписками
В любом приложении, которое использует встроенные покупки присутствует пейволл. Есть требования от Apple, которые определяют минимальный набор необходимых элементов и поясняющих текстов для подобных экранов. На данном этапе мы не будем максимально точно выполнять их все, но наш вариант будет очень приближен к рабочему варианту.
Итак, наш экран будет состоять из следующих функциональных элементов:
Для верстки я использовал Interface Builder Storyboard. В код класса ViewController, который содержит всю необходимую логику UI я вынес связи с кнопками покупок и индикатором прогресса (UIActivityIndicatorView) для того, чтобы визуализировать процесс оплаты.
Доработка кода для отображения информации о покупках
Разберем каркас нашего ViewController. Пока что тут нет логики, мы допишем ее позднее.
Обратите внимание, как здесь (1) используются объекты SKProduct. Мы не используем их поля напрямую, но сделаем extension для более удобного извлечения необходимой нам информации:
Дорабатываем модуль Purchases
В прошлой части мы провели инициализацию модуля покупок. Для этого мы запросили информацию о месячной и годовой подписке у серверов Apple. Я немного доработал класс Purchases для того, чтобы результат асинхронной операции было возможно отображать в интерфейсе, а также добавил сохранение объектов SKProduct в память для дальнейшего использования.
Реализация механизма покупки
Для того, чтобы полноценно сообщать об ошибках, произошедших внутри нашего кода, создадим enum PurchaseError, который будет реализовать протокол Error (или LocalizedError):
Если же во время оплаты произойдут ошибки на уровне StoreKit, то в результате мы также получим ошибку (подробнее о типах ошибок можно почитать в документации).
Функция purchaseProduct запускает процесс покупки выбранного нами продукта, а restorePurchases — запрашивает у системы список уже совершенных пользователей покупок (автовозобновляемые подписки или non-consumable покупки):
Для того, чтобы обрабатывать результаты покупок, нам необходимо реализовать протокол SKPaymentTransactionObserver:
В данном случае мы рассмотрели не все возможные состояния транзакции. Существует также состояние purchasing (означает, что транзакция находится в процессе обработки) и deferred — транзакция отложена на неопределенное время и будет завершена позднее (например, в ожидании подтверждения от родителей). Эти состояния при необходимости также можно показывать в UI.
Вызовы в интерфейсе
Теперь осталось только вызвать данные функции из нашего ViewController, позаботившись о том, чтобы процесс был визуализирован, а всевозможные ошибки отображены пользователю.
Вот и все, очередной забор за нашей спиной. Спасибо Алексею Гончарову x401om за помощь в подготовке статьи.
Про Adapty
В целом, добавление покупок в приложения — довольно трудоёмкий процесс. Поэтому советуем познакомиться с SDK Adapty для in-app покупок. Он не только облегчает работу по подключению покупок, но и даёт много других преимуществ:
Познакомьтесь подробнее с этими возможностями, чтобы быстрее внедрить подписки в своё приложение и улучшить конверсии.
15 советов, как пройти ревью в App Store приложению с подписками
В этой статье я расскажу, как увеличить шансы пройти проверку в App Store приложению с подписками. Если вы когда-либо испытывали проблему с аппрувом приложений с подписками или вот-вот планируете релиз, тогда это будет вам полезно.
Как вы наверняка знаете, проверка состоит из двух этапов: ручная проверка (приложение просматривает человек) и автоматическая проверка ботом. Но не каждое обновление проверяется человеком. С каждым годом доля автоматических проверок увеличивается и бот берет на себя все бóльшую роль при проверки приложений.
Важные сведения о проверке приложений
Мы не знаем, как именно проверяют приложения и в каком случае оно отправляется на ручную проверку, но наш опыт подсказывает, что справедливо следующее.
Советы при отправке на ревью
Ниже мы приводим некоторые рекомендации, которые помогут облегчить прохождение модерации.
1. Заранее создайте все возможные длительности подписок и отправьте их на ревью
Если вы добавите новые подписки в обновлении, то оно с большой вероятностью уйдет на модерацию к ревьюеру. А ведь разумно сводить число ручных проверок к минимуму, правда? Поэтому желательно отправлять на ревью приложение сразу с полным набором подписок. Создайте несколько продуктов с разными ценами и длительностями, даже если они сейчас и не нужны. Поверьте, в будущем пригодятся.
2. Максимально упростите экран покупки при ее отправке на первую проверку
Избегайте неочевидных трактовок и нестандартных интерфейсных решений. В первый раз пройдите проверку с самым простым экраном покупки. Когда пройдете, сможете его обновить по своему усмотрению (но, разумеется, в рамках App Review Guidelines).
Кстати, ревьюеры запросто могут проверить ваше приложение вручную в любое время. Даже если вы не отправляли обновление. Учитывайте это и не меняйте интерфейс экрана покупки после прохождения модерации без ведома Apple. Это чревато удалением приложения из App Store.
3. Укажите сразу все варианты подписок на экране покупки
Модераторы Apple не будут тратить много времени на поиск всех возможных подписок в вашем приложении. Потому мы советуем сделать один экран со всеми возможными покупками, доступными пользователю. Например, используйте одну большую кнопку с основной подпиской и кнопку “показать больше опций”, при нажатии на которую будет показываться экран с остальными вариантами подписок.
4. Добавьте информацию о подписках.
Это крайне важный пункт. Информация о подписке может быть написана мелким шрифтом (но оставаться читабельной), может быть обрезана, но обязательно должна быть видна хотя бы частично без прокрутки экрана.
На экране покупки вы должны указать следующее:
Мы также рекомендуем для первой проверки добавить в самое начало еще одну фразу :
В последующих обновлениях это предложение можно опустить.
5. Проверьте экраны покупки
Ревьюеры почти всегда проверяют приложения на iPad, на которых стоят экраны с пропорциями iPhone 6s. Поэтому обязательно проверьте экраны покупки на iPhone 5s/SE и 6/6s.
6. Предварительно загрузите продукты
Никогда не показывайте пользователю экран покупки без предварительно загруженных продуктов. Приложение отклонят, если вы отобразите ревьюеру кликабельный экран покупки без цены на кнопке, пусть даже на пару секунд.
7. Указывайте полную цену
Всегда указывайте полную цену, соответствующую периоду подписки: 599 руб в год, 199 руб в неделю. Не делите цены (например, на кнопке нельзя показывать цену28 руб в день (28 руб
199 руб / 7 дней) при подписке 199 рублей в неделю).
8. Локализуйте цены покупок
Цены покупок должны быть показаны пользователю в его валюте. Это можно сделать, например, так:
9. Добавьте ссылки на Правила пользования (Terms of use) и Политику конфиденциальности (Privacy policy)
Ревьюеры всегда их открывают, но в текст особо не вчитываются. Убедитесь, что ссылки не битые и не перепутаны. Для создания правил и политики можно воспользоваться любым генератором, например, TermsFeed, Termly или даже этим безымянным сервисом.
10. Добавьте восстановление покупок
На экране покупки следует обязательно разместить кнопку восстановления покупок (Restore Purchases). Желательно хотя бы на первый релиз сделать ее крупной и назвать именно “Восстановить Покупки” (“Restore Purchases”). Известны случаи, когда приложение отклоняли из-за того, что на кнопке было указано “Restore” (“Восстановить”) вместо “Restore Purchases” (“Восстановить Покупки”)
11. Не делайте недельную или годовую покупку основной, по крайней мере на первый релиз.
Месячная – в самый раз. Добавьте щедрый триал – уменьшить его можно в любое время.
12. Укажите действительные цены
Желательно сразу указать действительные цены. Если будете менять их после релиза, может сработать триггер, и ваше приложение уйдет к ревьюеру.
13. Не забудьте обновить интерфейс должным образом, когда пользователь оформил подписку
Например, измените статус подписки пользователя в настройках приложения с Бесплатного на Премиум.
14. Может сперва обойтись без подписок?
Если вы боитесь, что вас могут не пропустить из-за недостатка контента или функционала, то поначалу отправьте на модерацию версию без подписок. После успешного прохождения первой проверки выпустите несколько обновлений (можно с незначительными изменениями) и после этого добавьте платные подписки.
15. Не забудьте про описание приложения в App Store Connect
В описании приложения в App Store Connect не забудьте добавить информацию о подписках, включая их название, цену и длительность.
Если вас отреджетили, не тратьте время на споры. Спорить с ревьюерами бесполезно. Просто исправьте, что они просят.
Заключение
Сейчас каждую неделю в App Store проверяется 100 000 новых приложений и обновлений. И 40% из них отклоняют по самым разным причинам. Очень сложно пробиться в App Store без единого реджекта, особенно с подписками. Однако если вы будете соблюдать наши советы, то ваши шансы пройти проверку с первого раза сильно возрастут.
Что делать после успешной модерации? Добавьте Apphud SDK в ваше приложение и узнайте, сколько вы действительно зарабатываете на подписках.
Apphud – это удобная аналитика для подписок на iOS. Одна из функций Apphud — это отправка событий о подписках в вашу любимую систему аналитики (например, Amplitude, Flurry или Mixpanel). Проект сейчас находится на стадии Beta-тестирования, и вы можете поучаствовать в нем! Все что нужно — перейти на сайт Apphud и оставить свой email.
When to refresh a receipt vs restore purchases in iOS?
Our iOS app uses in-app purchases, both one-time and an auto-renewing subscription. Both these are non-consumable.
It seems that the latter works for all cases, while the former works in only some cases. Specifically, when we restore an auto-renewable purchase to a new device, restore purchased transactions will cause future renewals to generate a transaction that will be sent in the background to the new device, where as refreshing the receipt will not cause a transaction to be sent to this device the next time there is a renewal.
Given this, is there any reason to use refresh receipt?
Apple seems to say we can use either:
Retrieve information about past purchases by either refreshing the app receipt using the SKReceiptRefreshRequest class or restoring completed transactions using the restoreCompletedTransactions method of the SKPaymentQueue class.
3 Answers 3
You need to read this Restoring Purchased Products to understand the purposes between the 2.
Users restore transactions to maintain access to content they’ve already purchased. For example, when they upgrade to a new phone, they don’t lose all of the items they purchased on the old phone. Include some mechanism in your app to let the user restore their purchases, such as a Restore Purchases button. Restoring purchases prompts for the user’s App Store credentials, which interrupts the flow of your app: because of this, don’t automatically restore purchases, especially not every time your app is launched.
In most cases, all your app needs to do is refresh its receipt and deliver the products in its receipt. The refreshed receipt contains a record of the user’s purchases in this app, on this device or any other device. However, some apps need to take an alternate approach for one of the following reasons:
If you use Apple-hosted content, restoring completed transactions gives your app the transaction objects it uses to download the content. If you need to support versions of iOS earlier than iOS 7, where the app receipt isn’t available, restore completed transactions instead.
Refreshing the receipt asks the App Store for the latest copy of the receipt. Refreshing a receipt does not create any new transactions.
Restoring completed transactions creates a new transaction for every completed transaction the user made, essentially replaying history for your transaction queue observer.