AppleScript vs PhotoKit

[torarnv]

Is there a list of the remaining issues lack of feature parity between these two mechanisms of exporting photos? I would assume PhotoKit should be the more stable approach, given that it's a supported direct API, compared to controlling Photos.app via AppleScript, but perhaps that's not the case? What would it take to make PhotoKit be a stable (and preferred) export backend for osxphotos ? Thanks!

[RhetTbull]

I'd like to switch to PhotoKit and have a separate project to create a more robust PhotoKit interface but just haven't had time to complete this and test. Several users have said they've had issues with PhotoKit. I think most of these are due to the user not granting permission when the terminal first asks for permission to access Photos. If the user does that, future calls fail. But I've not been able to do enough testing with different configurations to figure this out.

Also, the current PhotoKit code doesn't provide a way to create albums which is a feature many users use. I plan to add this but again, haven't had the time.

[RhetTbull]

I've got it on a separate branch at the moment. See new disclaim.py and where it's called in the cli here:

osxphotos/osxphotos/cli/cli.py

Lines 111 to 113 in 9333cf3

	if pyinstaller() or pyapp():
	# Running from executable, run disclaimer
	disclaim()

[torarnv]

Thanks! Look forward to testing it out!

[RhetTbull]

I've gotten pyapp working to reliably build the executable and using my applecrate tool to package it into a signed macOS installer which I should eventually be able to also handle notarization. This would vastly simplify distribution of osxphotos. Additionally, it has built in update so you can run osxphotos self update to install the latest version. This all works great with one big caveat: due to the way pyapp works the process that actually gets spawned is python3.13 not osxphotos so the dialog box shows python3.13 requesting permission and that's also what shows up in the Privacy & Security settings.

The pyapp built app runs much faster than the pyinstaller version (10x on initial load) and has the nice self-update feature but I don't know if this trade-off is worth it as seeing python3.13 (or whatever the python executable is) in the permission dialog may be confusing. Will need to tinker with this and think about it some more.

I have an idea for how to make the pyinstaller version also self-updating but need to play with that. There's still the issue that the pyinstaller version (which is a self-extracting zip) is very slow...on my 2019 Intel Macbook Air, it takes ~40 seconds to load every time osxphotos is run.

[rajscode]

Could you wrapper everything so the final installed item when it executes calls an Automator script that is a simple launcher (i.e. osxphotos_automator_script.app)? That way you permission the osxphotos_automator_script.app one time with privelege and it doesn't need to itself ever be updated whilst the underlying items can be updated without MacOS having priv pop ups happening again and again. i.e. #1080 (comment)

[RhetTbull]

@rajscode that's a possibility but it would need to know where the python executable and script files are which somewhat complicates installation. I haven't tried this but I think it would also mean that launching the app would require "open osxphotos" as opposed to just typing osxphotos on the command line. I may default back to having the Terminal handle permissions but putting in code in osxphotos to verify it has the permissions and prompting the user what to do if Terminal has granted them.