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

Quan a les empreses es parla de Delphi multiplataforma 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 desenvolupat funciona de manera fiable sobre Windows, però els departaments de negoci demanen macOS-clients, els equips de TI volen integrar Linux-serveis en els estàndards de servidor existents, o cal una modernització sense desenvolupar de nou tot l’abast funcional.

Delphi pot ser, en aquest camp de tensions, un pont pragmàtic — sempre que la multiplataforma es comprengui com un tema d’operació i d’arquitectura. Perquè els costos reals no apareixen en la primera compilació, sinó en el manteniment, el procés de llançament, les actualitzacions de seguretat, l’accés a dades, l’ecosistema de controladors, l’empaquetat i el suport. Aquest article situa com planificar la multiplataforma de manera realista, quines decisions tècniques són rellevants en l’operació i quins entrebancs acostumen a aparèixer tard en els projectes.

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

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

• Dispositius finals heterogenis: Windows està establert, macOS arriba a través de gestió, vendes, disseny o direcció. Linux apareix o bé com a escriptori en entorns especials o com a estàndard de servidor al centre de dades.
• Estandardització en l’operació: Moltes àrees de TI volen consolidar serveis sobre Linux (monitoratge, gestió de paquets, enduriment), encara que els clients continuïn sent Windows.
• Modernització sense Big Bang: Les aplicacions existents s’han d’anar traslladant pas a pas a capes mantenibles, sovint en paral·lel amb projectes de bases de dades i interfícies.

És important distingir: multiplataforma al client (aplicació d’escriptori) és una qüestió diferent que multiplataforma al backend (serveis/REST). Especialment en el context B2B sovint convé un enfoc híbrid: clients Windows estables, però al servidor serveis Linux i APIs REST per a integració, automatització i portals web.

Delphi multiplataforma per a Windows, macOS i Linux: què significa concretament

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

• Capa d’interfície (UI): A Windows existeix en moltes empreses un món VCL establert (la interfície clàssica de Windows). Per a veritables clients multiplataforma sovint s’utilitza FireMonkey (FMX), que permet la mateixa interfície en diferents sistemes operatius — amb peculiaritats natives a cadascun.
• Lògica de negoci: El gran palanca està en la lògica comuna i ben encapsulada. Qui separa la lògica de negoci i l’accés a dades de la UI pot canviar de plataforma sense reinventar el producte.
• Temps d’execució i desplegament: Cada plataforma té requeriments diferents d’instal·lació, permisos, signatura, actualitzacions, rutes, certificats i biblioteques. Precisament aquí es decideix si la multiplataforma al dia a dia serà «senzilla» o «costosa».

Per als decisors la pregunta central, per tant, 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 costes de manteniment

Els projectes multiplataforma rarament fallen pel compilador, sinó per la manca de desacoblament. En aplicacions ja existents sovint està tot barrejat: esdeveniments de la interfície d’usuari, accés a la base de dades, lògica de negoci, impressió, sistema de fitxers, trucades de xarxa. Això funciona en el ‚únic‘ Windows-PC, però esdevé una obra permanent tan aviat com amplieu plataformes o externalitzeu serveis.

Model de capes en lloc de „formulari com a punt central“

És recomanable un model de capes clar (sovint anomenat arquitectura en capes):

• Presentació: UI d’escriptori (VCL o FMX) o frontends web.
• Lògica d’aplicació i de domini: regles, workflows, permisos, validacions; idealment sense dependència directa de la UI o dels drivers de base de dades.
• Capa d’integració: connexió amb ERP/DMS/CRM, interfícies de fitxer, missatgeria, REST.
• Accés a dades: accés consolidat a través de límits clars de repositoris/serveis, en lloc d’SQL a cada cantonada.

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

Lògica de domini compartida: multiplataforma sense desenvolupament duplicat

Si preneu seriosament el multiplataforma, la lògica de domini 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 domini han d’estar en serveis/mòduls, no en esdeveniments de clic d’una pantalla.

Estratègia d’interfície: mantenir VCL, fer servir FMX de manera selectiva, complementar amb web

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

Estratègia A: el client Windows es manté VCL, el backend esdevé independent de la plataforma

Aquí la lògica central s’extrau progressivament de l’aplicació VCL: a biblioteques i components del costat servidor. Resultat: el client Windows es manté estable, mentre que la integració, l’automatització i nous frontends s’implementen mitjançant serveis. Linux entra en joc amb l’explotació del servidor (p. ex. REST-servidor o serveis en segon pla).

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

