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
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).
The scenario is quite simple: there is an old App written using Cordova that has to be updated with a new App written from scratch using React Native.
I am not the developer and the maintainer of the App written using Cordova but I could put hands on its source code. I have to rewrite the App and to make a "silently" update, i.e. the new App must no "reset" the data stored on KeyStore (Android) and Keychain (iOS) and it must reuse these data.
When I "update" the App on my test devices I try to access the data generated by the old App using:
react-native-keychain
react-native-secure-key-store
and try to fetch the data, but with no success. The problem is the same on iOS and on Android.
Focussing for the moment on iOS, I use Xcode to build both the Apps. Firstly I build the old version of the App, generate the data and store them on Keychain. Then, I build the new App version, superseding the previous one. I have ensured that on Xcode the Bundle Identifier and the Signing Certificate is the same for both versions. But from the new version of the App I am still unable to access the Keychain. To make the litmus test: I downgrade the App re-building the old version another time, so the old app replaces the new one and in this case from the old App I am able to access the Keychain data.
I am suspecting that, even if the Bundle Identifier, the two Apps are using two different Keychain zones. So, what I have to do in order to be able to access the data stored by the old app from the new one?
The idea I that the user shouldn't be affected by the update of the App, so the Keychain (and the KeyStore) of the old app must be re-used by the new app.
Note: I see that on the old App, the function used to store data in Keychain/KeyStore is:
var ss = new cordova.plugins.SecureStorage(callback)
Note: I have already read this from Apple Developer website, but I suppose it could be not my case, because I can't set the Keychain sharing on the old App, since we are not permitted to release an update of the Cordova-base App. But, however we tried internally to use Sharing Access without success.
In iOS in particular, keychain access is not just tied to the Bundle ID and signing certificate for the app. There is a third element called the "Groups Entitlement" that is designed to allow multiple applications from the same vendor to share keychain access to the same data (imagine separate email and calendar apps sharing a user's login data). Documentation for this mechanism begins here:
https://developer.apple.com/documentation/security/keychain_services/keychain_items/sharing_access_to_keychain_items_among_a_collection_of_apps
The documentation is fairly dense, but despite being intended for multiple apps to share data this also controls an application reading its OWN data. You must ensure that your parameters match the old app precisely or you will not be able to read the old values. You didn't provide the code for the old or new apps, but as an example if the old app had stored values in the Keychain on iOS, you might use react-native-keychain and the following code to read it:
// The "access group" is the Team ID of the OLD APP followed by its full Bundle ID
const accessGroup = 'A12BC3D45.com.company.BundleId';
const accessOptions = {
accessGroup,
accessible: Keychain.ACCESSIBLE.AFTER_FIRST_UNLOCK,
};
const oldCreds = await Keychain.getGenericPassword();
console.debug('Found old credentials', oldCreds); // REMOVE AFTER DEBUGGING
react-native-keychain has several load functions and you may need to experiment with others (such as getInternetCredentials) if your old app stored things differently.
We are getting error like for following while APK file installation for particular OS version ( 8.0) in Android.
But, This is working fine while development.
Error is following
Error: Migration is required due to the following errors:
ReactNativeJS: - Property 'Some Field' has been added.
ReactNativeJS: - Property 'other Field' has been added.
We are using Realm DB in our React Native project.
As per some forums suggestions, We have deleted node modules and reset cache, Delete nodemodules/realm too. And done npm install too.
But, Still same error showing while trying to install APK, But, This issue not happening while we run in development mode.
Note: This issue happening only particular devices (OS version 8.0), Other devices its
working fine.
Any suggestions?
I know that is late but for anyone who comes for this here the answer:
Realm requires for any update made to its schema to be solved using something called a Migration. This was invented having in considering that when you update your app from an version to another it might have some changes to the database that may make you data inconsistent.
The easiest way the get rid of this is deleting all the current database data if you change your schema add deleteRealmIfMigrationNeeded add configurations as below
Realm.open({ schema: [BookSchema], deleteRealmIfMigrationNeeded: true, })
The other way is buy creating a migration your self as described at the official documentation
Restrictions on use of non-SDK interfaces
To help ensure app stability and compatiblity, the platform restricts the use of some non-SDK methods and fields; these restrictions apply whether you attempt to access these methods and fields directly, via reflection, or using JNI. In Android 9, your app can continue to access these restricted interfaces; the platform uses toasts and log entries to bring them to your attention. If your app shows such a toast, it is important that you pursue an implementation strategy other than the restricted interface. If you feel that no alternative strategy is feasible, you may file a bug to request reconsideration of the restriction.
Restrictions on Non-SDK Interfaces contains further important information. You should review it to ensure that your app continues to function properly.
Starting in Android 9 (API level 28), the platform restricts which non-SDK interfaces your app can use. These restrictions apply whenever an app references a non-SDK interface or attempts to obtain its handle using reflection or JNI. These restrictions were put in place to help improve the user and developer experience and reduce the risks of crashes for users and emergency rollouts for developers. For more information about this decision, see Improving Stability by Reducing Usage of non-SDK Interfaces.
See here for more information.
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).