Is it anyone else's experience that lately (Nov. 2011) the production URL for validating In App Purchase receipts now works to validate sandbox-generated receipts?
If this can be relied upon its a huge boon for me. It means that the build I submit to Apple can be exactly the same as the build I test with (except for final code signing.)
I'm referring to https://buy.itunes.apple.com/verifyReceipt and https://sandbox.itunes.apple.com/verifyReceipt.
This is no longer working as of 7/26/2012 (just found this post here, trying to figure out when it originally changed). You'll need to go back to the prod -> sandbox failover code, detailed in this tech note - http://developer.apple.com/library/ios/#technotes/tn2259/_index.html
I'm guessing this is because of all the hacking of IAPs going on, and Apple now closing possible loopholes.
If you want identical development and life behaviour (plus identical behaviour while your app is being reviewed): Verify the purchase first with the life server, and if it fails with the sandbox server.
I noticed this too, and it is May 2012 so I guess this has been working for awhile.
Related
I noticed today when using SwiftyStoreKit to validate auto-renewing subscription receipts, that when I test in the sandbox the validation works as expected, however if I download my app from the store - it's fully unlocked, which per my code could only happen if SwiftyStoreKit.verifyReceipt returns an error (if someone has a poor network connection etc, I don't want to lock their content).
Coincidentally on January 18th, there were changes to the App Store receipt signing certificate. Even though this response to the issue on SwiftyStoreKit's Github Issue says it shouldn't change anything, it seems very coincidental that I am seeing this issue just a few days after the change? Since it works fine in the sandbox, the problem only seems to be with case production = "https://buy.itunes.apple.com/verifyReceipt but of course since its only in production, it makes it very difficult to test.
Any thoughts on what may be causing or how to fix?
I have what I believe to be a pretty unique situation and I can't seem to find a solution online. The problem timeline:
4 years ago I paid a developer to build/upload an app to the iOS App Store for me under my own developer account.
Over the years it became outdated and this April it was kicked out of the App Store
I took some online courses this year and rebuilt the app from the ground up.
I would like to post my rebuilt version to the App Store - completely fresh like it's a brand new app (because it basically is)
A couple more things to consider...
I used Swift vs the original Objective-C that the developer used.
I used UserDefaults instead of what appears to be iCloud. (the dev account seems to be littered with permissions for things I don't intend to use - so advice on how to get rid of all of the weird stuff I don't use would be helpful, too)
I also have a different but similar bundle identifier (it replaces "RandomRuby" with "Random-Ruby") that Apple's App ID registration system seems to not like.
The level content and game play are the same - but I have no idea how to figure out what level the previous users were on. (which I'm ok with if it's ethical to make people start over).
It had In-App purchases (they could purchase consumable "Rubies" to use for hints and there was an "Ad Free" upgrade option. The new app doesn't use ads - it just has consumable "Rubies" for monetization). I have no plan to add ads back in - so I imagine a complete reset would be ok here, too? Again - is that ethical?
With all of this context - my question is...
How do I upload a completely-rebuilt-from-scratch app with the exact same name from the exact same company as an expired app through the iOS Developer system? Is this even possible? I'm having a hard time figuring out where to start. I can't even get past creating an App ID.
To update an existing app in your Apple Developer account you only need to use the same BUNDLE ID (e.g. com.apple.keynote) in your Xcode project and a higher version/build number. Everything else is not relevant.
Your previous iOS APP is bounded with the Apple Developer account when it was submitted. And the APP name is unique, just like anyone else may not create another app named 'Facebook'.
So, if the Apple Developer account was not yours, you are in trouble. You need to ask the previous programmer to transfer the APP to you.
If the Apple Developer account was merely expired, and you can prove that the account belongs to you, I guess you can contact Apple Support for help.
With our latest release, we converted our app from paid to in-app subscription purchase. We promised our current users that we would grandfather them into the subscription because they already paid for the app. In our code, we look for a valid receipt with an original application version prior to our first subscription version. It all worked great in our tests.
When we released the new app, we started getting feedback from our long-term users that they were being asked to subscribe (they shouldn't even see the subscribe button). As we researched the issue, we noticed that all of these users purchased our app prior to the app being transferred to a new developer in September of 2014.
Recreating this issue is difficult - how do we simulate an app install in 2014? I may be able to login as one of the affected users, which would involve using their Apple credentials. I'm not very comfortable asking users to share their credentials.
Since I haven't been able to recreate it and our code is pretty simple, my best guess as to what is happening is that we aren't receiving a valid receipt for users that purchased prior to the app transfer in 2014.
So, I have a few questions:
Has anyone else experienced this?
If so, how have you resolved it?
How would you troubleshoot it?
FYI - I've filed an issue with Apple (3045378).
In speaking with Apple Developer Technical Support, we discovered a way to pull the NSLog messages off of the devices using the recently released Unified Logging feature. A couple of our users submit their logs, which clearly showed that they were getting valid receipts, but the originally purchased versions of those receipts are 4 and 2.8.
Given that our current version is 1.7.1, these are strange and non-typical numbers. However, the Original Application Version reported from the receipt is actually the CFBundleVersion (or Build), which can be a completely different string than the App Version reported in the App Store.
I assume that the developer prior to the app transfer was using a different build numbering system than the standard ... scheme.
I refined the version check within my code and re-submitted the app. It was released today, and, so far, all are being grandfathered correctly.
I have an interesting issue with submitting an update for my iOS app. I have 2 API versions: production and staging. The TestFlight builds use the staging server, and the App Store builds use production via this check:
if ([[NSBundle mainBundle] pathForResource:#"embedded" ofType:#"mobileprovision"]) {
// TestFlight, use staging API
} else {
// App Store, use production API
}
This works great. We get to test the next version of the app with the next version of the API, while keeping the released version working with the production API.
The problem is that when we submit the app to Apple for review, their reviewers now have the new code that needs the new API, but the above check points them to the production API. This caused a crash and thus we got rejected.
I know that we should do proper API versioning so we could have the old and new API running in production at the same time, but sadly we're not at that stage yet. We mistakenly figured that the Apple reviewers would take the first code path (using the staging server), and we would manually release the app after it got approved and time that with deploying the new API to production and thus everything would work out just fine.
So, finally the question. Is there any way in code to detect if the app is run by Apple's reviewers, have it use the staging server? Or are we screwed and need to get the new API into production (and thus breaking the app that's currently in the App Store)?
I don't believe that you will find a reliable way of detecting the reviewer activity.
Is it possible to add a new "API" on your server specifically for your new app where it can post its version and get an answer back as to whether it is released or not (and therefore which server it should talk to subsequently)?
Once the app is approved then you can change the answer from this new API. You could even store a "production" answer in NSUserDefaults so that the app no longer checks each time once it "knows" it is in production - presumably you would never revert to staging.
I built a in-app payment for one of my iPhone apps. It worked in sandbox mode.
I submitted my app to the app store and it got accepted. I even submit my in app payment. It got accepted and it's status is 'ready for sale'.
However, when I go get my app in the app store, it still says it's in sandbox?
Is there something in MKStoreKit that you have to transfer environments, or does it take some time for it to change?
I currently pulled it from the store because of it. Please help! Thanks.
Hmmm. Are you using your Test User ID or a real Apple ID?
When this happens, it's usually because you previously used the same device for testing IAP in sandbox mode. To fix, just go into "Settings", then go to "Store", then log out and back in again. That should clear that up, assuming that you are actually using the archived app that you downloaded from iTunes, rather than your dev copy.
Re-released my app today so I could get it and see if the in app payment would work. Surprisingly, it worked and it wasn't in sandbox mode! So I guess it just takes time for apple's servers to make the change.
If anyone else had this problem, don't fret like I did! Just wait and be patient. Hold for developer release and wait around 24 hours and you should be good!
Here's the real solution (edit):
Set your availability date to the future so it will be removed from the app store
Set your availability date to the day it is so it will re appear