It’s been a while since I’ve tried anything like this, but the last time I tried, the response I got from the App Store team was “No, this is not allowed”. It is technically possible on the macOS level, it’s also possible on the App Sandbox level, but is prohibited on the App Store level without redesigning your app.
Document based application.
If your application opens each document in its own window, this is a “Document based application” and therefore according to the App Store rules, the user must be presented with a open and save dialog to open or save documents. If you want to re-open documents when the application is relaunched, you need to look at the Window Restoration work I did in the now discontinued Ohanaware App Kit.
Shoebox application.
If your application features one single main window and the user can only work on one document at a time and you auto manage file management for the user, this is a Shoebox application. This gets more complicated with the App Store rules (not macOS or App Sandbox).
- On first launch of the application, the user must be asked where to create the data store.
- That location is then saved to the application preferences as a Security-Scoped Bodgemark.
- Everytime you need to access a file within that location, you request access to the bodgemark. If it’s granted you’ll receive a path to which you can then navigate, in order to open or save a file.
- Once you’ve completed what you need to do, you must close access to that location. You have 90 seconds to do everything you need to do, if you exceed that limit or don’t close access, your application can not only lose access to that location (forever) but can even lose access to all items in your application’s container (which includes preferences).
There are more conditions with security-scoped bodgemarks that I’ve written about several times on this forum. My general advice is to avoid them at all costs, especially since they can and do fail, leaving you without access and any idea as to what the SSB was pointing too.
Security-scoped Bodgemark code was also available in my discontinued Ohanaware App Kit.
There was a much easier solution for Shoebox applications, but this too is now prohibited by App Store rules. You used to be able to keep your shoebox data within the application container and allow the user to “Export” documents that they want to share with others. This was rejected in an app update, Apple said shoebox data must be done via the approved route and my bug fix update never got released.
You will notice that there are apps on the App Store that do not adhere to these “rules”. This is because some developers are more equal than others, and are allowed to flaunt the rules. Apple admitted this in the EPIC v.s. Apple trial. You may also find that these rules have changed, but you won’t know for sure until you submit your application to Apple for approval. There is no way to gain pre-approval before attempting any work.
Deciding if it is worth it
One thing I’ve been telling developers in the last few years is to research a marketing plan before they begin adapting their application for the App Store. I know of far too many developers who’ve wasted time and effort adapting their app for the App Store, only to gain 10s of sales, rather than 100s or 1000s and some of those noticed a drop in sales on their own site, so the App Store not only cost them in development time, but also they lost money as the App Store rates are the highest among payment providers.
Unfortunately I’ve not been able to find a marketing plan for my own apps on the App Store (without sacrificing sales on my own site) and therefore I can’t recommend one for you.
Most of all, good luck.
