Kurz zu meiner Vorgeschichte: Ich arbeite seit 1998 mit Delphi. Wir haben damals mit meiner IT-Firma mit Delphi3 begonnen und sind dann bei D5 stehen geblieben, da danach (nach unserer Ansicht damals) die Griffigkeit verlorenging. Bis heute arbeite ich mit D5 und habe nun in Eigenregie seit zehn Jahren ein großes Projekt am Laufen, Patchwork, ein Programm für Schriftsteller, seines Zeichens das umfangreichste Autorenprogramm (viel Eigeninteresse dabei, weil ich selbst schreibe). Immer wieder erhalte ich aber Anfragen, warum es das nicht für 'wenigstens' MacOS gäbe - verständlich, weil sich viele Autoren als Künstler sehen und Künstler gerne Mac nutzen.

Blauäugig (und vielleicht zu draufgängerisch) wie ich nun mal mit Neuem bin, habe ich zuerst mal Lazarus ausprobiert. War positiv überrascht, wie ähnlich es D5 ist, aber ... die wichtigsten Zusatzkomponenten für Patchwork sind die von Developer Express, brauche ich in fast jedem der über 70 Formulare, oft mehrere. Die sind leider nicht auf Lazarus portierbar wegen der zu großen/tiefen Windows-Affinität. Der Ersatz wäre die TVirtualStringTree-Komponente. Anscheinend sehr leistungsfähig, aber vergleichsweise extrem aufwendig/umständlich zu programmieren und vor allem so gut wie nicht dokumentiert - wie das leider oft bei kostenfreien Sachen der Fall ist.

Also hab ich mich doch für D12 entschieden und bin nun da. Denn Delphi 12 ist ja plattformübergreifend und IOS und Android auch noch. Und Embarcadero eine große Firma und es gibt Doku ...
Meine bisherigen Erfahrungen sind - bis auf die Hilfe hier im Forum - eher ernüchternd. Und nun fiel mir siedend heiß in der Nacht ein: Selbst wenn es von DevExpress Grids & Co in neu gibt - sind die überhaupt wenigstens MacOS-fähig??

Vor diesem Post habe ich Artikel hier zu plattformübergreifend gelesen und heftige Zweifel bekommen: 'Nur VCL', 'FMX nicht brauchbar' und weitere abtörnende Erfahrungen.

Nun meine Fragen an euch:
1. Bin ich meiner Blauäugigkeit aufgesessen und sollte mich doch besser in Lazarus hineinfuchsen?
2. Vor allem: Wie erkenne ich (ohne es auszuprobieren), ob Komponenten multi-plattform-fähig sind? Ist offenbar keineswegs selbstverständlich.
3. Wisst ihr, ob überhaupt DevExpress-Grids MacOS-fähig sind ...?
4. Oder würdet ihr bei D5 bleiben, so lange es geht?

Danke für eure Lese- und Antwortszeit. Wäre euch für viele Antworten sehr dankbar, denn es geht um eine große Grundsatzentscheidung, die Mannjahre hinter sich herzieht.

Kurz gesagt, wenn du auf DevExpress quasi festgelegt bist, dann musst du bei VCL bleiben. Plattformübergreifend geht bei Delphi mit bordeigenen Mitteln aber nur mit FMX. Selbst das als Zusatzprodukt verfügbare CrossVCL, mit dem VCL-Anwendungen mit Delphi auch für MacOS erstellt werden können, hat die Unterstützung von DevExpress mittlerweile eingestellt.

Natürlich kann man mit Delphi auch für MacOS entwickeln. In der Regel sind aber bestehende VCL-Programme bezüglich des User Interfaces komplett neu aufzubauen. Meistens kommt das einer kompletten Neuentwicklung schon sehr nahe.

Wenn man von Anfang an mit FMX mit dem Ziel plattform übergreifend entwickelt, bietet Delphi da einem sehr viel, da bin ich eigentlich recht happy und nutze zusätzlich relativ viele TMS-Komponenten. Eine Portierung eines VCL-Projektes ist aber eine ganz andere Geschichte.

