Delphi Multiplatform til Windows, macOS og Linux: Arkitektur, drift og typiske faldgruber

Når virksomheder taler om Delphi Multiplattform for Windows, macOS og Linux, handler det sjældent om „teknik for teknikens skyld“. Ofte ligger der en konkret begrundelse bag: En etableret business‑software kører pålideligt på Windows, men forretningsafdelinger kræver macOS‑klienter, IT‑teams vil integrere Linux‑services i eksisterende serverstandarder, eller der står en modernisering for døren uden ønske om at genudvikle hele funktionsomfanget.

Delphi kan i dette spændingsfelt være en pragmatisk bro – forudsat at multiplatform betragtes som et drifts‑ og arkitekturtema. De reelle omkostninger opstår sjældent i første build, men i vedligehold, release‑proces, security‑updates, dataadgang, driverlandskab, paketering og support. Denne artikel sætter rammerne for, hvordan I realistisk planlægger multiplatform, hvilke tekniske valg der mærkes i drift, og hvilke faldgruber der typisk dukker op sent i projekter.

Hvorfor multiplatform i virksomheder sjældent er „bare et feature“

I praksis opstår behovet for multiplatform typisk ud fra tre drivere:

• Heterogene slutpunkter: Windows er fastlagt, macOS tilføjes via management, salg, design eller ledelse. Linux optræder enten som desktop i specialmiljøer eller som serverstandard i datacenteret.
• Standardisering i drift: Mange IT‑afdelinger ønsker at konsolidere services på Linux (monitorering, pakkehåndtering, hårdning), selvom klienterne fortsat kører på Windows.
• Modernisering uden Big Bang: Bestående applikationer skal løbende flyttes til vedligeholdelsesvenlige lag, ofte sideløbende med database‑ og integrationsprojekter.

Vigtigt er sondringen: multiplatform på klienten (desktop‑app) er et andet spørgsmål end multiplatform i backend (services/REST). Især i B2B‑sammenhæng er en hybrid tilgang ofte fornuftig: stabile Windows‑klienter, men serverside Linux‑services og REST‑APIer til integration, automation og webportaler.

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

Multiplatform i Delphi er ikke en tryllestav, men et værktøjssæt. For IT‑ og driftssiden er tre niveauer afgørende:

• UI‑lag: På Windows findes i mange virksomheder en etableret VCL‑verden (klassisk Windows‑grænseflade). Til egentlige multiplatform‑klienter kommer ofte FireMonkey (FMX) i spil, som gør det muligt at levere samme brugerflade på forskellige operativsystemer – med hver deres native særheder.
• Forretningslogik: Den største gevinst ligger i fælles, klart kapslet logik. Hvis forretningslogik og dataadgang adskilles fra UI, kan platforme udskiftes uden at gentænke produktet.
• Runtime og deployment: Hver platform stiller forskellige krav til installation, rettigheder, signering, opdateringer, stier, certifikater og biblioteker. Netop her afgøres det, om multiplatform i dagligdagen er „let“ eller „dyrt“.

For beslutningstagere er kerne­spørgsmålet derfor ikke „Kan Delphi macOS og Linux?“, men: Hvilke dele af vores løsning skal reelt være multiplatform‑kompatible – og hvordan sikrer vi drift og vedligehold over år?

Arkitektur: Den største multiplikator for vedligeholdelsesomkostninger

Multiplatform-projekter fejler sjældent på kompilatoren, men på manglende adskillelse. I eksisterende applikationer er ofte alt blandet sammen: UI-hændelser, databaseadgang, forretningslogik, udskrivning, filsystem, netværksopkald. Det fungerer på „den ene Windows-PC“, men bliver til en permanent byggeplads, så snart I udvider platforme eller udliciterer services.

Lagdelt model frem for „Formularen som omdrejningspunkt“

En klar lagdelt model (ofte kaldet layer-arkitektur) er gennemprøvet:

• Præsentation: Desktop-UI (VCL eller FMX) eller web-frontends.
• Anvendelses- og forretningslogik: Regler, workflows, adgangskontrol, valideringer; ideelt uden direkte afhængighed til UI eller database-drivere.
• Integrationslag: Tilslutning til ERP/DMS/CRM, filinterfacer, messaging, REST.
• Dataadgang: Konsolideret adgang via klart definerede Repository-/Service-grænser, i stedet for SQL overalt.

