I am trying to find the dates when apple will no longer accept the old style IAP receipt validation previous to iOS7 ? I looked at the apple doc's but I could not find it.
Thanks in advance
Do you mean "when will the transactionReceipt property disappear from SKPaymentTransaction"? That's happened in the Swift SDK.
Or do you mean "when will iOS 6 style receipts stop being accepted by Apple's web services?" That is unlikely to ever happen without a compelling reason to disrupt functioning code and purchase histories, so I wouldn't be overly concerned about that possibility. But Validating Receipts With the App Store would be a good place to go visit and upgrade to current best practices. Just in case.
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.
I am working on a mobile iOS app that is customized to each client, with their own app icon, startup screen, and a few other changes. Each is then submitted to the app store as an individual app.
This is working just fine so far, but what will happen if there's 1000 clients instead of around a dozen? Does Apple have any rules on quantity, submission rate or uniqueness? Any reviewer would clearly see that the apps are basically the same outside of the branding.
Don't do it. You will get kicked out of the appstore.
Read 2.20 of Apple iOS Guidelines which says that developers that spam appstore with similar apps will be kicked out completely!
Notably developers like AppGratis got kicked for this and many others reasons.
Sorry can't disclose, if you have a developers account though you can check the requirements
from https://developer.apple.com/appstore/resources/approval/guidelines.html
I know this is an old thread but somehow it popped up and the answer selected is not entirely correct. The requester needs the custom B2B program here:
https://developer.apple.com/programs/volume/b2b/
That is specifically made for the purpose she/he asked about: to distribute customized apps to a business without cluttering the app store. There is no cost but your customers will need to join the Apple Volume Purchase Program for Business though that doesn't cost them anything.
The reason I say the accepted answer is partially correct is because obviously one should not spam up the app store with similar apps intended for one business, which is entirely correct. But that does not answer the underlying why they wanted to do this and how they could achieve the result they need which is to use the B2B program.
I've read Apple's documentaion a few times now and I didn't really get much smarter from it. So I hope somebody here knows how to deal with receipt validation:
I know there was a problem pre iOS 6. But is Receipt Validation needed nowadays on iOS 7? Does it really add extra security? It seems like it can cause problems if Apple changes the format of their receipts (parsing them on device).
In what I've seen, iOS7 doesn't change the need for whether or not you should do receipt validation, just how receipt validation is possible. iOS7 has enabled receipt validation on the device (e.g., see link from https://stackoverflow.com/users/1226963/rmaddy above, and see A complete solution to LOCALLY validate an in-app receipts and bundle receipts on iOS 7).
Does on-device receipt validation add extra security? It seems to me that it does. It gives you one more tool with which to secure your purchases. In my app (yet to be released), I want to support iOS6 and iOS7 so I decided to have a back-end server to do receipt validation for the iOS6 case. And since I have that server in place, for iOS7 receipts, I do on-device validation first and if that succeeds, I do server validation as a second check.
Whether or not you do receipt validation (in iOS5, iOS6, iOS7 etc) really depends on how much your security means to you. If you don't have much in the way of security needs, then why spend much time on security. If you do, then do more.
What if Apple changes the format of the receipts? Well, of course, this can and likely will happen. Given that the iOS6 to iOS7 change restructured receipts and in-app purchases considerably, it seems we should expect iOS8 to do so again. That's the future. Deal with what we have now.
Receipt validation is not required, but needed in these cases:
In case of auto-renewable subscriptions when a purchase has just been made – to get an expiration date.
When restoring in-app purchases. If user has reinstalled the app or launched it from a new device, you must provide a mechanism to restore his purchases and give access to features he already paid for.
A couple of years ago, when jailbreak was commonly used, developers used to validate receipts to verify that payment wasn’t hacked – I believe those days are gone now, and it’s not so necessary anymore.
Here is a complete FAQ about App Store receipt validation from our blog:
https://blog.apphud.com/receipt-validation/
Back last year, that russian hacker created a way to validate in-app purchases without payment and this guy created a class to verify each purchase.
As far as I know, this technique exposed by the hacker does not work on iOS 6 anymore, but I am not sure about that.
I am creating a new app for iOS 6 and trying to minimize the code to a minimum and even better than that, my in-apps involved hosted content with Apple, so I wonder if this added validation is really necessary for my case.
Remember that
I am developing for iOS 6 and up;
my in-apps have hosted content with apple, so even if the hacking technique works the person will never get the content hosted with apple.
any thoughts?
thanks.
The vulnerability should be addressed in iOS6, but that does not mean you should deviate from Receipt Validation best practices in general. See Verifying Store Receipts and
In-App Purchase Receipt Validation on iOS for more information.
As mentioned in the links above, Apple recommend you follow their best practices for receipt validation, be it on iOS 5 or iOS 6. "Simplicity of code" is not a good enough excuse to deviate from these guidelines. If you structure your code into well defined classes, you can abstract away all the receipt validation logic to its own class, making the code that uses it a lot cleaner anyway.
If you connect to the App Store directly from the App for validation, the measures they explicitly state (see "My app performs validation by connecting to the App Store server directly. How am I affected?") should help. If you implement them in an abstracted way (in a category or class), then it should still keep your code clean.
Even if your content is hosted by Apple, you're still giving yourself an extra safeguard against fraud. Apple are not perfect; they could slip up themselves leaving your app open.
Ultimately, when you're dealing with your own revenue, you better play it safe than be sorry afterwards.
So I know that there are no promo codes for in-app-purchases in iOS. What I am wondering, is will Apple reject this mechanism:
Provide two in-app purchases, one at full price, say $9.99 and one at discount price say $7.99 (for the same thing)
When you click on the $7.99 one, you are first asked to input a coupon code to be allowed to use the discount price. This discount code would have been found elsewhere - bloggers giving it away, coupon sites, etc.
Thoughts?
I believe your proposed method would work because a) you are not linking to an outside site to purchase the product (i.e., you are still using the App Store iAP method) and b) there are other programs that use similar features (e.g., entering in your OpenFeint username to enable that service).
Good luck!
I really think only Apple can tell but it is a good chance that it is okay.
I sometimes just went ahead and called them and often I was lucky and had a real competent guy on the phone telling me answers to stuff like that right away sometimes I had someone more cautious but pointing me into the right direction within the legal contracts. And whatever they said at the end the very much shielded app approval team (no phone numbers, no e-mail addresses) will decide. The worst that can happen is that you have to resubmit your app without it. Costs you time but no more.
I always used this link for phone numbers I think they still work.
I had same problem... so I called to the apple developer IAP helpdesk and they redirect me to email the App Store Review section.
Next day they wrote me:
We understand that you would like clarification about a business model you are developing for your app.
We are unable to provide pre-approval or guidance on app ideas or concepts. After you have submitted your app, we will provide feedback during the review process, if applicable.
So I wish you luck... There is no one clear option 😔