Wenn Du wirklich echte zukunftsfähige Cross-Plattform Anwendungen bauen willst, dann bist Du mit allem Nativen auf dem Holzweg. Web-basierte Technologie ist da tatsächlich das einzige das wirklich 100% überall funktioniert.
Wir machen das seit mehr als 10 Jahren extrem erfolgreich. Wir haben schon viele andere Ansätze gesehen und auch Kunden gehabt die das nicht glauben wollten und es anders versucht haben. Davon sind ausnahmslos alle gescheitert.

Oder andersum gesagt, wenn Du etwas für eine Plattform bauen willst, nimm am besten ausschließlich Tools dafür, die auch auf dieser Plattform laufen.
Willst Du für den Mac bauen, nehme Tools die auf dem Mac tun. Willst Du für Mac und Windows bauen, nehme Tools die auf Mac und Windows tun. Willst Du für Mac, Windows, Linux, Android und iOS bauen, nehme Tools die überall dort laufen. Wenn (komplexes) Entwicklungstooling dort läuft, kannst Du davon ausgehen dass auch Deine Anwendung die damit gebaut ist dort tut.

Unser Stack ist Angular fürs Frontend und .NET auf dem Backend, aber alles was JS/TS ist (React, Vue etc.) wird vorne tun und hinten kannst Du gerne auch JS/TS nehmen (Node) wenn Du nix besseres haben willst

Zitat von Phoenix:

Web-basierte Technologie ist da tatsächlich das einzige das wirklich 100% überall funktioniert.

...

aber alles was JS/TS ist (React, Vue etc.)

Damit bin ich im Prinzip völlig mit einverstanden, nur JS ist wirklich völlig plattformübergreifend.

Nur leider komme ich jedes Mal, wenn ich wieder etwas Neues/Hybrides austeste, ganz schnell an irgendwelche Grenzen.
Solange man Web-Zentrierte Apps baut, die nicht viel von der Hardware oder von den Mobil-Spezialitäten nutzen, dann mag das OK sein.
Sobald man Location, Background-Modi, Bluetooth, Sensoren, Audio, Mail, SMS, PhoneCall, Mikrofon, SpeechRecognition, usw. usw. usw. braucht,
dann gibt es mit Web-Technologie oft noch mehr Beschränkungen als rein nativ.

Egal ob Flutter, React oder Xamarin, ich finde oft sehr viel ähnliche Beiträge in den Foren dort, wo es genauso wenig Lösungen gibt wie bei Delphi.
Zuletzt hatte ich bei Flutter gesucht, wo geschrieben stand: Ja, geht im Prinzip, da gab es diese OpenSource Library ( allerdings nur ein proof-of-concept, ungepflegt), aber offiziellen Support gab es nicht.
Ok, die Entwicklung geht da natürlich rasant immer weiter, aber ein kompletter No-Brainer ist IMHO keine dieser Technologien.

Das Problem ist ja mehr politischer Natur, wenn der Zugriff durch Google/Apple unnötig verkompliziert und restriktiver gemacht wird, ohne Rücksicht auf Verluste.

Deshalb ist Delphi gar nicht so verkehrt, für solche Anwendungen.
Und bei den ganzen obskuren Problemen, die mir untergekommen sind, wenn ich dann mal über den Tellerrand schaue:
Auch Xamarin, Unity, React, Flutter, NetMAUI, ja sogar XCode und Android-Studio selbst, haben oft die gleichen Probleme an die Hardware zu kommen.

Ich würde mir wünschen, einfach nur eine App mit einem DB-View machen zu müssen, eventuell noch mit REST-API,
aber meistens kommt dann doch noch sehr viel obendrauf.

Zitat:

himitsu schrieb: Weil du kein Bild dafür hochgeladen hast
Mein Profil > Profilbild
Einstellungen&Optionen > Benutzerbild

