Hallo,
ich suche für ein kleines Software-Projekt einen macOS-Entwickler.
Gibt es dafür evtl. "Entwickler-Börsen"?
Oder ist hier ein Entwickler im Forum unterwegs, der Interesse hat?
Dann bitte per PN melden...
Vielen Dank!

Ich glaube, es würde helfen, wenn Du minimale Infos zum Projekt angibst. "klein" reicht nicht so ganz aus.
(Bin selbst kein Entwickler, aber...)

stimmt wohl
Es geht um ein kleines Programm, das eine Einstellungsdatei (plist) einer von uns genutzten Anwendung in mehreren Versionen vorhält (wie Benutzerprofile) und es dann erlaubt, diese Anwendung mit dem gewählten Profil zu starten (plist-Datei an die richige Stelle kopieren, Anwendung starten).
Wenn die Haupt-Anwendung beendet wird, soll die aktuell aktive plist-Datei in die Profil-Verwaltung zurückkopiert werden.
So in etwa die Kurzbeschreibung...

Nur mal so als Entwickler gefragt: Wäre es nicht sinnvoller, wenn man in der Anwendung selbst beim Starten das Profil auswählen könnte - oder man es während des Betriebes wechseln könnte?
Einen "Launcher", der irgendwas macht bevor das eigentliche Programm gestartet wird, finde ich eigentlich unschön. Ansonsten könnte man ja das Programm auch mit dem gewünschten Profil starten.

Aber ich vermute, das Programm, um das es geht, ist nicht von Euch.

Wenn es eine überschaubare Anzahl von Profilen ist, ginge das vielleicht auch mit einem Kurzbefehl. Profil an Zielort kopieren und dann das Programm starten. Wenn die Profile nicht verändert werden, während das Programm läuft, könnte man sich den Rückweg ersparen.
Shell Skript geht natürlich auch

Hallo,
ja, Anwendung ist nicht von uns.
Der Entwickler hat zwar eine rudimentäre Profil-Verwaltung gemacht, die passt aber nicht zu unserem Nutzungsszenario. Wir können aus verschiedenen Gründen auch nicht über unterschiedliche macOS-Profile arbeiten. Mit Shell-Skripten usw würde _ich_ es hinbekommen, nicht aber meine Kollegen. Da brauchen wir eine kleine GUI. Wie die dann intern die plist rumkopiert, ist mir eigentlich egal
Wichtig ist vielleicht noch, dass dieser Launcher den Status der Anwendung überwacht, also "läuft", "wurde beendet" usw. Das geht glaube ich mit den Notifications, die das macOS systemweit bereitstellt.

Wenn _Du_ es mit Shell Script hinbekommst, dann kannst du das Shell Script ja entweder in einen Kurzbefehl packen oder es per Platypus in eine App verpacken, ggf. auch mit einer Liste von möglichen Argumenten.
Apple Script geht da auch.

Wenn du ein Shell Script ala "cp; run; cp" machst, dann wird der zweite cp ja erst ausgeführt, wenn run beendet wurde. Käme halt auf einen Versuch an.

Ansonsten würde eine GUI wohl einfach eine SwiftUI sein, in der ein Drop-Down mit den verfügbaren Profilen gefüllt werden könnte (vorher eventuell konfigurieren, wo nahc den Profilen gesucht werden soll). Dann wird der externe Prozess gestartet und überwacht und dann wieder zurück kopiert. Kling erst einmal einfach - aber der Teufel steckt dann im Details (was wenn man den Launcher beendet während die App noch läuft und so weiter).

Man könnte aber die Profile zu dingsda.plist.xylauncher umbenennen und dann einen kleinen Launcher machen, der mit plist.xylancher verknüpft ist. Doppelklick auf das Profil öffnet den Launcher und macht dann sein Ding. Also würde man die App per Doppelklick auf das Profil mit dem entsprechenden Profil starten.

Oh - und da du nach "Entwicklerbörsen" gefragt hast - hier ist ja im Prinzip kein schlechter Anlaufpunkt. Sonst vielleicht noch das osxentwicklerforum oder entsprechende Kanäle auf Social Media Plattformen.

ich habe auch schon ein wenig experimentiert, der Knackpunkt war bei mir dann das Lauschen und Reagieren auf "Anwendung beendet sich".
Das sollte schon einigermaßen stabil funktionieren

Danke für den Tip mit dem osxentwicklerforum, ich werde dort mal nachfragen.
Aber wenn hier jemand Lust auf ein solches Projekt hat: Ich freue mich über Nachrichten!
Ach ja, nur damit keine Missverständnisse auftauchen: Natürlich bezahle ich dafür

BetterTouchTool hat passende Trigger

Bunch (bunchapp.co) ist auch empfehlenswert, um Skripte zu erstellen für das Starten und Beenden einer Arbeitsumgebung aus Programm-Gruppen, Shell-Skripten und Einstellungen. Zudem einfach umzusetzen.

