I submitted the first version of my new app to Apple, it got approved but the release date is currently set to December 2014, because there's some work on the backend to do. I don't know how long it will take to get the work finished, so I'm thinking about submitted an update to the iOS app because I found some little bugs.
If the work on the backend is finished, I would like to go live ASAP. Therefore I don't want to developer reject the version waiting for release; is it possible to keep it in "developer hold" and submit an update or do I first have to release v1.0?
Related
I have a mechanism reading the Appstore version and forcing the user to update the app. For doing this, I use the following URI: https://itunes.apple.com/lookup?bundleId=xxxxxx
It used to work, but with the last release of my app, I have noticed that it wasn't forcing the update anymore, despite the new version was on the store (the Update button was visible on the store page).
I decided to not update it and let the weekend pass, and today my app was already up-to-date when I opened it. I suppose my phone updated it automatically, unfortunately, so I cannot be sure that my app would have forced the user to do it, but I suppose so.
My guess is that the link I'm using in my app and whatever API iOS is using to automatically update, need time to know the latest version that is already available on the store.
Does anyone have any information about this?
I am experiencing a strange issue.
New app version was released to appstore, containing new variable stored in user defaults and some minor updates. technically, we are creating new variable, which is an array of values in user defaults, and appending some items in the array. For append, we are using values which were already in place in the previous version (e.g. user_id, device_id and one more string parameter, all 3 were received from backend on 1st registration).
It was (obviously) tested before release. Testing strategy:
A. We were building adhoc old version (say #1) and new version (say #2), installing v1 on the devices and updating it to v2 (by simply downloading new adhoc v2 and installing it on top of v1).
Then, we published v2 to appstore, and issued one more test:
B. We were building same adhoc old version (say #1) installing v1 on the devices and updating it from the appstore, by
B.1 in-app update functionality - following the link to appstore and
B.2 just downloading most recent version from appstore.
Both were fine and both are still fine. Works perfectly.
Now, users are reporting old appstore-installed v.1, updated from appstore to v.2, is crashing after update (almost immediately when it is started).
Only difference we can observe is that when tested, appstore version was installed over adhoc, and now it is appstore over appstore.
Was anybody ever facing the same issue? What is the difference in update process "adhoc -> appstore" versus "appstore -> appstore"? Could it be related to the fact that appstore update is cleaning up all the info from user defaults and thus we need to repeat the application reg process (get all the data again like in the first clean install)?
I still have no crash reports in hand, so I am asking for some advices which can help me to solve the issue faster.
Thanks everyone in advance!
...looks like the issue is linked to GoogleUtilities: we have v7.2 in our current build, however previous build was of v7.4, and - as I found out recently, there is an issue related. TWIMC see https://github.com/google/GoogleUtilities/pull/37 for details.
It is still TBC now, we'll be checking in the next 1-2 days, and I will post some updates here. If indeed related to library version, then it has nothing to do with the app distribution (whatever if it is adhoc or appstore based).
Lets say I have a build uploaded to iTunes Connect that has had a status of "Waiting for Review" for 10 days. If I submit a new build will my app go to the back of the line and have to wait another 10+ days or will I still be in line to get reviewed very soon?
Yes, after you Reject Binary then upload a new one, this puts your app to the back of the line again.
Edit: see this answer, this answer, the later answer on this question and Apple's own dev guide.
Removing a build removes your app version from Apple’s review queue and changes its status to Developer Rejected. When you resubmit your app, the review process starts over from the beginning.
I've also experienced it myself, although that was years ago.
If you reject your binary, you will remove your app from the Review queue. If you then submit a new build, you will unfortunately be placed at the end of the line.
We know this from experience, and it's also indicated by Apple (emphasis mine):
Removing a build removes your app version from Apple’s review queue and changes its status to Developer Rejected. When you resubmit your app, the review process starts over from the beginning.
I want to change my app from a paid version to a free with ads. However, I don't want the people that originally paid for the app to get the ads.
I was thinking I could include a new update that has extra code that sets up some UserDefaults saying the version doesn't have ads and then do the update to the free version. But that doesn't seem like a very reliable solution.
I think, it depends on minimum OS version, that your program can be run on. For iOS 5.0 and later you can try to use iCloud to store some flag about purchased version. It allows you to set this flag not only for one device, but for the user's account.
Or you can store this info in the keychain to get it later. But in this case your user will not be able to have no ADs on some other device with his(her) account.
Anyway, as far as I know, you need to create an update for your app first to write this flag anywhere. And only in some time make an update with ADs.
I will be glad to see comments if someone has another thoughts about this issue.
It seems there is no reliable method to detect whether someone paid for your app or downloaded it later when the price has been changed to free. For this reason I have decided to create two separate entries in the app store.
I have app in App Store, I submitted version 1.1, after Apple reviewed, approved and published it, I noticed there is a clear major bug, so I had to suspend my app from App Store.
I submitted a new version 1.2, you know it would take 5-7 days to be reviewed and published, can I revert to my previous version app (1.0) while the new version is released?
Actually there is just one way :
Set the availability date for buggy version to far future, then submit new version and ask for a expedited review.
After these you should have new version reviewed under 48 hours, depending on weekday.
Open the app in iTunes Connect and click "Rights and Pricing" top right. You get a message like this: "You have selected an Available Date in the future. This will remove your currently live version from the App Store until the new date. Changing Available Date affects all versions of the application, both Ready For Sale and In Review."
Also you can request a faster review for your next update:
https://developer.apple.com/appstore/contact/?topic=expedite
No sadly you cannot according to Apple, here's an excerpt from the iTunes Connect FAQ :
Question: The new version of my app on the App Store has a bug. Can I use a previous version to replace it?
No. You cannot revert to a previous version on the App Store. You must submit a new version.
Source : iTunes Connect FAQ
So, It is quite clear that we can't revert to the previous version on the App Store and the only solution is to submit a new version to the store. But We can fasten up the reviewing process by requesting the Expedited reviews. please go to the link(Expedited Review Form) and Fill up the form.