Trypa - A New Automation app for MacOS

Hi, EDIT - NOW released.

I have been working on this for a bit, going to put on the app store.

Key Features:

  • Simple to use, set up your first trigger in a few seconds

  • Powerful Environmental, Hardware and System watchers including, Time and Date, Location, AC Power, Thermal Stress, USB devices, Airplay, Displays, Network Devices, Wifi Network, Audio Devices and more.

  • Pass Trigger input into to shortcuts

  • Can save external XML files, so you can access trigger details with other apps

  • App intents to add Trypa powers into your other Shortcuts

  • Intel and Apple Silicon native

  • Sandboxed with a hardened runtime

Its a closed beta, but let me know if you want to test.



Hey! I wouldn’t mind trying it out!

1 Like

Sounds exciting. I would love to try

1 Like

It is intriguing. And although I’m not quite sure what I would use it for, I’d like to give it a go. Thanks.

1 Like

more than happy to try it for you

1 Like

I use it to detect when I get to work and drop the volume down and connect the correct wifi network and turn do not disturb off.

One good idea is to get an audible warning when the system heats up and is getting stressed, very useful on Intel machines.

Also announce if your internet connection goes down, or the laptop power is unplugged. (Give a nasty shock to the kids using your MacBook charger on their iPads etc).

You could drop the screen brightness and volume down and when the sun goes down.

You could force a specific app to stay open, by re-launching it if it’s ever not running.

If running a headless server, get an sms (using shortcuts) when a specific disk is unmounted or the boot drive space is low.

It can detect strings inside xml files, so you can trigger an action from any other scriptable tool.

going to put on the app store

I strongly recommend you work on your branding first: “always watching”, “triggers alarming”, and all-seeing eye screams omnidirectional state surveillance and invasive spyware, not “my friendly (and safe!) Personal Assistant for handling my repetitive tasks for me”.

Other than that, couple questions:

  1. What does your app offer users that already-established apps—Shortcuts, Keyboard Maestro, Script Kit, and so on—do not? What’s your USP? (If you haven’t thought about this: I’m guessing you created it to scratch some personal itch, so start your story there.)

  2. If you’re planning to distribute through Apple’s AppStore, have you done a build with sandboxing enabled to check everything still works correctly? I’m guessing you’ll have to knock quite a few holes in your app’s sandbox to hook into lots of different services, which is the sort of thing AppStore review is most likely to wig out on. Do you have an alternate plan for distributing outside of AppStore if Apple doesn’t accept it?



Yes I get what your mean other people have said its a bit scary, the branding had been updated and the always watching tagline has been removed. That was an older screenshot. I do think I can still make it a bit more approachable so thank you.

The USP is really simplicity, it’s designed to be very easy and (hopefully) fun to set up tiggers without any scripting knowledge. It works with those other tools, so it’s really a detector of specific states. Think of it as a very friendly version of Keyboard Maestro’s triggers section, but the actions you can trigger are basic, and rely on other tools like AppleScript, Shortcuts or Keyboard Maestro, for anything other than simple alerts.

Most other tools are also tough to get your head around (I realise people on this site are probably not in that place), ControlPlane, Script Kit, Keyboard Maestro etc can be quite intimidating, some people are afraid of code, scripting languages, debugging etc. You should be able to fire up Trypa, click a few icons and have a trigger set up within a few seconds.

The triggers, will also be quite unique, while it already has a few, I am planning on adding more triggers that the other tools don’t have.

Shortcuts doesn’t have an automated way to trigger shortcuts based on specific conditions, so it’s really a partner app, not a competitor.

The other USP is that it will be on the App Store, something I think the other tools would struggle to do.

The App Store point is good, it is currently sandboxed and notarised and working fine.
I don’t believe I will have major issues, one point is it is mostly reading states, not writing to them, but if you want to do more you can trigger other tools like a Shortcut from within the sandbox.

But you never know what the review process will hold. If you were me, what would your alternate distribution plan be?

[quote=“Gorgeousity, post:8, topic:15080”]
The USP is really simplicity, it’s designed to be very easy and (hopefully) fun to set up tiggers


That’s a solid answer: a good core to your product pitch. “[A]mazing simplicity”, if you’re feeling ambitious—and why not? iPod conquered its own market by leading with the same. Less is more.

I wouldn’t use the word “triggers” (or tiggers). “Actions” is how Siri Shortcuts describes the behaviors to perform, so find a word like “Events” which really complements that[1].

I do like the surrounding framing: “When X then Y.” That works well.

I would advise radically simplifying the Actions your app can perform. That side of your app bring nothing new or novel; all it does is duplicate (weakly) what Shortcuts already supplies as standard. Instead, have your app run just Siri Shortcuts: strip out that entire list of custom behaviors (System Notification, Speak, etc) and just list the names of workflows already defined in Let the user put a tick mark besides one (or more) of those names so that, when the event fires, your app runs that shortcut.


