I have to implement In App Purchase Auto-Renewal Model in my app. I have created a test user and getting the response from App Store for subscription. When I tap "Confirm" then sometimes its state becomes SKPaymentTransactionStatePurchased and sometimes it becomes SKPaymentTransactionStateRestored. My problem is that I want to prevent user to use the app if he has not subscribed the app. For that I am trying to track the state of "SKPaymentTransaction" so that I can allow or disallow the user to use the app. Such that, if the state is SKPaymentTransactionStatePurchased, only then he could be able to use the app, but I don't understand how its state changes.
One more thing, When I tap on the "Settings" to manage my Auto-Renewal, it shows me that my app will be expired on the current date i.e., today itself, but when I tapped on the "Confirm" button to subscribe my app for one month then expiry date should be after one month. I don't understand how this whole process is working.
I have read whole documentation of Auto Renewal, but didn't get any help from that.
Please help!
Not sure about your first problem. In my case, I can never get SKPaymentTransactionStateRestored called at all. I am debugging why.
Meanwhile, I was facing the second problem you described. When I decoded the receipt, it looks like they keep the subscription valid for 5 mins. Sounds like a feature for testing in sandbox. At least that's what I am assuming.
Related
I have a problem with implementing multiple accounts in flutter app.
When the app is first opened, multiple network calls are made to get account related data. Those calls are usually made in initState of each widget using BLoC pattern. After await-ing on those data, UI or some other parts of app is updated.
The problem is, when user tries to switch to another account, app navigates user to the root page, so all the loading of required data for this account would happen again. But since some calls from previous account might still be ongoing and finish only after user switches to another account, I get multiple issues in application, like rendering UI with data that belongs to previous account.
I know I can dispose all those streams, so no UI is updated incorrectly regardless of the response. But, I was wondering if there is a way to kill all the ongoing requests, since app doesn't care about the response after the account is changed. In other words, I need the effect of restarting the app, but without actually restarting it. Is there any way to achieve that?
I have an app where I’m offering Auto Renewal Subscriptions. Here is how it currently works, when the user subscribes, it saves a Bool in UserDefaults as true, after that I can make a receipt request to see if the subscription has expired. My issue or what I don’t fully understand is the logic on how often to make that request, checking for authenticity every time the user launches the app seems like a lot, or do I need to save the expiration date in UserDefaults and just check a couple of days after the expiration date to see if the user renewed? This way we limit the requests we make to retrieve the Apple receipt.
Can someone share the logic used when checking for authenticity in an app using Auto Renewal Subscriptions?
The "right" way to do it is to manage everything server side (with some caching on the device in case the user is offline). Refreshing the receipt on the device is insecure, slow, and could make that annoying "Login with iTunes" prompt keep popping up for the user :)
It also prevents you from ever having complete analytics of your subscriber base since you can only get data points when they are active in the app.
What you would do is store the receipt file in a database after purchase, and refresh it there to keep the subscription status up-to-date. Then your app is asking your database if the user is subscribed (and caching the value in UserDefaults).
Here is a good blog post that outlines what the setup should look like: iOS Subscriptions are Hard
I am new to Facebook development and I am wondering how I can delay execution of an app notification by a given amount of time (days)?
At https://developers.facebook.com/docs/games/notifications or via Google I can't find anything regarding delaying notifications, everything seems to happen immediately.
What I am trying to achieve is that when a facebook app is loaded, I will add a notification to be executed in x days so that the user is reminded of returning to the app then.
I will do this every time the app loads, overwriting the existing notification that was still to be executed.
By that, the user will get the notification only when he really is not logged in for x days.
I'd like to solve that through Facebook alone and not through timers on the server. Can it be done?
There is no way to send delayed notifications, you need to do that on your own. For example, with a Cron Job that checks for the timestamp of the last login every day. Creating a new delayed notification (and deleting the old one) whenever the user logs in would be a weird solution anyway...Those things are usually done with Cron Jobs, there is no need to use the Facebook API when you don´t need it.
My iPhone app includes a subscription service for a web server, which Apple insists that I make available as an in-app purchase. However I not entirely happy about the way the user dialog pans out. Some time after the app submits the purchase to iTunes, the user gets a confirmation request from iTunes. But this could happen at any time after the purchase is submitted.
I am wondering whether my app should pop up an alert, after the submission is made. Is there a standard procedure for this? If the confirmation request comes back straight away, then the user would see two alerts one after the other, which could be confusing. On the other hand, if he is going to have to wait a while, it would be nice to let him know that this is the case.
Is there a standard procedure for this?
I think standard procedure would be to disable user interaction and show a spinner, or otherwise let the user know that the transaction is pending. You can then handle the purchase if it comes back, or implement a timeout and then show a pop-up notifying the user that the transaction could not be completed.
If you really don't want to make the user wait for completion before continuing in the app, I would put your notifying pop-up before you send the request. So when the user presses the button, you pop-up and say "This may take a while", and when they press "OK", THEN you send the request. Personally I don't think this is particularly good UX though, since in the majority of cases it will not take very long.
We are developing an app that uses the non-renewing subscription IAP model. While testing the subscription purchase process in the sandbox, we are seeing two messages with ‘buy’ buttons pop up.
The first message is displayed with the product information: “Do you want to buy one subscription for $xx.xx?”
After you click ‘buy’ for the first message, a second message (with another buy button) is displayed: “You’ve already purchased this subscription. Tap Buy to renew or extend it.”
Is this normal iTunes/sandbox behavior for re-purchasing non-renewing subscriptions after they have expired? Does iTunes require you to tap a ‘buy’ button twice?
I checked the behavior of EverNote by extending their non-renweing-subs, and it seems that is the behavior which we can't avoid.
I encountered the same issue with Non-Renewing-Subs + MKStoreKit, and thought it has something to do with my settings first, but I don't think there is nothing we can do about it.
One thing you could try (although I'm not sure Apple will like this) is creating a bunch of identical products in the store (say 48 identical products but with different identifiers: subscription1, subscription2, ..., subscription48). Then, when you need to extend the subscription you just pick the next subscription. This way the user will not get that annoying message. With 48 different products you should be good for 4 years. Hopefully by then Apple has its sanity back :)
may be you have purchased it and it hasnt expired. or it may have been purchased in a diffferent device, but you still have old one. when its tried to purchase its found that its already bought hence asked to extend. IAP is tied to apple id.