My newsstand app only offers one subscription and it is free. I know newsstand apps will be rejected if they do not use iTunes Connect subscriptions.
Will apple care that I never validate the receipt. The only thing I use the receipt for is to determine if they have subscribed or not and if they have then I register for push notifications.
Also, it doesn't seem like the concept of an "issue" as in the issue information that is posted to iTunes Connect is strictly necessary....
#Revanth I think 1 issue is necessary in 3 months, i.e ,4 issues in a year. but as you saying issue is not mandatory can you please provide any link in favour of your answer related to that issue part, i am also looking for this answer. Thanks
Receipt validation is not mandatory for a Newsstand app approval.
The issues part is also not mandatory unless you provide the default cover art for your app.
Related
I'm implementing IAP for SaaS application. I nearly finished with Store Kit's integration, receipt validation and other development related stuff. But I still have 2 more questions regarding Apple's guidelines which I couldn't find answer to on the docs.
The first question: I read on few places on the web that my app should provide minimum functionality even if the user is not subscribed. I offer a SaaS app and I don't want the user to be able to use the app if he's not subscribed. I will allow him to purchase a subscription if he is not subscribed. Is it enough for minimum functionality? (I suspect that these minimum functionality restrictions are old and obsolete, as they sound absurd).
The second question: I want to offer the user a possibility to try the app for free without subscribing at all (Without Store Kit's Free Trial option), because I don't want make the user make a commitment to pay before he tried the app (Apple also doesn't provide a convenient way to cancel the subscription, which may cause abandon-users to be charged even if they don't use the app, which will cause bad reviews etc). So the question is, can I do this without risking my app to get rejected? Does apple allow such kind of Free Trial feature which is managed solely by my server?
Forgive me if this info is somewhere on Apple's docs, but I couldn't find anything related. Thanks!
Okay after sending a query to Apple (Which didn't help me much to understand) and submitting an app to the App Store, I may have an answer:
Apple do allow SaaS apps and did approved my SaaS app. I honestly don't know if they checked my app enough to tell if it is okay but it was approved.
My app implements the Free Trial mechanism without App Store's free trial option. It is clearly written on the registration view controller that the app offers 3 month of free usage without obligation, and then continues without popping and App Store free trial page or something. My app was approved so I guess it is actually okay and within Apple's guidelines.
Hope it'll somehow help someone.
We have a successful app on the iOS app store with in-app purchases. Every time a purchase is completed we send the receipt to our server, our server than checks the receipt with Apple's servers and logs apple's response(including whether the purchase was valid and that they come from our app in that same time and date).
We have quite a few users who use iap cracks that send us receipts that apple says are invalid. However we started now to see cheaters that have receipts that apple replies that are VALID. What is strange in these cheats, that when such a cheater user purchases in our app, he usually purchases all of the purchases with the exact same receipt.
Have you heard of such a way to 'fool' apple receipt validation?(to generate receipts that apple will say they are from our app in the time of the 'purchase')
Is there something we can do to find those cheaters in their 1st purchase (for the next purchases we can simply check times of the next receipts or make sure that our receipts are unique)
Thanks!
Is there something we can do to find those cheaters in their 1st purchase
Actually, if this is the same hack I've seen discussed as a proof of concept recently, the first purchase is legitimate. The "innovation" is in decoding that legitimate receipt and rejigging its IAP ID with a different one while the receipt overall still appears valid. So simply avoiding the duplicates is enough. Didn't think that one was anywhere near production-ready though, so this might be something different.
We also faced similar issue while developing a game of iOS app store where business model was based on In App Purchase only.
Initially we used to check with Apple Servers for the receipts directly from the device. But some hacker has created a hack for the users where they can install the DNS server certificate on their device which spoofs the response from Apple.
The way to do this is let web server check for the receipts from Apple directly with some kind of hashing or md5 check to make sure the response if from Apple.
here is a link which have a detailed information on this https://www.objc.io/issues/17-security/receipt-validation/
Hope this helps.
We are using Amazon FPS payment gateway for purchasing goods through IOS app, now we need to upload it to apple review team and as this is production app, it is pointed to production/live Amazon FPS account so here I want to understand if apple really want to buy anything then they need some credentials by which they can test the purchases.
So first thing really apple tests the whole purchase flow? If yes then what credentials should I provide? or should I update the server for sandbox mode till apple approves the app?
You should submit your app and select "Hold for developer release".
Then you can provide Apple with credentials on your sandbox server to test with.
When Apple approved your app, you can switch your server to production, then release your app.
But, I have a feeling they are not going to approve your app because it provides a mechanism for folks to buy things that does not give Apple a cut of the action. This is not unlike the issue with magazines and newspapers (or anyone) selling subscriptions via non-Apple Store mechanisms: Apple doesn't like when they get cut out.
Apple would prefer you use In-App Purchase, so they get a cut.
Good luck!
EDIT:
Indeed, there is a distinction to be made for real versus virtual goods, which I guess I missed when I read your post. Sorry.
To your actual question: Will Apple test it? No one knows. :-) You should assume they will, and provide some test credentials for them to use.
I can tell you from experience with a (free) commercial app I built, before we launched the service, we had the app submitted, and Apple did register on our backend and test out the app.
We released a charitable "micro-giving" app on iOS that uses Amazon payments to externally process the donations. We submitted the app with our production payment system.
According to our server logs, during their review Apple never submitted a payment or even initiated one.
It took a couple of submissions to get approved, but their feedback largely was focused on making sure we were complying with Apple's guidelines (donations must be processed external to the app, i.e. via safari), and making it clear to the user what the exact donation process was.
I think it's unlikely that Apple would spend money to test your app, nor would they wait to see if you actually delivered the goods as promised either. However, I do think that they will make it clear to you in their feedback if they want to test without spending real money.
I'm developing an app that uses newsstand for subscription purchase. Is it an Apple approval requirement that the IAP uses server receipt verification?
It is possible to implement IAP in apps without using a server to verify receipts. I'm just wondering whether it's possible to take this approach with newsstand apps (I understand that doing so loses some level of security, but it also reduces complexity).
The simple answer is that it's not an approval requirement, but as MSK says. it is recommended. I decided to go with server verification which is not too much trouble anyway. However, if you're interested, here's an example of verification being done from the app itself.
http://www.viggiosoft.com/blog/blog/2011/10/29/at-newsstand-and-subscriptions
The app I'm working on was recently rejected by Apple for containing an auto-renewable subscription. They recommended that we switch to non-renewing subscriptions for our content.
The one thing I can't quite wrap my brain round is how to restore a purchased subscription to a shared device. Apple recommends we don't use user login - something we would like to avoid ourselves. I did come across one solution where unique codes were used between the two devices - to validate a purchased subscription, through a server. But I believe that could be easily pirated, as in theory friends or employees within a company could share these unique codes with one another and avoid paying the subscription charge.
I can't really find much on Google about this, and was curious to know if anyone has been able to successfully implement a non-renewing subscription?
To paraphrase the advice we received from Apple when dealing with these issues:
Per the iTunes Connect Developer Guide:
...subscriptions must be provided on all devices associated with a
user. In App Purchase expects subscriptions to be delivered through an
external server that you will provide. You must provide infrastructure
to deliver subscriptions to multiple devices.
Apple consider user registration to be appropriate but won't allow you to make it obligatory. So registration must be optional and the user must be able to register at any time — including to allow them to share a subscription they've already bought between devices.
So it sounds like we may have received slightly different advice. Is it possible that Apple only told you not to require user login in general, separately from the requirement for distributing the subscription to all devices?