How Deploy & Update Apple Shortcuts Folder for Family Members?

Dear Apple Shortcuts Mavens,

N00B question:

BACKGROUND
Working on final stages of development of a Shortcuts-based App intended only for use within our family.

The App is composed of ~20 smallish scripts. All within a single folder on my iMac (and presumably, tucked away somewhere on my iCloud Drive; but I can’t find them).

SEEKING
Seeking a way(s) to deploy the App–and updates–to my family members…that does not require sharing each script independently.

Which leads to this N00B question.

Because the App is intended only for my family, we do not want to use a public Shortcuts repository (e.g., RoutineHub) to host the App (and its parts).

OK…but how?

Is there a way…? A service…? A tool…? A script…? Anything that supports deploying a folder containing Shortcuts scripts only to specifically designated users (i.e., family members)? Also, because the App will evolve with use, I want to be able to change the source code (on my system) and “push” updates automatically to my family members.

While I found Mike Beasley’s UpdateKit API v1.…I also found the website to be quite expert friendly. I re-re-read the site…and don’t grok how UpdateKit API can be used to support a family-only App without resorting to an on-going expense (e.g., Switchblade with a cloud-based MySQL instance running).

  • (Mike: If you read this post: A Gentle Overview for the UpdateKit API N00B would be AWESOME!)

Your ideas? Suggestions? Any comments you’d care to offer as to how to deploy and automatically update a Shortcuts App for a very narrow audience are invited and welcomed!

** Thank you in advance for any assistance you can provide!*

With great appreciation,
Rick

Are the Shortcuts intended to be used on mobile devices, or can you get away with deploying as apps for use on Mac conputers only?

@sylumer,

Thanks for the reply.

The “Family-only App” is intended to operate on any family member’s iPhone, iPad, or Mac.

I’ve not seen anything that allows for what is in effect broadcast updates that isn’t using iCloud URLs for distribution. Looking at Switchblade, the example data load includes an iCloud URL.

The uniqueness and length of iCloud URL carries with it a high level of obscurity, but it is technically an external repo. But it isn’t publicly announcing the availability of your Shortcuts.

The most direct and secure deployment I think would be via Air Drop. You could choose other options like Mail too, but that would be a littl less secure than the I n person transfers and installations that you could also supervise.

@sylumer

Many thanks for the reply and comments.

Reading your note, I suspect—because I’m so new to Shortcuts—I have missed something basic and fundamental and don’t know where to find it.

How & where are the iCloud URLs for Shortcuts found? I searched my Mac and iCloud.com looking for them—without success. While I assume Shortcuts reside somewhere on my iCloud Drive…I cannot find them.

If I can locate the iCloud URLs for each script in my family-only Shortcuts App…is it a simple case to share (or send) a collection of URLs in bulk to my family members for a more-or-less “one-click” update (by each family member on each device)?

@sylumer, your assistance is valued & appreciated!

With many, many thanks!

Rick

As you noted, iCloud URLs are generated when you share them. Every time you share them, an export generates a new download link that differs from the previous one for th same shortcut.

Shortcuts are not executable files you find on your device, not even in iCloud Drive.

If you are happy to use URLS, manually export any updates one by one for each shortcut and paste them into an email.

Now, you may be able to automate that a little using Shortcuts. You used to be able to automate getting the iCloud links…

… but I get an error when I try that in the last couple of OS releases. But youcould maybe still automate the e-mail part with standardised instructions and recipients.

@sylumer, again, many thanks for responding.

Because the number of scripts * the number of family members that will use the scripts * the number of devices per family member * the prospect of near-daily updates to the scripts —> a LARGE number of shares per day…

…I am striving to avoid having to deploy each script in the App one-by-one using Share.

  • Editorial Note: It is AMAZING (not in a good way) that there isn’t a simpler solution for restricted Shortcut App deployment available for use cases like mine.
  • Certainly hope someone has, or will create, a useful solution!

With appreciation,
Rick

Without any detail of why the volumes are such, that simply sounds excessive when you give that description.

