Apple Blocca il Vibe Coding sull'App Store. Ma Intanto lo Mette in Xcode.

"Rules for thee, IDE for me." Se dovessimo riassumere l'ultima mossa di Apple in una frase, sarebbe questa. Il 18 marzo, Cupertino ha silenziosamente bloccato gli aggiornamenti di Replit e Vibecode sull'App Store, invocando una guideline che esiste dal 2010. Tre settimane prima, Apple aveva rilasciato Xcode 26.3 con Claude Agent e Codex integrati -- esattamente la stessa tecnologia di agentic coding che ora blocca su mobile.

I fatti parlano da soli. E dicono cose che abbiamo gia' sentito.

Il playbook di Apple: sedici anni di "noi si', voi no"

Chi sviluppa nell'ecosistema Apple sa che questa storia ha un copione ricorrente. Cambia il protagonista, ma la dinamica e' sempre la stessa: Apple invoca sicurezza e qualita', la community grida al monopolio, e alla fine Cupertino aggiusta il tiro -- ma solo quando la pressione (legale o di mercato) diventa insostenibile.

2010: Flash. Steve Jobs pubblica la lettera aperta "Thoughts on Flash" e bandisce Flash dall'iPhone. Il motivo dichiarato: sicurezza, performance, durata della batteria. Il motivo non dichiarato: Flash permetteva di creare app che bypassavano l'App Store. Adobe protesta. Il web si adatta. HTML5 vince. Apple aveva ragione sulla tecnologia, ma il metodo -- decisione unilaterale, nessuna alternativa offerta -- diventa il template per ogni mossa successiva.

2020-2021: iSH, iDOS e le app di scripting. La Guideline 2.5.2 viene usata per bloccare iSH (una shell Linux per iOS) e rimuovere definitivamente iDOS 2 (emulatore DOS). Saagar Jha, sviluppatore di iSH, documenta come i revisori Apple abbiano installato personalmente codice nell'app durante la review, per poi respingerla perche' "ha installato codice eseguibile". Kafka avrebbe apprezzato.

2024: gli emulatori. Dopo anni di divieti, Apple apre improvvisamente agli emulatori retro sull'App Store -- guarda caso, poco dopo che il Digital Markets Act europeo la costringe a permettere store alternativi in EU. Il cambiamento arriva presentato come generosita'. Era pressione regolatoria.

2024-2025: le Progressive Web Apps in EU. Apple annuncia la rimozione del supporto PWA per gli utenti europei di iOS 17.4. La reazione e' violenta. La Commissione Europea apre un'indagine. Apple fa marcia indietro in meno di un mese.

Il pattern e' chiaro: Apple alza il muro, aspetta che qualcuno lo contesti con abbastanza forza, e poi apre uno spiraglio -- il minimo indispensabile. Il vibe coding e' il capitolo piu' recente di questa storia.

Cosa e' successo il 18 marzo

Apple non ha rimosso le app. Non ha inviato comunicati stampa. Ha fatto quello che sa fare meglio quando vuole mandare un messaggio senza esporsi: ha bloccato gli aggiornamenti in review.

Replit e Vibecode -- due delle app di vibe coding piu' usate su iOS -- si sono trovate impossibilitate a pubblicare nuove versioni. Il motivo formale: violazione della Guideline 2.5.2 delle App Store Review Guidelines e della Section 3.3.1(B) della Developer Program License. Nessun preavviso, nessuna discussione preventiva. Solo un rejection in review con un riferimento a regole vecchie di quasi sedici anni.

Replit, che valeva 9 miliardi di dollari ed era al primo posto nei Developer Tools gratuiti, e' scivolata al terzo. Il suo ultimo aggiornamento risale a gennaio 2026, quando aveva lanciato la feature "Mobile Apps" -- creare app iOS con linguaggio naturale, preview via QR code, pubblicazione su App Store "in 3 click". A Vibecode e' stato chiesto qualcosa di ancora piu' drastico: rimuovere la capacita' di generare app per piattaforme Apple.

La Guideline 2.5.2: una regola del 2010 contro una tecnologia del 2026

