Delphi višeplatformski za Windows, macOS i Linux: arhitektura, rad i tipične zamke

Wenn in Unternehmen über Delphi Multiplattform für Windows, macOS und Linux gesprochen wird, geht es selten um „Technik um der Technik willen“. Meist steckt eine handfeste Lage dahinter: Eine gewachsene Business-Software läuft zuverlässig auf Windows, aber Fachbereiche fordern macOS-Clients, IT-Teams möchten Linux-Services in bestehende Server-Standards integrieren, oder es steht eine Modernisierung an, ohne den gesamten Funktionsumfang neu zu entwickeln.

Delphi kann in diesem Spannungsfeld eine pragmatische Brücke sein – vorausgesetzt, Multiplattform wird als Betriebs- und Architekturthema verstanden. Denn die eigentlichen Kosten entstehen nicht im ersten Build, sondern in Wartung, Release-Prozess, Security-Updates, Datenzugriff, Treiberlandschaft, Paketierung und Support. Dieser Beitrag ordnet ein, wie Sie Multiplattform realistisch planen, welche technischen Entscheidungen im Betrieb spürbar sind und welche Fallstricke in Projekten typischerweise spät auffallen.

Warum Multiplattform in Unternehmen selten „nur ein Feature“ ist

In der Praxis entsteht Multiplattform-Bedarf aus drei typischen Treibern:

• Heterogene Endgeräte: Windows ist gesetzt, macOS kommt über Management, Vertrieb, Design oder Führungsebenen hinzu. Linux taucht entweder als Desktop in Spezialumgebungen oder als Serverstandard im Rechenzentrum auf.
• Standardisierung im Betrieb: Viele IT-Abteilungen möchten Services auf Linux konsolidieren (Monitoring, Paketmanagement, Härtung), auch wenn Clients weiterhin Windows bleiben.
• Modernisierung ohne Big Bang: Bestandsanwendungen sollen Schritt für Schritt in wartbare Schichten überführt werden, oft parallel zu Datenbank- und Schnittstellenprojekten.

Wichtig ist die Unterscheidung: Multiplattform am Client (Desktop-App) ist ein anderes Thema als Multiplattform im Backend (Services/REST). Gerade im B2B-Kontext lohnt sich häufig ein hybrider Ansatz: stabile Windows-Clients, aber serverseitig Linux-Services und REST-APIs für Integration, Automatisierung und Web-Portale.

Delphi Multiplattform für Windows, macOS und Linux: Was das konkret bedeutet

Multiplattform in Delphi ist kein Zauberstab, sondern ein Werkzeugkasten. Für die IT- und Betriebsseite sind dabei drei Ebenen entscheidend:

• UI-Schicht: Auf Windows existiert in vielen Unternehmen eine etablierte VCL-Welt (klassische Windows-Oberfläche). Für echte Multiplattform-Clients kommt meist FireMonkey (FMX) ins Spiel, das dieselbe Oberfläche auf unterschiedlichen Betriebssystemen ermöglicht – mit jeweils nativen Eigenheiten.
• Fachlogik: Der große Hebel liegt in gemeinsamer, sauber gekapselter Logik. Wer Fachlogik und Datenzugriff vom UI trennt, kann Plattformen wechseln, ohne das Produkt neu zu erfinden.
• Laufzeit und Deployment: Jede Plattform hat andere Anforderungen an Installation, Rechte, Signierung, Updates, Pfade, Zertifikate und Bibliotheken. Genau hier entscheidet sich, ob Multiplattform im Alltag „leicht“ oder „teuer“ ist.

Für Entscheider ist die Kernfrage daher nicht „Kann Delphi macOS und Linux?“, sondern: Welche Teile unserer Lösung müssen wirklich multiplattformfähig sein – und wie sichern wir Betrieb und Wartbarkeit über Jahre?

Arhitektura: Najveći multiplikator za troškove održavanja

Multiplatformski projekti rijetko propadaju zbog kompajlera, a češće zbog nedostatka razdvajanja odgovornosti. U postojećim aplikacijama često je sve pomiješano: UI-događaji, pristup bazi podataka, poslovna logika, ispis, datotečni sustav, mrežni pozivi. To funkcionira na „tom jednom Windows-PC“, ali postaje trajna gradilišna situacija čim proširite platforme ili izbacite servise izvana.

Model slojeva umjesto „obrazac kao središnja točka“

