I am in a strange situation. I have around 200 in app purchases in my application. Some I am able to test while for others i keep on getting SKErrorDomain error with error code =0. Since I am able to test few products, I guess the problem is not with the code.
I have followed the checklist for testing in app purchases- my build number and version are not blank, i have double checked the spellings of the product identifiers. I have also tried reseting the device but all in vain.All the in apps are cleared for sale.
Can anyone guess what probably could be wrong with the settings or the code? Also I would like to know if there is any upper limit to the number of in apps that can be put in an application?
PS : I am using MKStoreKit
You can create up to 10000 in-app purchases per app.
You can create up to 10,000 separate product IDs assigned to your
in-app purchases per app in iTunes Connect. This number refers to the
number of in-app purchases, not the number of purchase transactions.
and i think this answer will solve your issue
Related
I have an odd problem on my hands with in-app purchases and any insight or help would be appreciated. I have in-app purchases setup for my app and have been using them regularly during testing; however, every once in a while the SKProductRequest will return with 0 products and won't load any products until I completely remove the app from the device and re-install it. Then everything shows up again and purchases can be made.
I'm not sure what is causing this problem. It may have something to do with the test environment for in-app purchases? I know everything is configured correctly seeing as I can normally use the in-app purchases without any errors. Thanks for any help.
There may be several causes to Product Requests failing on a device. Basically, the StoreKit environment is very picky: if something in the app seems weird (like the code signature, or the embedded Provisioning Profile, or multiple app with the same profiles), it will not sent the request, or receive invalid data.
A common cause of silent failures is having multiple Provisioning Profiles installed for the same app. You can try to:
Uninstall all Provisioning Profiles from your device (in Settings),
Remove the app from the Device (to remove the embedded Provisioning Profile),
Re-install the app.
I wrote a small blog post about this issue a few months ago, you may find more detailed informations there : http://kemenaran.winosx.com/?2011/12/02/180-ios-developer-what-to-do-if-in-app-purchases-stop-working
This is a conceptual workflow problem. I'm converting an app with an existing user base from Paid to Free with an in-app purchase (FWIAP) to remove ads. The problem I'm trying to avoid is having the existing paid customers updating the app and now suddenly seeing ads and being insulted/assaulted with the "option" to pay again to remove the ads they never bought in the first place.
Luckily, I do have some breadcrumbs in the form of persistent data (pData) that will indicate whether the app was already installed. So my thought is to have the new version check for existing installs before deciding whether to proceed with displaying the ads.
One problem I foresee is later updates then considering all those first-generation users as now eligible for ads again, so I'd have to then add another persistent flag (pFlag) to identify the two groups of users and then hope to remember for even later updates (i.e. third-gen., etc.) to check against the pFlag instead of the pData, as the pData values would have long changed by then.
Does this seem like a sound approach or is there another good known solution to this?
The problem with breadcrumb schemes is with users who upgrade, or have to get a replacement device, and don't have backups to restore from. When they re-download your app, there will be no breadcrumb.
I don't think you'll ever be able to support cases where someone has bought the paid version and installs it directly from the app store on a new device or a device where the app has been deleted.
We recently had this problem in the opposite direction. We have a FWIAP app that customers wanted to be able to purchase through the volume purchase program, which doesn't apply to IAP. So we built a paid version and sell it as a separate app, and it generates as many sales as the FWIAP version, basically doubling revenues (so far).
I think the simplest approach is to just release a separate app. If you convert the existing app, the biggest risk is negative reviews, which could drive down your star ratings and thus downloads. So if you do take that route, I'd have as generous a customer support policy as possible--give anyone who claims to have purchased the paid version a code that lets them unlock the FWIAP version.
But that's likely to be a headache in the future, and from my limited experience, you may make more money by just having both versions in the store.
The paid to free-with-inapp-purchase workflow is supported; it’s referred to as paid-to-fremium and is discussed in the 2013 WWDC video:
Using Receipts to Protect Your Digital Sales https://developer.apple.com/videos/play/wwdc2013/308/
So I already have 2 versions out on appstore..
One app is a free but limited version.
The other is a paid unlimited. The basic layout..
I have had questions from companies wanting to buy the app and give to their employees. So they don't have to buy the app with their personal accounts..
So I was thinking of releasing a 3rd version that prompts the user for a license key on first start, if the key is valid the app starts and works until reinstalled or w/e. If the key is invalid the app just keeps prompting for a valid license.
Now I remembered reading somewhere that apple wouldn't allow apps that had no public function or something like that. Which this app wont have unless u have a valid license..
But since I do also provide a valid public version of the app, will this one get accepted? Or have they removed theese rules?
Any insight in the matter would be helpful!
Edit:
Forgot to mention that the reason im looking to use the license is because i have the same app for android and want the companies to be able to buy for both device types, not just apple devices.
Thanks
I believe you should use the B2B functionality in ITunes Connect: http://developer.apple.com/support/ios/volume-purchase-program.html
Also check: https://developer.apple.com/appstore/resources/volume/
I did something very similar to this some time ago, they seemed ok with it (then at least), they just asked for a license key in the complementary info (during the app submission) to go through all their usual validation tests.
Klassmating has an app in the app store that has no public functionality unless you are a student at a specific university. So it seems like you can have apps like that.
Without knowing exactly, I would assume Apple would reject such an app from the store (mainly because it would allow you to sell applications "behind their back" - i.e. sell licence keys and not using in-app purchase) :-)
However, there are two possible solutions to your problem that come to my mind:
Create and distribute gift codes (would be a problem if you had to give out too many of them).
Do an ad-hoc distribution of your app to the companies. Basically they would need your application bundle and an ad-hoc mobile provision file. Then they can simply install your application by dragging it to iTunes.
There are different official iPhone application distribution methods.
In which for your current requirement,I suppose you can use the Custom B2B Apps,where you can deliver apps directly to your business customers who have a Volume Purchase Program account.You can get more information from the link provided above.
cheers!
Yes, I too have had an app in the app store which works like this. You have to provide them with a key/licence to access the app functionality so they can test it fully.
I've had an app rejected for this very reason - required a username and password, not a licence key, but was free. They said in contravened the licence terms regarding in app purchases.
Mine allowed time limited free trials from within the app, but full functionality was restricted to purchases outside the app. Apple wanted their 30% cut of the subscription cost so it was no dice for us.
On the other hand, the app store review process is seemingly entirely random, so who knows.
Apple doesn't offer promotional codes for in-app purchases. What's the best way to let users try the features or content unlocked by in-app purchases for free, while complying with Apple's Developer Guidelines?
The idea is to allow a special set of users (reviewers, key fans, etc.) to access the content or features offered as in-app purchases without paying.
Examples of apps that worked around this limitation would be much appreciated.
You could submit a version of your application that has all features unlocked by default.
Submitted apps have a publish date that you can set when you submit (and I believe you can change this on the fly as well) you could simply prevent the app from being published in the App store but still be able to give promotional codes for it.
Promo codes apply to a specific app version, so when users redeem promo codes for a version of an app that hasn’t been released yet, they download the prerelease version.
Source
Something like shareware? An app, that has a subset of features enabled until in-app purchase? Apple allows it now.
As example. We've a puzzle game, that has 12 difficulty levels. 4 or 5 of them are available for free and others are unlocked after in-app purchase.
I'm working on this now.
What I'm doing is I generate a random code/guid and store that on my webService's DB. Then give that code to who ever you want. They enter that code and it calls the web service passing the code, and device UDID. The webService returns another code indicating if that promocode was valid. If valid then the app will add that purchase to NSUserDefaults or Core Data (however you keep track of purchases).
If you don't have a server up and running (say the content is already in the app bundle) and you don't want a server would require you making an algorithm to generate keys that your app validates. However this is far less robust. Using a web service allows you to prevent 1 working key from being distributed between all users, as you can tie 1 promo code to 1 device.
My in app purchase project working perfectly now, but I need to test purchasing and when once purchase is successfully done it cannot be undone? How can I test in app purchasing and upgrading my app to full version when it can be done just one time?
Delete the app from your device
Run "Clean" from the Product menu in XCode
On your device, go to "Settings", "Store", "Apple ID", and Sign Out
Start your app again, since you're not signed in to any account, the previous in-app purchase will not be recognized and you'll be able to buy it/download it again with the same test user account
None of the answers is really correct. Even if the you remove the cached purchase from your testing device, the product is marked as bought in Apple's server, associated to your test Apple ID. So the testing will not exactly reproduce the expected behavior. This is very important for testing the restore products function use cases, for example.
As far as I know, the real answer to this question is: You can't without creating a new test account, but that's not a really big deal, you can even use an invented email address (no need to validate it), and you can delete the account after using it.
If you delete your app and reinstall it, you can repurchase products. It follows the same code flow and nearly exactly the same user experience (there is a dialog letting you know that you can repurchase for free the second time). Also you can create more test users in iTunes Connect to be sure that you are doing completely clean testing.
I've spent several weeks deleting and reinstalling my app many times per day to ensure that my storekit implementation works just like I want it too.
All you have to do is delete your app from the device. This will wipe out any NSUserDefaults where you may have stored in-app purchase details.
Once you run your app again, make the purchase one more time, and Store Kit will tell you this:
"You've already purchased this. Tap OK to download it again for free"
Once you tap OK, you go through the same sequence of events you did when you made your first in-app purchase, so you can test again and again.
Use unit tests on your app, with false data, until you're satisfied.
(create test code - for each module you use)
I think I'll need more description of your process to have a better answer.