Servizi di sviluppo software desktop: guida all’acquisto 2026

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

I servizi di sviluppo software desktop restano una voce di budget importante nel 2026, anche se la maggior parte del nuovo software aziendale nasce nel browser. Strumenti di ingegneria, terminali di trading, visualizzatori di immagini mediche, app per punti vendita e operatori sul campo, software companion per dispositivi e migliaia di strumenti Windows interni vivono sul desktop, e prima o poi quasi tutti hanno bisogno di nuove funzionalità, di un nuovo framework o di una ricostruzione completa.

La parte difficile raramente è il codice in sé. È decidere se il prodotto debba davvero essere un’app desktop, quali sistemi operativi supportare e come l’app verrà firmata, installata e aggiornata su centinaia di macchine gestite. Per questo la maggior parte dei progetti desktop viene definita come qualsiasi altro incarico dei nostri servizi di sviluppo software su misura: prima mappiamo il flusso di lavoro, poi scegliamo piattaforma e framework.

Il 2026 è un anno di decisioni per molti proprietari di software desktop. Il supporto di Windows 10 è terminato a ottobre 2025, i certificati di firma del codice emessi da marzo 2026 sono validi al massimo 460 giorni e il dibattito Electron vs Tauri ha reso la scelta del framework una vera questione di budget. Questa guida spiega che cosa includono i servizi di sviluppo desktop, quando il desktop batte il web, il panorama dei framework nel 2026, distribuzione e sicurezza, le opzioni di modernizzazione, costi realistici e una checklist per scegliere il fornitore.

Che cosa sono i servizi di sviluppo software desktop?

I servizi di sviluppo software desktop sono le attività di progettazione, sviluppo, test, distribuzione e manutenzione di applicazioni che vengono installate ed eseguite in modo nativo su computer Windows, macOS o Linux. A differenza di un sito web, un’app desktop gira sulla macchina dell’utente, può funzionare offline e può usare direttamente hardware, file e funzioni del sistema operativo locali.

Un incarico desktop full-cycle copre di solito sette aree:

1. Discovery e architettura: flussi di lavoro, utenti, esigenze offline, modello dei dati, sistemi operativi di destinazione e suddivisione client-server.
2. UI/UX per desktop: scorciatoie da tastiera, layout multi-finestra, drag and drop, supporto high-DPI e multi-monitor, accessibilità.
3. Sviluppo nativo o cross-platform: l’applicazione vera e propria, in WPF, WinUI 3, Qt, Electron, Tauri, Flutter, Swift o un altro stack.
4. Integrazioni: API REST o gRPC, database locali e cloud, sistemi ERP e CRM, stampanti, scanner, strumenti di misura e altri dispositivi.
5. QA su più versioni di sistema operativo: matrici di test per Windows 10 e 11, diverse versioni di macOS e distribuzioni Linux, oltre a hardware diverso.
6. Firma, packaging e distribuzione: certificati di firma del codice, notarizzazione Apple, installer MSI/MSIX e PKG, distribuzione tramite store o diretta, aggiornamento automatico.
7. Manutenzione, aggiornamenti e modernizzazione: patch di sicurezza, aggiornamenti del framework, nuove release del sistema operativo e rinnovo graduale del codice più vecchio.

Alcuni progetti richiedono solo una parte di questo elenco, per esempio un plugin per uno strumento CAD esistente o il packaging di un’app legacy per Windows 11. Altri, come un nuovo prodotto per tre sistemi operativi, le richiedono tutte e sette.

Sviluppo desktop nativo o cross-platform

Lo sviluppo desktop nativo crea un’app separata per ogni sistema operativo con gli strumenti propri di quella piattaforma, mentre lo sviluppo cross-platform condivide un’unica codebase tra Windows, macOS e Linux. Le app native (per esempio WPF o WinUI su Windows e SwiftUI o AppKit su macOS) ottengono la migliore integrazione con il sistema operativo e si presentano esattamente come le altre app di quella piattaforma. Le app cross-platform (Qt, Avalonia, Electron, Tauri, Flutter) costano meno quando servono due o tre sistemi, al prezzo di un po’ di lavoro specifico per piattaforma ai margini. La nostra guida su che cos’è lo sviluppo software cross-platform illustra i compromessi generali; la sezione sui framework qui sotto li applica al desktop.

