Mac und Windows unter einen Hut bringen?

[Winniefried]

Stehe vor folgendem Problem. Derzeit nutze ich noch hauptsächlich Windows, habe allerdings zeitgleich ein MacBook um ein paar kleine Apps für iPhone (nur für mich privat) zu schreiben. Da ich beruflich viel im Windows Umfeld unterwegs bin (bin "Turn-Schuh-Admin") und bisher auch privat Windows genutzt habe fällt der komplette Umstieg natürlich schwer. Daher werde ich wohl noch eine weile Windows als OS nutzen.
Für mein Hobby würde ich mir gern ein paar kleine Tools schreiben, allerdings kommt jetzt das Problem.
Irgendwann will ich ja mal komplett auf Mac umsatteln. Allerdings wird auf der Arbeit weiterhin mit Windows gearbeitet. Daher habe ich überlegt mich mit C++ zu beschäftigen. Damit könnte ich am Ende den Quellcode unter Mac einfach kompilieren und da weiter nutzen.
Zusätzlich zu Swift kann ich ein wenig C#.
Was würdet ihr mir raten? C++ zu nehmen für die Tools? Oder bis zum kompletten Umstieg erst einmal mit C# weiterzumachen? Und wenn irgendwann der Umzug komplett vollzogen ist, die Tools mit Swift nochmals neu schreiben?
Gibt es viele Tools, welche auf dem Mac laufen, wo mit C++ geschrieben wurden? Oder wird da eher Swift oder Object-C für Mac Anwendungen genommen. Aber die laufen dann nicht unter Windows.
Da ich zurzeit beruflich viel mit Windows zu tun habe und daher auch Windows noch Privat nutze, wäre die Überlegung mit C# da zu arbeiten, doch was ist bei einem Umstieg auf den Mac?
Gibt es jemanden der evtl. in der gleichen Situation ist und mir einen Rat geben kann.

 

[madmax2010]

Gibt es viele Tools, welche auf dem Mac laufen, wo mit C++ geschrieben wurden?

5 Stellig viele

Kommt halt immer darauf an was du brauchst.
Ueberleg dir welche Libraries du brauchst, welche UI Toolkits du nutzen willst. Clang und GCC kannst du ueberall nutzen

 

[Mickey Mouse]

viel wichtiger als die "Kern" Sprache ist doch, welches GUI Toolkit du verwenden möchtest?!?
und wenn du da keins benötigst, dann kannste die "Tools" auch schnell in Python schreiben (wobei es dazu auch wieder GUI Kits gibt...)

 

[uburoi]

Ich nutze aus ähnlichen Überlegungen heraus seit Längerem Xojo. Das ist ein kommerzieller Basic-Dialekt (mein Chef spendiert die Lizenz) mit eigener Entwicklungsumgebung. Die Sprache hat ihre Limitierungen, aber den Vorteil, dass man aus demselben Quellcode native Windows- und Mac-Programme kompilieren kann. Da würde ich zumindest mal einen Blick riskieren, ob das etwas für dich sein könnte.

Gruß Jens

 

[gymfan]

Tools bedeutet wohl auch GUI, oder nicht?

Persönlich würde ich nich da eher mit C# und einem passen UI Toolkit beschäftigen. Egal, ob man da MS vertraut und schon auf MAUI setzt (das kann man sogar meist als Singe-EXE so verpacken, dass es auch auf Rechnern läuft, auf denen .NET 6 noch nicht installiert ist), oder Blazor oder einen der QT-Wrapper.

C++ ohne zusätzliche Toolkits wird Dich an vielen Stellen vermutlich auch nicht dazu bringen, dass etwas systemnahere Tools ohne Anpassung unter Windows und MacOS laufen.

 

[KitKat::new()]

Was würdet ihr mir raten? C++ zu nehmen für die Tools?

Wenn andere Lösungsvorschläge aus dem Thread nicht zufrieden stellen und dir nichts anderes als C++ einfällt, erwäge bitte vorher Rust:

• sehr viel einfacher und robuster als C++
• kleineres ökosystem

 

[Winniefried]

Danke für Eure Ratschläge, ja es soll eine GUI enthalten sein.

Irgendwie habe ich "Angst", entwickele ich ein Programm mit C# unter Windows und ich switche später komplett auf Mac um, dass ich alles nochmal neu schreiben muss. Da ich leider nicht so recht abschätzen kann wann dies der Fall sein soll ist es gerade eine Zwickmühle in der ich mich befinde.

@KitKat::new()
Rust hab ich mir schon angeschaut, doch bin ich mir nicht schlüssig mich noch in einer weitere Sprache ein zuarbeiten. Und wie schaut es da mit GUI Frameworks aus?

 

[SheepShaver]

Rust und UI wird dich nicht glücklich machen.

React Native ist die Antwort
https://microsoft.github.io/react-native-windows/

 

[AW4]

