I have implemented In App purchase in one of the existing application. I have also created SandBox account for testing it. I have run the application and tested it, its working perfect. Since, I have tested it, by buying the feature, it means I have bought that feature.
Now, there is a change in code and I want to re-test it (In App purchase thing), but since the feature is already bought I cannot test it again.
I am running and testing the application from Xcode, so I tried to delete the application from device and run / test it again by from Xcode, still no result.
If you just want to test re-downloading the content, deleting the application works.
If you want to actually re-buy it, how about creating a new additional sandbox account?
Related
So I'm testing out an in-app purchase in my app. I've got the code set up properly and everything, but when I do attempt to buy or restore in the sandbox environment, I get this error:
MZCommerceInAppBuy.App BuyInfoDataAccessFailure_message
[Environment: Sandbox]
I've never seen this before, and I am finding only one Google search result from someone else who has. It never was solved. Has anybody seen this?
I figured out a solution. The problem was coming because I was adding an in-app purchase to the current live version of my app. I created a new version of my app and changed it on my target to the update version.
I also downloaded a new development provisioning profile. I'm not sure if this is necessary, but I wanted to add that I created a new one just in case.
When you add in-app purchases to an app, you must create a new app version even for testing.
Note:
Just a side note. I noticed while I received this error I also wan't receiving any in-app purchase products. You will not receive any products until you create the new version.
In Apple's "In-App Purchase Programming Guide" I read following advice when it comes to testing in-app purchase using Sandbox test.
Create a test user account in iTunes Connect.
On a development iOS device, sign out of the App Store in Settings.
Then build and run your app from Xcode.
Use your app to make an in-app purchase. When prompted to sign in to
the App Store, use your test account.
Note that the text “[Environment: Sandbox]” appears as part of the
prompt, indicating that you’re connected to the test environment. If
the text “[Environment: Sandbox]” doesn’t appear, you’re using the
production environment. Make sure you’re running a development-signed
build of your app. Production-signed builds use the production
environment.
My question is, How do I make sure that I am running a development-signed build of my app? Where exactly is that done, and what steps must I perform?
Project Setting -- >Build Settings
then search "code signing"
then you could see the options to select
As part of our software development life cycle, we want to make sure that the binary we test in house before pushing to iTunes, is the same as the binary that we push to iTunes. I know that sounds really silly, but it's a matter of checks and balances in a mid size company, so that the testers can be sure the coders didn't add in anything after testing occurred.
So is there a way to run a signed/certed app on a device that's not jail broken? Or is there a way to verify that an IPW is the exact identical code in the zip that gets pushed to iTunes?
Or possibly a way to accomplish my goals with a different way?
We have a valid developer account and around 15 different devices that are not jail broken. Would prefer to test with them left stock and not jail broken.
If you compile your app for distribution using an ad-hoc profile you can later take that archive and resign it with the appstore profile and upload it.
You can't however upload an application that was compiled with an development certificate.
A binary signed to go to the App Store cannot be run on devices via the normal ways. You can test the code by having the developers create an Ad Hoc build. This will have the same functionality as the App Store version, but you can test it.
Unfortunately, when the app is recompiled for the App Store, more code can be added.
Do you not have access to the code to test? If you must, you can have them create an adhoc in front of you, test it, and then recompile for the app store all in front of you. Seems a bit overkill, however.
There is with another trick:
first test you code for functionality's, buggs in normal way.
Than push the code to AppStore, but set the release date farther with 3 weeks, while your testers are validating it is that what they tested last time or not. Somewhere here, I have read that possibility forgot where. Never tried!
I send a new version of my iPad app to AppStore. The Apple will now validate it.
But, I want to have absolute certainty that NOTHING gone wrong. I have the Archived file and want to run it.
Ok, I can build a new program and run it in the device. But I want to test the exact file that I sent.
I tried to create a .ipa file but it give-me problem with "code signed". Run the file in simulator is a good idea. So, there are a easy way to run my new version?
You cannot install on our own device an app you build and is signed with your distribution certificate. Put another way, the build you submit to Apple cannot be directly installed by you on your device.
If you build any other way such that you can install that build on your device, it's the same code as you would otherwise be sending to Apple in a distribution build.
I have had the same desire, actually. I have an app with a conditional build setting based on whether it's a distribution build or not. For a distribution build, we have a production API URL, but for all other builds the URL is a development sandbox URL. So, I know how you feel! I wanted to be able to test the actual build sent to Apple to make sure it was hitting the correct production URL. I couldn't. I had to trust. :-)
I'll assume you're using Xcode 4; details will be different if you're using Xcode 3.
Once you've created an application archive, you can select the archive in the Organizer and click the Share... button to e-mail it to yourself and/or your testers. Xcode will let you sign it with your developer key, so you can install it on your device. When you're satisfied with the app, you can then validate and submit the app to the app store, again from the Organizer window. You'll re-sign the app with your distribution key and the application will be uploaded to iTunesConnect.
Just make sure your project and your target Build settings are absolutely 100% identical between your final Release build and your Distribution build, except for code-signing. Then do a clean build of both, one after the other, and QA the final Release build before submitting the Distribution archive.
After Apple approves the app, delete the app from one of your devices, and buy your app from the App store. That's the only way to get an exact customer download with the full customer experience. You'll get back 70% of the purchase price in a couple months; the other 30% is likely a very small part of your total development and testing cost.
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.