Quando un’app desktop batte una web app o un SaaS?

Un’app desktop batte una web app quando il software richiede funzionamento offline, elaborazione locale o grafica intensive, accesso diretto all’hardware o al file system, input a bassa latenza o una profonda integrazione con il sistema operativo. Se nessuna di queste condizioni si applica, una web app è di solito più economica da sviluppare, distribuire e aggiornare, perché ogni utente riceve la nuova versione al successivo caricamento della pagina.

Per un confronto più approfondito tra app basate su browser, app native e progressive web app, rimandiamo alla nostra guida web app vs app nativa vs PWA.

Quando un prodotto dovrebbe restare sul web?

Un prodotto dovrebbe restare sul web quando i suoi utenti lavorano soprattutto online, passano da un dispositivo all’altro e non hanno bisogno di hardware o file locali oltre a upload e download. Portali clienti, sistemi di prenotazione, la maggior parte delle dashboard SaaS e gli strumenti interni di approvazione rientrano in questo gruppo. Distribuirli come app desktop aggiunge installer, firma e test sui sistemi operativi senza dare agli utenti nulla che non potessero già fare nel browser. Se solo una funzionalità richiede capacità desktop, come stampare etichette o leggere uno scanner di codici a barre, una piccola app companion accanto al prodotto web costa di solito meno che spostare l’intero prodotto sul desktop.

Tipi di applicazioni desktop che le aziende sviluppano nel 2026

Nel 2026 le aziende sviluppano applicazioni desktop soprattutto dove prestazioni, lavoro offline o accesso all’hardware contano più della diffusione immediata. Le categorie più comuni sono:

• Ingegneria, CAD e 3D: strumenti di modellazione, front end per simulazioni, visualizzatori BIM e plugin per suite CAD esistenti.
• Media e produzione audio/video: editor, transcoder, strumenti di controllo per broadcast e streaming che richiedono GPU e bassa latenza.
• Imaging scientifico e medicale, visualizzazione dei dati: visualizzatori DICOM, strumenti di analisi di laboratorio e visual analytics su grandi dataset.
• Terminali di trading e finanziari: applicazioni multi-monitor a bassa latenza per dati di mercato e inserimento ordini.
• Controllo industriale, HMI e software companion per dispositivi: app che configurano, monitorano o aggiornano strumenti, macchinari e dispositivi IoT; spesso si sovrappongono allo sviluppo di software embedded lato dispositivo.
• Produttività aziendale e back office (offline-first): strumenti per assistenza sul campo, ispezioni, retail e magazzino che devono continuare a funzionare senza rete.
• Utility di sistema, plugin e SDK: agenti di backup e sincronizzazione, strumenti di sicurezza, add-in per suite da ufficio e librerie che altri sviluppatori integrano nei propri prodotti.

Ciò che accomuna queste categorie è una ragione per stare sul dispositivo: volume dei dati, hardware, latenza o la necessità di lavorare quando la rete non c’è.

Quale framework usare per un’app desktop nel 2026?

I team con competenze C# e .NET che puntano su Windows dovrebbero di norma scegliere WPF o WinUI 3; i prodotti che richiedono una vera copertura cross-platform con prestazioni native si adattano a Qt o Avalonia; i team web dovrebbero valutare Tauri per un ingombro ridotto o Electron per l’ecosistema più ampio; e le aziende con una codebase mobile in Flutter possono estenderla con Flutter desktop. La risposta giusta dipende dal team, dai sistemi operativi e da quanto a lungo l’app deve vivere.

Le dimensioni degli installer sono intervalli tipici riportati da Fora Soft a novembre 2026; la dimensione effettiva dipende dagli asset e dalle librerie incluse. La dimensione dell’ecosistema emerge anche dalle statistiche dei pacchetti: a fine ottobre 2026 il pacchetto electron contava circa 11,8 milioni di download settimanali su npm, contro circa 3,9 milioni di @tauri-apps/api (Fora Soft, su dati npm).

Per il software aziendale orientato a Windows, un team di sviluppo .NET con esperienza in WPF o WinUI resta la scelta meno rischiosa, soprattutto se l’azienda usa già .NET sul server. Se esiste già un’app mobile in Flutter, lo sviluppo Flutter per desktop può riutilizzare gran parte dell’interfaccia e della logica di business, ma prima di impegnarsi conviene verificare il supporto dei plugin per ogni funzione di dispositivo e di sistema operativo necessaria.