Müsste/Wollte ich heute, in einem kommerziellen oder privaten Umfeld, eine flexible Cross-Plattform-GUI-Applikation, im Sinne von "One Fits all", von Grund auf neu konzipieren, die alle großen Plattformen (Windows, Linux, macOS, iOS, Android) abdeckt und nicht im Browser läuft/laufen soll, kämen nach meinem aktuellen Kenntnisstand für mich persönlich folgendes in Frage:

• C++ mit QT und QT-Creator (Kosten Kommerziell: ~4000$ p. a.; Kosten Privat: 0$*)
• Delphi oder C++ mit FMX (Kosten Kommerziell: Mit Linux (RAD Studio Enterprise) 1. Jahr ~3400€, alle weiteren ~1000€ p. a.; Ohne Linux (RAD Studio Professional) 1. Jahr ~1530€, alle weiteren ~440€ p. a.; Kosten Privat: 0$**)

*: LGPLv3 und GPLv2/v3
**: Bis zu einem Jahresumsatz von 5000$.

Beides erlaubt einem (nahezu, Ausnahmen gibts immer) den absolut selben Code, so lange keine plattformabhängigen Bibliotheken genutzt werden/werden müssen, nativ für alle Plattformen zu kompilieren und liefern auch gleich von vorn herein mächtige, integrierte WYSIWYG-GUI-Designer fürs entspannte und zeitsparende Entwickeln mit.

Das genannte React Native ist auch eine Option, hat mit Facebook, trotz seinem relativ jungen alter, potentiell einen starken Stand, aber den Nachteil, dass man sich zusätzlich noch mit Web-Design auseinandersetzen und man seine Tools für die Entwicklung erst mal zusammensuchen muss.
Ich sag nicht, dass das schlecht, schlimm oder unüberwindbar ist, meinen persönlichen Präferenzen schmeckt das nur nicht 100%ig.
Auch wenn mir Full-Stack-/Web-Development schon hin und wieder Spaß macht, bin ich eher in der Welt der Hochsprachen zu Hause.

Java wäre theoretisch auch eine Option, da konnte ich aber zum einen keine verlässlichen Informationen bzgl. der aktuellen, einfachen Machbarkeit und den Kosten für die mobilen Plattformen herausfinden und zum anderen macht mich Java nicht mehr wirklich an...


Zusätzlich gibt es natürlich noch einige andere Optionen, aber entweder entziehen diese sich meinem aktuellen Kenntnisstand (Hinweise sind willkommen!) oder die Entwicklung von Cross-Plattform-GUI-Apps ist damit, in welcher Hinsicht auch immer, ein Flickwerk mit fraglicher Zukunft oder noch unausgereift.

 

[ZuseZ3]

@Winniefried https://www.areweguiyet.com/#ecosystem
@SheepShaver Würde ich jetzt nicht unbedingt sagen.
Hatte letztens ein Bewerbungsgespräch wo sie sogar komplett Rust genutzt hatten, Front und Backend.
Lief mittels wasm auch überall. Dazu haben sie noch 8 Wrapper drübergelegt, damit die Rust API auch von allen möglichen Sprachen aus direkt nutzbar ist.
Mehr kann ich dazu aber auch nicht sagen, mich hat der web Teil weniger interessiert, ich habe mit denen wegen HPC Zeug gesprochen.

 

[m.c.ignaz]

Ich bin C++ Entwickler und habe bisher fuer Windows, Mac und Linux entwickelt, wobei es fuer Linux keine GUI-Apps sind/waren. Dafuer waren die fuer Windows und Mac cross Plattform.

Hier waere, was ich mir persoenlich angucken wuerde:

• C++ in Verbindung mit Qt
• C++ als Unterbau, und so Node/React/Electron-Gerumpel fuer die UI
• C++ als Unterbau und https://sixtyfps.io/ fuer die UI
• Rust als Unterbau und https://sixtyfps.io/ fuer die UI
• Python fuer alles (bin da aber nicht zu sehr bewandert was gute UI Kits betrifft)

Kleine Anmerkung zu https://sixtyfps.io/: Das sind ehemalige Qt-Entwickler, die da wahnsinnig viel Energie reinstecken. Finde ich ein sehr interessantes Projekt.

 

[SheepShaver]

Wenn du was nützliches lernen möchtest und nicht komplett in der Nische bleiben willst, dann würde ich ganz stark zu React Native raten. Die anderen Vorschläge sind Murks. Rust GUI steckt noch in den Kinderschuhen. Keine Library hat genügend Maturität und jedes Update bringt Breaking Changes.
C++/Qt kannst du machen. Wunder dich aber nicht, wenn du dich zu Tode langweilst.

 

[blöderidiot]

C++/Qt kannst du machen. Wunder dich aber nicht, wenn du dich zu Tode langweilst.

Soweit ok.
Was es noch gibt, siehe: https://philippegroarke.com/posts/2018/c++_ui_solutions/
==> Dear IMGUI

 

[uburoi]

Es ist wie so oft, wenn man nach dem richtigen Werkzeug fragt: Der Maler empfiehlt den Pinsel, der Zimmermann die Säge. Das wird so zu nichts führen. Aber der TO ist offensichtlich auch raus …

Gruß Jens