I’m trying to figure out what just happened.
I used App Wrapper Mini to create a build script for my application, Font Sleuth. When I built the application and opened Font Sleuth it no longer loaded font group folders created in the previous version. After digging around I discovered that Specialfolder.ApplicationData.child(“Font Sleuth”) now refers to User>Library>Containers>com.ttpsoftware.fontsleuth>Data>Library>Application Support>Font Sleuth. Previously, SpecialFolder.ApplicationData.child(“Font Sleuth”) used to refer to User>Library>Application Support>Font Sleuth.
I downloaded a version of Font Sleuth that used to access User>Library>Application Support>Font Sleuth but now it can’t access that folder. I guess it is accessing the “Containers” path instead.
It would appear that the User>Library>Application Support>Font Sleuth folder is now unavailable to all versions of Font Sleuth regardless of when they were created. Is this correct?
That doesn’t make sense. I have a similar situation. The previous version of QuizMaker Pro returned User>Library>Application Support>COS from SpecialFolder.ApplicationData.Child(“COS”). I have a newer version which is sandboxed which returns the “Container” location. The behavior of the “sandboxed” version is somewhat odd (another topic), but the previous version still returns the usual path as it always has. Could something else be going on with your app?
Interesting. I don’t really know what is going on. Perhaps the external script I used that was generated by App Wrapper Mini did something. I’ll check with Sam the developer of AWM.
Thom, I understand that the sandbox will apply to versions of Font Sleuth built with App Wrapper Mini’s external build script but it seems odd that versions built previous to the script build don’t access User>Library>Application Support>Font Sleuth. I even ran a version of the Font Sleuth project created weeks before the script build occurred and it didn’t access the User>Library>Application Support>Font Sleuth folder. So it appears that all versions of Font Sleuth, regardless of when they were built, are being directed to the “Containers” Application Support folder . Is this to be expected?
My concern is that users of the non-App Store version of Font Sleuth might lose all of their font organization which is stored in User>Library>Application Support>Font Sleuth if they later switch to the App Store version.
This is not to be expected, and I think you are mis-diagnosing. When an app is not sandboxed, it absolutely will not use the container. When a sandboxed app is launched, it can migrate data from a non-sandboxed location, but only when explitly asked to do so. App Wrapper may have written the migration file, I don’t know.
I would recommend sandboxing even the non-MAS version. It is a good security feature, and helps you keep feature parity between the two versions.
As Thom says, when an application is in a Sandbox, it has limited access and many of the system folders are redirected to the apps container. This is how it works.
However there is some functionality that can be used to help those upgrading to a Sandboxed version (but not the other way). It’s called migration. Currently AWM doesn’t support it (although AW does).
Create a file called “container-migration.plist” in the resources folder, and copy and paste the following code into it.
[code]<?xml version="1.0" encoding="UTF-8"?>
Move
${Library}/Preferences/${BundleId}.plist
${ApplicationSupport}/${BundleId}
[/code]
In order to test this, you’ll need to delete the application container first. BE WARNED - this will move the data into the app container, which means that the data will no longer be available to previous versions or non-sandboxed versions of the application.
I agree with Thom, once you go Sandboxed, you should go all the way.
Thanks Thom and Sam. I’ll give Sam’s migration method a try. I don’t mind being committed to the sandbox. I just want to make sure users of older versions don’t lose their work.