La regola invocata da Apple risale al 2010, quando il primo iPad aveva appena cinque mesi. In sostanza dice che un'app non puo' eseguire codice non incluso nel bundle dell'applicazione se quel codice modifica le funzionalita' dell'app stessa.

Il testo esatto:

"Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps."

Il problema tecnico e' specifico. Le app di vibe coding generano interfacce e logica applicativa tramite AI, poi mostrano il risultato all'utente. Replit lo faceva dentro una web view interna all'app -- e per Apple, questo equivale a eseguire codice arbitrario che modifica il comportamento dell'applicazione. L'argomento di Replit -- che il codice gira in una VM separata e viene "solo visualizzato, come quando apri un link in un'app social" -- e' stato respinto.

La soluzione che Apple propone? Aprire il risultato in un browser esterno, fuori dall'app. Una distinzione sottile dal punto di vista dell'utente, ma che per Apple rappresenta il confine tra "app che esegue codice" e "app che rimanda a un sito".

Applicare una regola del 2010 al vibe coding del 2026 e' come usare il codice della strada del primo Novecento per regolamentare le auto a guida autonoma. La tecnologia e' cambiata in modo fondamentale, la regola no.

Il codice di Schrodinger

Qui si apre il paradosso piu' interessante dell'intera vicenda. E tocca una domanda che nessuno ha ancora risolto in modo convincente.

Quando un utente apre Replit su iPhone e dice "creami una calcolatrice con tema scuro", l'AI genera codice React Native che produce un'interfaccia funzionante. Ecco la domanda: quel codice e' l'app o e' contenuto generato dall'utente?

Se scrivo un testo con AI su iPhone -- un'email, un post, un racconto -- nessuno lo considera "una nuova app". E' contenuto. Se disegno un'immagine con un'app AI, e' contenuto. Se genero un filtro Instagram con Canva, e' contenuto. Ma se genero codice che produce un'interfaccia, improvvisamente diventa "esecuzione di codice arbitrario che modifica le funzionalita' dell'app".

La Guideline 2.5.2, come nota Saagar Jha nella sua analisi del 2020, non distingue tra codice dello sviluppatore e codice creato dall'utente. Non contiene una definizione rigorosa di "scripting applications". I revisori, di conseguenza, applicano la regola in modo incoerente.

Lo stesso Jha fa notare un'analogia rivelatrice: le app di disegno non vengono respinte se un utente crea contenuti espliciti al loro interno. Ma le app di scripting vengono respinte per cio' che gli utenti generano. Lo strumento e' neutro -- e' l'output che viene giudicato. Ma solo se l'output e' codice.

Una calcolatrice generata da AI e' un'app o un risultato? Se e' un'app, allora anche una spreadsheet con formule complesse e' un'app. Se e' un risultato, allora la 2.5.2 non si applica. Apple ha scelto la prima interpretazione. Ma la linea e' sottile, e diventa piu' sottile ogni giorno.

L'elefante nella stanza: Xcode 26.3

Qui la storia si fa esplosiva. Il 3 febbraio 2026 Apple ha annunciato Xcode 26.3 con un comunicato dal titolo inequivocabile: "Xcode 26.3 Unlocks the Power of Agentic Coding". Il rilascio finale e' arrivato il 26 febbraio -- tre settimane prima del blocco su App Store.

Le feature? Claude Agent di Anthropic e Codex di OpenAI integrati direttamente nell'IDE. Generazione di codice tramite AI. Refactoring automatizzato. Debug assistito. Supporto per il Model Context Protocol. Agenti autonomi che possono esplorare file, aggiornare impostazioni, verificare con Xcode Previews, iterare su build e fix.

Susan Prescott, VP of Worldwide Developer Relations di Apple:

"Agentic coding supercharges productivity and creativity, streamlining the development workflow so developers can focus on innovation."

La stessa categoria di tecnologia -- agentic coding, AI che scrive e modifica codice -- che Apple promuove sul desktop e blocca su mobile. La differenza, dal punto di vista di Apple, e' che Xcode gira su macOS, dove le regole dell'App Store non si applicano, e genera codice che poi viene compilato e sottoposto a review. Le app di vibe coding su mobile generano ed eseguono codice nello stesso ambiente.

