Questions regarding reliability (after using SwiftyStoreKit in production) and a delegate-based API

[almostintuitive]

Hi,

First of all, thank you all for your hard work, SwiftyStoreKit is a huge help for us.
We have been using it in production for the last 6 months (migrated over from RMStore), and found it great. (happy for it to be featured in the README: https://itunes.apple.com/us/app/5-minute-italian-drops/id939540371?ls=1&mt=8)
But also, since we made the jump, we have been getting support requests indicating that around 5-10% of our users (fluctuating between 60-200k monthly) are consistently having problems with buying IAP products.
This was not something we've experienced before - we have not had any complaints with the previous library we're using (RMStore).

1. Are there any others who have problems on a similar scale (5-10% of purchases)?

In addition to handling the standard callbacks, we're calling completeTransactions() at the start of the app, and handling its result according to the docs.

I've read that the closure (callback) based interface does not necessarily map to how StoreKit works.
I do like the convenience SwiftyStoreKit provides (receipt validation, help with subscriptions, etc), but it'd be great to optionally also use delegate methods or notifications (no matter how much I don't like any of those options personally) and potentially increase reliability via that route.
It'd be also great since we could then hook up various analytics tools to log purchases that way.

2. Is this something that other people requested?
3. Would it potentially increase the reliability of SwiftyStoreKit?

If the answer to point 3 is yes, I'll consider implementing that myself (or creating an additional library that uses most of SwiftyStoreKit's code, but provides "direct" wrapped access to the delegate methods of StoreKit.).

Thanks a lot!

Mark

[bizz84]

@itchingpixels thanks for reporting this!

I am currently working on a major refactor that hopefully will address the 5-10% of cases where purchases don't work correctly. See this PR: #131

This maps more closely to how SKPaymentQueue works in StoreKit, while retaining the same familiar callback API.

Other people have requested a way to hook up analytics / logging.

I'm open at looking at ways to include this feature once the PR above is merged, provided that the way it is implemented will keep the code clean (I would prefer to avoid scattering a lot of calls for the various checkpoints that we may wish to log).

[almostintuitive]

@bizz84 great, thank you for your response!

Is there anything I can help with the refactor? Do you have a list of actions that are left to do?
Happy to invest some time into making this happen!

Seeing how the refactor approaches payment processing, I think making that happen could be as easy as adding a "logTransactions" closure to the singleton (as far as the public facing API goes).

[bizz84]

@itchingpixels For now a code review would be most welcome.

I have added a checklist of tasks here: #131

I expect to complete most of these this weekend.

As for additional help I would appreciate some input / PR with unit tests for receipt verification, verify purchase and subscriptions.

Also if you don't mind trying out the new work that would be good too. This should help with the integration:

pod 'SwiftyStoreKit', :git => 'https://github.com/bizz84/SwiftyStoreKit.git', :branch => 'feature/payment-queue-controller'

[almostintuitive]

Okay, thank you for the info!

My schedule will be the following:

• Will get familiar & review the code, write some unit tests tomorrow (today my time will be taken up by a release)
• Test the branch with our internal QA team on Monday/Tuesday
• If everything is good, release a version of our app with the 'payment-queue-controller' branch to our test country (that's always one version ahead), and gather feedback

Thanks a lot, and looking forward to this!

[almostintuitive]

An update on my progress:

• We're starting to manually QA the new branch today - sorry for the delay.
• I've had a close look at the PR & the code in general. Unfortunately I'm really confused by all the local state that's going on inside the library, and I'm not sure if I'll be able to get my head around it to an extent where it'll be helpful. This is completely different to how I approach state (I have been using the single app state paradigm for the last few years), which is completely fine. I'd be happy to submit a PR by refactoring the whole library to use one single, immutable state object - but I do not think that'll necessarily help you or the others who are contributing to this library. Let me know if you'd like me to contribute on that level.
• One thing that I noticed is that some of the "callback" closure properties are called by switching on the main thread first, some of them called without.

I'm sorry that I'm bailing on contributing.

[bizz84]

@itchingpixels that's fine, thanks for looking into this.

I plan to keep the main design as is and only iterate in small changes going forward.

I'll also review all the callbacks for thread consistency.

If you encounter any issues with your Q/A, please let me know.

[almostintuitive]

No worries, sorry again.

QA said they've executed 80% of their test plans involving payments and so far they haven't found any issues. I'll confirm when they reach 100% and gave green light later today.

[bizz84]

@itchingpixels would be good to know if you have migrated to the new 0.7.0 release and whether this has resolved the previous IAP problems.

Thanks.

[almostintuitive]

@bizz84: we've been using it in produysince yesterday. will report back in a few days about whether we're seeing nore or less problems!

…

On 2017. Feb 4., Sat at 22:01, Andrea Bizzotto ***@***.***> wrote: @itchingpixels <https://github.com/itchingpixels> would be good to know if you have migrated to the new 0.7.0 release <https://github.com/bizz84/SwiftyStoreKit/releases/tag/0.7.0> and whether this has resolved the previous IAP problems. Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#130 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFKlYKGvX42-DsZ4IVD8Pb7lgEd8rp3dks5rZPU-gaJpZM4LoWBO> .

[janremes]

@itchingpixels Hi, we had experienced similar issue, any updates about your status and performance in production? Thanks!

[almostintuitive]

I'm sorry, I thought I did report back. So far - good. We're still seeing support tickets popping up about "restore purchase" failing sometimes (rarely), but I think we haven't got any about the actual purchase not going through.

[bizz84]

@itchingpixels I'm closing this due to inactivity. Feel free to reopen if you still experience issues.