Electron vs Tauri: quale è meglio per le app aziendali?

Tauri produce app molto più piccole e leggere perché usa la WebView del sistema operativo e un core in Rust, mentre Electron include in ogni app una copia completa di Chromium e Node.js. La differenza si vede nella dimensione dell’installer (3–15 MB contro 50–150 MB) e nel consumo di memoria.

• Modello di sicurezza: Tauri usa un modello di capability basato su allow-list, quindi il front end può chiamare solo le funzioni di sistema abilitate esplicitamente. Electron può essere irrobustito con context isolation e sandboxing, ma la superficie predefinita è più ampia.
• Coerenza del rendering: Electron ha lo stesso rendering ovunque perché porta con sé il proprio motore browser. Tauri dipende da WebView2 su Windows, WebKit su macOS e WebKitGTK su Linux, quindi occorre testare su ciascuno.
• Carico degli aggiornamenti: Electron rilascia una nuova major circa ogni 8 settimane e applica patch solo alle ultime tre, quindi un’app Electron longeva richiede un budget regolare per gli aggiornamenti.
• Ecosistema e assunzioni: Electron ha la community più grande e più moduli pronti; Tauri richiede un po’ di Rust per le funzioni native.

La nostra regola pratica: Tauri per strumenti nuovi e mirati in cui contano ingombro e sicurezza, Electron quando servono il suo ecosistema o un rendering identico al pixel e si può sostenere il ritmo degli aggiornamenti.

Copertura delle piattaforme: Windows, macOS o Linux?

Secondo i dati StatCounter di ottobre 2026, Windows gira ancora su circa il 77% dei computer desktop nel mondo, macOS su circa il 16% (OS X 9,86% più macOS 5,81%), Linux su circa il 5,6% e ChromeOS su circa il 2%. Queste quote significano che il supporto a Windows è quasi sempre necessario, mentre macOS e Linux dipendono da chi sono gli utenti.

• Software B2B ed enterprise: si parte da Windows. Parchi macchine aziendali, Active Directory e dispositivi gestiti con Intune sono ancora in gran parte Windows.
• Pubblico creativo, design e sviluppatori: pianificare macOS fin dall’inizio; questi utenti usano il Mac molto più della media globale.
• Utenti di ingegneria, scienza e industria: Linux conta per workstation, PC di laboratorio e macchine in reparto.
• Istruzione e parte del settore pubblico: verificare ChromeOS; una versione web o Android può servire questi utenti meglio di una build desktop.

Ogni sistema operativo aggiuntivo comporta lavoro di design, QA e packaging anche con un framework cross-platform, quindi conviene aggiungere piattaforme quando utenti reali ne hanno bisogno, non «per sicurezza».

Come funziona il processo di sviluppo software desktop?

Il processo di sviluppo software desktop attraversa sette fasi, dalla discovery al rilascio e alla manutenzione, e un’app aziendale raggiunge di solito il primo rilascio in produzione in 4–9 mesi. Nella pratica le fasi si sovrappongono e il QA procede in parallelo allo sviluppo fin dal primo sprint.

1. Discovery e requisiti (1–3 settimane): utenti, flussi di lavoro, scenari offline, dispositivi, versioni di sistema operativo di destinazione, esigenze di sicurezza e conformità.
2. Architettura e scelta del framework (1–2 settimane): suddivisione client-server, sincronizzazione dei dati e un breve spike tecnico che mette alla prova il framework sulla funzionalità più rischiosa.
3. Design UX/UI (2–4 settimane): pattern specifici del desktop come menu, scorciatoie, layout multi-finestra e asset high-DPI.
4. Sviluppo iterativo (3–6+ mesi): sprint di due settimane con build funzionanti su ogni sistema operativo di destinazione.
5. QA su versioni di sistema operativo e hardware (in parallelo): test automatici di UI e integrazione, più verifiche manuali su macchine e dispositivi reali.
6. Firma, packaging, distribuzione e configurazione dell’aggiornamento automatico (2–4 settimane): certificati, notarizzazione, installer e canale di aggiornamento, integrati nella CI.
7. Rilascio, monitoraggio e manutenzione: rollout graduale, crash reporting, supporto e un piano per gli aggiornamenti di sistema operativo e framework.