E' una distinzione tecnica valida. Ma il messaggio che arriva agli sviluppatori e' inequivocabile: Apple puo' integrare AI agentica nei propri strumenti. Tu no.

L'enforcement selettivo

C'e' un dettaglio che rende la posizione di Apple ancora piu' difficile da difendere. Vercel v0 -- che offre funzionalita' comparabili di generazione di interfacce tramite AI -- resta sull'App Store senza problemi. Nessun blocco, nessuna richiesta di modifiche. Anche Canva contiene feature AI che generano filtri, quiz e altri elementi interattivi.

Perche' Replit e Vibecode si', e v0 no? Apple non ha fornito spiegazioni pubbliche sulla differenza di trattamento.

Come nota Michael Tsai nel suo blog: se le app violano regole "di lunga data", perche' bloccare solo gli aggiornamenti e non rimuovere le app originali? Se la regola e' chiara, va applicata a tutti. Se non e' chiara, non si puo' applicarla selettivamente.

Un commento su Reddit sintetizza il problema:

"A large percentage of apps use the WebView component to show some content that changes without Apple's knowledge."

Se la regola non vale per tutti, non e' una regola. E' una scelta strategica.

La vera posta in gioco: chi controlla la creazione di software

Le app di vibe coding rappresentano una doppia minaccia per il modello di business di Apple.

Primo: bypassano l'App Store. Se un utente puo' creare un'app funzionante dentro Replit senza mai passare per il processo di review e la commissione del 30%, il modello economico dell'App Store si sgretola. Non e' teoria: ad aprile 2025 un giudice federale USA ha stabilito che Apple ha violato "intenzionalmente" l'ingiunzione Epic Games. Il 30% e' gia' sotto attacco legale da piu' fronti.

Secondo: competono con Xcode. Se chiunque puo' creare un'app con linguaggio naturale su Replit, il valore di Xcode -- e dell'intero ecosistema di sviluppo Apple -- diminuisce. E questo e' un problema strategico, non tecnico.

Gene Burrus, avvocato specializzato in competition law, lo dice senza giri di parole:

"Apple has a history of blocking apps or features that create competition."

Il vibe coding e la promessa tradita della democratizzazione

Il termine "vibe coding" lo ha coniato Andrej Karpathy il 2 febbraio 2025. Da allora ha una voce su Wikipedia, il Collins English Dictionary lo ha eletto Word of the Year 2025, e Replit da sola conta oltre 50 milioni di utenti.

La promessa del vibe coding e' semplice: chiunque puo' creare software. Descrivi cosa vuoi, l'AI scrive il codice. Non serve sapere programmare. Non serve un IDE da 8GB. Non serve un Mac da 2.000 euro.

E dove vive la maggior parte delle persone digitalmente? Sul telefono. Il mobile e' la piattaforma piu' accessibile al mondo -- e' il device che hanno in mano le persone che il vibe coding dovrebbe abilitare. Quelle che non hanno un Mac. Quelle che non sanno cosa sia un terminale. Quelle per cui "programmare" significava "impossibile" fino a un anno fa.

Apple sta mettendo un gate esattamente sul punto di accesso piu' democratico. E lo sta facendo mentre promuove la stessa tecnologia sul suo device meno accessibile -- il Mac con Xcode. L'ironia e' strutturale.

Karpathy stesso, nel suo recente racconto di come lavori esclusivamente con agenti AI da dicembre, descrive un mondo in cui il confine tra "scrivere codice" e "dirigere la scrittura di codice" e' svanito. Apple sta cercando di ridisegnare quel confine su mobile -- ma il treno e' gia' partito.

Cosa dice la community

Le reazioni degli sviluppatori sono state immediate e in larga parte critiche.

Su Reddit, il commento piu' votato:

"So I could not publish an IDE to the App Store if I wanted to? What a f---ing joke."

Su Slashdot, un'osservazione che coglie il punto strategico:

"If AI-generated app creation becomes truly effective, it is going to break the entire central app store model."

Chi difende Apple -- una minoranza, ma con argomenti non banali -- punta sulla sicurezza:

"Web views open up a window from inside an app through which very bad things can happen."

Ed e' vero. Le web view sono un vettore di attacco noto. Ma la soluzione non puo' essere "vietiamo tutto cio' che usa web view" -- perche' meta' delle app sull'App Store le usa gia'. La soluzione dovrebbe essere un framework di sicurezza specifico, non un blocco selettivo.

Nel frattempo, la reazione pragmatica di molti sviluppatori e' stata la piu' significativa: spostare tutto su web. Se Apple blocca l'app nativa, l'alternativa e' una web app che gira nel browser -- fuori dal controllo di Apple, fuori dalla commissione del 30%, fuori dalle guideline. Esattamente l'opposto di quello che Apple vorrebbe ottenere.

Tre scenari per il futuro

La situazione e' in movimento. Fonti vicine alla vicenda indicano che Apple e' gia' "vicina ad approvare gli aggiornamenti" dopo che gli sviluppatori hanno accettato modifiche. Ma il precedente resta. Cosa succede ora?

Scenario 1: Apple rilassa la regola (probabile). E' il pattern storico. Successo con gli emulatori, successo con le PWA in EU. Apple resiste, la pressione cresce, Apple cede -- ma alle sue condizioni. Potrebbe creare un'eccezione specifica per le app di "code generation" che non eseguono il risultato in-app. Non risolve il paradosso di fondo, ma elimina il problema pratico immediato.

Scenario 2: Apple crea un framework dedicato (possibile, ma lento). Un "Vibe Coding Kit" che permette alle app di terze parti di generare e visualizzare codice in un sandbox controllato da Apple. Vantaggi: sicurezza reale, standard uniforme. Svantaggi: Apple controllerebbe le regole del sandbox, diventando gatekeeper non solo della distribuzione ma anche della creazione.

Scenario 3: Apple mantiene il blocco (improbabile). Se il DMA europeo e le corti americane continuano a erodere il modello App Store, un blocco rigido sulle app di vibe coding diventa insostenibile politicamente e legalmente. Apple ha gia' ridotto la commissione al 15% per le "mini app" -- segno che sa di non poter tenere la linea dura su tutto.

La mia scommessa: finiremo nello scenario 1 entro giugno, con Apple che presenta il compromesso come "impegno verso l'innovazione" piuttosto che come resa.

Cosa significa per chi sviluppa

Se stai costruendo tool di coding per iOS, la Guideline 2.5.2 e' il tuo punto di attenzione critico. La linea di Apple e' tracciata: il codice generato non puo' essere eseguito dentro l'app tramite web view. Browser esterno, oppure trovi un'altra architettura. Vale la pena studiare come v0 ha strutturato la propria app per capire cosa passa la review e cosa no.

Se usi app di vibe coding su mobile, preparati a un periodo di transizione. Replit e Vibecode dovranno riprogettare il flusso utente per conformarsi, e questo probabilmente significhera' un'esperienza meno fluida -- almeno nel breve termine.

Se stai facendo agentic engineering, il messaggio e' chiaro: il desktop resta il campo di gioco aperto. Xcode, VS Code, Cursor, Claude Code, Windsurf -- nessuna di queste piattaforme ha limiti su cosa il codice generato puo' fare. Il mobile e' un altro mondo, con regole dettate dai gatekeeper.

Se guardi il quadro generale, questa vicenda conferma il pattern Apple: usare le regole dell'App Store come leva competitiva, applicandole in modo selettivo. Non e' la prima volta, non sara' l'ultima. Per chi costruisce prodotti nell'ecosistema Apple, la variabile "rischio di policy" resta una delle piu' difficili da gestire -- e da prevedere.

Il codice di Schrodinger non si risolvera' con una guideline. Si risolvera' quando la pressione -- legale, di mercato, regolatoria -- rendera' il muro piu' costoso dello spiraglio.

Fonti: