Closed the-mace closed 7 years ago
@the-mace I get the point of the "faster" time in Apple's sandbox store. I tend to simply use the r.expires_date < Time.now.utc
solution. Sadly I'm not able to perform manual tests for subscription. Would you or @klaseskilson be able to test the change?
If you have a change I should be able to test it sometime. I'm using that r.expires_date < Time.now.utc for my expired check in production now.
@the-mace I think I've fixed this issue. Could you be so kind and check the current master branch?
gem 'candy_check', git: 'https://github.com/jnbt/candy_check.git', ref: '1dee844'
I tested this and it's working as expected. I'm now using the expired? test and it properly showed when it wasnt expired and then when it was expired.
@the-mace Thanks! I've released version 0.1.1
to rubygems.org to address this issue.
Wonderful, thanks for the support. Now if we can just get apple to let our app through...
@the-mace I'm feeling with you. It's always the same: waiting, rejection, waiting, rejection, ... :-(
When using the Sandbox the expiration checks are incorrect for the test subscriptions as subscription periods are much shorter.
expired?
andoverdue_days
are day-based so they may work in production, but on the sandbox things expire much faster (minutes) so the check for expires would be better as something like this:r.expires_date < Time.now.utc
Which would work both in production and the sandbox. The overdue_days isn't really a valid test for the sandbox. Also
expired?
depends onoverdue_days
.The workaround for now is to not use
expired?
oroverdue_days
.