Dokazana je jasna podjela u slojeve (često nazvana Layer-architekturom):

• Prezentacija: Desktop-sučelje (VCL ili FMX) ili web-frontendi.
• Aplikacijska i poslovna logika: Pravila, workflowi, autorizacije, validacije; idealno bez direktne ovisnosti o UI-ju ili driverima za baze podataka.
• Sloj integracije: Povezivanje s ERP/DMS/CRM, datotečnim sučeljima, messagingom, REST.
• Pristup podacima: Konsolidirani pristup preko jasno definiranih granica repozitorija/servisa, umjesto SQL-a na svakom koraku.

Ta razdvojenost nije akademska vježba: smanjuje slučajeve specifične za platformu, olakšava testiranje, omogućuje server-side komponente i čini migracije baza podataka (npr. na PostgreSQL) znatno kontroliranijima.

Zajednička poslovna logika: Multiplatform bez dvostruke implementacije

Ako mislite ozbiljno o multiplatformskom pristupu, poslovna logika treba biti dizajnirana tako da radi jednako dobro u desktop-aplikaciji i u servisu. To je posebno važno ako kasnije nadograđujete klijentski portal (klijentski portal), interno web-sučelje ili integraciju REST. U praksi to znači: poslovne odluke trebaju biti u servisima/modulima, a ne u klik-događajima obrasca.

UI-strategija: VCL zadržati, FMX ciljano koristiti, web nadopuniti

Mnoge tvrtke imaju snažnu Windows-desktop-bazu. Trenutačna konverzija na novu UI-tehnologiju često je nepotrebno rizična. Tipične održive strategije su:

Strategija A: Windows-klijent ostaje VCL, backend postaje platformno neutralan

Ovdje se jezgra postupno izvlači iz VCL-aplikacije: u biblioteke i server-side komponente. Rezultat: Windows-klijent ostaje stabilan, dok integracija, automatizacija i novi frontendi nastaju preko servisa. Linux tada ulazi u igru kroz serverski rad (npr. REST-server ili pozadinski servisi).

Strategija B: Multiplatform-klijent s FMX za definirane scenarije

FMX ima smisla kad zaista trebate istog klijenta na Windows i macOS, primjerice za terensku službu, mobilna radna mjesta ili miješane flotne okoline. Važno: UI-detalji (fontovi, tipkovničke prečice, dijalozi, odabir datoteka) razlikuju se po platformi. To treba uračunati u testiranje i podršku.

Strategija C: Desktop nadopunjen portalom

Mnoge tvrtke „macOS-temu“ ne rješavaju punim klijentom, već portalom za jasno ograničene procese: upiti, odobrenja, status naloga, dokumenti. To rasterećuje desktop-rolloutove, smanjuje trošak instalacije i često se brže može učvrstiti jer je središnji web-sloj lakše kontrolirati.

Pristup podacima i baze podataka: FireDAC kao operativni faktor stabilnosti

U multiplatformskim arhitekturama pristup podacima često je područje u kojem povijesni zaostaci postaju najskuplji. Posebice stariji Delphi-sustavi ovise o Borland Database Engine (BDE) ili o upravljačkim programima koji ispravno funkcioniraju samo na Windows. Za rad to predstavlja rizik: dostupnost upravljačkih programa, pitanja 32/64 bita, Unicode, sigurnosne zakrpe i nadgledanje teško je kontrolirati.

Strategija upravljačkih programa: jedinstvena, dokumentirana, testabilna

BDE-zamjena s nativnom integracijom u Delphi je rašireni sloj pristupa podacima koji jedinstveno obrađuje različite baze podataka. Operativno je manje važno „koliko elegantno“ to izgleda u kodu, a više:

• Koje klijentske biblioteke su potrebne? (npr. PostgreSQL, MariaDB ili Oracle klijent)
• Kako se distribuiraju? Dio instalera, centralno upravljano, container-image
• Kako se sigurnosno upravljaju parametri veze? (tajne, zaštićena konfiguracija, bez lozinki u prostom tekstu u datotekama)
• Koliko je stabilno ponašanje pri mrežnim smetnjama? ponovna pokušavanja, timeouti, pooling

Migracije baza podataka: multiplatforma kao povod za jasne sučajne granice

