Big Sur and access to the Documents folder

Targets macOS
1

Testing my app under Big Sur. How can I best detect that the user declined to permit access to their Documents folder, and exit gracefully rather than crashing?

2

I use a bit of code like this:



//test that we can write to all the places we need to write
//which are:
//documents
//applicationdata
//temporary

static saidso as boolean

dim ts as textoutputstream
dim tsi as textinputstream
dim failcreate as boolean
dim failchange as boolean

dim t as folderitem
dim d as new date
dim readback as string



if not app.specialfolderdocuments.IsWriteable then
  msgbox "No Permissions to write to " + app.specialfolderdocuments.nativepath
  failcreate = true
end if

//test documents
t = app.specialfolderdocuments.child("testwrite.png")
if t.exists then
  try
    t.delete
  catch
  end try
end if
try
  app.specialfolderdocuments.child("testwrite.png").saveaspicture somepictureinmyproject,150
catch
  failcreate = true
end try

if t.exists then
  try
    t.delete
  catch
  end try
end if



//test applicationdata
t = specialfolder.applicationdata.child("testwrite.png")
if t.exists then
  try
     t.delete
  catch
  end try
end if
try
  specialfolder.applicationdata.child("testwrite.png").saveaspicture somepictureinmyproject,150
catch
  failcreate = true
end try

if t.exists then
  try
    t.delete
  catch
  end try
end if



if failcreate or failchange and not saidso then
  saidso = true
  if chooseyn("Unable to create/amend some data files. This may be due to a virus checker, or permissions. Click Yes to view our FAQ") then
    ShowURL "https://mypageallaboutit.html"
  end if
end if


exception
3

Yeah, in fact at the point in question it might or might not be Documents, so it seems that the rubber hits the road when I try to open a file (textstream), then I get an exception if the user refuses permission.

But the whole thing seems odd. Testing appears to show that if none of my folder/files structure exists in Documents, I can create it without the user being bothered. But if it exists already, then is when the user is questioned.

Makes no sense to me.

4

Under Big Sur, the common behavior is to Kernel Panic and reboot the machine when something is wrong.

5

When I complained about the App Sandbox (all those years ago) and filed a feature request for Shoebox Style apps (which was rejected). A Apple engineer explained to me that rule of thumb is “Do not save into the Users space without the Users say so.”

What Apple want you (as a 3rd Party Developer) to do, is to produce a save file dialog on the first app launch, ask the User where they want to save their data. Then store the path, and use that location as it is considered the User has provided consent for that location.

When I tried to argue that none of Apple’s own apps do this, I got no response. When Apple introduced these 'Privacy" warnings, they added private exceptions for their own apps, as a way of admission that what they want us (3rd Party Developers) to do is NOT user friendly. While you can use these “Private” entitlements in your own apps, they will be rejected from the App Store and may be rejected from the Notarization service in the future.

6

But if it exists already, then is when the user is questioned.
Makes no sense to me.

Yeah: Ive seen that too. One several occiasions Ive had to ask people to delete or rename what exists and start over. No problem after that.

ask the User where they want to save their data. Then store the path,

Are these the ‘security scoped bodgemarks’ I keep hearing about?

7

Only if you use the App Sandbox. Which I would strongly advise against using such a thing. I recommended using hardlinks for a period of time, until Apple closed off that “Security Loophole”.

If not, then you can simply store an URL, nativePath, symlink or alias to the location.

8

Oddly, my app does store a basic path to where it keeps stuff. The idea, originally, was that the user could keep the app and its data on a stick and just move it around if they felt like it. Just unplug from one machine, plug into another, and carry on working. If they put the mac/Win/Lin apps all on the same stick, they could plug into any damn machine and carry on working.

However, then Apple got all starchy about such an approach and insisted data had to be in the user’s Documents folder. So now I check where the executable is in /Applications, or c:\Program Files\ or /usr/local/bin and use Documents if so. Otherwise the original approach.

But doing much of anything these days seems to risk eliciting a fit of the vapours from the OS. We’ll all be Linux users long-term, mark my words.

1 Like
9

I use a built version of the IDE Communicator App for building my Xojo apps. Crapolina and higher think that loading files from next to the app ain’t safe. I had to give the app some simple preferences so save the location of the text file which is used for building.

1 Like
10

Funny thing,

I was just coding an app and on my New Big Sur and MacMini m1, it seems that I cannot access anymore the database I save it in Documents as Debug mode, if I compile the app and then run it, it will first time ask me to allow access to documents and it works without any issues but not if I run the app in debug more anymore , XOJO 2021R2.1

Did anybody else got same issue ? that is new for me and I don’t remember having those issues until now. something changed in 2021R2.1 ?

Thanks

11

Just with a quick update, apparently I had to go to Security & Privacy and allow full disk access to the Debug app in order to read the data, which is weird as it was working until now .

12

I’m seeing weird things with debug apps, too. I have 2 apps I run in the IDE ; one of them always gets access to the Photos folder, and for the other one, the OS asks me every single time. I can’t see why they are treated differently.

13

Sadly Apple’s TCC subsystem is a mystery in how it behaves or doesn’t behave. Just when I think I have a solid understanding of it, my own apps start not working as expected.

Ideally your application should always be code signed with a Apple issued certificate. Apple use these credentials to aid with identifying your application. If you use App Wrapper 4, check out the scripting capability so that even debug builds can be code signed correctly.

14

The IDE should be applying an ad-hoc code signature to your app when it is built or run. If you’d like an easy way to check the signature on an app from the Finder, check out Whats Your Sign from Objective-See.

15

The Ad-Hoc signature isn’t the same as an Apple issued certificate, it is lacking in meta data and cannot be used for an increasing amount of Apple API.

I’d imagine that shortly you’ll be required to have an Apple developer subscription just to create apps, let alone distribute them. There’s also rumors that next year, the fee may increase.

1 Like
16

well apparently I do have all there and the app goes nuts, I had to create an sign script and to sign the app even on debugging to avoid thing thing. While it does not happen on Catalina , I see it more often on Big Sur and no idea if related but more on m1 as well.