0

I'm preparing to release an open source Swift package with two companion MacOS applications: CLI and GUI. I'm expecting the GUI application to be available via the MacOS App Store. I'd also like to get the CLI application notarized.

I'd like the naming to be like this for the applications:

CLI: applicationname
GUI: ApplicationName.app

Is having the same name, other than capitalization and the .app file extension, going to cause trouble with how users access the tools? Will there be some sort of path resolution conflict given the case-insensitive magic Apple does with the filesystem?

Clarification:

ApplicationName.app has executable ApplicationName inside its package-contents -> Contents -> MacOS directory. But that’s all related to the GUI version. I will also release a separate CLI version, not included in the app bundle, called applicationname.

5
  • 1
    Trouble with what? The review process, the installation process, how the user accesses the tool, or something else altogether? – nohillside Jan 27 '20 at 17:27
  • @nohillside edited question to be more specific. Appreciate if you could reopen. – Darrell Root Jan 27 '20 at 17:41
  • Maybe I‘m missing something here but isn‘t this something you can and should test before submitting it to the Store? – nohillside Jan 27 '20 at 22:14
  • @nohillside Of course I’m testing. But I also seek the experience of the community. I prefer the same name but once I release changing the CLI name would be...unfortunate. – Darrell Root Jan 27 '20 at 22:20
  • you will have two binaries in to different places in the file system. What kind of issues do you worry about here? – nohillside Jan 28 '20 at 17:45
2

Nothing of Concern

As long as the application's binary and the command line binary are not stored in the same folder, there are no problems with your naming scheme.

We ship command line tools within the application bundle's name.app/Contents/Tools/ folder. This has worked well for our customers and is acceptable within Apple's Mac App Store.

Command line tools and the PATH

Your customers, or the installer, may want to place the applicationname CLI binary within the PATH, so it can be trivially used from the command line.

By default, the application bundles within the /Applications folder are not in the PATH.

2

Not sure how to understand how there could be a conflict in such cases:

  • foo.app is a directory (usually within /Applications) which contains all the files relevant for the application to run (including any resources, translated texts etc)
  • foo is a binary installed within foo.app which can be called from a shell by specificing the path, symlinking it from /usr/local/bin, or using any other way available in shells

So this are differently named things of different types, there shouldn’t be a conflict as far as macOS is concerned. We can‘t know what the App Store Review will make of it.

3
  • That’s a helpful observation that ApplicationName.app has executable ApplicationName inside its package-contents -> Contents -> MacOS directory. But that’s all related to the GUI version. I will also release a separate CLI version, not included in the app bundle, called applicationname. – Darrell Root Jan 28 '20 at 15:43
  • @DarrellRoot It doesn't change the answer in case you distribute a separate CLI version (even though I'm not sure this will be possible through the Store). But it might help to add such details to the question itself. – nohillside Jan 28 '20 at 16:31
  • correct store does not distribute CLI apps because it is an “app” store (this is documented in apples website). I think notarization of CLI apps is possible. I’ll try to clarify question. – Darrell Root Jan 28 '20 at 17:05

You must log in to answer this question.

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