Denne adskillelse er ingen akademisk øvelse: den reducerer platformssærtilfælde, letter testning, muliggør serverside-komponenter og gør databasemigrationer (f.eks. til PostgreSQL) væsentligt mere kontrollerbare.

Fælles forretningslogik: Multiplatform uden dobbeltudvikling

Hvis I mener multiplatform alvorligt, bør den faglige logik designes, så den kan køre lige godt i en desktop-app og i en service. Det er særligt relevant, hvis I senere skal tilføje en kundeportal, en intern webgrænseflade eller en REST-integration. I praksis betyder det: faglige beslutninger hører hjemme i Services/Module, ikke i klik-hændelser i en formular.

UI-strategi: Behold VCL, brug FMX målrettet, suppler med web

Mange virksomheder har et stærkt Windows-desktop-fundament. En øjeblikkelig omlægning til en ny UI-teknologi er ofte unødvendig risikabel. Typiske, gennemførlige strategier er:

Strategi A: Windows-Client bleibt VCL, Backend wird plattformneutral

Her trækkes kernelogikken gradvist ud af VCL-applikationen: ind i biblioteker og serverside-komponenter. Resultat: Windows-Clienten forbliver stabil, mens integration, automatisering og nye frontends opstår via services. Linux kommer så i spil via serverdrift (f.eks. REST-Server eller baggrundstjenester).

Strategi B: Multiplattform-Client mit FMX für definierte Szenarien

FMX giver mening, hvis I faktisk har brug for samme Client på Windows og macOS, f.eks. til feltservice, mobile arbejdspladser eller blandede enheder. Vigtigt: UI-detaljer (skrifttyper, tastaturgenveje, dialoger, filvalg) varierer pr. platform. Det skal indregnes i test og support.

Strategi C: Desktop ergänzt durch Portal

Mange virksomheder løser „macOS-temaet“ ikke med en fuld Client, men med en portal til klart afgrænsede processer: forespørgsler, godkendelser, ordrestatus, dokumenter. Det aflaster desktop-rollouts, reducerer installationsarbejde og er ofte hurtigere at hærde, fordi det centrale weblag er lettere at kontrollere.

Dataadgang og databaser: FireDAC som en operativ stabilitetsfaktor

I multiplatform-arkitekturer er dataadgang ofte det område, hvor historiske arv og teknisk gæld bliver dyrest. Især ældre Delphi-systemer er afhængige af Borland Database Engine (BDE) eller af drivere, der kun fungerer ordentligt på Windows. For driften er det en risiko: driver-tilgængelighed, 32/64-bit-spørgsmål, Unicode, sikkerhedsopdateringer og overvågning er svære at styre.

Driverstrategi: ensartet, dokumenteret, testbar

BDE-Ablösung mit nativer Anbindung er i Delphi et udbredt dataadgangslag, der taler ensartet til forskellige databaser. Operativt er det mindre relevant, hvor „elegant“ det ser ud i koden, men snarere:

• Hvilke klientbiblioteker er nødvendige? (f.eks. PostgreSQL-, MariaDB- eller Oracle-Client)
• Hvordan distribueres de? Del af installatøren, central styring, container-image
• Hvordan forvaltes forbindelsesparametre sikkert? (secrets, beskyttet konfiguration, ingen klartekstadgangskoder i filer)
• Hvor stabil er adfærden ved netværksforstyrrelser? Retries, timeouts, pooling

Database-migrationer: Multiplatform som anledning til rene grænseflader

Hvis platforme uanset giver mulighed for udvidelse, er det ofte det rette tidspunkt at konsolidere dataadgangen. En migration (f.eks. fra gamle filformater eller embedded-databaser til SQL-systemer som PostgreSQL eller SQL Server) bør køre som et projekt med klare faser: datamodel, migrationsværktøjer, parallel drift, godkendelse, tilbageførselsplan. Multiplatform øger her presset, fordi „Windows-only“-drivere eller filstier på macOS/Linux ikke længere fungerer.

