Changing app's bundleID

Hello,
suppose I have a sandboxed app (“My App”, com.mycompany.myapp) that keeps its preferences file in the Container. Such pref file stores user’s options, lists of this and that, or it can be a database file, and so on and so forth.
Now suppose I want to upgrade the app changing its bundleID to com.mycompany.mynewapp.
When/if a user of the old app buys the new one, she/he expects to get whatever she/he had stored in the old app.

Moreover: suppose the old app generated its own external files with .xxx extension, that could be opened only by such app. And the new app generates files with .yyy extension that can be opened only by the new one, but at the same time the new one can open .xxx files. Now, I would like for the new app to open a .xxx files by open-dialog and save them with .yyy extension WITHOUT calling a save-dialog.

How to accomplish all this stuff for a sandboxed app without telling the user to manually move x y z files from “a” folder to “b” folder?
On this forum I read that it is possible, but I’d appreciate if somebody showed the necessary steps.
Thanks.

[quote=249650:@Carlo Rubini]Hello,
suppose I have a sandboxed app (“My App”, com.mycompany.myapp) that keeps its preferences file in the Container. Such pref file stores user’s options, lists of this and that, or it can be a database file, and so on and so forth.
Now suppose I want to upgrade the app changing its bundleID to com.mycompany.mynewapp.
When/if a user of the old app buys the new one, she/he expects to get whatever she/he had stored in the old app.[/quote]
You can migrate stuff to containers, so you should be able to copy the old data to your new container. I’m not sure on the specifics, but it’s possible.

Don’t do that. That’s unexpected behavior and poor UX. The app should open .xxx files, but find some way to notify the user that this is the old format, and to save they must use the new format. Then, the next time they save you present the save dialog so they can save it in the new format.

In App Wrapper, under the “General” heading, you can use the “Container migration” options, enter in the paths and then first time the user runs mynewapp it will import these into the new apps container.

However, I’ve never tested it with migrating files from an existing Sandboxed application into a new one, so I don’t know if it will actually work.

I also wouldn’t recommend this course of action. If there’s a bug in your new application that prevents a user from using it, they then can no longer use the older version (well that depends of course). The files that are moved, are simply not available to the older version.

The Apple recommended way is to use a Group-Container for storing this information; I need to write up a tutorial on how to use this functionality, but the principle is that all the important data is stored in a independent location. It would mean that you’d have to release a version of your old app to move the existing stuff into the group container, before the new application can access it.

Before I knew about Group Containers, the lack of one app being able to access another was just another reason not to Sandbox App Wrapper 3, otherwise it couldn’t auto import the data files from version 2.

If you’re Sandboxed, it’s not likely to happen. In order for the name to be changed and have access to the file, you’re going to have to use a SaveAsDialog. There might be a possibility with NSFilePresenter protocol, however I’ve not done anything with it, so I can’t say for sure.

The better solution IMHO; is to have a version tag within the file; again it requires updating your existing application first; but if it find a version tag thats newer than what it’s expecting, it can alert the user that the file is from a newer version and it might cause problems if they choose to continue opening it.

@Tim and Sam
If possible, I would not use migration because a user may wish to keep the old app usable.
So I’ll wait, and see what Group Containers offers.

As for opening .xxx files and saving them as .yyy files I’ll stick with my present solution, i.e. alert the user and use a saveAsDialog (as you too suggested).

Thanks.