Wird die plist-Datei denn direkt von diesem Programm gelesen oder ist sie Teil des Einstellungssystems ("Preferences") von macOS? Wenn letzteres, ist die Sache etwas komplizierter. Austauschen von Einstellungsdateien führt nämlich nicht zwangsläufig dazu, dass die getauschten Einstellungen sofort gelten würden.

@marm
Vielen Dank, das schaue ich mir mal genauer an. Ich denke aber wirklich, dass wir eine kleine "dezidierte" App brauchen für unsere Profilverwaltung

@Marcel Bresink
Das könnte ein Punkt sein, müsste man dann genauer untersuchen. Ich frage schon mal bei dem Entwickler an, wie genau die Prefs gespeichert werden.

penumbra
Du hast nicht geschrieben, auf welcher macOS-Version das laufen soll und ich weiß nicht, ob Apple da jüngst zusätzlich etwas vernagelt hat, aber probiere doch mal Folgendes (auf Mojave jedenfalls geht das):

Angenommen, Dein Programm heißt Babsi und liegt direkt im Ordner /Programme (sonst Pfade eben entsprechend anpassen), dann erstelle in TextEdit folgende reine Textdatei (nicht RTF oder HTML):
und speichere sie irgendwo als Babsi.command.

Dann musst Du in einem Terminal-Fenster noch folgendes eingeben:
(/Pfad/zu/Babsi.command kannst Du am einfachsten in das Terminal-Fenster eingeben, indem Du die Datei Babsi.command einfach in das Terminal-Fenster ziehst. Leerzeichen davor nicht vergessen!)

Wenn Du jetzt im Finder einen Doppelklick auf Babsi.command machst, müsste Folgendes passieren:

• Ein Terminal-Fenster öffnet sich
• Es ertönt ein Signalton
• Babsi wird gestartet
• [Du kannst jetzt in Babsi tun, was Du willst; am Schluss beendest Du das Programm wie üblich]
• Nach dem Beenden von Babsi ertönt erneut ein Signalton
• Babsi.command beendet sich (entweder steht im Terminal-Fenster [Prozess beendet] oder das Fenster schließt sich automatisch; das hängt von den Terminal-Einstellungen ab)

Wenn das klappt, ist das Problem im Prinzip gelöst.

Die beiden Signaltöne werden durch die beiden printf \\a-Zeilen ausgelöst; diese beiden Zeilen können dann durch das ersetzt werden, was vor und nach dem Lauf von Babsi jeweils geschehen soll.

Wenn die Verwendung von Terminal ausreicht, wunderbar. Wenn nicht, kann ich Dir gerne ein eigenständiges kleines Cocoa-Programm mit schicker GUI draus basteln. In diesem Fall bitte PM.

Ich fand das interessant und habe mir das angeschaut. Erforderlich ist wohl, dass der aufgerufene Befehl "blockierend" ist. Mit dem Befehl open funktioniert es nicht. Wie muss "babsi.command" aufgebaut sein, so dass es blockierend ist und nicht sofort das Skript weiter läuft?

Der Befehl open kommt aus gutem Grund in meinem Skript doch gar nicht vor?

Du musst das Skript – bis auf den anzupassenden Namen des Programmpfades – schon exakt so kopieren wie von mir vorgegeben. Dann wird blockiert, das ist doch der ganze Gag daran.

Wenn du „open“ verwendest, dann wird ein Tool „open“ gestartet, welches Babsi startet und sich dann selbst beendet. Wenn du es so machst, wie Weia es geschrieben hat (also ohne open) sollte das gehen. Das Shell Script wartet, bis der Prozess Babsi beendet ist, bevor der nächste Befehl ausgeführt wird.
Ist im Prinzip das, was ich in einem früheren Post schon meinte.

"/Applications/Babsi.app/Contents/MacOS/Babsi" kann ein beliebiges Shell-Skript sein?

Nein, das ist überhaupt kein Shellskript! Das ist das, was Du eingeben musst, wenn Du die App Babsi, die in /Programme liegt, blockierend starten willst.

Wenn Du z.B. TextEdit so würdest starten wollen, müsstest Du /Applications/TextEdit.app/Contents/MacOS/TextEdit eingeben.

Die Datei TextEdit am Ende dieses Pfades ist die wirkliche Programmdatei. TextEdit.app ist ja in Wirklichkeit nur ein Ordner, der das Programm und alle möglichen Ressourcen dazu enthält, aber im Finder als Datei dargestellt wird.

Das war mein erster Test mit der Fehlermeldung: line 5: /System/Applications/TextEdit.app: is a directory
Daher hatte ich dann mit open probiert.
Mit "/System/Applications/TextEdit.app/Contents/MacOS/TextEdit" blockiert das Skript zwar, aber das Beenden von TextEdit setzt den Prozess nicht fort.

Jetzt klappt es doch beim zweiten Anlauf ...
Danke für den Tipp.