подписки, все ок в очереди приходящих транзакций
2. Если я делаю восстановление покупок, тоже все ок.
3. Если я во время действующей подписки пытаюсь купить снова, то показывает что куплено, транзакция приходит одна, все ок, очередь правильная.
4. Только если я делал п.3, то после перезагрузки приложения единоразово приходит очередь из всех ранее совершенных транзакций с transactionState == .purchased (Например 14 шт, если еще раз подпишусь то теперь будет 15 приходить и тд)
До перезагрузки аппки все отлично, почему после перезагрузеи приходит эта очередь, она совсем нежданная мною. Может есть объяснение и так надо? Может это решаемо? Или это баг и нужно просто добавить костыль?
А ты завершаешь все транзакции после обработки?
Да. Я для уверенности могу еще несколько раз нажать покупку (при уже купленной подписке), оно возвращает лишь ОДНУ транзакцию, и сообщение что уже куплено. Но как только перезагружаю приложение, прилетают 15 штук .purchased
this is the Way ;) то есть так задумано самим эпплом. каждый раз когда ты чего то запрашиваешь - генерируется новая транзакция в которой содержится информация об оригинальной транзакции
Но после рестарта прилетают просто все старые, которые я уже завершал ранее и они перестали приходить. Мне их зачем-то снова все пушат... Причем только в случае если я попытался купить уже купленное)))
так для этого и пушат чтобы ты проверил и понял что неправ пытаясь купить уже купленное. короче искать логику в этом не нужно, нужно просто построить обработку квитанций так чтобы выдавался купленный согласно входным билетам контент. и все.
Открыл детали поведения: 1. Если я пытаюсь купить купленное, то в paymentQueue:updatedTransactions приходить только эта одна попытка, но SKPaymentQueue.default() добавляются закулисами все предыдущие, до релоада в делегат они не отправляются. А при рестарте они уже оттуда все приходят в paymentQueue:updatedTransactions
Правильно проверять купленные билеты на обновляемую подписку это только через Validate App Store Receipt и вот это все? Без сервера это дело совсем тяжко проверять как я понял? Ибо во входных SKPaymentTransaction только дата покупки хранится, а высчитывать дату окончания это как я понял не принято и вообще может быть ошибочно посчитано?
да, если делать все по уму - то без своего сервера или по крайней мере строоннего сервиса валидации не обойтись. есть библотеки которые позволяют на устройстве проверять но это не есть правильно
А если допустим забить на валидацию как на безопасность, то как правильно проверить: 1. Истекла подписка или нет по факту 2. Дату окончания подписки
отсылать эпплу и получать расшифровку. но ты подставляешься под MitM-атаку
Но это они об этом же пишут НЕ ДЕЛАЙ ТАК? Имеется ввиду что просто реджект получу за это или всего лишь предупреждение что лучше бы так не делать?
реджект нет, просто не безопасно
Выходит что для одной лишь операции проверки чека, нужно на каком-нибудь Vapor писать сервер, заливать его на хероку и юзать его лишь для проверки подписки? (((
погугли RevenueCat
Спасибо!!! RevenueCat это лидер выбора или есть ближайший конкурент сравнить?
AppHud, qonversion
Благодарю
Обсуждают сегодня