Ako se ionako nadograđuju platforme, često je to pravi trenutak za konsolidaciju pristupa podacima. Migracija (npr. s starih datotečnih formata ili ugrađenih baza prema SQL sustavima poput PostgreSQL ili SQL Server) treba se voditi kao projekt s jasno definiranim fazama: model podataka, alati za migraciju, paralelni rad, prihvat, plan za povrat. Multiplatforma pojačava pritisak jer „Windows-only“-upravljači ili putanje datoteka na macOS/Linux više ne rade.

Servisi i sučelja: REST kao most između platformi

U heterogenim okruženjima REST pristup (REST = HTTP-bazirano sučelje s jasno definiranim resursima i metodama) često je najpragmatičniji način povezivanja platformi. Za operativu to znači: središnja autentifikacija, standardizirani protokoli, bolja observabilnost (logovi/metrike) i čisto odvajanje klijenta od baze podataka.

Delphi REST-Server vs. direkter DB-Zugriff vom Client

Mnoge postojeće desktop-solucije rade s izravnim pristupom bazi podataka iz klijenta. U čistim Windows mrežama to je dugo bilo uobičajeno. S multiplatformom i modernom sigurnošću to postaje teže:

• Segmentacija mreže: Baze podataka više nisu u istoj mreži kao klijenti; firewalle postaju stroži.
• VPN/Zero Trust: Izravne veze prema bazi podataka preko promjenjivih mreža sklone su pogreškama.
• Revizija i prava: Funkcijska prava u aplikaciji teško je precizno mapirati ako svaki klijent izravno izvodi SQL upite.

Jedan REST-Server (ili sloj usluga) može centralizirati ove točke: autentifikacija, dozvole, bilježenje, ograničavanje zahtjeva (rate limiting), verzioniranje. Za administratore to je često lakše za upravljanje nego „sto klijenata s pristupom bazi podataka“.

Autentifikacija i SSO: SAML 2.0, OAuth, Token

U B2B okruženju Single Sign-on (SSO) često je obavezno. SAML 2.0 (standard za federaciju identiteta između Identity Provider i aplikacije) ili OAuth/OpenID Connect (token-bazirani postupci) tipični su dijelovi rješenja. Presudno nije buzzword, nego operativno pitanje: gdje su identiteti pohranjeni, kako teče provisioning, kako se tokeni štite i kako se pristupi revizijski zapisno bilježe?

Deployment i pakiranje: potcijenjeni napor

Delphi višeplatformsko za Windows, macOS i Linux također znači: tri svijeta u pakiranju. Mnogi troškovi nastaju tek nakon prvog Go-livea, kada se ažuriranja moraju redovito razmještati.

Windows: Installer, prava, servisi

Na Windows su uobičajeni MSI/Installer-procesi, grupne politike, UAC (User Account Control) i Code-Signing. Čim je uključen Windows- i Linux-Services, pojavljuju se dodatne teme: servisni račun, prava na datotečnom sustavu i mreži, redoslijed pokretanja, opcije oporavka i rotacija logova. Za održavanje je važno da je servis jasno verzioniran i da se može ažurirati bez ručnih intervencija.

macOS: Notarisierung, Signierung und Gatekeeper

macOS za distribuirane aplikacije obično zahtijeva potpisivanje i, ovisno o načinu distribucije, notarizaciju (proces provjere kako bi Gatekeeper pokrenuo aplikaciju). Za tvrtke je to manje „Apple-tema“, a više problem procesa: tko drži certifikate, kako teče build-pipeline, kako se reprodukcibilno stvaraju releasevi? Bez te discipline svaki Hotfix postaje pojedinačna akcija.

Linux: Pakete, ovisnosti, systemd

Na Linux su relevantne systemd-unit datoteke (definicije kako se servisi pokreću i nadziru), formati paketa (npr. DEB/RPM) ili kontejnerizirani deployamenti. Za administratore vrijedi: jasna konfiguracija, definirane putanje, smisleni logovi (npr. preko journald), health-checks i put ažuriranja koji je kompatibilan s vlastitom politikom distribucije.

CI/CD und Release-Prozess: Multiplattform braucht reproduzierbare Builds

Najkasnije s tri ciljane platforme „Build per Hand“ postaje rizik. CI/CD (Continuous Integration/Continuous Delivery) ovdje ne znači nužno „sve potpuno automatski u produkciju“, nego prije svega: reproducibilne artefakte, provjerljive verzije i standardizirani proces testiranja i odobravanja.

U praksi biste trebali barem definirati:

• Build-Matrix: Koje platforme, koje varijante (Debug/Release), koji upravljači baza podataka, koji opcionalni moduli?
• Versionierung: Jedinstveni brojevi verzija za klijent i server, plus stanja migracija baze podataka.
• Signierung: Gdje se potpisuje, kako se ključevi štite (npr. HSM ili zaštićeni build-agent(i))?
• Smoke-Tests: Minimalne funkcionalne provjere po platformi koje mogu blokirati svakog kandidata za izdanje.

Za donositelje odluka to je pitanje governancea: bez discipline izdanja višeplatformsko će tijekom godina postati skuplje, jer se obrasci grešaka teže reproduciraju i Hotfixovi imaju različite nuspojave po platformi.

Monitoring, Logging und Fehleranalyse: Was im Betrieb wirklich zählt

U svakodnevnom radu IT timovi trebaju brze odgovore: „Zašto je proces zapeo?“, „Je li to problem klijenta ili problem backenda?“, „Od kada se pojavljuje?“ Multiplatformnost povećava varijabilnost, pa treba poboljšati Observability.

Jedinstvena strategija logiranja za klijent i server

Dokazana je višerazinska strategija logiranja:

• Klijentski logovi: lokalni zapisi s rotacijom, jedinstvenim korelacijskim identifikatorom (npr. Request-ID), u skladu s pravilima zaštite podataka.
• Server-logovi: centralna pohrana, strukturirani unosi (precizno vremenski, strojno čitljivi), odvajanje audit- i debug-logova.
• Metričke vrijednosti: vremena odgovora, stope pogrešaka, duljine redova čekanja, iskorištenost poola baze podataka.

Posebno kod REST-arkitektura Request-ID (jedinstveni identifikator po zahtjevu koji se prosljeđuje kroz sve komponente) vrijedi zlata, jer se slučajevi podrške tako ograničavaju u minutama umjesto u satima.

Obrada pada aplikacije i simbolizirana analiza grešaka

Na desktop platformama crash-dumpovi i stacktracevi moraju se rukovati tako da budu upotrebljivi u podršci, a da pri tome ne procuri osjetljivi sadržaj. To je organizacijsko pitanje: koji se podaci smiju prenijeti? Kako se dobiva suglasnost? Kako se debug-simboli sigurno pohranjuju i kako se povezuju s verzijama? Bez tih odgovora podrška za multiplatforme često ostaje „traženje u magli“.

Sigurnost i usklađenost: platforme znače različite površine napada

S Windows, macOS i Linux rizik se ne povećava automatski, ali površina napada postaje raznovrsnija. Tipične točke koje se u projektima često adresiraju prekasno:

• Upravljanje certifikatima: TLS certifikati za servere, certifikati za klijente, datumi isteka, automatizirano obnavljanje.
• Tajne: lozinke baze podataka, API-ključevI, ključevi za potpisivanje – ne u konfiguracijama u čistom tekstu ili u instalacijskim skriptama.
• Koncept prava: princip najmanjih privilegija za servise, jasna razdvojenost administratorskih i korisničkih funkcija.
• Sposobnost ažuriranja: sigurnosne zakrpe moraju se brzo distribuirati; to je izravno povezano s procesom pakiranja i izdanja.

Posebno u poduzećima s revizijskim zahtjevima isplati se rano definirati kratku sigurnosnu kontrolnu listu po platformi i uvrstiti je u prihvatne kriterije.

Tipične zamke u multiplatformskim projektima

Nepravilnosti se ponavljaju – ne zato što timovi „loše rade“, nego zato što su u povijestima koje su bile Windows-only nevidljive:

Datotečni sustav i putanje: mali detalj, veliki učinak

Različite konvencije putanja, osjetljivost na velika/mala slova (case-sensitivity), korisnički direktoriji i prava uzrokuju pogreške pri eksportima, privitcima, privremenim datotekama ili cacheevima. Pomaže konzistentan koncept apstrakcije: centralni path-servisi, definirani app-direktoriji, bez „hard-coded“ lokacija za pohranu.

Ispis, PDF i integracija Officea

Radni tokovi ispisa i dokumenata često su kritični u poslovnim procesima. Windows ima ustaljene putove ispisa, dok se macOS i Linux ponašaju drugačije. Ako su generiranje PDF-a, potpisi ili izdavanje dokumenata relevantni, te funkcije treba rano testirati na svim ciljanim platformama – ne tek neposredno pred rollout.