Services og grænseflader: REST som bro mellem platforme

I heterogene landskaber er en REST-tilgang (REST = HTTP-baseret grænseflade med klare ressourcer og metoder) ofte den mest pragmatiske måde at forbinde platforme på. For driften betyder det: central autentificering, standardiserede protokoller, bedre observabilitet (logs/metrikker) og en ren løsrivelse mellem klient og database.

Delphi REST-server vs. direkte DB-adgang fra klienten

Many eksisterende desktopløsninger arbejder med direkte databaseadgang fra klienten. I rene Windows-netværk var det længe almindeligt. Med multiplatform og moderne sikkerhed bliver det vanskeligere:

• Netzsegmentierung: Databaser ligger ikke længere i samme net som klienter; firewalls bliver strengere.
• VPN/Zero Trust: Direkte DB-forbindelser over skiftende net er fejlbehæftede.
• Audit og rettigheder: Faglige rettigheder i applikationen er svære at afbilde korrekt, hvis hver klient taler SQL direkte.

En REST-Server (eller et service-lag) kan centralisere disse punkter: autentificering, rettighedsstyring, protokollering, rate-limiting, versionering. For administratorer er det ofte nemmere at drive end „hundrede klienter med databaseadgang“.

Autentificering og SSO: SAML 2.0, OAuth, Token

I B2B-miljøer er Single Sign-on (SSO) ofte påkrævet. SAML 2.0 (en standard for identity-federation mellem Identity Provider og applikation) eller OAuth/OpenID Connect (token-baserede procedurer) er typiske byggesten. Det afgørende er ikke buzzwordet, men driftsmæssige spørgsmål: Hvor ligger identiteterne, hvordan foregår provisioning, hvordan sikres tokens, og hvordan logges adgangene revisionssikkert?

Deployment und Packaging: Der unterschätzte Aufwand

Delphi Multiplattform für Windows, macOS und Linux bedeutet auch: drei Welten im Packaging. Viele Kosten entstehen erst nach dem ersten Go-live, wenn Updates regelmäßig ausgerollt werden müssen.

Windows: Installer, Rechte, Services

Auf Windows sind MSI/Installer-Prozesse, Gruppenrichtlinien, UAC (User Account Control) und Code-Signing üblich. Sobald ein Windows- und Linux-Services beteiligt ist, kommen zusätzliche Themen hinzu: Dienstkonto, Rechte auf Dateisystem und Netzwerk, Startreihenfolge, Recovery-Optionen und Log-Rotation. Für die Wartung ist wichtig, dass der Service klar versioniert ist und sich ohne manuelle Eingriffe aktualisieren lässt.

macOS: Notarisierung, Signierung und Gatekeeper

macOS verlangt für verteilte Anwendungen in der Regel Signierung und je nach Verteilweg eine Notarisierung (Prüfprozess, damit Gatekeeper die App ausführt). Für Unternehmen ist das weniger „Apple-Thema“ als ein Prozessproblem: Wer hält die Zertifikate, wie läuft die Build-Pipeline, wie werden Releases reproduzierbar erzeugt? Ohne diese Disziplin wird jeder Hotfix zur Einzelaktion.

Linux: Pakete, Abhängigkeiten, systemd

Auf Linux sind systemd-Units (Definitionen, wie Services starten und überwacht werden), Paketformate (z. B. DEB/RPM) oder containerbasierte Deployments relevant. Für Admins zählt: klare Konfiguration, definierte Pfade, sinnvolle Logs (z. B. über journald), Health-Checks und ein Updatepfad, der mit der eigenen Distribution-Policy kompatibel ist.

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

Spätestens mit drei Zielplattformen wird „Build per Hand“ zum Risiko. CI/CD (Continuous Integration/Continuous Delivery) bedeutet hier nicht zwingend „alles vollautomatisch in Produktion“, sondern vor allem: reproduzierbare Artefakte, nachvollziehbare Versionen und ein standardisierter Test- und Freigabeprozess.

In der Praxis sollten Sie mindestens festlegen:

