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).
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?
Recently some updates were made into an iOS app build within WQA and new builds were distributed successfully. It is expected to have new/updated build version of the app in the collected data, however, new app build versions are not captured in WQA bug, feedback and session details.
In iOS the "CFUUIDCreate" method is used to generate a Universally Unique Identifier (UUID). When the back-end detects that this has changed, it checks automatically creates a new version for the application. Small UI changes might not generate a new UUID.
See the following tech note for more information:
http://www-01.ibm.com/support/docview.wss?uid=swg21679495
Is there a way I can make my Worklight's app public version number be different than the version number we're providing in application-descriptor.xml?
For example, I want my users to see the version 3.0.1 on Android settings (which is defined by the version attribute in the application-descriptor.xml) and one day I will want them to get an update from the Worklight server, but at that point I'd like that to turn into version 3.0.2. The problem is that a 3.0.1 will not update against something on the Worklight server that is 3.0.2.
Is there a way I can get around this?
Worklight does not provide this ability. IMO this is because what you're asking for is not inline with the thinking and intended usage of the Direct Update feature.
Direct Update is meant as a way to quickly provide fixes after having already released an app version to the store, for example in cases such as:
discovery of minor or major UI or logic bugs you've found in the app, or
for closing security holes that have been found
This is all happening to the same app version (lets say 3.0.1). Consider these as 3.0.1.build releases. or something.
It is not meant as a way of releasing new versions of the app. For this purpose use the conventional and appropriate way of releasing new app versions.
If you want to change the app version (which should coincide with a new app release), then you need to increase it in application-descriptor.xml (and other Worklight-related tasks), create a new binary and upload it to store, which users are then able to update and will see the new version number (lets say 3.0.2).
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.