My application it's already published on the App store.
I need to add "Associate Domains" to capabilities so I can use Universal Links in my app.
If I save the edit of the capabilities list, a popup appears:
Modify App Capabilities
Adding or removing any capabilities will invalidate any provisioning profiles that include this App ID and they must be regenerated for future use.
This will compromise the future updates of the app and the version that is still on the store?
Related
e.g. app v1.0 stored some user settings through shared_preferences plug-in,
then app v1.1 is published in App Store and Play Store, and user updated to app v1.1,
do those customized settings still work?
Yes, the shared preferences survive app updates.
Suppose the following situation:
A user buys an app
this app is removed from the store temporarily, by changing the availability date to a year in the future. Note that the app was not deleted from the store, it is just hidden by a change on the availability date.
the user deletes the app
the user regrets deleting and wants to restore the app from icloud.
will the user be able to do that? and what about apps that were completely deleted from the store?
thanks.
The other answer is incorrect. Unless you indicate in iTunes Connect that the app was removed for legal reasons (Rights and Pricing section) the user will still be able to re-download the app from iCloud.
If the app is not displayed in the app store(developer hide or remove), user can not re-install it after deleting, until developer make it displayed in app store again.
if developer deleted the app completely from app store , that means the app is not displayed int the app store, user can not re-install it yet, but the developer can re-upload the app again using the same app-id.
Can or not can re-install app depends on whether the app is displayed in app store
Also depends on whether it is the same app-id
In the Keychain Services Programming Guide it states the following:
"On iPhone, Keychain rights depend on the provisioning profile used to sign your application. Be sure to consistently use the same provisioning profile across different versions of your application."
Which I have no problem with but I would like to test that if I provide an update to my app in the AppStore that it will still be able to access the old values stored in the keychain. I have tried to test by updating the app with a version signed with an ad-hoc distribution profile that contained the same bundle id and product name as the original but it could not access the old value in the keychain.
Is the only option to submit the update to the AppStore and hope that it will work?
This is a good question.
One of the main reason why you might want to store some data in the keychain is to prevent malicious users from accessing it. This is quite a dry sentence on its own so I recommend reading about how someone might access that data.
Another way to access keychain data would be to create a malicious app with the same app ID as the target app. Apple have secured this route by requiring the provisioning profile to be the same.
So, to answer your question, you can only test the keychain data in update from the same provisioning profile, i.e.
Ad hoc to Ad hoc
App store to app store.
App store to app store is not really an option since it will be too late by then (your update will be on the market). So instead you need to delete your app store app and install an ad hoc version. Then recreate your data on the keychain, then update to the latest ad hoc version and test that it worked.
Of course this requires you to have an archived ad hoc version of the app thats currently on the app store. If you don't have this, then its not possible to test an update.
Unless I am mistaken, to update an app in the app store you need to use the same provisioning profile. Therefore, since you will be using the same profile, you should have access to the same keychain items.
It's actually not the provisioning file that matters, but the app ID. Specifically the Bundle Seed ID that you set when creating an App ID. Keychain access is governed by it. So as long as your profile uses an app ID with the same Bundle Seed ID you can continue to access the info in the keychain. I have a few apps that do this.
This allows you to to create a suite of apps that can all access the same keychain items as long as you set them to use the same Bundle Seed ID. So if you do a light and a pro version, they can both access the same keychain info while maintaining separate bundle identifies for things like user defaults.
SFHFKeychainUtils may be your good choice.
It's a wrapper to access keychain.
More about: SFHFKeychainUtils :http://www.ioslib.com/archives/sfhfkeychainutils/
I've got my app approved a while ago and used the * provisioning profile so I created somehting like:
com.mydomain.MyApp
but now I have the necessity of adding push notifications and I can't due I am using the * provisioning profile and it needs to have its own app ID and profile.
How should I proceed in order to achieve an app update without breaking anything
The bundle identifier for an app must always remain the same between updates, but the AppID can actually be different. So all you need to do is create a new AppID that used the same bundle identifier as the original app instead of a wild card.
Apps that use a wildcard still need a normal bundle identifier. The wildcard AppID lets you use any bundle identifier you like, but it still needs one.
There used to be an Apple article about this:
but it is no longer available online However, an archive is available.
You can't change the CFBundleIdentifier of a released app if you want to release updates for it, the App Store will automatically reject it when you upload. So...
I needed to enable iAds on an app previously developed with a wildcard App ID. Here's what I did:
I have a wildcard App ID of <AlphaNumeric>.* which my app currently uses, and my app has a CFBundleIdentifier of com.companyname.mygame.
Created a new App ID of <AlphaNumeric>.com.companyname.mygame.
Created new development and distribution provisioning profiles that include the new App ID.
Download the new provisioning profiles to Xcode and my devices.
I was then able to compile the App with the new non-wildcard distribution profile, which meant on upload I could enable iAds (or Push for you). The CFBundleIdentifier didn't change so the new compilation appears as an update to the existing app.
I can confirm this process worked without issue.
Under Frequently Asked Questions in the document entitled "Technical Note TN2259," which is "Adding In-App Purchase to your iOS and Mac Applications," there's this bit
Question: My iOS application is currently signed with a Provisioning Profile
that uses a wildcard App ID. How do I enable my App ID to support
In-App Purchase?
Answer: Read the Creating and Configuring App IDs section of
the iOS Team Administration Guide to learn how you can enable your App
ID to support In-App Purchase.
The link points here, and there's a section called, "Updating Your App to Include APNS, iCloud, In-App Purchase, or Game Center Requires an Explicit App ID"
That said, I don't know (yet) at what point the app takes on the new App ID. Is it when you upload for review, before that, or when it has been approved? I am working on this problem now, so I might be able to add to this answer soon.
Edit: The explicit app id only affects the piece of software you are testing and has, essentially, nothing to do with iTunes Connect whatsoever. This means that if you are testing in-app purchases, the piece of software that's running (your app) has to have a provision profile based on a cert that is app specific. What happens in iTunes Connect is totally irrelevant.
Our app is already there in app store. We now have integrated push notification support to our app and this requires new app id to be created, because our existing app id has got asterisk symbol in it. To enable push notification, app id should not have asterisk at the end, instead it has to have an unique name. So we decided to create a new app id which has got push notification enabled.
But if we do so, will we be able to upload our app as an update to our existing app which is there in the app store?, or our new submission will be considered as a new app? or what other problems we will be facing?
Thanks in advance!
We've gone through similar issues, and I'd like to put a disclaimer here that we don't actually have anything released yet, but we were able to use the same bundle identifier with a new app-id and a new provisioning profile, and it did overwrite the old app on the phone that had the old version.
I don't think the changed app-id will make a difference After all, if you have 10 different apps using the asterisk ID, they are still considered 10 different apps, so the app-id is probably more specific to the signing end. The Bundle-id is what determines the app's identity on the device itself, and so I think it's the same in the app store.