• Build-Matrix: Welche Plattformen, welche Varianten (Debug/Release), welche Datenbanktreiber, welche optionalen Module?
• Versionierung: Einheitliche Versionsnummern über Client und Server, plus Migrationsstände der Datenbank.
• Signierung: Wo wird signiert, wie werden Schlüssel geschützt (z. B. HSM oder gesicherte Build-Agenten)?
• Smoke-Tests: Minimale Funktionsprüfungen je Plattform, die jeden Release-Kandidaten blockieren können.

Für Entscheider ist das ein Governance-Thema: Ohne Release-Disziplin wird Multiplattform über die Jahre teurer, weil Fehlerbilder schwerer reproduzierbar sind und Hotfixes Plattform-unterschiedliche Nebenwirkungen haben.

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

I dagligdagen har IT-teams brug for hurtige svar: „Hvorfor er processen gået i stå?“, „Er det et klientproblem eller et backend-problem?“, „Siden hvornår opstår det?“ Multiplatform øger variationen, derfor skal observabilitet forbedres.

Ensartet logstrategi for klient og server

En bevist tilgang er en trindelt logstrategi:

• Klient-logs: lokale logfiler med rotation, entydig korrelationsreference (f.eks. Request-ID), i overensstemmelse med databeskyttelse.
• Server-logs: central lagring, strukturerede poster (tidsmæssigt konsistente, maskinlæsbare), adskillelse af audit- og debug-logs.
• Metrikker: svartider, fejlrater, kølængder, database-pool-udnyttelse.

Især i REST-arkitekturer er en Request-ID (en entydig identifikator pr. forespørgsel, som føres gennem alle komponenter) guld værd, fordi supporttilfælde dermed kan indsnævres på minutter i stedet for timer.

Crash-håndtering og symboliseret fejlanalyse

På desktop-platforme skal crash-dumps og stacktraces håndteres sådan, at de er brugbare i supporten uden at lække følsomme data. Det er et organisatorisk spørgsmål: Hvilke data må overføres? Hvordan indhentes samtykke? Hvordan sikres debug-symboler, og hvordan knyttes de til versioner? Uden disse spørgsmål forbliver multiplatform-support ofte „fumlen i blinde“.

Sikkerhed og compliance: Platforme betyder forskellige angrebsflader

Med Windows, macOS og Linux stiger risikoen ikke automatisk, men angrebsfladen bliver mere varieret. Typiske punkter, der i projekter ofte adresseres for sent:

• Certifikatstyring: TLS-certifikater til servere, klientcertifikater, udløbsdatoer, automatiseret fornyelse.
• Secrets: databaseadgangskoder, API-nøgler, signeringsnøgler – ikke i konfigurationer i klartekst eller i installationsskripter.
• Rettighedskoncept: Least Privilege for services, klar adskillelse mellem admin- og brugerfunktioner.
• Opdaterbarhed: Sikkerhedsrettelser skal kunne rulles ud hurtigt; det afhænger direkte af pakke- og releaseprocessen.

Især i virksomheder med revisionskrav er det værd at definere tidligt en kort security-tjekliste pr. platform og inkludere den i godkendelsen.

Typiske faldgruber i multiplatformprojekter

Nogle problemer dukker igen og igen op – ikke fordi teams „arbejder dårligt“, men fordi de i historikker med kun Windows var usynlige:

Filsystem og stier: Lille detalje, stor effekt

Forskellige sti-konventioner, case-sensitivity (store/små bogstaver), brugerbiblioteker og rettigheder fører til fejl ved eksport, vedhæftninger, midlertidige filer eller caches. Her hjælper et konsekvent abstraktionskoncept: centrale sti-services, definerede applikationsmapper, ingen hårdkodede lagringssteder.

Udskrivning, PDF og Office-integration

Udskrivnings- og dokumentarbejdsgange er ofte kritiske i forretningsprocesser. Windows har etablerede udskrivningsstier, macOS og Linux opfører sig anderledes. Hvis PDF-generering, signaturer eller kvitteringsudskrifter er relevante, bør disse funktioner testes tidligt på alle målapparater – ikke først lige før rollout.

Unicode og tegnsæt