Why is the volume so large and what is changing so much - just data or the logic?

I can’t help but think you are taking the wrong approach somehow for a set of shortcuts you want to share with your family if they require that much maintenance on a daily basis.

For example, if it is data that is changing, then storing the data centrally and having a shortcut retrieve and process that data would be a more typical model than updating the locally installed shortcuts and pushing them out constantly.

If the logic were changing, then consider parameterise g it is much as possible and using centralised configuration data to drive the behaviour. I would hope the underlying logic is not radically divergent across a large number of Shortcuts on a daily basis.

@sylumer,

The anticipated volume of updates is attributed to:

  • [Although the App works perfectly on my iPhone…] Anticipation of “Bug Reports” from family members as the App is executed by an increasing number of users on an increasing number of devices; and
  • The initial version of the App is “just to get started.” As the family App gains more users, and use, and affected datasets grow in volume, then I plan to add—and need to deploy—additional functionality.

So: fixes and features.

Yesterday, I tried deploying the App to one family member on one device. WHAT A PAIN!!! By the sacred Elders of the Internet, there MUST be an easier way than sharing individual scripts via SHARE (messages, etc.).

Oh?

Did I mention?

WHAT A PAIN!!!

Hoping you—or someone in the aether—can provide hints as to a simple solution to deploying and updating a multi-script Shortcuts App to a narrow & defined audience (e.g., family members).

I must be missing something I’m afraid. Sharing a link to a shortcut via a message seems quick and easy to me. I am also not sure why their “MUST” be an easier way.

  1. Get iCloud link from Shortcut.
  2. Create a message to the family member asking them to itap the link to get the latest version of the Shortcut they should replace any existing version with.
  3. Paste the link into the message.
  4. Send the message.

As previously notes, you could even use a shortcut to simplify that sort of thing, Use generic text and a selection list, pull in the link from the clipboard, the steps drop to copy the link and run the Shortcut to select recipients and send the message.

Shortcuts, unlike apps, are intended to be editable by the user. There is an expectation of potential change. As a result, there’s no Shortcuts store (just the gallery and the link sharing system) and background automatic updates - no one wants their modified shortcuts overwritten by the author. Thay are after all more of a script than an app. At least that’s my understanding of the situation. Hence existing shortcut update solutions are based more around the interactive package management approach.

In terms of different approaches, what if you had a family shortcut launcher shortcut? That one remains simple and unchanging. It could be used to launch I’m functionality and notify people of updates or availability of new features. For this shortcut, it could be configured by a set of data stored online. Perhaps requiring a local key on the device to get the location? It could check periodically for updates, and prompt the download of additional shortcuts to provide new functionality, or updates to existing shortcuts. It could even have an option to message you diagnostic info about the installed shortcuts. This would also have the advantagea of keeping your shortcuts smaller (much easier to manage changes to smaller shortcuts than megalithic ones - same principle app developers use with libraries and resource files), and you could manage different configuration for different users by using different centralised files for different groups within the family.

@sylumer,

To reaffirm: As a Shortcuts N00B, I thank you for your comments and suggestions.

My “Distribution Test” was based on sharing Shortcuts one at a time.

At the moment, there are 24 Shortcuts in the App.

  • When the App is built out with functionality, I expect that number to double, if not more.

Which meant: repeating the “Share” process 24 times…for 1 user. UGH!

Because of your helpful hints, I’m prototyping with “Get shortcuts from {SOURCE}”. Is this part of your suggestion of a way(s) to simplify distributing shortcuts?

@sylumer, again: Many, many thanks for your assistance! Flummoxed, I am.

To illustrate some earlier points, I’ve put together a little shortcut (or three).

https://www.icloud.com/shortcuts/218a58075b784db382bab0c1e0b65f30

This shortcut will read some configuration information from a file online. I’ve popped the config file in a GitHub gist in this case, which could be a private gist, but I’ve made it a public one as it is not sensitive.

The content is a sample JSON file:

{
	"first_action" :
	{
		"name" : "Say Hello",
		"version" : "2",
		"install_url": "https://www.icloud.com/shortcuts/a1f7d39b7b1a4a8b982478457ce1d8fb"
	},
	"last_action" :
	{
		"name" : "Say Bonjour",
		"version" : "5",
		"install_url": "https://www.icloud.com/shortcuts/5e1ed1c47d2748ac94c942910f6c5b3f"
	}
}

The shortcut only makes use of the names and install URLs, but you could store version numbers too so the shortuct can use that to automatically check for updates.

The shortcut downloads the file and adds an option to a launch list for both of the shortcuts defined in the file. Of course it will only be able to run them once the shortcut is installed.

The shortcut could check for a matching name and could check the current version number against the online configuration details before running, but this is just an example rather than a bespoke solution for you, so I’ll leave it to you to look into that further if you wish.

The list also includes an option at the top to update shortcuts. This is a dumb, update all shortcuts function, but you could once again check version numbers, allow users to choose from a list of available shortcuts to install new ones, etc. But currently, it is dumb and will just prompt the user in turn to install each shortcut by opening up the iCloud installation page where the user can opt to install it. The URLs for the shortcuts are read from the configuration file.

Because you would control the configuration file, you can control what options users see. If you want different users to have different options, you could give them different configuration files to use. If you do that, I would advise storing the configuration URL outside of your main shortcut. To my mind, using an application like Data Jar would be well suited to that, but there are other options (save to file manually, reference another shortcut, use a user entered key that reads a certain section in the configuration file, etc.)

Hopefully, that gives you some insight into how you could centralise information and have shortcuts retrieve it and support the end users in updating and running the various components.

@sylumer,

WOW! What a fabulous example and explanation!

A BIG THANK YOU for taking the time to explain your approach…and prepare such a useful illustration.

Quick question (which, to me, is further evidence I’ve missed something quite fundamental about Shortcuts): Where are the URLs specified for the various Shortcuts? I’ve looked all over my iCloud Drive and cannot find any [URLs…or, Shortcuts for that matter]. Is there a setting in iCloud, or macOS Finder, that will make the Shortcuts & their URLs visible?

  • Many, many, many thanks for your incredible helpfulness.

In case you are curious as to the motivation for my questions: The purpose of the “Family App” is to support a family member’s specialized, delicate, and complex medical condition by recording various treatments/medications, keeping a log (in AirTable, which is awesome), distributing notices–AND WARNINGS (e.g., the patient missed taking an important medication)–to other family members, et cetera.

  • (In the works functionality includes displaying charts, graphs, etc.; which is one reason why there is a relatively large number of scripts.)

Thus, I have to get this right and ensure it is readily useable & updatable among the narrow range of users.

Your generous and valuable assistance is helping me make this possible.

With gratitude,
Rick

It is available on the share sheet. Here’s how you can do it on the Mac, but the same principle applies on i*OS devices too.

@sylumer

That sound you just heard?

Me…hitting my forehead.

Thank you!

@sylumer,

Returning to seeking a way(s) to distribute ~45-50 shortcuts to selected recipients (i.e., family members).

As illustrated in the attached screenshot, I’m starting this quest off with a tiny step…trying to get the URL for each Shortcut contained in a folder.

Without success.

Shortcuts complains that:

“{SHORTCUT_X} is not uploaded to iCloud. Could not get a link to this file because it must already by uploaded to iCloud.”

Which leads to this question: What actions should, must, or can a developer (such as: myself) take to ensure that all Shortcuts are—in fact—uploaded to iCloud.

Stumped, I am.

Any insights? Suggestions? Solutions?

With thanks!
Rick

Remember when I said this earlier in the thread?

Well, now you have experienced it too.

You need to manually collate your list of URLs using the method covered earlier; until such time as Apple fix this problem - but I’ve been waiting quite a long time for that already.

@sylumer,

A BIG THANK YOU for the clarification. Apologies; I did not make the connection between your prior remarks on the apparent bug and the result I posted above.

Your expertise and assistance are much appreciated!

Rick