Genau dorthin würde ich gern, aber ich finde es beim Profil nicht (siehe hier) und außer neben Willkommen, xyz finde ich nichts. Seltsamerweise konnte ich früher mal das Bild einfügen, kann es jetzt aber nicht mehr ändern. Und Signatur finde ich auch nicht.

Zitat:

jaenicke schrieb: Ich persönlich finde datensensitive Komponenten überhaupt nicht gut, weil man die Datenebene viel zu fest mit der UI verbandelt.

Bei plattformübergreifend vermutlich schon. Wir hatten uns selbst seinerzeit eine Schnittstelle zu Pervasive (live und SQL) geschaffen mit abgeleiteten Komponenten. Das war auf jeden Fall angenehmer, als Daten und GUI komplett zu trennen. So hatten wir eine Applikation, aber die wurde dadurch etwas krakelig.

Zitat:

Aber für eine plattformübergreifende TVirtualStringTree mit auch nur annähernd der Funktionalität der VCL Version wäre ich bereit einiges zu zahlen (und ich denke einige andere auch).

Meines Wissens ist TVirtualStringTree plattformübergreifend. Aber zum Programmieren ein Horror mit den ganzen Records und Zeigern. Diesbezüglich war die Treelist von Developer Express optimal. Für eine gescheite TreeView würde ich auch gern was zahlen. Ist die von TMS nicht so etwas?

@Mavarik: Hab mir ein Video von dir angesehen. Warum soll man bei plattformübergreifend keinen Code hinter einen FMX-Button setzen?

Zitat von jik:

1. Bin ich meiner Blauäugigkeit aufgesessen und sollte mich doch besser in Lazarus hineinfuchsen?

Lazarus kann durchaus einiges, kommt an Delphi aber bei Weitem nicht heran. Wenn man nur kostenlos möchte und dafür deutlich mehr Aufwand in Kauf nimmt, ist es trotzdem keine schlechte Wahl.

Wenn man aber Kaufkomponenten einbezieht, kommt man mit Delphi meiner Meinung nach deutlich weiter.

Zitat von jik:

2. Vor allem: Wie erkenne ich (ohne es auszuprobieren), ob Komponenten multi-plattform-fähig sind? Ist offenbar keineswegs selbstverständlich.

Das steht dann in der Regel schon deutlich dabei, wenn du im Internet angebotene Komponenten meinst. In Delphi selbst brauchst du nur schauen, was unter FMX zur Verfügung steht.

Zitat von jik:

3. Wisst ihr, ob überhaupt DevExpress-Grids MacOS-fähig sind ...?

Es gibt auch das FMX Data Grid von DevExpress. Das ist plattformunabhängig (Windows, Android, and macOS).

Von TMS gibt es auch größere Sammlungen an plattformunabhängigen Komponenten (TMS FNC UI Pack, ...).

Zitat von jik:

4. Oder würdet ihr bei D5 bleiben, so lange es geht?

Definitiv nicht. Da hat sich so viel getan, unabhängig von Plattformunabhängigkeit, dass das keinen Sinn macht (Unicode, Generics, ...). (Außer, weil der Umstieg zu viel Aufwand wäre natürlich, dann geht es ggf. nicht sofort, aber man sollte dran arbeiten, wenn das Produkt weiterentwickelt wird.)

Zitat von jaenicke:

Es gibt auch das FMX Data Grid von DevExpress. Das ist plattformunabhängig (Windows, Android, and macOS).

Ich bin vielleicht nicht ganz auf dem Laufenden, aber hat sich an dem Status wie hier beschrieben mittlerweile was geändert?

Da davon nichts bei der Komponente dabei steht, wusste ich davon nichts. Ich habe mich einfach auf diese Webseite verlassen. Ich kenne die DevExpress Komponenten kaum, da ich immer bei denen von TMS war.

Okay, dann ist der Blog-Post offenbar immer noch aktuell.