Normally I sort out and investigate my coding issues, however, this one has stumped me and I have spent a day trawling through stackoverflow, github, youtube, apple developer documentation to no avail.
I have written an app in xcode v13, IoS 13, and the app has in-app purchases. For in-app purchases I have 2 auto-renewing subscriptions, one for a monthly subscription, the other for an annual subscription. I am testing the restore process which works fine. I have used standard apple code. However, what I am trying to do is establish/detect which service is being restored ie. suppose the use signs up for the annual subscription then when the in-app restore is done I am trying to detect that the user restore is for the annual subscription as opposed to the monthly subscription.
As I say I am struggling and have tried many many things but to no avail. Has anyone else done this and if so are you able to give any pointers as to how you do it??
Thanking everyone in advance for guidance if you've done this before...
Ok, so after spending a day trawling through many sources and getting nowhere, I stumbled across a little nugget from 2015 which has resolved the issue. To recap - what I am trying to do is ascertain "which" in-app purchase subscription a customer has previously purchased that is being restored so that I can tune the scene / UI to reflect the in-app purchase previously made. To do that I needed to find a way of determining the in-app purchase identifier. Enough of all the talk, the magic [var identifier....] code to insert is as follows and goes into the section of your code where you detect the condition of SKPaymentQueue .restored:
case .restored:
var identifier : NSString = transaction.payment.productIdentifier as NSString
print("Restore identifier is \(identifier)")
UserDefaults.standard.set(true, forKey: myProductID)
SKPaymentQueue.default().finishTransaction(transaction)
Related
So I have a question about doing an in-app purchase with a subscription in swift. I read at this link: https://www.revenuecat.com/blog/the-ultimate-guide-to-subscription-testing-on-ios#sandbox that you need your app to enter subscribed state. Is this some kind of delegate method or something I call, or does it simply mean that I enable the features? I haven't been able to find much detail on that part. Any guidance would be much appreciated. I do have the in-app purchase dialog appearing and the sandbox account working. I also get the alert saying the purchase was a successful. But even 2 seconds later if I try again it just allows me to purchase again.
By subscribed state they mean that a user still should have access to the content he unlocked with the subscription.
But even 2 seconds later if I try again it just allows me to purchase again.
Unfortunately, it is your responsibility to hide already bought in-app purchases from your users. Although, Apple prevents buying the same subscription again. So, when your first purchases succeeded, the second one should lead to an alert from Apple, that the purchases weren't executed. Otherwise, I assume your purchase logic is faulty.
How do you check the eligibility of your users? Do you validate the receipt locally, or are you using RevenueCat for that?
We have a non consumable IAP in our app which costs €3.49. I have purchased the IAP on my phone ages ago and also tested restore a couple of times and everything works just fine. This morning however, while testing the app, I uninstalled and installed the app from the App Store back on my phone. Instead of tapping 'Restore Purchases', I chose to 'Remove Ads', hence purchase the IAP again. I thought that the SDK(Xamarin.InAppPurchase) itself, would automatically track that I had previously purchased this IAP and it would go through the restore process on its own. However, I was proved wrong since a couple of minutes later, I received an invoice from Apple, that I had purchased the IAP again. I also received a statement from my bank for my purchase.
So my question here is: shouldn't the SDK itself check that the IAP was previously purchased under the Apple ID I was using? Should I amend my code on 'Remove Ads' to firstly go through the restore process and if I get a fail callback then move on to the actual purchase process?
Server side should check if non consumable purchase was made before or not.
In case if you try to buy second time your should get message like this:
"You have already purchased this. Do you want to
purchase this again for free?"
It works for non consumable purchases. Check inside itunesconnect if your app really non consumable, probably you made it consumable by mistake.
Also FYI info from apple communities:
https://discussions.apple.com/thread/5574903
I am having a programmer code my iOS app, which he has done great. However, due to a new competitor we have decided to change from our current revenue model with In-App Purchases as subscription based to just having users pay a one-time fee. He tells me it'll take a lot of hours to make that change. Is it really true that there is no easy way around changing the code from having renewable purchases to simply have one-time purchases?
Well, this is a very objective question. It's impossible to tell you with any certainty without reviewing the actual code, but here are a few of the obstacles your developer may face:
The methods to buy a subscription is slightly different to buying a non-consumable product, however the app will need to continue to provide content users who are currently paying for a subscription. There is no way to change a subscription to a non-consumable product in iTunes Connect, and you may need to, or should ask and remind the user to cancel their subscription to prevent further renewals (you can't do this yourself or in the app, you can only link to the subscriptions page in their iTunes settings).
The app will need to check for either the subscription product (active or expired) or the non-consumable product has been purchased in order to provide the content. Support for this will need to be on the start of the app, purchase of a product and on the restore in-app purchases function.
There may be further complexities too, particularly if your app uses a backend API that syncs purchase information with a user account.
In conclusion, it's non-trivial, if your developer says it will take a lot of hours, I would be inclined to believe him.
On 6/16 in Firebase I see some in app purchases from 1 user in my Vampires iOS app. 2 for $19.99 each and 1 for $9.99. I don't see that in App Annie/iTunes connect.
For a different app, Pirates iOS, I see on 6/15 2 in-app purchase at a price of 3.30 each. In App Annie stats I see revenue of $4.15, but for for 6/16.
Looks like dates of in-app purchases are messed up/not reporting?
I also checked iTunes connect and AppAnnie reports for 6/17 and see no revenue for that day.
Has anyone else experienced this?
Also posted at the Google Group for Firebase first 2 days ago with no responses: https://groups.google.com/d/topic/firebase-talk/f0W8Gu0WlIQ/discussion
In-app purchases are not currently being validated by Firebase on iOS, and so it might be that these purchases are the result of piracy. In that case, Firebase would report these purchases and iTunes (and, subsequently AppAnnie) would not. This should addressed in an upcoming release of the SDK.
Firebase 3.5.1 should solve this.
https://firebase.google.com/support/release-notes/ios
"FEATURE Added a feature to validate the authenticity of in-app
purchase events before they are reported by Firebase Analytics."
I have the same issue.. high volume of purchase in Firebase and many (many) less in ITC / App Annie... and by the way, I don't think that it's a problem related to piracy..
EDIT: I think that probably Firebase track the trigger of the button i.e. when updatedtransactions is fired, and not when the purchase is actually confirmed. So for example an User click the IAP button in the app and then cancel the operation. Maybe this activity is tracked by Firebase even if the purchase isn't happened.
Just my 2 cents.. I'll make some test and I will report here..
I have a magazine app, and I want to provide users a one year auto-renewable subscription, and for non-subscribed users, they can use non-consumable IAPs to pay for each issue and then download it. What is the best way to implement it?
For auto-renewable subscription I don't think it's a problem. I can follow the tutorial at http://www.viggiosoft.com/blog/blog/2011/10/29/at-newsstand-and-subscriptions/ to finish this part. But for the non-consumable IAP part, I'm not sure. Do I need to add all the non-consumable IAPs for future issues before I submit the app? If I do this, how could Apple review my IAPs, because the future issues are not prepared at the reviewing time. Or, can I add non-consumable IAPs after my app is published to the App store? For example, every time when a new issue is ready in our server, we add a new non-soncumable IAP in iTC, and also set the product id to the issue in the server. When the non-subscribed user click that issue, the purchase for the specified product id will start. Is it possible?
After some research I found that the best way to implement it is to set up a new non-consumable IAP at each time when you want to publish a new issue.
The only problem is that, each IAP needs to be submitted for review, and before it is approved, the users who try to buy the issue will get an error message: "Cannot connect to the iTunes store". I haven't figured out how to know that the IAP is in review, so I can popup a nicer message like "Issue is review, please wait" other than a confusing error message.
I have a magazine app, and I want to provide users a one year
auto-renewable subscription, and for non-subscribed users, they can
use non-consumable IAPs to pay for each issue and then download it.
What is the best way to implement it?
You should accept your solution, but here is another case, maybe it helps you or others:
The subscribers can have they magazines, which are not in at iTunes Server, but at your hosting. Those magazines not need to bypass the apple review.
It depends whether you want a user to be able to permanently have a record stored in their app receipt of the issues they have bought. You might want this, if you want a user to be able to delete the app, with all associated content, then later re-install the app, and be able to download the specific back issues they purchased previously—all without having any user account on your own server. The use of a non-consumable in-app purchase also enables you to give them access to these issues across multiple devices that are signed in to that Apple ID, again without having to run your own user account-server combination to track purchased issues.
If these features don't matter to you, then there is a solution you could consider that is much simpler where you don't have to keep creating new in-app purchase products. Have a consumable in-app purchase product that is called something like Purchase One Issue. When a person buys this product, they get one credit and they can use this to select the issue they wish to be given access to. Your app then gives them access to that issue. You could also of course reverse this process in the UX: they pick the issue, click buy, you send them into the purchase process for the Purchase One Issue product, and you automatically give them access to the selected issue since they already selected it.
Note: consumable in-app purchases are not stored in the app receipt, so a user couldn't use this approach to 'restore previous purchases'. In scenarios where this is acceptable however, this is a much less labour intensive approach once set up.