0

The functionality of my application is as follows:

  • Get highlighted text from any application in macOS.
  • Do some processing on it, including interaction with a server.
  • Show output as a dialog on macOS.

I know that we can read the highlighted text from any application if we use a Mac Automator service. This pretty much works for me with only one caveat. The Automator service can be read and modified by anyone. I would like to distribute this as a paid application. Hence, I would prefer that my application not be modified or even read by anyone. Is it possible to do so? I'm fine with using something other than an Automator if the functionality written above is satisfied.

4
  • Did you read the conditions of use for Automator? As agreed when you instalked it?
    – Solar Mike
    Apr 18, 2021 at 18:03
  • 1
    "I would prefer that my application not be modified or even read by anyone." I can modify non-Automator apps too. Swizzling is fun. :) Apr 18, 2021 at 18:56
  • I would have suggested making your own action, if testing it from Xcode wasn’t such a mess. Any application can include an NSService though, and a regular app could also have double-click and drag-and-drop functionality. Something compiled such as Swift or Objective-C would be the way to go, although pretty much anything can be decompiled if someone has enough motivation.
    – red_menace
    Apr 19, 2021 at 0:09
  • Yes, I think something compiled sounds perfect. While creating an application in Xcode, should I choose "App" or "Automator action" or "Applescript App" as a template? Apr 24, 2021 at 7:24

1 Answer 1

1

Yes, it is definitely possible.

I don't think the logic that it is necessary that a paid application is opaque and static is true. It is entirely possible to sell software while providing access to the source code and letting the customer modify it. Software has been sold that way by large and small companies for decades.

If you really want a technical solution, you can use obfuscation to hide the plain text of scripting languages such as AppleScript. Some languages have an eval-like functionality enabling you to deobfuscate source code and run it directly, whereas for AppleScript you probably want to store it in a seperate object file and run it - or employ OSAKit to be able to run the source directly.

Most programmers in closed-souce, commercial software would probably not employ such "tricks", but rather go for a compilable language such as Swift, Objective-C, C++ or similar to get an executeable that is not immediately "readable" by humans.

Note that all software that can be run can also be reverse-engineered.

14
  • Yes, thanks. I was not going for something that should be sealed in a vault like 100 percent kind of a thing. But, yes, not immediately readable as you said. This brings me to my follow up question. While creating an application in Xcode, should I choose "App" or "Automator action" or "Applescript App" as a template? Apr 24, 2021 at 7:23
  • Depedens on what you want to create? From the description in your question, I would choose App. You want something with its own user interface where running the AppleScript in question is just a minor part of it.
    – jksoegaard
    Apr 24, 2021 at 12:32
  • Okay, so my flow is as follows: I need to receive the highlighted or selected text from the user, then I have my core business logic and then I would like to display some dialogs. What would you suggest in this case? Apr 24, 2021 at 13:52
  • You just described the exact same thing as the description in the question?
    – jksoegaard
    Apr 24, 2021 at 17:59
  • Yes, I think. I guess my question was: how do I receive selected text from "any" application in my own "App"? Is it possible via App? All I know right now is it's feasible in an Automator action where you get an option of receiving any text from any application. Hence, I'd like to know your rationale behind choosing the application. Apr 25, 2021 at 5:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .