Delphi Multiplatformní řešení pro Windows, macOS a Linux: architektura, provoz a typické úskalí

Když se ve firmách mluví o Delphi Multiplattform pro Windows, macOS a Linux, zřídka jde o „techniku pro techniku samu“. Většinou je za tím konkrétní situace: Dlouhodobě rostoucí podnikový software běží spolehlivě na Windows, ale oborová oddělení požadují macOS klienty, IT týmy chtějí Linux-services integrovat do existujících serverových standardů, nebo je plánována modernizace bez přepisování veškeré funkcionality.

Delphi může v tomto napětí představovat pragmatický most – za předpokladu, že se multiplatforma chápe jako provozní a architektonické téma. Skutečné náklady totiž nevznikají při prvním buildu, ale při údržbě, procesu vydávání, bezpečnostních aktualizacích, přístupu k datům, v oblasti ovladačů, balíčkování a podpoře. Tento příspěvek objasňuje, jak multiplatformu realisticky plánovat, které technické volby budou v provozu znát a na které nástrahy projekty typicky narážejí až pozdě.

Proč multiplatforma ve firmách zřídka bývá „jen funkcí“

V praxi potřebu multiplatformnosti pohánějí tři typické faktory:

• Heterogenní koncová zařízení: Windows je zavedený standard, macOS přichází z managementu, prodeje, designu nebo vedení. Linux se objeví buď jako desktop v specializovaných prostředích, nebo jako serverový standard v datovém centru.
• Standardizace v provozu: Mnoho IT oddělení chce konsolidovat služby na Linux (monitoring, správu balíků, hardening), i když klienti nadále zůstanou Windows.
• Modernizace bez Big Bangu: Stávající aplikace by měly být krok za krokem převedeny do udržovatelných vrstev, často paralelně s projekty databází a rozhraní.

Důležité je rozlišení: Multiplatforma na klientovi (desktopová aplikace) je jiné téma než multiplatforma v backendu (services/REST). Zvláště v B2B kontextu se často vyplatí hybridní přístup: stabilní Windows klienti, ale serverově Linux-services a REST-API pro integraci, automatizaci a webové portály.

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

Multiplatform v Delphi není kouzelná hůlka, ale sada nástrojů. Pro IT a provoz jsou přitom rozhodující tři úrovně:

• UI-vrstva: Na Windows v mnoha společnostech existuje zavedený svět VCL (klasické Windows rozhraní). Pro skutečné multiplatformní klienty se obvykle používá FireMonkey (FMX), které umožňuje stejný uživatelský povrch na různých operačních systémech – s jejich nativními zvláštnostmi.
• Doménová logika: Hlavní páka spočívá ve společné, čistě zapouzdřené logice. Kdo oddělí doménovou logiku a přístup k datům od UI, může měnit platformy, aniž by produkt musel být znovu vynalezen.
• Runtime a deployment: Každá platforma má jiné požadavky na instalaci, oprávnění, podepisování, aktualizace, cesty, certifikáty a knihovny. Právě zde se rozhoduje, zda je multiplatforma v běžném provozu „lehké“ nebo „nákladné“.

Pro rozhodovatele tedy není klíčová otázka „Kann Delphi macOS und Linux?“, ale: Které části našeho řešení skutečně musí být multiplatformní – a jak zajistíme provoz a udržovatelnost po léta?

Architektura: Největší multiplikátor nákladů na údržbu

Projekty pro více platforem zřídka selhávají kvůli kompilátoru, ale kvůli chybějícímu oddělení. V existujících aplikacích je často vše zamícháno: UI-události, přístup k databázi, obchodní logika, tisk, souborový systém, síťová volání. To funguje na „tom jednom Windows-PC“, ale stává se trvalou údržbovou zátěží, jakmile rozšíříte platformy nebo přenesete služby.

Vrstevný model místo „formuláře jako středobod“

Osvědčil se jasný vrstevný model (často nazývaný vrstvená architektura):

