I'm stuck in a slightly weird situation. When our app was first created, nobody really knew what they were doing and I'm trying to clean things up a bit.
In the iOS developer center, it seems that there are two App IDs for my app. I think I can delete one of them, because the other one is the one that is actually being used, but I'm not 100% sure.
Here is the App ID that I think is actually being used in our released app:
Here is the "other App ID":
The annoying thing is that the "other App ID" seems to match the bundle ID of the app and xCode seems to be trying to use it as the application-identifier when the app is submitted to the store. I don't want the application identifier to change.
Is it safe to delete the other app id? Can I force xCode to use the correct application identifier? How can I tell which app ID is actually being used by our released app?
Edit:
Why this arose is because after submitting our latest build to the store for testflight, I got this notification:
Dear developer,
We have discovered one or more issues with your recent delivery for
"My Cool App". Your delivery was successful, but you may wish to
correct the following issues in your next delivery:
Potential Loss of Keychain Access - The previous version of software
has an application-identifier value of ['ABCDE.MyCoolApp'] and the new
version of software being submitted has an application-identifier of
['QWERTY.MyCoolApp']. This will result in a loss of keychain access.
After you’ve corrected the issues, you can use Xcode or Application Loader to upload a new binary to iTunes Connect.
Regards, The App Store team
The fact that the application-identifier is changing, and that it appears to be using the "prefix" as part of this value, suggests that it was using the first app ID, but now it is going to use the second.
Do you have access to login in to the iTunes Connect for that account? That's what you really need to verify the bundle ID (aka app ID) of the released app.
Login at itunesconnect.apple.com, click on apps, click on your specific app, click on the 'more' tab, click on 'about this app' it will show you the bundle ID being used for the released app. Feel free to delete the OTHER app ID out of your account. Not the one in iTunes Connect :)
The bundle ID in your Xcode project can always be modified to match whatever app ID you'd like, as well as you can easily regenerate any necessary provisioning profiles for any app ID. (of course, you should make it match the existing one in iTunesConnect if you want to release an update for that app)
Edit:
It sounds like you've been able to match up the app ID, but not the prefix. The way prefixes are assigned has changed over the years and now they are all team based. You can read this technical note and see if it will help you resolve the warning you encountered.
Developer Link
The primary difference between your 2 App ID is the ID:
the first one has '*' as ID. It means it is a wildcard ID. You can create multiple applications using different bundle identifiers with the same provisioning profile using this ID. But you don't have access to specific capabilities such as Push Notifications, in-app purchase (because multiple apps will share the same profile
the second one is fully qualified and can be used only with the app whose bundle identifier is 'MyCoolApp' and can have access to full capabilities of apps.
Note that your app ID naming convention should be in reverse url format as Apple advices: myCompany.myInternalGroup.myAppId.appFlavor for instance.
Related
I have an app, which uses Apple Universal Links feature. So, this app should be opened, when user clicks on my web site link. But, somehow, this happens. One of the reasons is wrong App ID. Can test flight change it somehow?
UPD: The Apple App ID is a two part string used to identify one or more apps. Specifically, the Apple app ID is your team ID and bundle ID joined with a period, for example: 1A234H7ABC.com.yourdomain.YourApp.
No, the app ID should not change. The bundle ID should never change and neither should the team ID. You should check your device logs when installing the app to see if the AASA file is getting downloaded. This could be an iOS 11.2 issue in which you'll have to delete the app and re-download it.
Hi I created an app with a bundle ID but that App was rejected from Apple, Now I need to upload a new App but with the same bundle ID, but the rejected one keeps holding it, I need to delete this App and upload new one, I tried this link
Deleting an app in iTunes Connect
but all it says is to deselect all from sales section, I also tried changing it bundle-ID but to no avail,..is there any other way to get rid of this rejected app and upload a new one with the same bundleID
First of all,
Bundle ID: A reverse DNS string that precisely identifies a single app.
Bundle ID search string: it is used to match a set of bundle IDs, where each bundle ID identifies a single app. For example, if the bundle ID search string is com.mycompany.MyApp or a wildcard such as com.mycompany.*, then it will match the bundle ID com.mycompany.MyApp.
App ID: A string that identifies one or more apps from a single team. An App ID consists of a bundle ID search string preceded by the Team ID, a 10-character string generated by Apple to uniquely identify a team.
Bundle Id is Unique, it can't be reused as exact.
If you had created this app Id from one account (com.mycompany.MyApp) , you can't create the same app Id from the other account. However, you will still be able to create a new one as com.mycompany.MyApp1 like or so. There should be atleast 1 character difference in the app Id's.
Also, App IDs cannot be removed because once allocated they need to stay alive, so that another App ID doesn't accidentally collide with a previously existing App ID.
I believe you cannot re-use a bundle id. it is unique for each app created on iTunes.
in fact, if i am not mistaken itunes clearly warns about not being able to change bundle id once the app is created.
The submitted app is holding you up because you have not yet rejected the binary so you can replace it with a new one.
You can submit an app with the same BundleID by first rejecting the binary of the first one.
Please refer to the guide and look for the Rejecting Your Binary article (below): https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/ChangingAppStatus.html#//apple_ref/doc/uid/TP40011225-CH30-SW34
Rejecting Your Binary
Rejecting a binary removes your app version from Apple’s review queue and changes its status to Developer Rejected. You can then move your app back to Waiting For Upload (See “Uploading Your Binary”). When you resubmit your binary, the review process starts over from the beginning.
You can reject the binary you’ve submitted if its status is any of the following:
Missing Screenshot (iOS only)
Waiting For Export Compliance
Waiting For Review
In Review
Pending Developer Release
Pending Apple Release
If your app’s status is not one of these, see “Deleting an App.”
I was not able to add a new app,but was able to upload a new build by updating the build number , I also had to update the Version, because the new Build contained In-APp purchases, any ways, it went smoothly after that, The In-app purchase was causing me the problem here.
No, unfortunately you can't delete an application from iTunes.
These have baffled me ever since I signed up for developers account!
I Need to Know which one to use when I submit my app to the store?
Also in target > build settings > code signing > provisioning Profile are those values as shown in the image, which one do I pick to submit my app?
The com.domain.name or wild card?
And lastly what in the heckaroo is the com.domain.name used for and what's its importance?
Wild card ids are for development purposes only. Suppose you're working on an app, and don't know what its final name will be. You use the wildcard app id until you've named it.
Once you've named it, you do the com.domain.name one for submission.
These must be unique across the entire iOS ecosystem, which is why they work this way. Provided no two companies have the same name and product name, there will be no collisions.
The wildcard app ID (defined as *) can be used for any bundle identifier (the one you set in Xcode).
If you app conforms to the following (taken from the Registering an App ID page in the Certificates, Identifiers & Profiles section of the developer portal):
If you plan to incorporate app services such as Game Center, In-App Purchase, Data Protection, and iCloud, or want a provisioning profile unique to a single app, you must register an explicit App ID for your app.
Then you need to specify an explicit App ID - the com.domain.name you mentioned. This must match the bundle identifier of your app you set in Xcode.
The App ID is tied to the developer account (I believe it can be transferred) and this is unique per application. For example, say I set up an app with the App ID of com.stackoverflow.rich, you could then not use that App ID.
The App ID must be an explicit App ID when finally submitting the app to the App Store.
When releasing for the App Store you need to set your App Store Distribution profile under Provisioning Profile -> Release. You can probably just press delete/backspace on the Code Signing Identity -> Release, and then the Automatic setting will pick up the correct certificate.
Whenever you use the Archive command (under Product), the Release build configuration is always used (unless you change it under the Scheme settings).
If you want more info about this have a read of the App Distribution Guide.
There's also a Technical Q&A on this topic as well.
I am trying to understand the role of the first part of the AppID for iOS apps.
This part was formerly known as the "Bundle Seed ID", but is now often referred to as the AppID Prefix.
A while ago (iOS 5?), Apple made some changes in both their portal and their documentation and started to recommend using the "Team ID" (unique per developer account) as the AppID Prefix. This is simple and straightforward for new developers with new apps.
But what is the the best practice for handling existing apps with regards to the AppID prefix?
I know that it is not possible to change BundleID (= the second part of the AppID) between two app versions, but is it safe to change the prefix between app versions?
Note that I am not referring to replacing a "wildcard AppID", e.g. ABC1234567.*, to an explicit AppID using the same prefix, e.g. ABC1234567.com.mycompany.myapp. There is tons of information about this (most of it outdated, though). I am thinking about changing the complete AppID, e.g. ABC1234567.com.mycompany.myapp, for an existing app by replacing the prefix with my Team ID, e.g. DEF7654321.com.mycompany.myapp.
I think I have read somewhere that it should be OK to change the prefix for existing apps, except in the special case that the app is using the keychain to store data. If this is true, the easiest way to handle the prefix for existing apps would be to migrate to the new Team ID when it's time to release next update. When all my apps are migrated, I can continue using the Team ID (as Apple recommends for new apps) and finally forget about all this mess.
Can anyone confirm this?
If you can shed some more lights upon the concept of the AppID prefix, and what it is actually used for on an iOS device (except the keychain which I already know about), I would be happy if you could write a comment. Perhaps we could build up the full understanding of this by adding bits and pieces from different sources. Sadly, the Apple documentation is very thin in this area.
(There is another similar question: Can I change the Bundle Identifier in my app after it's been approved? But that is mainly focusing on the BundleID, i.e. the second part of the AppID, so this is not a duplicate, even though some of the answers and comments are touching upon this topic.)
My conclusion, as of today, is that it is completely safe to replace the AppID prefix by a new one, with the exception of apps using the keychain. This opens up for migrating the prefix for all my exiting apps on the App Store to the new TeamID based prefix.
This conclusion is based on the following input:
A discussion I had with Apple's developer support a couple of weeks
ago. They told me that there should not be any problems changing the prefix, except for apps using the keychain.
A test I did, using ad-hoc distribution, verifying that an existing app on a test device did not lose any data when it was updated to a new version with another prefix.
The fact that I have successfully uploaded new versions, with replaced prefix, of two
of my existing apps without any problems so far.
The status of the two "live" apps that I have changed, is that they have been approved in the review. However, they are currently waiting in "Pending Developer Release", since I am waiting for a third app to get ready in order to sync the release with that one.
If I see any kind of problems when they go live on the App Store, I will of course update this answer.
Update:
The two apps were released successfully more than three weeks ago. The roll-out worked as expected and I have not received any user complaints.
In summary, the answer is YES, this is completely safe!
Apple published a new tech note on February 12th 2014 confirming that it's possible (and safe*) to change Prefixes yourself for Wildcard App IDs, but it's still impossible to do it yourself for Explicit App IDs.
However, they say you can contact member center maintainers if you would like them to change your Prefixes for Explicit App IDs.
Gonna include this part here in case they change their mind again:
All other App IDs will require the assistance of the member center maintainers - if you are not using a wildcard App ID, then you should contact the iOS member center maintainers for assistance. Here are the steps you can use to do that:
Go to https://developer.apple.com/contact/.
Submit a request by clicking the link under Enrollment and Account.
* Keep in mind that if your app stores data in Keychain, changing app ID prefix will result in one-time Keychain data loss.
I have an app published on the AppStore and I want to migrate it to an enterprise developer account for in-house distribution. I read in the enterprise documentation that:
If you want users to keep the app’s data stored on their device, make sure the new version uses the same bundle-identifier as the one it’s replacing, and tell users not to delete their old version before installing the new one. The new version will replace the old one and keep data stored on the device, if the bundle-identifiers match.
Now, assuming we keep the Bundle ID the same between the AppStore binary already installed and the enterprise binary signed with a different certificate... it should overwrite the same app on their phone rather than create a second app.
I contacted Apple support and they said "No, you will have 2 apps installed if you do not instruct the clients to uninstall their old one". Is this true?
EDIT: I'm leaving my original answer below for conversations sake as there is good dialogue below. As #mja noted when you initially create an app ID it is associated with one of a few available prefixes to your developer portal and that prefix may be used by iOS to associate & differentiate between apps.
EDIT2: When I go into my Enterprise Portal and try to create an app ID with an identical value to an existing app ID but with a different prefix it still blows up on me and says:
An App ID with Identifier 'com.mycompany.myapp' is not available.
Please enter a different string.
ORIGINAL Answer:
The latter part is incorrect - iOS devices use the Bundle Identifier to differentiate between apps. I can have 20 apps labeled "Cool App" on the same iOS device so long as they have unique bundle identifiers such as com.mycompany.coolapp.1 - com.mycompany.coolapp.20. Likewise (and I've done this accidentally) if I open two projects, both of which have bundle identifiers com.mycompany.myapp, and run one right after the other the last app to be run will be installed on the device whereas the previous app will be overwritten.
Regarding the app data sustaining itself I have not tested that though I'd be interested in what happens for you!
I have managed to achieve this, so that the 'enterprise' build of the app overwrites an 'app store' distributed version.
This does not use the exact same bundle ID but does achieve what OP asked in his original question.
How I did this was, in my enterprise account, create a wildcard bundle identifier with the first two parts the same as the bundle identifier for our production app, for example:
Production : com.xyz.abc
Enterprise : com.xyz.*
Using this wildcard bundle ID, the app can be distributed and will overwrite any versions installed via the app store (user data will still persist). The prefix does not seem to matter here.
One drawback of the wildcard bundle id is the fact that you cannot use APNS etc.