The bit that you do want to put all your energy is your list of supported events, and the UI for configuring trigger conditions. Your current list of events is painfully sparse, very focused on “nerd features” and lacking in “general lifestyle” events. The motivation for adding trigger types should not be “Is it trivial for me to implement?” so much as “How much do my target audience need and want it?” Else you end up with lots of low-cost but low-value clutter no-one really needs while the high-value features they do want is swamped or left out.

Focus on this event detection and notification UI+UX you’ve built, because that’s a step in automating your automation that’s a PITA for most users. Incoherent, inconsistent; if apps support it at all, they rarely do so the same way. Hide all that mess, pain, and complexity behind your single clean unified UI, and you’re rolling. track change notifications are an absolute no-brainer; and trivially easy to hook:

    let dnc = DistributedNotificationCenter.default()
    dnc.addObserver(self, selector:#selector(AppDelegate.myTrackChangedMethod),
                     name:NSNotification.Name(rawValue:""), object:nil)

Sniff to see what other DNs are flying around; most will be crap (DN is criminally undervalued and underused) but there might be the odd good one worth adding while you’re on that. Me, I’d implement the track change detector widget so its code is trivially reusable for detecting other DNs. Put your Music track change widget in “Lifestyle” catefory (née Environment) and put a generic reusable version with a text field for typing the notification ID under your “macOS” (née System”) category so techies can play around with it.

Calendar alarms should be another essential “Lifestyle” event; and even a single social media event (e.g. Facebook or Instagram post notification) will prove to your audience that your app can expand to those too. Don’t spend long on this (you wanna get to market) but look around for a day to see what low-hanging fruit there is, and grab a couple tasty bit to put in v1.0.

If your app finds its market, I’m sure your market will tell you which to add for v2.


It might be worth adding an “AppleScript[ed] Event” trigger, as a generic catchall for those willing to do the work to set it up. Define a very simple AppleScript dictionary with a single command, do event, that takes an arbitrary string. Define an “AppleScript” event widget that has a text field for entering a matching string. That allows an external AppleScript to trigger an event in your app. Technically an AppleScript can already send a run shortcut "NAME" command directly to Shortcuts, but that tightly couples the two (the script has to know a workflow’s name, and a workflow with that exact name has to exist).

Or skip past AppleScript and install a little shell command, like macOS’s notifyutil except it messages your app, which all scripting languages can use.

Adding this hook provides a low-cost route for both you and users to define new event behaviors where there isn’t an existing macOS API (e.g. Distributed Notifications) to hook into. You could write a full-blown Apple Mail extension which listens for incoming/outgoing emails and sends your app the notifications; but is that worth the effort for something already doable by “Run AppleScript” Mail Rule. This same approach can be equally applied to other email apps that have similar Mail Rule capabilities (as well as other apps and scripts in general).

With luck you can automate away the tedium and specialized knowledge of installing and configuring these “event scripts” too, so the user only has to click an “Enable This Event” button in your GUI, and that triggers’s ready to use. As you say, simplicity’s your goal. If you can achieve zero-config “don’t-make-me-think” UX, you’re there.


One more thing: it is entirely possible that Apple will finally pull its finger out at WWDC23 and add the same trigger support directly into Shortcuts. (iOS Shortcuts already has this; there’s no good reason Mac Shortcuts doesn’t except Apple are complacent and slooooow.) Or, if not this year, then next. So it’s possible your implementation may have a fairly short lifetime.[3]


[1] My first thought was the obvious “Reactions”, but, oops, that just replaced my mental image of a gun with a bout of the flu, so nope. Honestly, I wouldn’t over-clever it: “Events” might well be the best name for it. Annoyingly, iOS shortcuts label this “Automation”, which is blindingly stupid: ALL of it is automation; what distinguishes is whether it’s proactive (the user manually, explicitly, presses Run) or reactive (automatically in response to something of interest happening in the system).

[2] You might have to keep “special” options, like “Pause this trigger” and other development/troubleshooting features, in your UI; Shortcuts is rather monolithic and lacks fine-grained hooks into its interaction as it runs, so users will probably need a way to temporarily pause/cancel events being dispatched to actions.

[3] Honestly, you could do worse than tap @AriX and co, on offchance they might take it off you. Easy win for both parties if they haven’t begun internal development, assuming vast Apple bureacracy and inertia is navigable.

1 Like

Can I get an invite to test it?

1 Like

Keyboard Maestro provides sufficient AppleScript support that you could have a Keyboard Maestro action that allows the user to select a macro by macro group/macro name and then stores the UID so you can execute the macro directly.

If you want to do that and need any help with the details, feel from to contact me.

Also, if you want to keep working on this, and want to be able to justify spending time, give it a reasonable price (at least $10).

1 Like

I’d love to give it a try :smile:


Thanks Peter, I need to move quickly but will definitely reach out if needed.

1 Like

I’d really like to try this app. I registered here solely for this reason. :wink: Please?

Can I access testing?

One of the shots looks awfully close to Shortcuts. I think I’d want to make it look a little different from that. No objection to an array of tap targets, mind.