• Prezentace: Desktopové UI (VCL nebo FMX) nebo webové frontendy.
• Aplikační a obchodní logika: pravidla, pracovní postupy, oprávnění, validace; ideálně bez přímé závislosti na UI nebo ovladačích databáze.
• Integrační vrstva: napojení na ERP/DMS/CRM, souborová rozhraní, Messaging, REST.
• Přístup k datům: konsolidovaný přístup přes jasně definované hranice repository-/service, místo SQL na každém rohu.

Toto oddělení není akademické cvičení: snižuje specifika platforem, usnadňuje testy, umožňuje serverové komponenty a činí migrace databází (např. na PostgreSQL) výrazně lépe kontrolovatelnými.

Společná obchodní logika: Multiplatformně bez duplicitního vývoje

Pokud to s multiplatformností myslíte vážně, měla by být obchodní logika navržena tak, aby běžela stejně v desktopové aplikaci i v servisu. To je zvlášť relevantní, pokud později doplníte zákaznický portál, interní webové rozhraní nebo integraci REST. V praxi to znamená: odborná rozhodnutí patří do služeb/modulů, ne do událostí kliknutí formuláře.

Strategie UI: zachovat VCL, FMX cíleně použít, web doplnit

Mnoho společností má silnou Windows-desktopovou bázi. Okamžitý přechod na novou UI technologii je často zbytečně rizikový. Typické osvědčené strategie jsou:

Strategie A: Windows-klient zůstává VCL, Backend se stává platformně neutrální

Zde se základní logika postupně extrahuje z VCL-aplikace: do knihoven a serverových komponent. Výsledek: Windows-klient zůstává stabilní, zatímco integrace, automatizace a nová frontendy vznikají přes služby. Linux se pak uplatní v provozu serveru (např. REST-Server nebo služby na pozadí).

Strategie B: Multiplatformní klient s FMX pro definované scénáře

FMX dává smysl, pokud skutečně potřebujete tentýž klient na Windows a macOS, například pro terénní pracovníky, mobilní pracoviště nebo smíšené flotily. Důležité: detaily UI (písma, klávesové zkratky, dialogy, výběr souborů) se liší podle platformy. To je třeba zahrnout do testů a podpory.

Strategie C: Desktop doplněný portálem

Mnoho společností neřeší téma „macOS“ pomocí plnohodnotného klienta, ale portálem pro jasně vymezené procesy: dotazy, schválení, stav zakázek, dokumenty. To uleví desktopovým nasazením, sníží nároky na instalaci a často se dá rychleji zabezpečit, protože centrální webová vrstva je snáze kontrolovatelná.

Přístup k datům a databáze: FireDAC jako provozní faktor stability

V multiplatformních architekturách je přístup k datům často oblastí, ve které se historické zátěže nejvíce prodražují. Zvláště starší Delphi-systémy jsou závislé na Borland Database Engine (BDE) nebo na ovladačích, které fungují správně pouze na Windows. Pro provoz to představuje riziko: dostupnost ovladačů, otázky 32/64 bitů, Unicode, bezpečnostní záplaty a monitoring jsou obtížně zvládnutelné.

Strategie ovladačů: jednotná, dokumentovaná, testovatelná

BDE-nahrazení s nativním napojením je v Delphi běžná datová přístupová vrstva, která jednotně oslovuje různé databáze. Operativně relevantní není tolik „jak elegantně“ to vypadá v kódu, ale:

• Které klientské knihovny jsou potřeba? (např. klienty PostgreSQL, MariaDB nebo Oracle)
• Jak budou distribuovány? Součást instalátoru, centrálně spravované, obraz kontejneru
• Jak jsou parametry připojení bezpečně spravovány? (secrets, chráněná konfigurace, žádná hesla v prostém textu v souborech)
• Jak stabilní je chování při síťových výpadcích? opakování pokusů (retries), timeouty, pooling

Migrace databází: Multiplatforma jako příležitost pro čisté rozhraní

Pokud se platformy stejně rozšiřují, je to často správný čas konsolidovat přístup k datům. Migrace (např. od starých souborových nebo embedded databází k SQL systémům jako PostgreSQL nebo SQL Server) by měla probíhat jako projekt s jasnými fázemi: datový model, migrační nástroje, paralelní provoz, akceptace, plán rollbacku. Multiplatforma zde zvyšuje tlak, protože ovladače typu „Windows-only“ nebo cesty k souborům na macOS/Linux přestanou fungovat.

Služby a rozhraní: REST jako most mezi platformami

V heterogenních prostředích je přístup REST (REST = HTTP-založené rozhraní s jasnými zdroji a metodami) často nejpraktičtější cesta, jak propojit platformy. Pro provoz to znamená: centrální autentizaci, standardizované protokoly, lepší observability (logy/metriky) a čisté oddělení mezi klientem a databází.

Delphi REST-Server vs. přímý přístup k DB z klienta

Mnoho stávajících desktopových řešení pracuje s přímým přístupem k databázi z klienta. V čistých Windows-sítích to dlouho bylo běžné. S multiplatformou a moderní bezpečností to však bude obtížnější:

• Segmentace sítě: Databáze už neleží ve stejné síti jako klienti; firewally jsou přísnější.
• VPN/Zero Trust: Přímá DB připojení přes měnící se sítě jsou náchylná k chybám.
• Audit a oprávnění: Aplikační práva je těžké konzistentně zajistit, pokud každý klient přímo volá SQL.

Server REST-Server (nebo servisní vrstva) může tyto body centralizovat: autentizace, oprávnění, protokolování, omezení počtu požadavků, verzování. Pro administrátory je to často snazší provozovat než „sto klientů s přístupem k databázi“.

Autentizace a SSO: SAML 2.0, OAuth, tokeny

V B2B prostředí je Single Sign-on (SSO) často povinnost. SAML 2.0 (standard pro identity-federaci mezi Identity Provider a aplikací) nebo OAuth/OpenID Connect (tokenově založené postupy) jsou typické stavební kameny. Rozhodující není marketingové heslo, ale provozní otázka: Kde jsou identity uloženy, jak probíhá provisioning, jak jsou tokeny zabezpečeny a jak jsou přístupy auditně zaznamenávány?

Nasazení a balení: Podceňované náklady

Delphi Multiplattform pro Windows, macOS a Linux znamená také: tři světy v balení. Mnoho nákladů vzniká až po prvním go-live, když je třeba pravidelně rozesílat aktualizace.

Windows: Installer, práva, služby

Na Windows jsou běžné MSI/procesy instalátoru, skupinové zásady, UAC (User Account Control) a podepisování kódu. Jakmile je zapojen Windows- a Linux-service, přibývají další témata: servisní účet, práva na souborovém systému a v síti, pořadí spouštění, možnosti obnovy a rotace logů. Pro údržbu je důležité, aby byla služba jasně verzovaná a aby se dala aktualizovat bez manuálních zásahů.

macOS: Notarizace, podepisování a Gatekeeper

macOS obvykle vyžaduje pro distribuované aplikace podepisování a v závislosti na distribuční cestě i notarizaci (ověřovací proces, aby Gatekeeper aplikaci spustil). Pro firmy to není primárně „Apple-problém“, ale procesní otázka: Kdo drží certifikáty, jak probíhá build-pipeline, jak se vytvářejí reprodukovatelné releasy? Bez této disciplíny se každý hotfix stává jednotlivou akcí.

Linux: Balíčky, závislosti, systemd

Na Linux jsou relevantní systemd jednotky (definice, jak se služby spouštějí a monitorují), formáty balíčků (např. DEB/RPM) nebo kontejnerová nasazení. Pro administrátory platí: jasná konfigurace, definované cesty, smysluplné logy (např. přes journald), health-checky a update-cesta kompatibilní s politikou vlastní distribuce.

CI/CD a release proces: Multiplatforma potřebuje reprodukovatelné buildy

Nejpozději se třemi cílovými platformami se „ruční build“ stává rizikem. CI/CD (Continuous Integration/Continuous Delivery) zde nemusí nutně znamenat „vše plně automaticky do produkce“, ale především: reprodukovatelné artefakty, dohledatelné verze a standardizovaný testovací a schvalovací proces.

V praxi byste měli alespoň stanovit:

• Build-matrix: Které platformy, které varianty (Debug/Release), které databázové ovladače, které volitelné moduly?
• Verzování: Jednotné čísla verzí pro klienta a server, plus stav migrací databáze.
• Podepisování: Kde se podepisuje, jak jsou klíče chráněny (např. HSM nebo zabezpečení build-agentů)?
• Smoke-testy: Minimální funkční kontroly pro každou platformu, které mohou blokovat každého kandidáta na release.

Pro rozhodovatele jde o governance téma: Bez release disciplíny se multiplatforma v čase prodražuje, protože chybové stavy se hůře reprodukují a hotfixy mohou mít platformově odlišné vedlejší účinky.

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

V běžném provozu potřebují IT týmy rychlé odpovědi: „Proč proces uvízl?“, „Je to problém klienta nebo backendu?“, „Od kdy se to objevuje?“ Multiplatformní provoz zvyšuje variabilitu, takže je potřeba zlepšit observabilitu.

Jednotná logovací strategie mezi klientem a serverem

Osvědčila se víceúrovňová logovací strategie:

• Klientské logy: lokální logy s rotací, jednoznačný korelační odkaz (např. Request-ID), v souladu s ochranou osobních údajů.
• Serverové logy: centralizované uložení, strukturované záznamy (časově přesné, strojově čitelné), oddělení auditních a debug logů.
• Metriky: doby odezvy, míra chyb, délky front, vytížení databázového poolu.

Právě u REST-architektur je Request-ID (jedinečný identifikátor pro každý požadavek, který se předává všemi komponentami) neocenitelná, protože se díky ní dají podpůrné případy omezit během minut místo hodin.

Zpracování pádů a symbolizované vyhodnocení chyb

Na desktopových platformách musí být crash-dumpy a stacktracy zpracovány tak, aby byly pro podporu použitelné, aniž by došlo k úniku citlivých údajů. To je organizační otázka: Jaká data lze přenášet? Jak se získává souhlas? Jak jsou zabezpečeny debug symboly a jak se přiřazují verze? Bez zodpovězení těchto otázek zůstává multiplatformní podpora často tápáním v mlze.

Bezpečnost a soulad: Různé platformy znamenají odlišné vektory útoku

S Windows, macOS a Linux se riziko automaticky nezvyšuje, ale povrch útoku se stává rozmanitějším. Typické body, které se v projektech často řeší pozdě:

• Správa certifikátů: TLS certifikáty pro servery, klientské certifikáty, doby expirace, automatizovaná obnova.
• Secrets: databázová hesla, API klíče, podpisové klíče – nesmí být v konfiguracích v otevřeném textu nebo v instalačních skriptech.
• Práva a role: zásada nejmenších oprávnění pro služby, jasné oddělení administrátorských a uživatelských funkcí.
• Schopnost aktualizace: bezpečnostní opravy musí být rychle nasaditelné; to závisí přímo na balíčkování a release procesech.

Zvláště ve firmách s auditorskými požadavky se vyplatí brzy definovat krátký bezpečnostní kontrolní seznam pro každou platformu a zahrnout ho do akceptace.

Typické nástrahy z multiplatformních projektů

Některé problémy se opakují – ne proto, že týmy „pracují špatně“, ale protože byly v historii pouze Windows neviditelné:

Souborový systém a cesty: Malý detail, velký dopad

Různé konvence cest, case-sensitivity (velká/malá písmena), uživatelské adresáře a práva vedou k chybám při exportech, připojeních, dočasných souborech nebo cache. Pomůže důsledné abstrakční řešení: centrální path služby, definované aplikační adresáře, žádná „tvrdě zakódovaná“ místa pro uložení.

Tisk, PDF a integrace Office

Workflows tisku a dokumentů jsou v byznysových procesech často kritické. Windows má zavedené tiskové cesty, macOS a Linux se chovají jinak. Pokud je relevantní generování PDF, podpisy nebo tisk dokladů, měly by být tyto funkce testovány brzy na všech cílových platformách – ne až těsně před nasazením.

Unicode a znakové sady

Nejpozději u smíšených platforem, rozhraní a databází se Unicode (standard znakových sad pro mezinárodní znaky) stává nutností. Starší zásoby s „ANSI“ historií jinak způsobují těžko vysledovatelné chyby při vyhledávání, třídění, CSV exportech nebo rozhraních. Strategie pro Unicode zahrnuje UI, databázové sloupce, rozhraní a testovací data.

32/64-bit a závislosti knihoven

Klasička: ovladač nebo knihovna třetí strany je dostupná pouze pro jednu architekturu. Pro provoz to znamená: jasný seznam závislostí, dokumentování verzí, ověření licencí a možnosti aktualizací. Multiplatformní nasazení je tak stabilní pouze jako jeho nejslabší závislost.

Pomoc při rozhodování: Kdy se Delphi multiplatformní řešení skutečně vyplatí?

Pragmatický pohled na náklady a přínos pomáhá diskuse zpřesnit. Multiplatformní přístup se typicky vyplatí, pokud:

• je odborné jádro dlouhodobě stabilní a opětovné využití se vyplatí v průběhu let,
• existují skutečné organizační důvody pro macOS-klienty (nejen „by bylo hezké“),
• Linux v backendu je tak jako tak standard a služby/REST jsou plánovány,
• aplikace musí být integrována do integrační sítě z ERP/DMS/CRM,
• lze vybudovat čistý release proces (build, podepisování, testy).

Méně smysluplné je multiplatformní řešení, pokud aplikace silně závisí na komponentách specifických pro Windows (např. hluboká Office-automatizace, speciální ovladače, COM‑založené integrace) a tyto funkce nelze jasně zapouzdřit. V takovém případě je realistická často smíšená strategie: Windows‑klient pro speciální případy, portál/REST pro platformně neutrální procesy.

Směr modernizace: Multiplatformně bez kompletního restartu

Pro mnoho firem je klíčové: multiplatformní neznamená nutně vše přepsat. Robustní cesta často vypadá takto:

1. Analýza stávajícího stavu a definice rozhraní: Které moduly jsou doménově stabilní, které jsou blízko UI nebo databáze, kde jsou největší rizika?
2. Konsolidovat přístup k datům: např. BDE-nahrazení, BDE-Ablosung mit nativer Anbindung, jednotná strategie připojení a transakcí.
3. Zavedení servisní vrstvy: REST‑API pro klíčové procesy, postupné nahrazování přímého přístupu k DB.
4. Upřednostnění platforem: Nejprve stabilizovat backend na Linux, pak macOS‑klienta pro definované skupiny uživatelů, místo všeho najednou.
5. Profesionalizace balení a CI: reprodukovatelné sestavení a aktualizace jako pevná součást projektu.

Tato cesta je zvláště vhodná pro individuální podnikový software s dlouhými životními cykly, protože chrání doménovou logiku a kontrolovaně snižuje technická rizika.

Závěr: multiplatformní řešení je provozní rozhodnutí – nejen rozhodnutí vývojářů

Delphi multiplatformní řešení pro Windows, macOS a Linux může pro firmy představovat velmi pragmatickou cestu, jak technicky dál rozvíjet vybudované procesy, aniž by se ztratilo doménové jádro. Rozhodující je plánovat multiplatformní přístup jako celek: architektura s jasnými vrstvami, konsolidovaný přístup k datům, rozhraní připravená pro služby, reprodukovatelné buildy, čisté balení/distribuce a strategie logování/monitoringu, která rychle vyjasní podpůrné případy.

Když jsou tyto základy položeny, nestane se multiplatformní řešení nekonečným projektem, ale kontrolovatelným rozšířením vašeho digitálního podnikového řešení – s realistickými provozními náklady a roadmapou, která propojuje migraci a další vývoj.

Pokud chcete strukturovaně vyhodnotit vaši výchozí situaci (stav, cílové platformy, databázi, rozhraní a provozní model): Kontaktujte nás pro technické úvodní jednání.

V odborném prostředí hraje také Delphi Modernisierung důležitou roli, když musí integrace, datové toky a další vývoj hladce spolupracovat.

Projednat projekt nebo modernizační záměr s Net-Base.