FMX té sentit si realment necessiteu el mateix client en Windows i macOS, per exemple per a personal de camp, estacions de treball mòbils o flotes mixtes. Important: els detalls de la UI (fonts, dreceres de teclat, diàlegs, selecció de fitxers) difereixen segons la plataforma. Això cal tenir-ho en compte en les proves i en el suport.

Estratègia C: escriptori complementat amb un portal

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

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

Dins d’arquitectures multiplataforma, l’accés a dades sovint és l’àrea on els llegats històrics resulten més costosos. Especialment els sistemes més antics Delphi depenen de la Borland Database Engine (BDE) o de controladors que només funcionen correctament a Windows. Per a l’explotació això suposa un risc: disponibilitat dels controladors, qüestions 32/64 bits, Unicode, pegats de seguretat i monitoratge són difícils de controlar.

Estratègia de controladors: uniforme, documentada, verificable

BDE-substitució amb connexió nativa és en Delphi una capa d’accés a dades estesa que tracta diverses bases de dades de manera uniforme. Operativament és menys rellevant «com d’elegant» es veu això en el codi, i més aviat:

• Quines biblioteques client es necessiten? (p. ex. client PostgreSQL, MariaDB o Oracle)
• Com es distribueixen? Inclòs en l’instal·lador, gestionat centralment, imatge de contenidor
• Com es gestionen de manera segura els paràmetres de connexió? (secrets, configuració protegida, cap contrasenya en text pla en fitxers)
• Com d’estable és el comportament davant de fallades de xarxa? Reintents, timeouts, pooling

Migracions de bases de dades: la multiplataforma com a ocasió per a definir límits nets

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

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

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

Delphi REST-servidor vs accés directe a la BD 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 mesures de seguretat modernes resulta més difícil:

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

Un REST-servidor (o una capa de servei) pot centralitzar aquests punts: autenticació, permisos, registre, limitació de taxa, versionat. Per als administradors sovint és més fàcil 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 que importa no és la paraula de moda, sinó la qüestió operativa: on resideixen les identitats, com es fa l’aprovisionament, com es protegeixen els tokens i com es registren els accessos amb validesa per a auditoria?

Desplegament i empaquetatge: l’esforç subestimat

Delphi Multiplattform per a Windows, macOS i Linux també vol dir: tres mons en l’empaquetatge. Molts costos apareixen només després del primer Go-live, quan cal desplegar actualitzacions de forma regular.

Windows: instal·lador, permisos, serveis

A Windows són habituals els processos MSI/Installer, les polítiques de grup, UAC (User Account Control) i la signatura de codi. Tan aviat com hi participi un Windows- i Linux-services, s’afegeixen temes addicionals: compte de servei, permisos sobre el sistema de fitxers i 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 intervencions manuals.

macOS: notarització, signatura i gatekeeper

macOS sol·licita per a aplicacions distribuïdes habitualment la signatura i, segons la via de distribució, una notarització (procés de verificació perquè el gatekeeper executi l’app). 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 pipeline de build, com es generen els releases de manera reproduïble? Sense aquesta disciplina, cada hotfix es converteix en una acció aïllada.

Linux: paquets, dependències, systemd