Unicode i skupovi znakova

Najkasnije kod miješanih platformi, sučelja i baza podataka, Unicode (standard skupa znakova za međunarodne znakove) postaje nužnost. Stare baze s „ANSI“-poviješću inače proizvode teško reproducirajuće pogreške u pretraživanju, sortiranju, CSV-izvozima ili sučeljima. Strategija za Unicode obuhvaća UI, stupce baze podataka, sučelja i testne podatke.

32/64-Bit und Bibliotheksabhängigkeiten

Klasik: upravljački program ili biblioteka treće strane dostupni su samo za jednu arhitekturu. Za rad to znači: jasna lista ovisnosti, dokumentiranje verzija, provjera licence i mogućnosti ažuriranja. Multiplatforma je stabilna onoliko koliko i najslabija ovisnost.

Entscheidungshilfe: Wann lohnt sich Delphi Multiplattform wirklich?

Pragmatičan pogled na troškove i koristi pomaže da se rasprave svedu na bit. Multiplatforma se tipično isplati ako:

• funkcionalna jezgra dugoročno ostaje stabilna i ponovna upotreba se isplati tijekom godina,
• postoje stvarni organizacijski razlozi za macOS-klijente (ne samo „bilo bi lijepo“),
• Linux je u backendu ionako standard i planirani su servisi/REST,
• aplikacija se mora integrirati u mrežu integracija ERP/DMS/CRM,
• može se uspostaviti čist proces izdavanja (Build, potpisivanje, testovi).

Manje smisla ima multiplatforma ako aplikacija u velikoj mjeri ovisi o komponentama specifičnim za Windows (npr. duboka Office-automatizacija, specijalni upravljački programi, COM-bazirane integracije) i te funkcije nisu jasno enkapsulirane. Tada je često realnija mješovita strategija: Windows-klijent za specijalne slučajeve, portal/REST za platformno-neutralne procese.

Modernisierungspfad: Multiplattform ohne kompletten Neustart

Za mnoga poduzeća najvažnije je: multiplatforma ne mora značiti pisati sve ispočetka. Pouzdan put često izgleda ovako:

1. Analiza stanja i definiranje sučelja: Koji moduli su funkcionalno stabilni, koji su blizu UI-a ili baze podataka, gdje su najveći rizici?
2. Konsolidirati pristup podacima: npr. BDE-zamjena, BDE-Ablosung mit nativer Anbindung, jedinstvena strategija povezivanja i transakcija.
3. Uspostaviti sloj servisa: REST-API za ključne procese, postupna zamjena izravnog pristupa bazi podataka.
4. Prioritizirati platforme: Prvo stabilizirati backend na Linux, zatim macOS-klijent za definirane skupine korisnika, umjesto istovremenog pristupa.
5. Profesionalizirati Packaging/CI: reproducibilni Buildovi i ažuriranja kao sastavni dio projekta.

Ovaj put je posebno prikladan za individualni korporativni softver s dugim životnim ciklusima, jer štiti poslovnu logiku i kontrolirano smanjuje tehničke rizike.

Fazit: Multiplattform ist eine Betriebsentscheidung – nicht nur eine Entwicklerentscheidung

Delphi Multiplattform für Windows, macOS und Linux može za tvrtke biti vrlo pragmatičan put za tehničko unapređenje naslijeđenih procesa, bez gubitka funkcionalne jezgre. Ključno je planirati multiplatformu kao cjeloviti paket: arhitektura s jasnim slojevima, konsolidirani pristup podacima, sučelja prilagođena servisima, reproducibilni Buildovi, uredno pakiranje i strategija logiranja/monitoringa koja brzo razjašnjava slučajeve podrške.

Ako su ti temelji postavljeni, multiplatforma ne postaje dugotrajan projekt, već kontrolirano proširenje vašeg digitalnog poslovnog rješenja – s realističnim operativnim troškovima i planom razvoja koji povezuje migraciju i daljnji razvoj.

Ako želite strukturirano procijeniti svoje polazno stanje (postojeće stanje, ciljne platforme, baza podataka, sučelja i operativni model): Kontaktirajte nas za tehnički uvodni razgovor.

U stručnom okruženju važnu ulogu također igraju Delphi modernizacija, kada se integracije, tokovi podataka i daljnji razvoj moraju besprijekorno uskladiti.

Razgovarajte o projektu ili planu modernizacije s Net-Base.