Delphi Multiplataforma per Windows, macOS i Linux: Arquitectura, explotació i esculls típics

Quan a les empreses es parla de Delphi Multiplattform per a Windows, macOS i Linux, rarament es tracta de «tecnologia per la tecnologia». Sovint hi ha una situació concreta al darrere: un programari empresarial evolucionat funciona de manera fiable a Windows, però les unitats de negoci demanen clients macOS, els equips d’IT volen integrar Linux-Services als estàndards de servidor existents, o bé cal una modernització sense tornar a desenvolupar tot el conjunt funcional.

Delphi pot ser en aquest escenari un pont pragmàtic —sempre que la multiplataforma es consideri un tema d’operació i d’arquitectura. Perquè els costos reals no apareixen en el primer build, sinó en el manteniment, el procés de release, les actualitzacions de seguretat, l’accés a dades, el ventall de controladors, la paquetització i el suport. Aquest article situa com planificar la multiplataforma de manera realista, quines decisions tècniques es noten en l’operació i quins paranys solen aparèixer tard en els projectes.

Per què la multiplataforma rarament és „només una característica“ en les empreses

En la pràctica, la necessitat de multiplataforma sorgeix de tres impulsors típics:

• Dispositius heterogenis: Windows està establert, macOS s’afegeix des de direcció, vendes, disseny o nivells de gestió. Linux apareix com a desktop en entorns especials o com a estàndard de servidor al centre de dades.
• Estandarització en l’operació: Molts departaments d’IT volen consolidar serveis sobre Linux (monitorització, gestió de paquets, endureixement), encara que els clients continuïn sent Windows.
• Modernització sense Big Bang: Les aplicacions existents s’han de migrar pas a pas a capes mantenibles, sovint en paral·lel amb projectes de base de dades i interfícies.

És important la distinció: Multiplatform al client (aplicació d’escriptori) és una cosa diferent que Multiplatform al backend (Services/REST). Especialment en context B2B sovint és adequat un enfocament híbrid: clients Windows estables, però al costat del servidor Linux-Services i APIs REST per a integració, automatització i portals web.

Delphi Multiplattform per a Windows, macOS i Linux: què significa això en concret

La multiplataforma en Delphi no és una vareta màgica, sinó una caixa d’eines. Per a l’àmbit d’IT i d’operacions hi ha tres capes decisives:

• Capa UI: A Windows existeix en moltes empreses un món VCL establert (la clàssica interfície Windows). Per a clients multiplataforma reals normalment entra en joc FireMonkey (FMX), que permet la mateixa interfície en diferents sistemes operatius —amb les seves peculiaritats natives en cada cas.
• Lògica de negoci: El gran palanca està en una lògica comuna i netament encapsulada. Qui separa la lògica de negoci i l’accés a dades de la UI pot canviar de plataformes sense haver de reinventar el producte.
• Temps d’execució i desplegament: Cada plataforma té requisits diferents respecte a instal·lació, permisos, signatura, actualitzacions, rutes, certificats i biblioteques. Precisament aquí es decideix si la multiplataforma en el dia a dia és «fàcil» o «cara».

Per als decisors, per tant, la pregunta clau no és «Pot Delphi macOS i Linux?», sinó: Quines parts de la nostra solució han de ser realment multiplataforma — i com assegurem l’operació i la mantenibilitat durant anys?

Arquitectura: El major multiplicador dels costos de manteniment

Els projectes multiplataforma rarament fallen pel compilador, sinó per la manca de desacoblament. En aplicacions existents sovint està tot barrejat: esdeveniments de UI, accés a base de dades, lògica de negoci, impressió, sistema de fitxers, trucades de xarxa. Això funciona en «l’únic Windows-PC», però es converteix en una obra permanent tan bon punt amplieu plataformes o externeu serveis.

Model de capes en lloc de «el formulari com a centre neuràlgic»

Una estructura clara per capes (sovint anomenada arquitectura en capes) ha demostrat la seva eficàcia:

• Presentació: UI d’escriptori (VCL o FMX) o frontends web.
• Lògica d’aplicació i de negoci: regles, fluxos de treball, permisos, validacions; idealment sense dependència directa de la UI ni dels controladors de base de dades.
• Capa d’integració: connexió amb ERP/DMS/CRM, interfícies de fitxers, missatgeria, REST.
• Accés a dades: accés consolidat a través de límits de repositori/servei clarament definits, en lloc de SQL a cada cantonada.

Aquesta separació no és un exercici acadèmic: redueix els casos especials per plataforma, facilita les proves, permet components en costat servidor i fa que les migracions de base de dades (p. ex. a PostgreSQL) siguin molt més controlables.

Lògica de negoci compartida: Multiplataforma sense desenvolupament duplicat

Si us preneu seriosament el multiplataforma, la lògica de negoci hauria d’estar dissenyada perquè pugui executar-se tant en una aplicació d’escriptori com en un servei. Això és especialment rellevant si més endavant afegiu un portal de clients, una interfície web interna o una integració REST. A la pràctica això vol dir: les decisions de negoci pertanyen a serveis/mòduls, no als esdeveniments de clic d’un formulari.

Estratègia d’UI: conservar VCL, fer servir FMX de manera selectiva, complementar amb web

Moltes empreses disposen d’una base d’escriptori sòlida Windows. Un canvi immediat a una nova tecnologia d’UI sovint és innecessàriament arriscat. Estratègies típiques i viables són:

Estratègia A: el client Windows continua sent VCL, el backend es torna neutral respecte a la plataforma

Aquí la lògica central s’extreu pas a pas de l’aplicació VCL: cap a biblioteques i components en costat servidor. Resultat: el client Windows roman estable, mentre la integració, l’automatització i nous frontends s’implementen mitjançant serveis. Linux entra aleshores en joc amb l’operació del servidor (p. ex. REST-Server o serveis en background).

Estratègia B: client multiplataforma amb FMX per a escenaris definits

FMX té sentit si realment necessiteu el mateix client a Windows i macOS, per exemple per a personal de camp, llocs de treball mòbils o flotes mixtes. Important: els detalls de la UI (fonts, drecers de teclat, diàlegs, selecció de fitxers) difereixen segons la plataforma. Això ha d’incloure’s en les proves i en el suport.

Estratègia C: escriptori complementat per un portal

Moltes empreses no resolen el tema «macOS» mitjançant un client complet, sinó mitjançant un portal per a processos clarament delimitats: consultes, aprovacions, estat de comandes, documents. Això alleugereix els desplegaments d’escriptori, redueix l’esforç d’instal·lació i sovint és més ràpid de reforçar, perquè la capa web central és més fàcil de controlar.

Accés a dades i bases de dades: FireDAC com a factor d’estabilitat operativa

En arquitectures multiplataforma l’accés a dades sovint és l’àrea on les càrregues històriques es tornen més costoses. Especialment els sistemes Delphi més antics depenen de la Borland Database Engine (BDE) o de controladors que només funcionen correctament a Windows. Per a l’operació això és un risc: disponibilitat dels controladors, qüestions de 32/64 bits, Unicode, pegats de seguretat i monitoratge són difícils de dominar.

Estratègia de controladors: homogènia, documentada, verificable

BDE-Ablösung mit nativer Anbindung és a Delphi una capa d’accés a dades estesa que tracta diverses bases de dades de manera homogènia. Operativament és rellevant menys «com d’elegant» sembla això al codi, i més bé:

• Quines biblioteques client es necessiten? (p. ex. client de PostgreSQL, MariaDB o Oracle)
• Com es distribueixen? Part de l’instal·lador, gestionats centralment, imatge de contenidor
• Com es gestionen de manera segura els paràmetres de connexió? (Secrets, configuració protegida, no contrasenyes en text clar en fitxers)
• Com d’estable és el comportament davant d’interrupcions de xarxa? Reintents, temps d’espera (timeouts), pooling

Migracions de bases de dades: la multiplataforma com a ocasió per definir interfícies netes

