views:

960

answers:

3

I have an app in the app store that uses a wildcard bundle identifier. I want to implement in-app purchashing , which requires a non wildcard ID. How do I convert the wildcard ID of an existing app to a static ID for in-app purchase and push notification?

+1  A: 

You don't actually need to change the app's id, you just need to make a new provisioning file for the specific id you've already shipped, and then sign the upgraded version of your app with the new code-signing certificate.

That is, if the old app's bundle id was com.yourcompany.myapp, and signed with a com.yourcompany.* certificate, you just make a new com.yourcompany.myapp certificate, but you leave the app's bundle identifier the same as before.

David Maymudes
The app and cert were com.yourcompany.*. It never had a specific id. Was always a wildcard. So that means I will need to change the bundle id to something specific and also get a new cert right?
4thSpace
I didn't know it would work to use an asterisk in your bundle id... so if you actually did that, I guess you might have to change it.
David Maymudes
Having just put myself through this hell, this actually is the answer. If you have a wildcard distribution certificate, you may have problems. BUT, your app STILL has a bundle identifier. Just create a new app id, using your previous id, but postfix the bundle id (as used in app, no wildcards), then create a distribution certificate.
Jonathan Watmough
+1  A: 

In short you can convert an already submitted app that uses a wildcard bundle ID to a unique App ID. However, you're going to have some issue(s), or fallout from a user standpoint if you do so.

Apple uses bundle ID's to identify apps on the app store (hence the term App ID :-)).

The problem that you're facing is that your app is already up on the App Store with possible user downloads. Now when you update your application with the new unique App ID, the users that have already downloaded your application (with the old App ID) will not get the update (with the new unique App ID).

The reason why this happens is that you now have a new bundle ID in your application. With no connection to the old App ID. Since apps can only have one reference to an App ID. It's usually a good idea to keep an App ID the same throughout the production release, and updates of your application.

If you create a unique ID for your App (which you can). Users that download the new updated app everything will be all fine and dandy, but for the users that downloaded your app before the update. Well... you have now officially created an app orphan for those users, these users will never get that update since it doesn't match the App ID.

As far as there being a way around this. I'm not sure if there is. I can only suggest that you ALWAYS create unique App ID's for your future production release applications.


In order to create an application that allows you to use Apple's Push Notification service, and Apple's In App Purchase. You will need to create an App ID that is a unique App ID. I would always recommend that you use unique ID's for your applications. It will save you a ton of headaches later on down the road.

For clarification purposes the following are unique ID's

  • com.companyname.appname (preferred naming convention for unique App ID's)
  • appname.companyname
Tammen Bruccoleri
+1  A: 

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.

http://developer.apple.com/iphone/library/qa/qa2009/qa1680.html