---
term: 'Sviluppo multipiattaforma'
seoTitle: 'Sviluppo multipiattaforma: framework e backend condiviso'
headline: 'Che cos''è lo sviluppo multipiattaforma?'
slug: sviluppo-multipiattaforma
category: frontend-web
shortDefinition: 'Lo sviluppo multipiattaforma è un modo di costruire un''app da un''unica codebase condivisa che gira su più piattaforme – iOS, Android, web, desktop.'
relatedTerms:
  - backend-sdk
  - progressive-web-app-pwa
  - baas-vs-custom-backend
  - api
contrastsWith:
  - progressive-web-app-pwa
aboutTerms:
  - 'Native vs. Cross-Platform'
  - 'Compiled vs. Bridge vs. WebView'
  - 'Shared Backend'
faq:
  - question: 'Che cos''è lo sviluppo multipiattaforma?'
    answer: 'Costruire un''applicazione da un''unica codebase condivisa che gira su più piattaforme – iOS, Android e, sempre più, web e desktop – invece di scrivere codice separato per ciascuna. Lo slogan guida è "write once, run anywhere" (scrivere una volta, eseguire ovunque), con la nota a piè di pagina del realista: "write once, debug everywhere".'
  - question: 'Qual è la differenza tra multipiattaforma e nativo?'
    answer: 'Il nativo punta a un solo sistema operativo con il suo linguaggio e i suoi strumenti – Swift per iOS, Kotlin per Android – per prestazioni massime e l''accesso più profondo al dispositivo. Il multipiattaforma riusa una codebase tra sistemi operativi per un costo inferiore e una consegna più rapida, cedendo un po'' di prestazioni e di immediatezza sulle novità del sistema operativo.'
  - question: 'Quali sono i principali framework multipiattaforma?'
    answer: 'Due guidano il campo: un framework JavaScript che renderizza veri componenti UI nativi tramite un bridge, e uno che porta con sé il proprio motore di rendering e compila in codice nativo. Altri condividono la logica di business mantenendo la UI nativa, oppure avvolgono una web app in un contenitore nativo. Differiscono soprattutto nel modo in cui disegnano lo schermo.'
  - question: 'Qual è la differenza tra ibrido e multipiattaforma?'
    answer: 'I framework multipiattaforma compilano in codice nativo o renderizzano componenti nativi; le app ibride eseguono una web app dentro un contenitore WebView nativo. L''ibrido è la strada più rapida per i team web e la meno performante; il multipiattaforma sta tra l''ibrido e il completamente nativo. Alcune tassonomie trattano l''ibrido come un sottoinsieme del multipiattaforma.'
  - question: 'Il multipiattaforma è veloce quanto il nativo?'
    answer: 'I framework moderni raggiungono circa il 90–95 % delle prestazioni native, più che sufficiente per la maggior parte delle app. Il nativo vince ancora per i giochi ad alta intensità grafica, AR e VR e l''elaborazione pesante in tempo reale, dove contano gli ultimi punti percentuali e l''accesso diretto all''hardware.'
  - question: 'Quanto codice si può riusare, e quanto si risparmia?'
    answer: 'Sul frontend, comunemente intorno al 90 %, a seconda del framework e di quanta UI o logica specifica per piattaforma serve all''app. Le cifre riportate dal settore si concentrano intorno al 30–40 % di costo in meno e a una consegna più rapida del 30–40 % rispetto ad app native separate. Ma il guadagno di riuso più grande e più affidabile è il backend – condiviso al 100 % tra tutti i client, nativi o multipiattaforma che siano.'
  - question: 'Quando conviene scegliere il multipiattaforma invece del nativo?'
    answer: 'Il multipiattaforma per budget e tempi stretti, MVP, app di business e di contenuti standard e lanci simultanei su più piattaforme. Il nativo per le app critiche nelle prestazioni, esigenti sull''hardware o vetrina di una piattaforma. In entrambi i casi il backend è condiviso, quindi la decisione riguarda in realtà il frontend.'
  - question: 'Il multipiattaforma riguarda solo il frontend?'
    answer: 'No – ed è la parte che la maggior parte delle guide trascura. La scelta del framework frontend è un trade-off tra UX e prestazioni, ma il guadagno di riuso più grande è un backend condiviso: un''unica API che serve iOS, Android, web e desktop. Perfino due app completamente native sono multipiattaforma a livello di backend, se lo condividono.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Write once, run anywhere — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Write_once,_run_anywhere'
  - name: 'Cross-platform software — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Cross-platform_software'
  - name: 'React Native — open-source framework'
    url: 'https://reactnative.dev/'
  - name: 'Stack Overflow Developer Survey'
    url: 'https://survey.stackoverflow.co/'
cta:
  title: 'Scrivi il backend una volta sola'
  text: 'Back4app fornisce SDK per Flutter, React Native, iOS, Android e JavaScript sopra un''unica API – qualunque frontend usi ciascuna piattaforma, dati, autenticazione e regole sono scritti una volta sola.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-23'
translationKey: cross-platform-development
---

**Lo sviluppo multipiattaforma è un modo di costruire un'app da un'unica codebase condivisa che gira su più piattaforme – iOS, Android, web, desktop.** Lo slogan è "write once, run anywhere"; la realtà aggiunge "write once, debug everywhere". Eppure l'intera conversazione sul tema, da una guida ben posizionata all'altra, tratta il multipiattaforma come una questione di *frontend* – quale framework UI scegliere. Questa voce aggiunge la parte che tutte saltano: **il guadagno di riuso del codice più grande e più affidabile non è la UI, è un backend condiviso** – e quel guadagno è disponibile anche per le app completamente native.

## Punti chiave

| Domanda | Risposta |
| --- | --- |
| L'idea | Una codebase → più piattaforme, invece di una per sistema operativo |
| Gli approcci frontend | Compilato (renderer proprio) · bridge nativo · contenitore WebView |
| vs. nativo | Copertura + velocità + codice condiviso ↔ prestazioni massime + UX nativa |
| Il guadagno di cui non si parla | Il **backend è condiviso al 100 %** – nativo o multipiattaforma |
| Il meccanismo | [SDK](/glossary/it/sdk-backend/) + un'[API](/glossary/it/api/) REST/GraphQL che ogni client parla |

## Lo stesso backend, per ogni frontend

**JavaScript:**

```javascript
// JavaScript / React Native / web — Back4app JS SDK
// The SAME backend call, whatever the frontend framework
const query = new Parse.Query('Task');
query.equalTo('done', false);
const tasks = await query.find();
// This exact query runs from React Native, a web SPA, or Node —
// because the backend is written ONCE and every client shares it.
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// Same data, same auth, same rules — a different frontend framework
final tasks = await QueryBuilder<ParseObject>(ParseObject('Task'))
    .whereEqualTo('done', false)
    .query();
// The Flutter app and the native iOS app can differ entirely on the frontend
// and still share ONE backend — the cross-platform win nobody talks about.
```

**Swift:**

```swift
// iOS / Swift (native) — Back4app Swift SDK
// A fully NATIVE iOS app — still cross-platform at the backend layer
let tasks = try await Task_.query("done" == false).find()
// Native iOS + native Android + web can each pick their own UI stack
// and share the identical backend API — write the backend once.
```

**Kotlin:**

```kotlin
// Android / Kotlin (native) — Back4app Android SDK
// A fully NATIVE Android app — still cross-platform at the backend layer
val tasks = ParseQuery.getQuery<ParseObject>("Task")
    .whereEqualTo("done", false)
    .find()
// Native iOS + native Android + web can each pick their own UI stack
// and share the identical backend API — write the backend once.
```

Quattro frontend diversi – una web app in JS, Flutter, Swift nativo, Kotlin nativo – e una sola query, perché parlano tutti con lo stesso backend. È l'architettura che i risultati di ricerca non disegnano mai: **frontend multipiattaforma (o perfino frontend nativi) + un unico backend condiviso.** Il framework frontend è una decisione vera con trade-off veri; il riuso del backend è quasi gratuito e quasi universale.

## I tre approcci frontend

| Approccio | Come disegna la UI | Compromesso |
| --- | --- | --- |
| Compilato / renderer proprio | Porta con sé il proprio motore, compila in codice nativo | Prestazioni massime, UI identica al pixel su tutte le piattaforme |
| Bridge nativo | Renderizza *veri* componenti nativi tramite un bridge | Aspetto e comportamento nativi per piattaforma, ecosistema JS |
| WebView / ibrido | Una web app dentro un contenitore nativo | Il più rapido per i team web, il più debole in prestazioni e UX |

La tassonomia che la maggior parte delle guide confonde: un framework **compilato** disegna ogni pixel da sé (coerente ovunque, veloce come il nativo); un framework a **bridge nativo** chiede al sistema operativo di disegnare i propri widget (aspetto nativo per piattaforma); un'app **WebView/ibrida** renderizza HTML in un involucro (un sito web travestito da app). "Multipiattaforma" indica di solito le prime due; "ibrido" la terza – e la differenza sta esattamente in che cosa gira: vero codice nativo o un motore di browser.

```mermaid
flowchart LR
  accTitle: Frontend multipiattaforma sopra un unico backend condiviso
  accDescr: Più frontend – un'app multipiattaforma compilata, un'app a bridge nativo, app native iOS e Android e una web app – girano ciascuno sulla propria piattaforma, ma comunicano tutti con un'unica API backend condivisa che fornisce dati, autenticazione e logica di business. La scelta del framework frontend è indipendente dal backend condiviso.
  F1["App multipiattaforma<br/>(compilata / bridge)"] --> API[("API backend condivisa<br/>dati · auth · logica")]
  F2["iOS nativo"] --> API
  F3["Android nativo"] --> API
  F4["Web / PWA"] --> API
  API -.->|"SDK per piattaforma"| SDK["Un backend,<br/>scritto una volta sola"]
```

## Nativo vs. multipiattaforma, onestamente

