Fantastic @ayli.voltok , thank you for trying it out (again and again no less).
For future reference for anyone building a macOS app trying to access the contents of a folder like your Obsidian vault, I tried the following work-arounds I tried.
After failing 5 times, my “last resort” turned out to be the solution.
TLDR: Invest an extra hour and make your app downloadable as a .dmg
file from the start instead of taking a well-meant shortcut of using .zip
files.
A detailed run-down
Testing my obvious assumptions
Since it worked on my machine (classic), I used my gf’s computer when she wasn’t working.
I was able to replicate the issue you described.
“I believe markdown files are not indexed on your machine because…”
- AppKit file permissions have changed so much recently that even the smallest deviation of what is know to work results in failure[^1] (False)
- According to this blog post, Dropbox may be interfering[^3] which results in unexpected behavior (False)
- There is a significant difference between my macOS version 13.1 and lower versions. (False)
- On my machine, Obsidian’s markdown files have content-type
net.daringfireball.markdown
but that might not necessarily on other machines[^4]. (False)
- Whatever the reason, the exception/error will not fail silently but throw some information that I can use to fix it.[^5] (False)
Rethinking my known risks
So I had to re-rethink my riskiest assumptions when all these experiments did not change the outcome on your machines.
- If it wasn’t the code…
- If it wasn’t the OS…
- If it wasn’t some known unholy behavior from Dropbox…
- And if it wasn’t vocal about throwing any exceptions…
Finding an unknown risk
- What comes before all of that?
- What am I doing now that is so mundane that I don’t believe it’s a risk?
- What blind spot am I missing?
Then I remembered that little red alert Chrome showed when I first downloaded the .zip
with the message. I had never seen it before.
“This file is not commonly downloaded. Are you sure you want to save it?”
What if…
- macOS is very, very hesitant[^6] to provide file access to apps that were downloaded as
zips
- macOS does so silently?
Having shipped another app of mine named “Unblah” as .dmg
in the past without security hiccups, I figured this could totally be a reason.
I re-used most of that setup[^7] to create Streamline.dmg
in v3.5.3 and it immediately worked on my gf’s machine.
So, yeah. I might have saved myself some time starting at the top. I don’t know.
But whoever reads this in the future: You’re not crazy.
Thanks!
Footnotes and references
[^1]: Revised, refactored and tested several versions 1 and 2
[^2]: Modern AppKit File Permissions by Ben Scheirman
[^3]: “Watch out for Dropbox and other filesystem-bending plugins. Dropbox does some useful but unholy things to Finder and the file system in order to do its job. This might result in strange behavior when trying to access those files & folders.” – Stopped any and all Dropbox daemons on her laptop, compare before/after
[^4]: Commit 3 where I am relying on the file-extension .md
to indicate a markdown file.
[^5]: Added a simple log storage system to keep track, copy/paste errors
[^6]: “The technically sophisticated runtime protections in macOS work at the very core of your Mac to keep your system safe from malware. This starts with state-of-the-art antivirus software built in to block and remove malware. Technologies like XD (execute disable), ASLR (address space layout randomization), and SIP (system integrity protection) make it difficult for malware to do harm, and they ensure that processes with root permission cannot change critical system files.” via macOS Security and Apple Platform Security
[^7]: I use this run.sh that to compile the image.