I'm building an automated wallpaper updater that fetches images from an API and sets them as desktop wallpaper on macOS Tahoe. The automation uses AppleScript combined with database manipulation to ensure wallpaper applies to all spaces.
Current implementation (via Apple Shortcuts):
wallpaper_path="$1"
osascript -e "tell application \"System Events\" to tell every desktop to set picture to
POSIX file \"$wallpaper_path\""
sqlite3 ~/Library/Application\ Support/Dock/desktoppicture.db "UPDATE data SET space=NULL
WHERE space IS NOT NULL;" 2>/dev/null
killall -HUP Dock
Issue
First run: Works perfectly - sets wallpaper on all spaces/desktops, "Show on all spaces" is ON
After first run: "Show on all spaces" automatically toggles OFF in System Settings
Second run onwards: New wallpaper only updates on the active space, inactive spaces show old wallpaper
Expected: "Show on all spaces" should remain ON after programmatic wallpaper changes
Actual: System Settings automatically disables it, breaking subsequent updates
Tested workarounds (all failed):
UPDATE data SET space=NULL to clear per-space entries
Using every desktop instead of current desktop in AppleScript
killall Dock vs killall -HUP Dock vs killall -USR1 Dock
Clearing space_id entries from pictures table
Running DELETE FROM pictures WHERE space_id IS NOT NULL before setting
The database manipulation doesn't prevent macOS from automatically creating per-space entries
and disabling the "Show on all spaces" toggle.
Question: Is there a way to programmatically set wallpaper while preserving the "Show on all
spaces" setting on macOS Tahoe?
Environment:
macOS: Tahoe (latest)
Architecture: Apple Silicon
Use case: Daily automated wallpaper updates via Shortcuts
Automation & Scripting
RSS for tagLearn about scripting languages and automation frameworks available on the platform to automate repetitive tasks.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I'm implementing app intents for my tasks app which supports recurrence rule for tasks. I see that when creating a todo for Reminders via Siri it allows to set a recurrence rule via natural language.
Is there a built in way to receive that recurrence rule as a @Parameter in my AppIntent? If not, is it possible to receive the full user dictated text in the AppIntent:perform method so that I can use some ML model to convert the text to EKRecurrenceRule or similar?
We have an app that controls InDesign Desktop and InDesignServer via hundreds of AppleScripts. Some macOS security updates a while back dictated that we start communicating with other apps via ScriptingBridge. We couldn't afford to convert the hundreds of AppleScripts into direct ScriptingBridge nomenclature, so we opted to keep them as is and instead tell the external apps to:
[app doScript:<the script text> language:InDesignScLgApplescriptLanguage withArguments:nil undoMode:InDesignESUMScriptRequest undoName:@"blah"]
There are a handful of scripts that we did convert to direct ScriptingBridge.
There are times (and under the right circumstances, it's repeatable) when a certain script will have run perfectly dozens of times, and then it will throw errOSAInternalTableOverflow.
We create a new SBApplication for every job (which could be a single instance of Desktop or the multiple instances of Server).
Why is this error happening seemingly randomly? Is there anything we can do to work around or prevent this?
Should there be separate intents to open each supported file type? Or a single intent, and my code sniffs out the format?
When asking Siri to run a shortcut, it will spawn two processes called BackgroundShortcutRunner that do not die when the shortcut is done running. If the Siri window is on screen when I speak to have the shortcut run it does not spawn those two processes. However if the Siri window is not on screen when I speak, the Siri window appears and spawns these two processes. The two processes do not terminate once the shortcut is done running. I now have over 200 these processes since rebooting three days ago to install 26.4.
FB22015192
Topic:
App & System Services
SubTopic:
Automation & Scripting
I've got a streaming Radio app that loads an HLS stream into an AVAudioPlayer. I've set up an Intents extension that notifies SiriKit that my app must handle the INPlayMediaIntent in app, and, I'm able to successfully initiate the stream playing from my phone using the string "Play ".
My intent handler in app looks like this:
completionHandler(INPlayMediaIntentResponse(code: .success, userActivity: nil))
DispatchQueue.main.async {
AudioPlayerService.shared.play()
}
The Audio Player service, in its init, does the following:
try AVAudioSession.sharedInstance().setCategory(
.playback,
mode: .default,
policy: .longFormAudio
)
Additionally, in my Info.plist, I have the AirPlay optimization policy set to Long Form Audio.
Having said all that, when I try to route my app to play "on a given HomePod speaker" ("play on ") the speaker routing instructions are never followed. I've looked and not been able to find where I might be able to instruct my app to follow the correct path here. I was assuming I could not trigger this behavior manually, as I believe I don't really have any control over AirPlay routing.
Is there any guidance for working with SiriKit to do the right thing with regards to audio routing?
Topic:
App & System Services
SubTopic:
Automation & Scripting
Tags:
Audio
AVAudioSession
SiriKit
AirPlay 2
We use AppShortcutsProvider with a parameterized App Shortcut. One of the entities has a dynamic display title (e.g. "Everyone is searching: {keyword}") that comes from UserDefaults and is returned in EntityQuery.suggestedEntities() and entities(for:).
When we change the keyword and call updateAppShortcutParameters(), the Shortcuts app updates and shows the new title.
In Spotlight (Siri Suggestions), the displayed title stays on the old value (e.g. still shows "Everyone is searching: 456" after we switched to "123").
On tap, the shortcut runs with the new value (123), so the execution is correct; only the displayed title in Spotlight is stale.
Question: Is this expected? Is there any API or recommended approach to invalidate or refresh the Spotlight suggestion so the displayed title matches the current parameter, or should we avoid dynamic titles for the first suggestion for better UX?