Come riferimento, Fora Soft stima che trasformare un’app React esistente in un’app desktop per tre sistemi operativi, con packaging enterprise, richieda da 9 a 16 settimane-uomo nell’arco di 8–12 settimane di calendario. Le fasi generali corrispondono a qualsiasi processo di sviluppo software su misura; ciò che è specifico del desktop sono la matrice di test dei sistemi operativi e la pipeline di distribuzione.

Firma del codice, distribuzione e aggiornamenti nel 2026

Nel 2026 un’app desktop non firmata fa scattare gli avvisi SmartScreen su Windows e i blocchi di Gatekeeper su macOS, e molte policy aziendali ne rifiutano del tutto l’installazione. Firma, notarizzazione e canale di aggiornamento fanno parte della build, non sono un ripensamento dell’ultimo minuto, e vanno inseriti fin dal primo piano di progetto.

Firma del codice su Windows

I certificati di firma del codice pubblicamente attendibili emessi a partire dal 1° marzo 2026 sono validi al massimo 460 giorni, contro i 39 mesi precedenti, in base al Ballot CSC-31 del CA/Browser Forum adottato il 17 novembre 2025. Le chiavi private devono risiedere su hardware conforme a FIPS 140-2 Level 2 o superiore, come un token o un HSM cloud.

• Costo: da circa 129 $ all’anno per un certificato OV fino a circa 349 $ per un EV, secondo i dati 2026 di Fora Soft.
• Rinnovo: con una validità di 460 giorni i rinnovi sono più frequenti, quindi conviene automatizzarli e monitorare le scadenze.
• Integrazione nella CI: firmare nella pipeline di build tramite un HSM cloud o un servizio di firma, non sul laptop di uno sviluppatore.

Notarizzazione su macOS

Il software distribuito al di fuori del Mac App Store deve essere firmato con un certificato Developer ID e notarizzato da Apple; è un obbligo da macOS 10.15 per il software compilato dopo il 1° giugno 2019. La notarizzazione richiede anche l’hardened runtime. L’Apple Developer Program costa 99 $ all’anno e la notarizzazione viene eseguita come passaggio automatico dopo ogni build.

Packaging e rollout aziendale

I clienti enterprise si aspettano installer che i loro team IT possano distribuire in modo silenzioso e controllare centralmente. I formati abituali sono MSI o MSIX su Windows, PKG o DMG firmati su macOS e AppImage, Flatpak, deb o rpm su Linux.

• Installazione silenziosa e disinstallazione per strumenti come Microsoft Intune e altri sistemi MDM.
• Controllo amministrativo sull’aggiornamento automatico, con la possibilità di disattivarlo e bloccare una versione.
• Una SBOM (software bill of materials, distinta dei componenti software) perché i team di sicurezza possano esaminare le dipendenze.
• Distribuzione tramite store o diretta: Microsoft Store e Mac App Store gestiscono aggiornamenti e pagamenti ma aggiungono revisione e regole di sandbox; la distribuzione diretta dà il pieno controllo, ma firma, hosting e aggiornamenti restano interamente a carico dell’editore.

Aggiornamento automatico

Un buon sistema di aggiornamento automatico distribuisce le correzioni rapidamente senza bloccare gli utenti nel mezzo del lavoro. Conviene usare un rollout graduale (per esempio 5%, poi 25%, poi tutti), verificare la firma di ogni pacchetto di aggiornamento prima di installarlo e mantenere un percorso di rollback alla versione precedente. Il crash reporting dovrebbe essere collegato al canale di aggiornamento, così una release difettosa viene fermata prima di raggiungere tutti gli utenti.

Come mantenere un’app desktop sicura e accessibile?

Un’app desktop è sicura quando gira con i privilegi minimi necessari, protegge i dati locali con gli archivi di chiavi del sistema operativo, accetta solo aggiornamenti firmati e tiene sotto controllo le proprie dipendenze. Poiché un’app desktop gira su hardware che non si controlla, queste misure contano più che per un server gestito in proprio.