Senest ved blandede platforme, grænseflader og databaser bliver Unicode (en tegnsætstandard for internationale tegn) et must. Gamle systemer med „ANSI“-historik fremkalder ellers vanskeligt efterfølgelige fejl i søgning, sortering, CSV-eksport eller grænseflader. En Unicode-strategi omfatter UI, databasekolonner, grænseflader og testdata.

32/64-Bit und Bibliotheksabhängigkeiten

En klassiker: En driver eller et tredjepartsbibliotek er kun tilgængeligt i én arkitektur. For driften betyder det: klar afhængighedsliste, dokumentér versioner, tjek licens- og opdateringsmuligheder. En multiplatform-løsning er kun så stabil som den svageste afhængighed.

Entscheidungshilfe: Wann lohnt sich Delphi Multiplattform wirklich?

Et pragmatisk blik på indsats og gevinst hjælper med at objektivere diskussioner. Multiplatform er typisk relevant, wenn:

• kernen af forretningslogik er stabil på lang sigt, og genbrug betaler sig over flere år,
• der er reelle organisatoriske grunde til macOS-Clients (ikke kun ‚det ville være rart‘),
• Linux i backend i forvejen er standard, og services/REST er planlagt,
• applikationen skal integreres i et integrationsnetværk med ERP/DMS/CRM,
• en ordentlig release-proces kan etableres (Build, Signierung, Tests).

Multiplatform er mindre fornuftigt, hvis applikationen i høj grad er afhængig af Windows-specifikke komponenter (f.eks. dyb Office-automation, særlige drivere, COM-baserede integrationer) og disse funktioner ikke kan tydeligt kapsles. Så er en hybridstrategi ofte mere realistisk: Windows-Client til specialtilfælde, Portal/REST til platformneutrale processer.

Modernisierungspfad: Multiplattform ohne kompletten Neustart

For mange virksomheder er det vigtigste punkt: Multiplatform behøver ikke at betyde, at alt skal skrives helt om. En robust vej ser ofte sådan ud:

1. Analyse af status og definition af snitflader: Hvilke moduler er fagligt stabile, hvilke er UI- eller database-nære, hvor findes de største risici?
2. Konsolider dataadgang: f.eks. BDE-Ablösung, BDE-Ablosung mit nativer Anbindung, ensartet connection- og transaktionsstrategi.
3. Etabler et servicelag: REST-API til kerneprocesser, gradvis afvikling af direkte DB-adgang.
4. Prioritér platforme: Stabiliser først backend på Linux, derefter macOS-Client til definerede brugergrupper, i stedet for alt på én gang.
5. Professionalisér Packaging/CI: reproducerbare Builds og Updates som en fast del af projektet.

Denne vej er særligt egnet til individuel virksomhedssoftware med lange livscyklusser, fordi den beskytter faglogik og reducerer tekniske risici på en kontrolleret måde.

Fazit: Multiplattform ist eine Betriebsentscheidung – nicht nur eine Entwicklerentscheidung

Delphi Multiplattform für Windows, macOS und Linux kan for virksomheder være en meget pragmatisk vej til at videreudvikle etablerede processer teknisk, uden at miste den faglige kerne. Afgørende er at planlægge Multiplatform som et samlet pakke: Arkitektur med klare lag, konsolideret dataadgang, serviceorienterede grænseflader, reproducerbare Builds, ordentligt Packaging og en Logging-/Monitoring-Strategie, der hurtigt afklarer supportsager.

Når disse forudsætninger er på plads, bliver arbejdet på tværs af platforme ikke et evighedsprojekt, men en kontrollerbar udvidelse af jeres digitale virksomhedsløsning – med realistiske driftsomkostninger og en roadmap, der forbinder migration og videreudvikling.

Hvis I ønsker at vurdere jeres udgangssituation (eksisterende systemer, målplatforme, database, grænseflader og driftsmodel) struktureret: Kontakt os for en teknisk indledende samtale.

I det faglige miljø spiller også Delphi Modernisering en vigtig rolle, når integrationer, dataflows og videreudvikling skal indgå i et ordnet samspil.

Drøft projekt eller moderniseringsforløb med Net-Base.