Big ideas - Building standalone apps, a Keyboard Maestro store

Questions & Suggestions
1

I’ve been using Keyboard Maestro for years, and love it. I’ve been able to do so much with it and I would love to be able to distribute the macros in an App store. With that in mind, here are some ways that could happen.

Distribute on the Apple App store
Keyboard Maestro would export to an Xcode project. Apple developers would be left to their own devices to do the remaining work to meet Apple’s requirements on the app store.

Distribute on Keyboard Maestro App and macro store
Developers could publish to a Keyboard Maestro store where their work could be sold as standalone apps or Keyboard Maestro macros to anyone who knows about Keyboard Maestro.

Best of both worlds
Developers can publish standalone apps from Keyboard Maestro. These apps include a built-in app store as part of the UI framework, allowing users to discover and purchase other Keyboard Maestro macros that can run inside the same framework immediately, possibly even adding logic for users to logically link multiple macros together.

2

Interesting ideas. One that I would add to the mix is to provide a KM Run-Time version, which could only execute macros, not build them.

This would allow small companies (or even large ones) to deploy KM solutions throughout their company. Most Mac users are not developers, even KM-style developers. They just want to automate their stuff.

So, combined with your idea of a KM Macro store (which could include free macros), many users might be willing to buy the run-time version who would not buy the developer version.

3

The run time idea has lots of merit…

… I could build macros and ship them to people in my company, instead of nagging them about how they could buy Keyboard Maestro and build them themselves…

… I find myself ranting about Automation to little effect when I could just ship some. And then the recipients might be inspired to buy Keyboard Maestro and build some more themselves.

My recent “Setup IBM Notes just the way I like it” macro would be a good example.

4

Let’s not forget though, that making a Run-Time version and a macro store will add significantly to tech support issues.

1 Like
5

Of course you can already turn KM inside out, and distribute macros as Javascript code to systems which have KM installed.

(Each macro becomes an array of JS objects,

[{
    "MacroActionType": "SpeakText",
    "Rate": "Default",
    "IsDisclosed": true,
    "TimeOutAbortsMacro": true,
    "Text": "This is a simple example",
    "IsActive": true
}, {
    "MacroActionType": "PlaySound",
    "Volume": 74,
    "IsDisclosed": true,
    "TimeOutAbortsMacro": true,
    "IsActive": true,
    "Path": "/System/Library/Sounds/Glass.aiff",
    "DeviceID": "SOUNDEFFECTS"
}]

executed by some variant of a function like this:

// jsoDoScript :: Object (Dict | Array) -> IO ()
const jsoDoScript = jso => {
    const strPath = tempFilePath('tmp.plist');
    return (
        Application('Keyboard Maestro Engine')
        .doScript((
            $(Array.isArray(jso) ? jso : [jso])
            .writeToFileAtomically(
                $(strPath)
                .stringByStandardizingPath,
                true
            ),
            readFile(strPath)
        )),
        true
    );
};

(Enhancement Wish -- Copy KM Action as plist, JSON, XML)

6

It will add some, but I'm not sure how much. If good documentation is provided in the KM Wiki, then I don't see much of an impact on support, which could easily be absorbed here in the KM Forum.

7

Apple specifically disallow "templated applications" and are cracking down on this - they would never allow such applications.

Yes, it would be possible to create a run-only version of Keyboard Maestro. But I have no plans to do it. For it to make any sense, the price of the run-only app would have to be significantly lower, with significantly higher numbers of users then required, leading to massively larger support costs, which are already a significant percentage of the development costs of Keyboard Maestro.

As well as that, the clients who would want large volumes of run-only versions of Keyboard Maestro generally have their own IT department that can developer their own custom solutions.

Further, such a devision would detract from development efforts focussed on Keyboard Maestro, and I much prefer to spend my energies making Keyboard Maestro better for the customers that use it rather than making it appropriate as some sort of distribution system.

As an aside, Keyboard Maestro has been (in fact still is) distributed as a custom run-only macro system for a specific purpose utility by a third party. It is still based on an old version of Keyboard Maestro because it never made sense to expend the effort to continue with that development, and I doubt any other "run only" version would fare any better.

As far as selling macros go, I know there is at least one company selling a macro set complete with a licensing system.

If the macros are not worth $36 (or less in volume) to the end user, then they aren't really worth doing whether it is in a run only Keyboard Maestro or not. Since you can currently just install Keyboard Maestro and then install a set of macros and the user never has to launch Keyboard Maestro themselves, the system is already available - the only thing difference is a cheaper version of Keyboard Maestro which is definitely not a path I intend to head down.

I have tried various variants and cut down versions of Keyboard Maestro before, and the results have been lots of effort producing no appreciable gain for anyone.

8

Well, I suppose as the volume of sales goes up, then support costs would also go up. But then I would think that would be a good thing, as long as the increased revenue exceeded the additional support cost.

You are obviously seeing some factor that I do not to state that it would result in "leading to massively larger support costs". "Massively" implies extreme, and I don't get that, especially if your new machine learning assistant evolves well.

I also think that if the user of a run-time version has questions/issues about a macro, then the macro author would be responsible for the initial response. In concept, the running of a run-time version seems much, much less complex than, say, "Dictionaries", or "Local/Instance Variables", which are, of course, only of concern to the macro developer.

Having said all that, if it still seems like an unacceptable about of support would be required, then you could consider selling the run-time ver as part of a "Business Version", which would include N development licenses, and M run-time licenses, with the requirement that the business admin provide the direct support to the run-time users. Then, only if the admin can't resolve an issue, the admin could contact KM for support.

As we know, the real money in the software business is achieving high volume. There was time when all software support was free. But today many (most?) businesses only provide online support for free, requiring payment for email/phone support.

Peter, don't misunderstand me. I'm not in any way trying to tell you how to run your business. I'm only offering some ideas which may, or may not, be reasonable or practical. That, of course, is up to you to decide.

Good luck in whatever you decide. I know we all want to see Keyboard Maestro and Stairways Software continue to grow, improve, and prosper. Or, as Spock would say: "Live long and prosper." :wink:

1 Like
9

@peternlewis do you have an enterprise-wide licensing / distribution scheme?

Of the 300,000+ employees here a good proportion are getting Macs or already have them. I really think a lot of them could benefit. I’ve no idea how internally to kick off the discussion. But before I even try it I’d like to understand if there is such a scheme.

Then we get into the logistics of distribution - of the product and also any of company-wide macros.

10

Not specifically for that kind of volume. There are volume discounts for 5-200 users. For any quantity above a few hundred, it could be negotiated as necessary.

1 Like
11

I was not aware of that. That approach could be a good alternative to having a run-time version.

12

Thanks @peternlewis.

I’ll try and figure out who in the company can pursue such a negotiation. I’m not in Finance / Purchasing - so it’s definitely not me.