| | Frontend multipiattaforma | Frontend nativo |
| --- | --- | --- |
| Codebase | Una sola, ~90 % condivisa | Una per sistema operativo |
| Tempi e costi | ~30–40 % in meno | Riferimento ×2 per due piattaforme |
| Prestazioni | ~90–95 % del nativo | 100 % |
| Fedeltà della UX | Molto buona; i casi limite affiorano | Perfetta per la piattaforma |
| Novità del sistema operativo | Attendere il supporto del framework | Immediate |
| Ideale per | App standard, MVP, copertura | Grafica, AR, hardware in profondità |
| **Il backend** | **Condiviso** | **Condiviso** |

L'ultima riga è tutto il senso di questo articolo. La scelta del frontend è un vero trade-off tra UX e prestazioni, da prendere con cognizione di causa – ma *qualunque* sia il lato scelto, il backend si scrive una volta sola ed è condiviso da tutti i client. Il che significa che il riuso più difficile e più prezioso dello sviluppo multipiattaforma è quello che nessuno presenta come multipiattaforma.

## Come il backend diventa multipiattaforma: SDK e un'API

Il meccanismo è a due livelli. Un backend espone un'**[API](/glossary/it/api/) neutra rispetto alla piattaforma** – [REST e GraphQL](/glossary/it/api-rest/) parlano JSON con qualsiasi cosa – e, sopra di essa, **[SDK per piattaforma](/glossary/it/sdk-backend/)** che avvolgono l'API negli idiomi di ciascun linguaggio: un SDK Swift per iOS, Kotlin per Android, JavaScript per web e React Native, Dart per Flutter. Ogni SDK è un client sottile sopra gli stessi endpoint, così il *modello dei dati, l'autenticazione, i permessi e la logica di business* vivono una sola volta sul server e ogni frontend li eredita. È per questo che un [BaaS](/glossary/it/baas-vs-backend-personalizzato/) è il backend naturale per il lavoro multipiattaforma: *è* il backend condiviso, con gli SDK già scritti. Una [PWA](/glossary/it/pwa/) è semplicemente un'altra via di distribuzione multipiattaforma – un'unica web app installabile su tutte le piattaforme – che parla con quello stesso backend.

## Casi d'uso comuni

- **Startup e MVP** – coprire iOS e Android con un solo team e un solo calendario.
- **App di contenuti e di business** – UI standard dove il 90 % di codice riusato è puro risparmio.
- **Suite di prodotti multipiattaforma** – client mobile, web e desktop sopra un unico backend.
- **App native che condividono comunque un backend** – frontend a prestazioni massime, un'unica API dietro.
- **[PWA](/glossary/it/pwa/) più nativo** – la copertura del web e la profondità del nativo, con lo stesso [backend](/glossary/it/baas-vs-backend-personalizzato/).

## Conviene passare al multipiattaforma? Matrice decisionale

| Situazione | Tendenza |
| --- | --- |
| Budget/tempi stretti, app standard | Frontend multipiattaforma |
| Lancio iOS + Android insieme | Frontend multipiattaforma |
| Grafica, AR, hardware in profondità | Frontend nativo |
| Vetrina di piattaforma o prestazioni massime | Frontend nativo |
| Uno qualsiasi dei casi sopra | **Backend condiviso** – sempre |
| Copertura web con budget ridotto | [PWA](/glossary/it/pwa/) sopra il backend condiviso |

## Limiti e trade-off

- **Il ritardo dei framework frontend.** Le novità del sistema operativo arrivano prima nel nativo; i framework multipiattaforma seguono – un costo reale per le app che devono adottarle dal primo giorno.
- **Gli ultimi punti percentuali di prestazioni.** Le app ad alta intensità grafica e in tempo reale sentono il divario dal nativo; la maggior parte delle app non lo sente mai.
- **Le convenzioni UX affiorano.** Gesti e pattern specifici per piattaforma richiedono attenzione per piattaforma anche nel codice UI "condiviso".
- **Dimensione dell'app e dipendenze.** I runtime multipiattaforma aggiungono peso e una dipendenza mantenuta dalla community che non si controlla.
- **Niente di tutto questo tocca il backend.** Ogni limite qui sopra è un limite *frontend*; il guadagno del backend condiviso resta intatto, ed è per questo che è la scommessa sicura in una decisione frontend incerta.

## Lo sviluppo multipiattaforma su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. È la metà "backend condiviso" di questo articolo resa concreta: Back4app fornisce [SDK](/glossary/it/sdk-backend/) per Flutter, React Native, iOS (Swift), Android (Kotlin) e JavaScript sopra un'unica [API](/glossary/it/api/) REST/GraphQL, così – come mostrano le schede di codice – la stessa query, la stessa [autenticazione](/glossary/it/autenticazione-vs-autorizzazione/) e le stesse [regole ACL](/glossary/it/liste-di-controllo-degli-accessi-acl/) servono ogni client, sia che il frontend sia un'unica codebase multipiattaforma o quattro codebase native separate. La decisione sul frontend resta in mano a chi sviluppa, su criteri di UX e prestazioni; il backend si scrive una volta sola in ogni caso, ed è il guadagno multipiattaforma che vale di più e di cui si parla di meno.