Si de totes maneres s’amplien plataformes, sovint és el moment adequat per consolidar l’accés a dades. Una migració (p. ex. de vells formats de fitxer o bases de dades embegudes a sistemes SQL com PostgreSQL o SQL Server) hauria de funcionar com un projecte amb fases clares: model de dades, eines de migració, funcionament paral·lel, acceptació, pla de rollback. La multiplataforma augmenta la pressió perquè els controladors «Windows-only» o les rutes de fitxer a macOS/Linux deixen de funcionar.

Serveis i interfícies: REST com a pont entre plataformes

En paisatges heterogenis sovint un enfocament REST (REST = interfície basada en HTTP amb recursos i mètodes clars) és el camí més pragmàtic per connectar plataformes. Per a l’operació això significa: autenticació centralitzada, protocols estandarditzats, millor observabilitat (logs/mètriques) i una desconnexió neta entre client i base de dades.

Delphi REST-servidor vs. accés directe a la base de dades des del client

Moltes solucions d’escriptori existents treballen amb accés directe a la base de dades des del client. En xarxes purament Windows això va ser habitual durant molt de temps. Amb multiplataforma i seguretat moderna això es complica:

• Segmentació de xarxa: les bases de dades ja no estan en la mateixa xarxa que els clients; els tallafocs són més restrictius.
• VPN/Zero Trust: les connexions directes a la base de dades a través de xarxes canviants són propenses a errors.
• Auditoria i permisos: és difícil reflectir correctament els permisos funcionals a l’aplicació si cada client parla SQL directament.

Un REST-Server (oder eine Service-Schicht) pot centralitzar aquests punts: autenticació, permisos, registrament, limitació de taxa, versionat. Per als administradors sovint és més senzill d’operar que «cent clients amb accés a la base de dades».

Autenticació i SSO: SAML 2.0, OAuth, tokens

En l’entorn B2B, el Single Sign-on (SSO) sovint és obligatori. SAML 2.0 (un estàndard per a la federació d’identitats entre el proveïdor d’identitat i l’aplicació) o OAuth/OpenID Connect (procediments basats en tokens) són components típics. El decisiu no és el terme de moda, sinó la qüestió operativa: on es troben les identitats, com funciona el Provisioning, com es protegeixen els tokens i com es registren els accessos de manera revisions-fàcil?

Desplegament i empaquetatge: l’esforç subestimat

Delphi Multiplattform per a Windows, macOS i Linux també significa: tres mons en l’empaquetatge. Molts costos sorgeixen només després del primer go-live, quan les actualitzacions s’han de desplegar regularment.

Windows: Instal·lador, permisos, serveis

En Windows són habituals els processos MSI/installer, les polítiques de grup, UAC (User Account Control) i el code-signing. Tan aviat com hi participa un Windows- i Linux-serveis, apareixen temes addicionals: compte de servei, permisos al sistema de fitxers i a la xarxa, ordre d’inici, opcions de recuperació i rotació de logs. Per al manteniment és important que el servei estigui clarament versionat i que es pugui actualitzar sense intervenció manual.

macOS: Notarització, signatura i Gatekeeper

macOS sol requerir per a aplicacions distribuïdes la signatura i, segons la via de distribució, una notarització (procés de comprovació perquè el Gatekeeper executi l’aplicació). Per a les empreses això és menys un «tema d’Apple» i més un problema de procés: qui manté els certificats, com funciona la build-pipeline, com es generen els releases de manera reproductible? Sense aquesta disciplina, cada hotfix esdevé una actuació aïllada.

Linux: Paquets, dependències, systemd

En Linux són rellevants les systemd-units (definicions de com s’inicien i es monitoritzen els serveis), els formats de paquet (p. ex. DEB/RPM) o els desplegaments basats en contenidors. Per als administradors compta: configuració clara, rutes definides, logs significatius (p. ex. via journald), health checks i un camí d’actualització compatible amb la política de distribució pròpia.

CI/CD i procés de release: la multiplataforma necessita builds reproductibles

A partir de tres plataformes objectiu, el „build per mà“ esdevé un risc. CI/CD (Continuous Integration/Continuous Delivery) no vol dir necessàriament «tot automàtic a producció», sinó sobretot: artefactes reproductibles, versions rastrejables i un procés estandarditzat de proves i aprovació.

En la pràctica caldria, com a mínim, establir:

• Build-Matrix: quines plataformes, quines variants (Debug/Release), quins controladors de base de dades, quins mòduls opcionals?
• Versionament: números de versió unificats per a client i servidor, més els estats de migració de la base de dades.
• Signatura: on es signa, com es protegeixen les claus (p. ex. HSM o agents de build assegurats)?
• Smoke-Tests: comprovacions funcionals mínimes per plataforma que puguin bloquejar qualsevol candidat a release.

Per a qui pren decisions, això és una qüestió de governança: sense disciplina de release la multiplataforma surt més cara amb els anys, perquè els patrons d’error són més difícils de reproduir i els hotfixes provoquen efectes secundaris diferents segons la plataforma.

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

En el dia a dia els equips d’IT necessiten respostes ràpides: «Per què s’ha quedat bloquejat el procés?», «És un problema del client o del backend?», «Des de quan es produeix?» La multiplaforma augmenta la variància, per això cal millorar l’observabilitat.

Estratègia de registre unificada entre client i servidor

S’ha demostrat eficaç una estratègia de registres per nivells:

• Registres del client: registres locals amb rotació, referència de correlació inequívoca (p. ex. Request-ID), complint la normativa de protecció de dades.
• Registres del servidor: emmagatzematge centralitzat, entrades estructurades (amb marca temporal precisa, llegibles per màquina), separació entre logs d’auditoria i de depuració.
• Mètriques: temps de resposta, taxes d’error, longituds de cua, ocupació del pool de base de dades.

Precisament en arquitectures REST una Request-ID (un identificador únic per petició que es fa passar per tots els components) resulta molt valuosa, ja que els casos de suport es poden acotar en minuts en comptes d’hores.

Gestió de fallades i anàlisi d’errors simbolitzada

En les plataformes d’escriptori els crash dumps i els stacktraces han de gestionar-se de manera que siguin útils per al suport sense filtrar dades sensibles. Això és una qüestió organitzativa: quines dades es poden transmetre? Com s’obté el consentiment? Com es protegeixen els símbols de depuració i s’assignen les versions? Sense resoldre aquestes qüestions, el suport multiplataforma sovint esdevé anar a cegues.

Seguretat i compliment: les plataformes signifiquen superfícies d’atac diferents

Amb Windows, macOS i Linux el risc no augmenta automàticament, però la superfície d’atac es fa més diversa. Punts típics que als projectes sovint s’aborden massa tard:

• Gestió de certificats: certificats TLS per a servidors, certificats de client, dates d’expiració, renovació automatitzada.
• Secrets: contrasenyes de bases de dades, claus d’API, claus de signatura — no en configuracions en text clar ni en scripts d’instal·lació.
• Concepte de permisos: principi de mínims privilegis per als serveis, separació neta entre funcions d’administrador i d’usuari.
• Capacitat d’actualització: els fixes de seguretat han de poder desplegar-se ràpidament; això depèn directament del procés de empaquetatge i publicació.

Sobretot en empreses amb requeriments d’auditoria convé definir aviat una breu llista de comprovació de seguretat per plataforma i incloure-la a la validació d’acceptació.

Errors típics en projectes multiplataforma

Alguns problemes reapareixen sovint — no perquè els equips treballin «malament», sinó perquè eren invisibles en històries exclusivament Windows:

Sistema de fitxers i rutes: detall petit, gran efecte

Convencions de rutes diferents, sensibilitat a majúscules/minúscules, directoris d’usuari i permisos condueixen a errors en exportacions, adjunts, fitxers temporals o memòries cau. Aquí ajuda un concepte d’abstracció coherent: serveis de rutes centrals, directoris d’aplicació definits, no fer servir ubicacions d’emmagatzematge «codificades de forma rígida».

Impressió, PDF i integració amb Office

Els fluxos d’impressió i de documents sovint són crítics en processos de negoci. Windows té rutes d’impressió establertes, mentre que macOS i Linux es comporten de manera diferent. Si la generació de PDFs, les signatures o les sortides de comprovants són rellevants, aquestes funcions s’han de provar aviat a totes les plataformes destinació — no només a tocar del desplegament.

