My app saves a lot of things, mainly controls positions, fonts and font size, printing preferences, in a subfolder of SpecialFolder.ApplicationData.
I got several reports from customers that all that is not saved, and they have to redo every time they start the app.
What could it be ?
Is there some versions of the system which prevent writing there ? Or which wipe the data somehow ?
Which OS are they running?
10.14.x
Previous to more recent versions of my main project I stored everything in Application Support as well. I never had any problems such as that. I recently moved all the data to a folder in Documents instead as there are folders in there that users need to be able to access and getting to Application Data in the Finder requires extra steps since by default you cant get inside your Library folder via the Finder.
I believe that change was at least after 10.14 came about and I have users running everything from 10.11 up to 10.14.5.
The mystery is also that they don’t report any error. Yet I verified that since I don’t check if I can write there to create the subfolder, it should crash.
What about a MenuItem that display that user dealing folder data ?
(I had enough to be asked about How to get the data folder of an application recently and I added a MenuItem for that displays a window with icons a click in one of them opens and displays the corresponding folder: the user do not needs to recall what is available and where it is in its hard disk and this avoid to access to a different folder if by hazard a second / thrice /q folder exists / created by error / whatever).
Every once in a while I get these kind of reports also. I’ve never been able to narrow it down, except that my first report came from High Sierra, so I suspect it be something with APFS.
I had an argument with the App Store reviewers over this. Recently they enforced the policy that “user data” must be stored in the Documents folder, even for shoeBox style applications. Which I agree with but…
There is no provision for a Sandboxed application to have access to a subfolder of the users documents folder. So this must be done with a Security-Scoped Bodgemark and asking the user on first launch where to write their data too. The main problem with bodgemarks, is that they’re fragile and when they break you can’t get any meta data about the file they used to link to. So when it goes wrong, you can’t even suggest to the user where to look or the name of the file that they’d chosen. You know for security reasons . The second major issue with using a SSB, is that the application must request and release access (within 90 seconds), every time it wants anything from that folder (including meta data). It made database work impossible (although a workaround is to create the database in the application support folder, leave it there, but hardlink the file into the users selected folder, just make sure that your application always uses the file in the app support folder, not the user location).
So I filed a feature request; which was shot down within days. I tried to argue my points; but it feel on deaf ears.
I had this already in my application and informed the App Store reviewers about it; they don’t care. The policy is…
@Sam Rowlands: why has my shoebox app with data in the ApplicationSupport folder been approved? And the database access with the SSBs also works fine.
Because the rules are inconsistently applied. I’ve been rejected for things; that others are approved for and vice versa. The only assured way is to read the App Store rules before you begin a project and before you submit it. As they can and do change without notice.
In regards to the database via SSB, I seem to recall you use the Valentina engine? Maybe they use create their WAL files in accordance with Apple’s policy. I’ve tried enough times with the built-in SQL classes over the years to notice that it fails. I don’t want to turn off the WAL incase there’s a problem.
However if there was a provision for shoeBox applications to have unhindered access to a dedicated folder within the user’s documents folder; you wouldn’t need to use SSBs either. We recently encountered a complete SSB breakage with one of the 10.14.6 betas; where our application was using SSBs to link to the original images, and they ALL got broken. recreating the file from scratch worked. So I’m now copying in the original files into the package. Takes up more space, but reduces possible points of failure.
@Sam Rowlands : yes, I use Valentina. And an SQLite database as index. Valentina has their own WAL file but there isn’t anything special about the file.
Except that with a SSB, your application is ONLY allowed to access that file. Over time Apple added support for atomic saving of their files (at first a save would fail if it used an atomic function) and support for their CoreData WAL files. The latest SQLite that Xojo uses may have changed; but for many years this was a problem, which affected many developers.
SSBs however still don’t support Apple’s own image caching functions; so you MUST load the entire image into memory before you use it. By default CGImage functions use Lazy loading, so the data is loaded only when it needs to be displayed and a version of that image at that size is cached. Changing the size of the display image, forces the data to be re-loaded.