I have an iPhone application in the App Store. I submitted 1.1 to the app store a few days ago, and selected to "Hold for Developer Release." I found out that there is a very serious bug in the approved version. I need to pull this binary.
From what I can tell, Apple doesn't support this. I have sent them an email, but there's another bug in the current version that needs to be fixed also, so time is of the essence.
I've heard that you can release the update in some random country (where I would have no sales) and then release the next (fixed) update in all countries. If I only release 1.1 in, say, Luxembourg, is the old version (1.0) pulled from the other stores? Are the chart ratings reset? I'm relatively high in the charts, and I don't want to lose the momentum the app currently has.
Until Apple supports rejecting approved binaries, I'm looking for the quickest alternative.
Craig. Let me answer some of your questions. First, if you release an update, regardless of what country it is released in, it will replace the old binary for every country. Thus, if you only select Luxembourg, you are not only releasing the update to all countries, but also removing the app entirely from every app store except Luxembourg.
Second, it would appear that even Apple has no say over the iTunes Connect website in terms of altering the process for one person. I believe you should be able to reject an approved update, I don't see why they would want to disallow this. However, since they do not right now, it's best to forget about it.
You basically have 2 options. One, you can release this new version to the world, which keeps your standing in the App Store and warn users of the bug and promise them a fix. At that point, you can appeal to the Review Board for an expidited review, which they may not give you. Remember, if you release the update, I would upload another update immediately after.
You're not going to avoid your problem but there are things you can do to minimize the impact of your mistake.
Second, you can remove the App from Sale, accept the new update, and upload a new one for review, and put the app back up for sale again once approved. The problem here is that you will most likely lose your store ranking and the app will be unavailable for about a week. Not what I would do. I would go with the first solution.
From my experience, customers are ok if you need to issue a fix and they're fairly understanding. Make sure you tell them exactly what's going on in the app description AND the "What's New" section. Make sure they see it. They'll be ok with a few days of inconvenience in return for your honesty and reassurance that the issue has been fixed in a near-future update.
Hope this helps.
Cheers!
You can reject an app that is on "Hold for developer release". You need to click "Binary Details", and there you should find the reject button.
Related
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/
If I push an app update to the app store, but choose "I will release new version" when submitting. If my update is rejected for some reason, is the current version already approved going to be taken out of the store?
Anyone had experience with this?
I've got no experience with this exact situation, but I have submitted updates and then invalidated them myself. The original is unaffected until the new version is approved - if it gets rejected, they would just expect you to send a corrected version instead.
The only reason I could see Apple pulling the original would be if they discovered something pretty nasty in the update and decided to check the original as well in case they'd missed it, but that is total speculation.
I have one app where an update was rejected over a year ago. I haven't resubmitted the update yet and the original is still selling in the app store.
I was hoping someone can answer a simple question for me...
If you create an iphone app and get it approved for sale, what happens if you add updates to it? Do you have to submit this for approval too?
How does the whole process of updating existing apps work?
Assistance would be very much appreciated, thanks
Yes, every update requires a new round of approval. Once your first app is live, the management page for your app offers an "Add Version" button, which takes you through a similar process to the original app, but with options to document changes.
You do indeed need to have updates approved. So once your initial application is created in iTunes Connect, uploaded and approved by apple and available through the store, you can easily submit new versions.
You log into iTunes Connect and click Manage my Applications.
Select the application and click the Add Version button.
Fill out details of the update (such as the new version number, what's changed, any new screenshots, etc).
Upload your new binary via the application loader.
Wait for review.
The process of update is almost exactly like the process of creating and pushing out the first release. It's really quite simple, tbh.
The update process is nearly identical to the original submission, except that you don't have to reenter all the metadata (but you can modify almost all of it, except for the app ID, during update submission).
Update review times have historically varied by large amounts, either slower or faster than the original app's approval time, on the order of 1 day to 1 month. Don't count on it being any less.
I've submitted my application to the app store and had it approved. I'd set the release date to a few months in the future, but in the meantime have added a lot of extra functionality to the product.
I still want my app to be listed as a 'new release' when it comes out (the release data hasn't been reached yet) so should I replace the binary, or do I have to remove the old app completely and start a new app?
Obviously, the previously approved app hasn't been released so I don't want the new code to be counted as an update.
Cheers,
Bryn
I asked the question here mainly because there is much more active iPhone community here, coupled with the huge amount of questions regarding iStore submission/code signing etc.
For anyone still wanting an answer to this:
If the application has not ever been released, reject the binary and create a new application altogether. If you want to keep the same name as the app you'll have problems since Apple won't allow you to completely remove the old application and you can't have two with the same name. In this case, email them directly explaining the situation and they should rename the old application to an arbitrary name, freeing up the name for the new app
Has anyone had apple send back the app with a name change requirement? We submitted our app in Nov. and have been going back and forth with them, we corrected the items they asked us to fix which were both interface and memory driven, and they said nothing about the name. They have been testing our API a TON so we know they are doing something on it, but today we saw a app with our same name come out. The developer had it released from Apple back in Dec. and just didn't turn it on till now. Why would Apple not tell us to change that by now, has anyone else had issues with their names, and how do we submit a new name mid process. Our apps are totally different, so that isn't the problem.
When it comes to copyright infringement apple has immediately put us in touch with creators of other apps that use our name. They don't want to get involved in a legal battles, but they do facilitate the connection between all parties. You may consider changing your name to avoid any further delays, as apple can simply wait on an app that they think could become a copyright issue.