Unicode i jocs de caràcters

Com a mínim quan hi ha plataformes, interfícies i bases de dades mixtes, Unicode (un estàndard de jocs de caràcters per a caràcters internacionals) esdevé imprescindible. Els llegats amb historial „ANSI“ en cas contrari generen errors difícilment traçables en la cerca, l’ordenació, les exportacions CSV o les interfícies. Una estratègia Unicode inclou la UI, les columnes de la base de dades, les interfícies i les dades de prova.

32/64 bits i dependències de biblioteques

Un clàssic: un controlador o una biblioteca de tercers només està disponible per a una arquitectura. Per a l’explotació això implica: llista clara de dependències, documentar versions, comprovar la capacitat de llicència i d’actualització. La multiplataforma només és tan estable com la dependència més feble.

Ajuda per a la decisió: Quan val realment la pena Delphi multiplataforma?

Una mirada pragmàtica a esforç i benefici ajuda a fer les discussions més objectives. La multiplataforma sol ser rendible quan:

• el nucli funcional és estable a llarg termini i la reutilització compensa al llarg d’anys,
• hi ha raons organitzatives reals per a macOS-Clients (no només „seria agradable“),
• Linux al backend ja és estàndard i s’estan planificant serveis/REST,
• l’aplicació ha d’integrar-se en una xarxa amb ERP/DMS/CRM,
• es pugui establir un procés de release net (build, signatura, proves).

La multiplataforma té menys sentit quan l’aplicació depèn fortament de components específics de Windows (p. ex. automatització profunda d’Office, controladors especials, integracions basades en COM) i aquestes funcions no són clarament encapsulables. Sovint una estratègia mixta és més realista: Windows-Client per a casos especials, portal/REST per a processos neutrals a la plataforma.

Camí de modernització: multiplataforma sense reinici complet

Per a moltes empreses, el punt més important és: multiplataforma no significa haver de reescriure-ho tot. Un camí robust sovint s’assembla a:

1. Anàlisi de l’estat i definició de punts de contacte: Quins mòduls són estables des del punt de vista funcional, quins són propers a la UI o a la base de dades, on són els majors riscos?
2. Consolidar l’accés a dades: p. ex. BDE-Ablösung, BDE-Ablosung mit nativer Anbindung, estratègia unificada de connexió i transacció.
3. Establir una capa de servei: API de REST per als processos nuclears, substitució gradual de l’accés directe a la base de dades.
4. Prioritzar plataformes: Primer estabilitzar el backend sobre Linux, després macOS-Client per a grups d’usuaris definits, en lloc de fer-ho tot al mateix temps.
5. Professionalitzar el packaging/CI: builds i actualitzacions reproduïbles com a part integral del projecte.

Aquest camí és especialment adequat per a programari empresarial a mida amb cicles de vida llargs, perquè protegeix la lògica funcional i redueix els riscos tècnics de manera controlada.

Conclusió: la multiplataforma és una decisió d’explotació — no només una decisió dels desenvolupadors

Delphi multiplataforma per a Windows, macOS i Linux pot ser per a les empreses un camí molt pragmàtic per desenvolupar tècnicament processos consolidats sense perdre el nucli funcional. El que és decisiu és planificar la multiplataforma com un paquet global: arquitectura amb capes clares, accés a dades consolidat, interfícies orientades a serveis, builds reproduïbles, packaging net i una estratègia de logging/monitorització que resolgui ràpidament els casos d’assistència.

Quan aquestes bases estan establertes, la multiplataforma no es converteix en un projecte indefinit, sinó en una ampliació controlable de la seva solució empresarial digital – amb costos operatius realistes i un full de ruta que integra migració i desenvolupament continu.

Si voleu avaluar de manera estructurada la vostra situació inicial (inventari, plataformes objectiu, base de dades, interfícies i model d’operació): contacteu-nos per a una reunió tècnica inicial.

En l’àmbit tècnic també té un paper important la Delphi modernització, quan cal que les integracions, els fluxos de dades i el desenvolupament continu funcionin de manera integrada i ordenada.

Parlar del projecte o de la iniciativa de modernització amb Net-Base.