I have an existing app on the app store, lets say its called coolApp.
It is written using Xojo, and creates a database in Apple’s sandboxed directory:
/Users/Me/Library/Containers/com.mycompany.coolApp/Data/Library/ApplicationSupport/coolAPP/coolDatabase.dbs
The thing I am worried about is that the name of the directory (referred to by Xojo as Special Folder ApplicationData) is referenced from the app’s name.
For my next update I want to change the name of the existing app to coolApp Pro (the BundleID will not change), but also release a second app called coolApp (a limited version of coolApp Pro).
What will happen with the name change - will Apple keep the database in its original location for coolAPP Pro so existing users can still access their data? Where will the new app create its database? Am I inviting trouble by re-naming my original app, and creating a new App with the same name as the old one? And what happens in Windows?
Actually I changed the name of a couple of apps of mine on the AppleStore keeping the same BundleID. MAS did not complain.
Since you are keeping the same BundleID, the same directory in Containers (Containers/com.mycompany.coolApp/) will be accessed as before.
In other words, you have only to change the name of the app (coolApp Pro) in the app itself and on itunesconnect’s relevant meta. Needless to add that, in the app, any textual ref to coolApp will have to modified into coolApp Pro.
On the other end, the second app you are going to deliver, even if retaining the old app-name, will have to have a different BundleID, and its directory in Containers will be created according to such new BundleID.
But if that means that the ‘other’ CoolApp has less features than the existing one, Apple is likely to kick up about that too. (So will the users)
No-one will complain if you upgrade the feature set of CoolApp so that existing users are automatically up to Pro
The ‘other one’ launches as ‘CoolApp Lite’
But then you arent seeing any upgrade fees.
Maybe you have a non-MAS version that offers more features?
Thanks for your replies. From what I can read, changing the name of an app is allowed in iTunesConnect when uploading a new version, so that part I’m not worried about.
The existing app will become the Pro version, so all existing users automatically get upgraded to Pro. So there should not be any complaints from users.
The new version (coolApp) with no current users, will have some feature restrictions. This new version will have the new BundleID.
I got worried that Apple uses the app name in the directory structure, but I can see now that it actually uses the BundleID that I set. It just happens when I set my BundleID years ago, I based it on the app name. I can set the new bundleID to whatever I want for the new app, so all should be good.
Just one more point: keep increasing the last “Version number” and the “Non Release Version” as you were submitting a new instance of the “old” app. Good luck.
To clarify - make sure both apps have the same version number? Even if the new app (the lite) will actually be 1.0.0?
Is this just to avoid confusing customers, or another reason?
Nope, name change is totally allowed, but only when uploading a new version of the app. BundleID must stay the same - that is what Apple uses as the primary identifier for a particular app. Maybe rejected for a different reason??
@Rob Lang To clarify - make sure both apps have the same version number? Even if the new app (the lite) will actually be 1.0.0?
Is this just to avoid confusing customers, or another reason?
No, I was referring to the app with the new name. So, for instance, from coolApp 2.3.4 (319) to coolApp Pro 2.3.5 (320).
The new app (the lite) can have any number you decide (1.0.0 or whatever).
[quote]
/Users/Me/Library/Containers/com.mycompany.coolApp/Data/Library/ApplicationSupport/coolAPP/coolDatabase.dbs[/quote]
The bit I’ve highlighted in bold, are you hardcoding that part of the path. If so, then your “Pro” version can still access it as long as the bundle identifier is the same. If you change the bundle identifier, by default it will not be able to access that folder. You can choose to use a special entitlement to “upgrade” the database from the existing version to a pro version (i.e. move the files from the old bundle identifier to the new one), but of course this means that they cannot access the data from the older version any more.
Another way to do it would be to add an export function in your current application, that simply copies the data to a location of the users choice. Then add an “Import” option to the “Pro” version which will read that data.
Now as for having two apps on the app store with similar functionality; this depends on the reviewer you get. I’ve run into problems with something very similar in the past, where as others here have not had a problem. Hopefully you’ll be lucky, but be prepared to get a shitty app reviewer and have to fight Apple to allow this.
You should also sell the Pro version on your own web site, never just limit your applications to one distribution channel. @Michel Bujardet is a shining example of what spreading your applications across as many platforms as possible and distribution channels as possible can do.
It’s the same story for the Windows Store. In the AppManifest.xml, just keep the Identity Name as before and change the “Display Name” to the new name. For the Mac AppStore, they are not particular about the filename of the appbundle but that cannot be said with Windows. You will have to change the name of the executable file to match the new app name.
Thank you all. My problem was I thought Apple derived the sandboxed ApplicationSupport directory from the app name, because that folder was called coolAPP for my app. What I had forgotten (app is 4 years old) is that the directory is actually made from the bundleID that I named. So the change of app name won’t change the bundleID, so the database will continue to sit in the same directory.
You are correct, Sam, that the child directory within ApplicationSupport is hard-coded by me, so it won’t change either. Yes I do sell on my own website as well, with a custom-rolled licensing system (that was actually quite fun to create!) and the sales are handled by a Rapidweaver store-page called RapidCart/RapidLink that can send out licences from a list upon getting the OK from PayPal. 75% of my sales are from my own website, and the rest are via the MAS. I dont’t sell on the Windows store, but I do have a Windows version on my website.
My impression was that it was commonplace to have a Lite and a Pro version of apps on the MAS. I’m hoping no issues with getting approval.
It used to be the other way around, at one point I almost considered shutting down our site because sales on the Mac App Store were so great, now almost everyone sees the same as you, with the Mac App Store being the weakest channel (and the worst profit sharing model).
It is/was, but Apple have never liked that model. They added In-App-Purchase, but as they don’t use it themselves, their guidelines basically crippled the effectiveness of it. Our own figures indicated that lite/pro has a better conversion ratio. There’s a new 14-Day trial model that Apple are proposing, I’ve yet to see it, but it works via the IAP functions.
The trouble is if you get a crappy reviewer, they’ll make it difficult for you no matter what you do, so you must plan ahead and be prepared to spend time fighting them.
Fingers crossed for you mate, hopefully it will go swimmingly, don’t forget to update the thread here of Xojo made apps in the Mac App Store and let us know if you need anything else.