Согласно нашим данным и тем чекам, что мы видели, in_app содержит только первую транзакцию авто-возобновляемой подписки. Правда есть случаи, когда могут быть более одной транзакции, например, при восстановлении транзакций, но в случае подписок это все равно бесполезный массив
Да, все покрывается. Серверные события говорят лишь о том, что в чеке что-то изменилось: возврат, смена подписки. Это уже описано в статье. Кстати, на эту тему у нас тоже есть пояснительная статья на хабре.
чек по ссылке [NSBundle mainBundle].appStoreReceiptURL при установке из AppStore есть сразу при 1 запуске приложения. Если это верно для всех версий iOS то это супер.
Да, именно так.
App Store Аккаунт действительно можно сменить, однако это редкий случай) Максимум, чем это грозит, это то, что вы покажете новому пользователю недоступность триала, хотя он на самом деле будет доступен. Как вариант, да, можно выполнять SKReceiptRefreshRequest перед каждым отображением экрана покупки, но стоят ли эти усилия редкого кейса смены Apple ID, решать вам.
Но тут дело не только в проверки доступности. Вы можете оформить подписку и сразу же сменить App Store аккаунт, подписка по прежнему будет активна до тех пор, пока вы не обновите чек.
Это глобальная проблема связи между Apple ID аккаунтами и аккаунтами в вашем приложении, и каждый разработчик решает по своему усмотрению.
Если приложение установлено на чистую, то чек будет всегда (если скачано с апстора). Для ревьюеров и для себя нужно рефрешить чек через SKReceiptRefreshRequest, но как вы сказали, будет запрос юзеру на пароль. И некоторые ревьюеры могут отреджектить приложение из-за этого.
Поэтому, можно не делать проверку доступности триала (intro), если нет чека.
Вот тут можете почитать.
Вы немного неправильно поняли, чек (App Store Receipt) – он всегда один и содержит в себе транзакции покупок и возобновлений.
На валидацию отправляется единый чек в виде binary и возвращается JSON.
В latest_receipt_info смотрите наиболее позднюю транзакцию и ее expires_date.
Правда учитывать только expires_date ненадежно, о чем написано в подводных камнях в конце статьи. Попробуйте ApphudSDK, там все сделано уже :)
И да, и нет. SwiftUI действительно позволяет писать на все устройства, включая Apple TV и Apple Watch. Однако универсален лишь синтаксис и общие принципы. Универсальным приложение все равно не будет из-за различий в железе и размере экранов. На эту тему есть замечательное видео с wwdc (смотреть с 4й минуты)
Да, именно так.
App Store Аккаунт действительно можно сменить, однако это редкий случай) Максимум, чем это грозит, это то, что вы покажете новому пользователю недоступность триала, хотя он на самом деле будет доступен. Как вариант, да, можно выполнять SKReceiptRefreshRequest перед каждым отображением экрана покупки, но стоят ли эти усилия редкого кейса смены Apple ID, решать вам.
Но тут дело не только в проверки доступности. Вы можете оформить подписку и сразу же сменить App Store аккаунт, подписка по прежнему будет активна до тех пор, пока вы не обновите чек.
Это глобальная проблема связи между Apple ID аккаунтами и аккаунтами в вашем приложении, и каждый разработчик решает по своему усмотрению.
SKReceiptRefreshRequest, но как вы сказали, будет запрос юзеру на пароль. И некоторые ревьюеры могут отреджектить приложение из-за этого.Поэтому, можно не делать проверку доступности триала (intro), если нет чека.
Вот тут можете почитать.
На валидацию отправляется единый чек в виде binary и возвращается JSON.
В latest_receipt_info смотрите наиболее позднюю транзакцию и ее expires_date.
Правда учитывать только expires_date ненадежно, о чем написано в подводных камнях в конце статьи. Попробуйте ApphudSDK, там все сделано уже :)
Немного не понял по схемам: почему на всех ваших схемах компрессор сужается, а турбина расширяется?