• Capability con privilegi minimi: l’allow-list di Tauri, oppure Electron con context isolation e sandbox attivati; nessun diritto di amministratore se non strettamente necessario.
• Archiviazione locale sicura: segreti nel keychain del sistema operativo o in DPAPI, database locali cifrati, nessun token in file di configurazione in chiaro.
• Solo aggiornamenti firmati: l’updater verifica le firme e rifiuta tutto il resto.
• Gestione delle dipendenze e della SBOM: tracciare le librerie di terze parti e correggere rapidamente le vulnerabilità note.
• Telemetria attenta alla privacy: dati su crash e utilizzo raccolti con consenso e nel rispetto del GDPR.
• IPC sicura: messaggi validati tra interfaccia, servizi in background e processi helper.
• Penetration test prima del rilascio, soprattutto per app che trattano dati sanitari, di pagamento o industriali.

Questi controlli rientrano in un più ampio ciclo di vita dello sviluppo software sicuro che comprende threat modelling, code review e test.

In Europa l’accessibilità è anche un requisito commerciale. L’European Accessibility Act si applica dal 28 giugno 2025 e la clausola 11 della norma EN 301 549 riguarda il software non web, come osserva la sintesi 2026 di Fora Soft. In pratica significa piena operatività da tastiera, rispetto delle impostazioni di sistema come contrasto e dimensione del testo e test con screen reader come NVDA, Narrator e VoiceOver. Gli obblighi specifici vanno verificati con un consulente legale; il punto è che il lavoro sull’accessibilità deve essere nel piano, non aggiunto dopo che un cliente europeo lo chiede.

Modernizzare un’applicazione desktop legacy

Nel 2026 la maggior parte dei progetti desktop sono modernizzazioni più che nuovi sviluppi: applicazioni WinForms, VB6, Delphi o MFC che devono funzionare in modo affidabile su Windows 11, acquisire la sincronizzazione cloud o spostarsi in parte sul web. Queste app contengono spesso anni di regole di business che nessuno ha mai messo per iscritto altrove.

La pressione delle scadenze è reale. Microsoft ha terminato il supporto di Windows 10 il 14 ottobre 2025 e il programma Extended Security Updates per i consumatori dura solo fino al 12 ottobre 2027. Le applicazioni legate a runtime datati o a versioni di sistema operativo non supportate diventano un rischio di sicurezza e di conformità, e ogni anno di ritardo rende più costoso il passaggio finale.

La maggior parte dei team combina le opzioni: oggi si reimpacchetta per restare al sicuro, poi si fa refactoring o si sostituisce modulo per modulo. I nostri servizi di modernizzazione del software legacy seguono questo approccio incrementale, e la nostra analisi dei costi e del ROI della modernizzazione legacy mostra come costruire il business case.

Quanto costano i servizi di sviluppo software desktop nel 2026?

Secondo le nostre stime per il 2026, i servizi di sviluppo software desktop costano circa 30.000–60.000 $ per uno strumento semplice per un solo sistema operativo, 60.000–150.000 $ per un’app aziendale cross-platform e 150.000–400.000 $ o più per prodotti complessi o integrati con hardware. La tabella presuppone un team nearshore misto al servizio di clienti negli Stati Uniti e nell’UE.

Questi intervalli corrispondono alle fasce della nostra guida più ampia sul costo dello sviluppo software su misura. Come verifica di mercato, un fornitore ai primi posti nei risultati di ricerca, The App Solutions, indica 5.000–50.000 $ per piccoli progetti desktop, 50.000–120.000 $ per quelli medi e fino a 1 milione di $ per quelli grandi, su un arco di 4–12 mesi.

Lo sviluppo non è l’unico costo. Fora Soft stima i costi operativi del primo anno di un’app desktop in circa 2.700–12.200 $: 99 $ per l’Apple Developer Program, 129–349 $ per la firma su Windows, 120–600 $ per hosting degli aggiornamenti e CDN, fino a circa 1.188 $ per il crash reporting e 2.400–9.600 $ per gli aggiornamenti major di Electron. La maggior parte di questa cifra è tempo di ingegneria, non licenze.

I principali fattori di costo sono:

• Numero di sistemi operativi e di versioni da supportare e testare.
• Scelta del framework, incluse licenze (per esempio Qt commerciale) e ritmo degli aggiornamenti.
• Integrazione con hardware e dispositivi: driver, SDK, banchi di prova e tempo di laboratorio.
• Sincronizzazione offline e risoluzione dei conflitti tra dati locali e dati sul server.
• Conformità: HIPAA, GDPR, European Accessibility Act o normative di settore.
• Packaging enterprise e MDM: MSI/MSIX, installazione silenziosa, policy amministrative, SBOM.
• Migrazione dei dati legacy e lo sforzo necessario per riscoprire regole di business non documentate.

