Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SKPayment.quantity member not accessible #200

Closed
4 of 9 tasks
cleofasv opened this issue May 9, 2017 · 7 comments
Closed
4 of 9 tasks

SKPayment.quantity member not accessible #200

cleofasv opened this issue May 9, 2017 · 7 comments

Comments

@cleofasv
Copy link

cleofasv commented May 9, 2017

Platform

  • iOS
  • macOS
  • tvOS

In app purchase type

  • Consumable
  • Non-consumable
  • Auto-Renewable Subscription
  • Non-Renewing Subscription

Environment

  • Sandbox
  • Production

Version

0.4.0

Related issues

None

Report

Issue summary

The framework does not provide a way to access the SKPayment.quantity member during purchase. A workaround is to do multiple single purchase transactions to match the quantity, but this would generate multiple receipts.

What did you expect to happen

Enable users to access SKPayment.quantity to support multiple purchases in one purchase transaction to receive just one transaction receipt.

What happened instead

Could not find a way to access the SKPayment.quantity.

@bizz84
Copy link
Owner

bizz84 commented May 9, 2017

I plan to implement this soon. The new API will likely look like this:

SwiftyStoreKit.purchaseProduct(productId, atomically: atomically, quantity: quantity)

I will also look into exposing the quantity parameter of SKProduct in the Product object returned by the purchase method.

@cleofasv
Copy link
Author

Thanks so much @bizz84! I'll keep posted on future releases of SwiftyStoreKit. Also, if ever you need a hand on implementation, I'm very willing to contribute.

@bizz84
Copy link
Owner

bizz84 commented May 10, 2017

@cleofasv I have added the quantity option when making purchases. This is also returned as part of Payment when the callback is called.

You can test this on the latest develop branch.

As for contributing, as soon as I can get some issues ready with some implementation specs it would be great to get you on board!

@cleofasv
Copy link
Author

cleofasv commented May 11, 2017

Thank you so much, @bizz84! I won't be able to test this just yet. Our code base is still Swift2.3, and migration to Swift3 is set to start on June/July. For now, I will be using the workaround.

Edit: @bizz84 , is it possible to port this support for Swift2.3? After further analysis, we found that it is inconvenient for the users to tap on the Purchase confirmation dialog multiple times if we use the workaround(multiple single transaction.) I understand that support for 2.3 has already stopped, but we're hoping that you'd reconsider.

@bizz84
Copy link
Owner

bizz84 commented May 11, 2017

@cleofasv While I don't have bandwidth to support Swift 2.3, implementing this on your own fork is fairly straightforward:

  • Locate the startPayment() method in InAppProductPurchaseRequest, and add the following line:
let payment = SKMutablePayment(product: product)
payment.applicationUsername = applicationUsername
payment.quantity = quantity // new code
  • Add a quantity parameter to InAppProductPurchaseRequest.startPayment()
  • Add a quantity parameter to SwiftyStoreKit.purchase(), and pass that to InAppProductPurchaseRequest.startPayment()

This should be all you need for the purchase path. Any compiler errors can be fixed by passing thequantity parameter to various places if missing.

If you also want to see the quantity in your callback, you could just modify PurchaseResult and pass along the quantity from your SKProductTransaction as needed:

public enum PurchaseResult {
        case Success(productId: String, quantity: Int)
        case Error(error: PurchaseError)
}

@bizz84
Copy link
Owner

bizz84 commented May 11, 2017

Closing this issue as this is now available on pod version 0.9.0

@bizz84 bizz84 closed this as completed May 11, 2017
@cleofasv
Copy link
Author

cleofasv commented May 11, 2017

Oh alright @bizz84, we'll just fork 2.3 and do our modifications there. Thank you so much for the support!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants