I have already submitted an app (v1.0) now i wanna update my app. here, i got confusion. There in the windows developer center, two options are available.
Replace or Add New. Which one I should give to update my existing app ?
To update your app, you should use Replace.
Add new allows you to associate multiple XAPs with the same app GUID (for example, if you want to publish two different binaries for a single app: a WP7 version and a WP8 version).
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?
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.
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).
The MSDN page for CurrentApp.appId is here.
In a typical application the property comes back in the format 00000000-0000-0000-0000-000000000000, and precisely that number if you're running an app that is not in the Windows store.
Once in the Windows store, it gets a real number, and my question is: Is there anything that would cause an appId to ever change? Perhaps as versions of the app are updated, or if the app is renamed?
The AppId will not change unless you remove the existing app and republish.
I do not have a source for this, but it is the same process from the Windows Phone Marketplace/Store. The ID is used in many places.
The direct link (URL) to your app
Used by the Store app to identify which apps have an update
Used by Visual Studio when creating/uploading packages
...
Changing the Global Unique Identifier is totally against the point of a GUID. If it changed, many things would break. The ID does not change when updating the app, it remains the same.
I need to be able to update my app from within the app itself. I know Sparkle works for Mac Apps but I can't seem to find any for iOS.
Edit: I am not asking how to bypass the review process. I was thinking that there might be frameworks similar to Clutch.io that allow updates to images/documents/etc from within the app. Or things like UrbanAirship that manage in app purchase data that allows an app to be extended from the app itself.
You can't replace your app with an updated one (except through the App Store) and you can't replace parts of your app with updated parts (that would make your app's code signature invalid); you can only update stuff that's outside of your app's bundle.
You can't update the app binary yourself, the system is responsible for updating all apps.
Though, if you just want to update some data in your app you can do that for sure.
Here is what I was looking for:
http://code.google.com/p/cooliris-toolkit/
It has a class called RemoteUpdater which allows me to download zip files of images/data or whatever I like to extend my content.
Depends on your needs. If you dont want to see the app you can also do an Enterprise Deploy.
Used by corporations to distribute apps to their clients or employees.
Needs a separate Apple account which costs more.
Uses same process as deploy to appstore
Archive > Distribute > create ipa/plist > copy these to webserver with html page with link to plist and user clicks on link from Safari on iOS Device and it installs.
Going back to CArpp Store review process after that is painful.