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

Når der i virksomheder tales om Delphi Multiplattform for Windows, macOS og Linux, handler det sjældent om «teknik for teknikens skyld». Ofte ligger der en konkret situation bag: En etableret business-software kører stabilt på Windows, men fagafdelinger kræver [[NBML_TERM_4_8b06df02]-klienter, IT-teams vil integrere Linux-services i eksisterende serverstandarder, eller der planlægges en modernisering uden at genudvikle hele funktionaliteten.

Delphi kan i dette spændingsfelt være en pragmatisk bro — forudsat at Multiplattform forstås som et drifts- og arkitekturtema. For de reelle omkostninger opstår ikke ved første build, men i vedligehold, release-processen, sikkerhedsopdateringer, dataadgang, driverlandskab, paketering og support. Dette indlæg sætter i perspektiv, hvordan I realistisk planlægger Multiplattform, hvilke tekniske valg der mærkes i driften, og hvilke faldgruber der typisk dukker op sent i projekter.

Hvorfor Multiplattform i virksomheder sjældent er „kun en funktion“

I praksis opstår behovet for Multiplattform ud fra tre typiske drivere:

• Heterogene endepunkter: Windows er etableret, macOS tilføjes via ledelse, salg, design eller styringsniveauer. Linux optræder enten som desktop i specialmiljøer eller som serverstandard i datacenteret.
• Standardisering i driften: Mange IT-afdelinger ønsker at konsolidere services på Linux (monitoring, pakkestyring, hårdning), selv om klienter fortsat forbliver Windows.
• Modernisering uden Big Bang: Bestående applikationer skal trinvis overføres til vedligeholdelsesvenlige lag, ofte parallelt med database- og integrationsprojekter.

Vigtigt er sondringen: Multiplattform på klienten (desktop-app) er et andet emne end Multiplattform i backend (services/REST). Netop i B2B-konteksten er en hybrid tilgang ofte fordelagtig: stabile Windows-klienter, men serverside Linux-services og REST-API’er til integration, automatisering og web-porte.

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

Multiplattform i Delphi er ikke en tryllestav, men en værktøjskasse. For IT- og driftssiden er tre niveauer afgørende:

• UI-laget: På Windows findes i mange virksomheder en etableret VCL-verden (den klassiske Windows-brugerflade). Til reelle Multiplattform-klienter kommer ofte FireMonkey (FMX) i spil, som muliggør samme brugerflade på forskellige operativsystemer — med hver deres native særheder.
• Forretningslogik: Den største gevinst ligger i fælles, klart kapslet logik. Den, der adskiller forretningslogik og dataadgang fra UI’en, kan skifte platforme uden at genopføre produktet.
• Runtime og deployment: Hver platform stiller forskellige krav til installation, rettigheder, signering, opdateringer, stier, certifikater og biblioteker. Netop her afgøres det, om Multiplattform i dagligdagen er „let“ eller „dyr“.

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 vedligeholdbarhed over år?

Arkitektur: Den største multiplikator for vedligeholdelsesomkostninger

Multiplatform-projekter fejler sjældent på compileren, men på manglende afkobling. I eksisterende applikationer er ofte alt blandet sammen: UI-hændelser, databaseadgang, forretningslogik, udskrivning, filsystem, netværkskald. Det fungerer på „den ene Windows-PC“, men bliver en konstant byggeplads, så snart I udvider platforme eller udlægger services.

Lagmodel i stedet for „formularen som omdrejningspunkt“

En klar lagdelt arkitektur (ofte kaldet layer-arkitektur) har vist sig at virke:

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

Denne adskillelse er ikke en akademisk øvelse: Den reducerer platformspecifikke undtagelser, 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 forretningslogikken være designet, så den kan køre både i en desktop-app og i en service. Det er særligt relevant, hvis I senere vil efterruste en kundeportal, et internt webinterface eller en REST-integration. I praksis betyder det: forretningsmæssige beslutninger hører hjemme i services/moduler, 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-desktopfundament. En øjeblikkelig omlægning til en ny UI-teknologi er ofte unødvendigt risikabel. Typiske holdbare strategier er:

Strategi A: Windows-klienten forbliver VCL, backend bliver platformneutral

Her ekstraheres kernelogikken gradvist fra VCL-applikationen: i biblioteker og serverside-komponenter. Resultat: Windows-klienten 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: Multiplatform-klient med FMX til definerede scenarier

FMX giver mening, hvis I faktisk behøver den samme klient på Windows og macOS, f.eks. til feltservice, mobile arbejdspladser eller blandede enheder. Vigtigt: UI-detaljer (fonte, tastaturgenveje, dialoger, filvalg) adskiller sig pr. platform. Det skal indregnes i test og support.

Strategi C: Desktop suppleret med portal

Mange virksomheder løser ikke „macOS-emnet“ ved en fuld klient, men ved et portal til klart afgrænsede processer: forespørgsler, godkendelser, ordrestatus, dokumenter. Det aflaster desktop-udrulninger, reducerer installationsarbejde og er ofte hurtigere at gøre robuste, fordi det centrale web-lag er lettere at kontrollere.

Dataadgang og databaser: FireDAC som en operationel stabilitetsfaktor

I multiplatform-arkitekturer er dataadgang ofte det område, hvor historiske byrder bliver dyrest. Især ældre Delphi-systemer er bundet til Borland Database Engine (BDE) eller til drivere, der kun fungerer korrekt på Windows. Det udgør en driftmæssig risiko: tilgængelighed af drivere, 32/64-bit-spørgsmål, Unicode, sikkerhedsrettelser og overvågning er svære at håndtere.

Driverstrategi: ensartet, dokumenteret, testbar

BDE-udskiftning med native tilslutning er i Delphi et udbredt dataadgangslag, der adresserer forskellige databaser ensartet. Operationelt er det mindre relevant „hvor elegant“ det ser ud i koden, men snarere:

• Hvilke klientbiblioteker kræves? (f.eks. PostgreSQL-, MariaDB- eller Oracle-klient)
• Hvordan distribueres de? En del af installationsprogrammet, centralt forvaltet, container-image
• Hvordan håndteres forbindelsesparametre sikkert? (secrets, beskyttet konfiguration, ingen adgangskoder i klartekst i filer)
• Hvor stabil er adfærden ved netværksforstyrrelser? retry-mekanismer, timeouts, pooling

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

Når platforme alligevel udvides, er det ofte det rette tidspunkt at konsolidere dataadgangen. En migration (f.eks. fra gamle filformat- eller embedded-databaser til SQL-systemer som PostgreSQL eller SQL Server) bør gennemføres som et projekt med klare faser: datamodel, migrationsværktøjer, parallel drift, accept, rollback-plan. Multiplatform øger presset her, 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 observability (logs/metrikker) og en klar adskillelse mellem klient og database.

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

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

• Netværkssegmentering: Databaser ligger ikke længere i samme netværk som klienter; firewalls bliver strengere.
• VPN/Zero Trust: Direkte DB-forbindelser over skiftende netværk er fejlbehæftede.
• Audit og rettigheder: Faglige rettigheder i applikationen er svære at afbilde korrekt, når hver klient kommunikerer direkte via SQL.

En REST-server (eller et serviceslag) kan centralisere disse punkter: autentificering, rettigheder, logning, rate-limiting, versionering. For admins er det ofte lettere at drifte end „hundrede klienter med databaseadgang“.

Autentificering og SSO: SAML 2.0, OAuth, Token

I B2B-miljøet er Single Sign-on (SSO) ofte obligatorisk. SAML 2.0 (en standard for identitetsfederation mellem Identity Provider og applikation) eller OAuth/OpenID Connect (token-baserede procedurer) er typiske byggesten. Det afgørende er ikke buzzwordet, men driftsaspektet: Hvor ligger identiteterne, hvordan foregår provisioning, hvordan sikres tokens, og hvordan logges adgang 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 det daglige har IT‑teams brug for hurtige svar: „Hvorfor er processen gået i stå?“, „Er det et Client-problem eller et Backend-problem?“, „Siden hvornår opstår det?“ Multiplatform øger variansen, så Observability må blive bedre.

En ensartet Log-Strategie over Client og Server

Bevist er en trininddelt log-strategi:

• Client-Logs: lokale logs med rotation, entydig korrelationsreference (f.eks. Request-ID), databeskyttelsesmæssigt i orden.
• Server-Logs: central lagring, strukturerede poster (tidsmæssigt korrekte, maskinlæsbare), adskillelse af Audit- og Debug-Logs.
• Metriken: svartider, fejlrater, kølængder, database-pool-udnyttelse.

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

Crash-Handling und symbolisierte Fehlerauswertung

På desktopplatforme skal crash-dumps og stacktraces håndteres, så de er anvendelige i supporten uden at lække følsomme data. Det er organisatorisk: Hvilke data må overføres? Hvordan indhentes samtykke? Hvordan sikres Debug-Symbole og tilknyttes versioner? Uden disse afklaringer forbliver Multiplattform-support ofte „fumlen i blinde“.

Sikkerhed und Compliance: Plattformen bedeuten unterschiedliche Angriffsflächen

Med Windows, macOS und Linux øges risikoen ikke automatisk, men angrebsoverfladen bliver mere kompleks. Typiske punkter, der i projekter ofte adresseres for sent:

• Certifikatstyring: TLS-certifikater for Server, Client-certifikater, udløbsdatoer, automatiseret fornyelse.
• Secrets: databasepasswörter, API-Keys, signeringsnøgler – ikke i klartekstkonfigurationer eller i installationsskripter.
• Rettighedskoncept: Least Privilege for tjenester, klar adskillelse mellem Admin- og Anwenderfunktioner.
• Opdaterbarhed: Security-Fixes skal kunne udrulles hurtigt; det afhænger direkte af Packaging- og Release-Prozess.

Især i virksomheder med audit-krav lønner det sig at definere tidligt en kort Security-Checkliste pr. platform og tage den ind i godkendelsen.

Typische Fallstricke aus Multiplattform-Projekten

Nogle problemer dukker igen og igen op – ikke fordi teams „schlecht arbeiten“, men fordi de i Windows-only-historier var usynlige:

Dateisystem und Pfade: Kleines Detail, große Wirkung

Forskellige sti-konventioner, Case-Sensitivity (Groß-/Kleinschreibung), brugermapper og rettigheder fører til fejl ved eksport, vedhæftninger, midlertidige filer eller caches. Her hjælper et konsekvent abstraheringskoncept: centrale Pfad-Services, definerede App-Verzeichnisse, ingen „hart codierten“ lagringssteder.

Druck, PDF und Office-Integration

Udskrifts- og dokumentworkflows er i forretningsprocesser ofte kritiske. Windows har etablerede Druckpfade, macOS und Linux opfører sig anderledes. Hvis PDF-Erzeugung, Signaturen eller Belegausgaben er relevante, bør disse funktioner testes tidligt på alle målplatforme – ikke først kort før rollout.

Unicode und Zeichensätze

Senest ved blandede platforme, grænseflader og databaser bliver Unicode (en tegnsætstandard for internationale tegn) en nødvendighed. Eksisterende data med „ANSI“-historik skaber ellers svært sporbare fejl i søgning, sortering, CSV-eksporter eller interfaces. En Unicode-strategi omfatter UI, databaskolonner, grænseflader og testdata.

32/64-bit og biblioteksafhængigheder

En klassiker: En driver eller et tredjepartsbibliotek findes kun for én arkitektur. For driften betyder det: klar afhængighedsliste, dokumenterede versioner, kontrollérbar licens- og opdateringsevne. Multiplatform er kun så stabil som den svageste afhængighed.

Beslutningshjælp: Hvornår er Delphi Multiplattform virkelig det værd?

Et pragmatisk blik på indsats og gevinst hjælper med at gøre diskussioner mere saglige. Multiplatform giver typisk mening, når:

• den faglige kerne er langsigtet stabil, og genbrug betaler sig over år,
• der er reelle organisatoriske grunde til macOS-clients (ikke kun ‚det ville være rart‘),
• Linux i backend allerede er standard, og services/REST er planlagt,
• applikationen skal indgå i et integrationsnetværk med ERP/DMS/CRM,
• en ren release-proces kan etableres (Build, signering, tests).

Mindst fornuftigt er Multiplattform, når applikationen i høj grad afhænger af Windows-specifikke komponenter (f.eks. dyb Office-automatisering, særlige drivere, COM-baserede integrationer), og disse funktioner ikke kan kapsles tydeligt. Så er en hybridstrategi ofte mere realistisk: Windows-client til specialtilfælde, portal/REST til platformneutral procesunderstøttelse.

Moderniseringsvej: Multiplattform uden komplet genstart

For mange virksomheder er det væsentligste punkt: Multiplattform behøver ikke betyde alt nyt. En holdbar vej ser ofte sådan ud:

1. Ist-Analyse und Schnittkanten definieren: Hvilke moduler er fagligt stabile, hvilke er UI- eller databasenære, hvor er de største risici?
2. Datenzugriff konsolidieren: f.eks. BDE-Ablösung, BDE-Ablosung mit nativer Anbindung, ensartet forbindelses- og transaktionsstrategi.
3. Service-Schicht etablieren: REST-API for kerneprocesser, gradvis udfasning af direkte DB-adgang.
4. Plattformen priorisieren: Stabiliser først backend på Linux, derefter macOS-client for definerede brugergrupper i stedet for alt på én gang.
5. Packaging/CI professionalisieren: Reproducerbare Builds og opdateringer som en fast del af projektet.

Denne vej er særligt velegnet til individuel virksomhedsoftware med lange livscyklusser, fordi den beskytter forretningslogik og kontrolleret nedbryder tekniske risici.

Konklusion: Multiplattform er en driftsbeslutning – ikke kun en udviklerbeslutning

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 Multiplattform som et samlet paket: arkitektur med klare lag, konsolideret dataadgang, serviceegnede grænseflader, reproducerbare Builds, ryddeligt Packaging og en logging-/monitoring-strategi, der hurtigt afklarer supporttilfælde.

Når disse grundlæggende forudsætninger er på plads, bliver multiplatform ikke et varigt projekt, men en kontrolleret udvidelse af jeres digitale virksomhedsløsning – med realistiske driftsomkostninger og en roadmap, der forener 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 faglig sammenhæng spiller også Delphi modernisering en vigtig rolle, når integrationer, dataflows og videreudvikling skal fungere sammen konsistent og vedligeholdbart.

Drøft projekt eller moderniseringsprojekt med Net-Base.