Come ridurre i costi di sviluppo desktop senza sacrificare la qualità?

Il modo più affidabile per abbassare i costi di sviluppo desktop è ridurre presto perimetro e numero di piattaforme, non tagliare tardi i test o la pipeline di rilascio. Poche decisioni prese in fase di discovery fanno di solito risparmiare più di qualsiasi trattativa sulle tariffe.

• Lanciare prima su un solo sistema operativo quando gli utenti lo consentono, e aggiungere la seconda piattaforma dopo aver validato i flussi di lavoro.
• Riutilizzare ciò che già esiste: un front end web esistente in una shell Tauri o Electron, oppure un back end .NET con un client WPF.
• Eseguire uno spike tecnico sulla funzionalità più rischiosa, come un driver di dispositivo o la sincronizzazione offline, prima di fissare il budget.
• Automatizzare firma, packaging e aggiornamenti dal primo sprint, così i rilasci non diventano lavoro manuale a ogni build.
• Mantenere leggero il client desktop dove possibile e collocare le regole di business sul server, dove è più facile modificarle e testarle.

I team che saltano il QA su macchine reali o rimandano il canale di aggiornamento di solito pagano due volte: prima in ticket di supporto, poi in una ricostruzione affrettata del processo di rilascio.

Come scegliere una società di sviluppo software desktop

Conviene scegliere una società di sviluppo software desktop in grado di mostrare app desktop firmate e già distribuite sui sistemi operativi di destinazione e che raccomandi un framework sulla base di uno spike tecnico, non di ciò che il suo team sa già usare. Il lavoro desktop ha trappole pratiche (firma, bug specifici del sistema operativo, hardware) che un’agenzia solo web spesso incontra per la prima volta a spese del cliente.

1. App desktop distribuite sui sistemi operativi di destinazione: chiedere installer firmati da eseguire, non screenshot.
2. Consulenza neutrale sul framework: una raccomandazione supportata da un breve spike sulla funzionalità più rischiosa.
3. Pipeline di firma, notarizzazione e aggiornamento nella CI: chiedere di vederla, inclusa la gestione dei certificati.
4. Matrice di QA multi-OS e laboratorio hardware: su quali versioni di sistema operativo e dispositivi testano, e come.
5. Pratiche di sicurezza: SBOM, scansione delle dipendenze e penetration test prima del rilascio.
6. Esperienza di modernizzazione con lo stack legacy in uso: WinForms, VB6, Delphi, MFC o vecchio .NET.
7. SLA di manutenzione e piano di aggiornamento: chi gestisce le nuove release dei sistemi operativi e gli aggiornamenti dei framework, come il ritmo di Electron, e a quale costo.

Segnali d’allarme da tenere d’occhio:

• Il framework viene scelto alla prima call, prima che qualcuno abbia visto i flussi di lavoro del cliente.
• Firma, installer e aggiornamenti mancano dal preventivo o sono etichettati «più avanti».
• Si testa un solo sistema operativo, anche se si prevede di vendere su due o tre.
• Nessuna risposta su chi possiederà i certificati e le chiavi di firma del codice al termine del progetto.

Per un metodo generale di selezione del fornitore, legga la nostra guida su come scegliere una società di sviluppo software. Se deve ancora decidere se sviluppare o meno, il nostro confronto tra software su misura e software pronto all’uso aiuta a rispondere alla domanda make or buy.

Fonti

• StatCounter Global Stats, Desktop operating system market share worldwide, ottobre 2026.
• Microsoft, Windows 10 support has ended on October 14, 2025 e Windows 10 Extended Security Updates.
• CA/Browser Forum, Code Signing Baseline Requirements (Ballot CSC-31).
• Apple Developer, Notarizing macOS software before distribution e macOS distribution.
• Fora Soft, Desktop App Development in 2026: Electron, Tauri or Native, aggiornato a novembre 2026.
• The App Solutions, Desktop application development services (intervalli di costi e tempi).
• Developex, Desktop applications development (confronto tra framework).

Domande frequenti