A Linux són rellevants les unitats systemd (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 útils (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 reproduïbles

Com a mínim amb tres plataformes objectiu, el „build per mà“ esdevé un risc. CI/CD (Continuous Integration/Continuous Delivery) no implica necessàriament „tot automàticament a producció“, sinó sobretot: artefactes reproduïbles, versions rastrejables i un procés estandarditzat de proves i aprovació.

A la pràctica, cal definir com a mínim:

• 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 segurs)?
• Smoke-Tests: proves funcionals mínimes per plataforma que poden bloquejar qualsevol candidat de release.

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

Monitoratge, registre i anàlisi d’errors: el que realment compta en explotació

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 multiplataforma incrementa la variabilitat, per això cal millorar l’observabilitat.

Estratègia de logs unificada entre client i servidor

S’ha demostrat efectiva una estratègia de logs escalonada:

• Logs del client: registres locals amb rotació, correlació única (p. ex. Request-ID), conformes a la normativa de protecció de dades.
• Logs del servidor: emmagatzematge centralitzat, entrades estructurades (ordre temporal net, llegibles per màquina), separació d’auditoria i logs de depuració.
• Mètriques: temps de resposta, taxes d’error, longituds de cua, ocupació del pool de la base de dades.

Especialment en arquitectures REST una Request-ID (una identificació única per cada sol·licitud, que es transmet a través de tots els components) resulta molt valuosa, perquè els casos de suport es poden acotar en minuts en comptes d’hores.

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

En plataformes d’escriptori, els crash-dumps i 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 com s’associen a versions? Sense respondre aquestes preguntes, el suport multiplataforma sovint queda reduït a anar a cegues.

Seguretat i compliança: les plataformes impliquen superfícies d’atac diferents

Amb Windows, macOS i Linux no augmenta automàticament el risc, però la superfície d’atac esdevé més variada. Punts típics que en 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 base de dades, API-Keys, claus de signatura – no en configuracions en text pla ni en scripts d’instal·lació.
• Model de permisos: principi de mínims privilegis per als serveis, separació clara entre funcions d’administrador i d’usuari.
• Capacitat d’actualització: els correctius de seguretat han de poder desplegar-se ràpidament; això depèn directament del procés de packaging i release.

Especialment en empreses amb requisits d’auditoria, val la pena definir aviat una breu llista de comprovació de seguretat per cada plataforma i incloure-la en l’acceptació.

Puntes problemàtiques típiques en projectes multiplataforma

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

Sistema de fitxers i rutes: detall petit, gran impacte

Diferents convencions de rutes, 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 centrals de rutes, directoris d’aplicació definits, no utilitzar ubicacions d’emmagatzematge codificades de forma rígida.

Impressió, generació de PDF i integració amb Office

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

Unicode i jocs de caràcters

En entorns amb plataformes, interfícies i bases de dades mixtes, Unicode (un estàndard de codificació per a caràcters internacionals) esdevé imprescindible. Els llegats amb història „ANSI“ generen altrament errors difícils de rastrejar en cerca, ordenació, exportacions CSV o 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 està disponible només per a una arquitectura. Per a l’explotació això vol dir: llista d’dependències clara, documentar versions, verificar llicències i capacitat d’actualització. Multiplataforma només és tan estable com la dependència més feble.

Ajuda a la decisió: Quan compensa realment Delphi Multiplataforma?

Una mirada pragmàtica a l’esforç i al benefici ajuda a desactivar les discussions. Multiplataforma convé típicament quan:

• el nucli funcional és estable a llarg termini i la reutilització compensa durant anys,
• existeixen raons organitzatives reals per a clients macOS (no només „seria bonic“),
• Linux ja és l’estàndard al backend i estan previstos serveis/REST,
• l’aplicació s’ha d’integrar en una xarxa d’integració amb ERP/DMS/CRM,
• es pugui establir un procés de release net (Build, Signierung, Tests).

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 funcionalitats 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 ha de significar reescriure-ho tot. Un camí robust sovint és el següent:

1. Anàlisi de l’estat i definició de les interfícies: 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 les dades: p. ex. BDE-substitució, BDE-Ablosung mit nativer Anbindung, estratègia unificada de connexions i transaccions.
3. Establir una capa de serveis: REST-API 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 tot alhora.
5. Professionalitzar el Packaging/CI: builds i actualitzacions reproducibles com a part fixa del projecte.

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

Conclusió: Multiplataforma és una decisió operativa – no només una decisió de desenvolupament

Delphi Multiplataforma per a Windows, macOS i Linux pot ser per a les empreses una via molt pragmàtica per evolucionar tècnicament processos consolidats sense perdre el nucli funcional. És crucial planificar la Multiplataforma com un paquet global: arquitectura amb capes clares, accés a dades consolidat, interfícies orientades a serveis, builds reproducibles, packaging net i una estratègia de logging/monitorització que resolgui ràpidament els casos de suport.

Quan aquestes bases estiguin establertes, la multiplataforma no esdevindrà un projecte interminable, sinó una ampliació controlable de la vostra solució empresarial digital — amb costos d’explotació realistes i una fulla de ruta que connecta la migració amb el desenvolupament posterior.

Si voleu avaluar de manera estructurada la vostra situació de partida (estat actual, plataformes objectiu, base de dades, interfícies i model d’explotació): contacteu amb nosaltres per a una reunió tècnica inicial.

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

Discuteixi un projecte o una iniciativa de modernització amb Net-Base.