La buona notizia è che Apple offre un modo per rispondere una volta sola, direttamente nel progetto: la chiave ITSAppUsesNonExemptEncryption in Info.plist.

Come funziona

Quando non trova questa chiave, App Store Connect ti fa compilare il questionario di export compliance a ogni caricamento: la build va su server negli Stati Uniti, e le leggi statunitensi sull’esportazione di software criptato richiedono una dichiarazione. Aggiungendo la chiave al Info.plist, la dichiarazione viaggia dentro il binario stesso, e il prompt sparisce sia per TestFlight che per la pubblicazione sull’App Store.

Il valore giusto per la stragrande maggioranza delle app:

<key>ITSAppUsesNonExemptEncryption</key>
<false/>

Un attenzione al dettaglio tecnico: deve essere un Booleano vero, non la stringa "NO" o "false" tra virgolette. Xcode lo scrive correttamente se aggiungi la chiave dall’interfaccia.

Aggiungerla da Xcode

1. Seleziona il progetto nel navigatore, poi il target dell’app
2. Apri il tab Info
3. Aggiungi una nuova proprietà: App Uses Non-Exempt Encryption
4. Tipo: Boolean, valore: NO

In alternativa, modifica direttamente il file Info.plist in vista sorgente.

Dopo averla aggiunta: Clean Build Folder (⇧⌘K), archivia di nuovo e carica. La build già presente su App Store Connect non la rileverà retroattivamente, quindi sblocca quella vecchia a mano — ma dalla prossima in poi non te lo chiederà più.

Quando è corretto usare false

Il nome della chiave si presta a confusione: non chiede se la tua app “usa la cifratura”, ma se usa cifratura non esente (non-exempt). Puoi impostare false quando l’app — comprese tutte le librerie di terze parti linkate — non usa cifratura, oppure usa solo cifratura esente dalle documentazioni di export compliance.

Copre praticamente tutte le app “normali”:

• chiamate HTTPS a un backend tramite URLSession o URLSessionWebSocketTask — l’HTTPS tramite le API di sistema è esente
• salvataggio di credenziali nel Keychain
• uso di framework Apple (CryptoKit, Security, CloudKit, StoreKit, Sign in with Apple, push notification)

Se usi SDK di terze parti che implementano la propria crittografia (un proprio motore crittografico, non le API di sistema), vale la pena verificare prima di dichiarare false.

Quando invece serve true

Impota true solo se la tua app usa cifratura non esente: algoritmi proprietari o non standard, protocolli crittografici custom (es. E2E messaging fatto in casa), librerie crittografiche bundled come OpenSSL o libsodium usate per la cifratura come funzionalità principale. In quel caso non basta la chiave: dovrai caricare la documentazione di export compliance su App Store Connect e, una volta approvata, Apple ti fornirà un codice da inserire in ITSEncryptionExportComplianceCode.

Perché conviene anche in CI/CD

Se usi Xcode Cloud o una pipeline CI per archiviare e caricare build, questo blocco diventa un vero ostacolo: i processi automatizzati si fermano in attesa di un’azione manuale su App Store Connect. Con la chiave nel Info.plist, l’intero flusso — build, archive, upload, distribuzione ai tester — scorre senza interruzioni.

Il risvolto legale, per onestà

Questa dichiarazione è una dichiarazione legale: la responsabilità di un’eventuale classificazione errata ricade sullo sviluppatore, non su Apple. Per la tipica app consumer che comunica con un backend via HTTPS è un’esenzione tranquilla e consolidata, ma se la tua app ha componenti crittografiche non banali, vale la pena leggere la documentazione Apple sull’export compliance e, se necessario, consultare un esperto.

Riepilogo

Una riga di Info.plist e addio al questionario. Il tempo risparmiato, build dopo build, si accumula più di quanto sembri.

enjoy!

flutter run -d 00007046-004082773524571B

per testare l’applicazione, scollegando il cavo l’appl’icazione non riparte e viene mostrato il messaggio:

In iOS 14+, debug mode Flutter apps can only be launched from Flutter tooling, IDEs with Flutter plugins or from Xcode.
Alternatively, build in profile or release modes to enable launching from the home screen.

approfitto per ricordarvi che Flutter in debug costruisce un “app sandbox” che comunica costantemente via USB/network con l’host per:

• Hot reload / hot restart
• DevTools (debugger, performance, logging)
• Dart VM service

Da iOS 14 in poi, per questioni di sicurezza, Apple blocca l’apertura di queste app dalla home se non sono state avviate dal tooling (Flutter/Xcode). Non è un bug: è una limitazione voluta.

Soluzione: installa in release o profile mode

Queste due modalità compilano AOT (codice macchina nativo ARM) e non richiedono connessione all’host. Funzionano a cavo scollegato.

Passaggi da fare:

1. Verifica prerequisiti sull’iPhone (solo 1a volta)

• Sblocca iPhone e tienilo sullo schermo home durante l’installazione.
• Developer Mode ON: Impostazioni → Privacy e sicurezza → Modalità sviluppatore → ON (riavvio richiesto).
• Fiducia computer: quando compare il popup "Fiducia di questo computer?" su iPhone → tocca Fiducia e inserisci il codice.

2. Controlla che Flutter veda il device

flutter devices

Dovresti vedere iPhone di XXXX (mobile) in elenco (non simulator). Se non lo vede:

brew install libimobiledevice ideviceinstaller ios-deploy

3. Installa in RELEASE mode (scelta consigliata per usarlo senza cavo)

flutter run --release -d 

oppure con il nome:

flutter run --release -d "iPhone di XXXX"

⚠️ Se ti chiede la password del keychain / permessi di accesso a Xcode: rispondi Consenti sempre (il sandbox dell’IDE spesso inghiotte questi dialoghi, per questo dal terminale esterno è più sicuro).

4. Alternative se flutter run fallisce per il signing

Se incontri errori di code signing / provisioning profile:

1. Apri Xcode → Apri progetto: ios/Runner.xcworkspace
2. Seleziona target Runner → Tab "Signing & Capabilities"
3. Team: seleziona il tuo account Apple Developer (anche free va bene)
4. Bundle Identifier: metti qualcosa di unico (es. com.tuonome.xxxxx)

Poi ridai:

flutter run --release -d "iPhone di XXXX"

5. Modalità Profile (utile se vuoi anche performance monitor, ma sempre standalone)

Se vuoi anche misurare performance:

BashRun

flutter run --profile -d "iPhone di XXXX"

6. Verifica cavo scollegato

Quando il terminale stampa:

💪  Running with sound null safety
🔥  To hot restart changes while running, press "r" or "R".

L’app è installata e avviata. Adesso puoi:

1. Premere q nel terminale per chiudere il processo Flutter (non disinstalla niente).
2. Staccare il cavo USB.
3. Aprire l’app dgtv direttamente dalla home di iOS: ✅ funzionerà.

enjoy!

Si può in alternativa usare unar, procediamo in questo modo:

brew uninstall unrar
brew install unar

unar archivio.rar

enjoy!

Basta aprire una nuova scheda di Firefox e digitare nella barra degli indirizzi:

about:processes

Questo mostrerà un elenco di tutte le finestre con il titolo e la RAM usata e, oltretutto, la possibilità di scaricare direttamente la scheda per liberare RAM.

enjoy!

Nel mio esempio il proxy è attivo sulla macchina host, pertanto lo si può “puntare” con il nome host.docker.internal avendo l’accortezza di aggiungere, come vedremo in avanti, nel file compose.yaml:

      extra_hosts:
        - "host.docker.internal:host-gateway"

Ipotizziamo che il Dockerfile contenga qualcosa di questo tipo:

# Stage 1: Dipendenze
FROM node:20-alpine AS deps
RUN apk add --no-cache libc6-compat
WORKDIR /app

dobbiamo aggiungere le necessarie variabili facendolo diventare:

# Stage 1: Dipendenze
FROM node:20-alpine AS deps
ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

ENV HTTP_PROXY=${HTTP_PROXY}
ENV HTTPS_PROXY=${HTTPS_PROXY}
ENV NO_PROXY=${NO_PROXY}
ENV http_proxy=${HTTP_PROXY}
ENV https_proxy=${HTTPS_PROXY}
ENV no_proxy=${NO_PROXY}

RUN apk add --no-cache libc6-compat
WORKDIR /app

Importante: Se l’applicativo cerca la variabile proxy in altro modo, ad esempio pip lanciato nel docker file, bisognerà dichiarare il proxy anche li in modo specifico, es:

COPY requirements.txt .
RUN python -m pip config --user set global.proxy $HTTP_PROXY
RUN pip install --no-cache-dir -r requirements.txt

ora passiamo a modificare il compose.yaml che da:

services:
  app:
    image: gest:latest
    build:
      context: .
      dockerfile: Dockerfile
      args:
        BUILD_GIT_SHA: ${BUILD_GIT_SHA:-unknown}
        BUILD_DATE: ${BUILD_DATE:-unknown}
    container_name: app-club
    restart: unless-stopped

dovrà diventare:

services:
  app:
    image: gest:latest
    build:
      context: .
      dockerfile: Dockerfile
      args:
        BUILD_GIT_SHA: ${BUILD_GIT_SHA:-unknown}
        BUILD_DATE: ${BUILD_DATE:-unknown}
        HTTP_PROXY: http://host.docker.internal:8888
        HTTPS_PROXY: http://host.docker.internal:8888
        NO_PROXY: 127.0.0.1,localhost
      extra_hosts:
        - "host.docker.internal:host-gateway"
    container_name: app-club
    restart: unless-stopped
    extra_hosts:
      - "host.docker.internal:host-gateway"

Nota: il TAG extra_hosts è ripetuto due volte, perché uno viene passato come ARG e l’altro viene usato dalla machcina docker.

enjoy!

L’installazione è molto semplice:

sudo -v ; curl https://rclone.org/install.sh | sudo bash

Oppure in modo specifico per MacOS:

brew install rclone

alla prima esecuzione bisogna configurare i dati di connessione:

rclone config

Questi gli step durante la configurazione (che poi viene scritta nel file ~/.config/rclone/rclone.conf):

• Premi n per n) New remote.
• Inserisci un nome, es eu2.
• Inserisci 5 per Amazon S3 Compatibile oppure 4 per Ceph Object Storage.
• Inserisci 1 per impostare le credenziali AWS o compatibili nel successivo step.
• Inserisci access_key per access_key_id.
• Inserisci secret_key, per secret_access_key.
• Premi invio per saltare la regione
• Inserisci l’endpoint url S3, es https://eu2.storage.ext.
• Premi invio per saltare la location_constraint.
• Premi invio per saltare le acl.
• Premi invio per saltare server_side_encryption.
• Premi invio per saltare sse_kms_key_id.
• Inserisci n per Modificare la configurazione avanzata.
• Inserisci y per confermare.
• Premi q per uscire dalla configurazione.

Dopo aver configurato la connessione, vediamo i principali comandi. Ipotizziamo che il nostro server si chiami eu2.

elenco file nel bucket test su server eu2:

rclone ls eu2:test/

elenco file, con dettagli, nel bucket test su server eu2:

rclone lsl eu2:test/

copio ker.txt dal bucket test dal server eu2 sul disco locale:

rclone copy eu2:test/ker.txt .

sync da /backup/ (source) verso server eu2 sul bucket cpanel(dest):

rclone sync -P /backup/ eu2:cpanel/ --s3-no-head

creo la cartella pluto:

rclone mkdir eu2:test/pluto

sposto pippo.txt nella cartella pluto:

rclone move eu2:test/pippo.txt ue2:test/pluto/

cancello la cartella pluto ed il realtivo contenuto, tipo rm -fr:

rclone purge eu2:test/pluto

cancello il file pippo.txt:

rclone delete eu2:test/pluto/pippo.txt

montare la cartella remota pluto in locale:

rclone mount eu2:pluto /mnt --vfs-cache-mode full --vfs-fast-fingerprint --no-modtime

enjoy!

Partiamo intanto vedendo come si crea un ambiente venv:

python3 -m venv ambiente_venv

questo crea nella cartella chiamata ambiente_venv il nostro ambiente di sviluppo. All’interno di questa cartella vengono create una serie di altre cartelle (es bin, lib) con quello che ci occorre. Una volta creato l’ambiente bisogna attivarlo e questo si fa scrivendo:

cd ambiente_venv
source bin/activate

mentre per uscire basterà digitare:

deactivate

Nota: Ovviamente possiamo anche eseguire gli script python direttamente scrivendo bin/python3 in modo da avviare automaticamente l’ambiene per lo script richiamato.

A questo punto ipotizziamo di aver installato una serie di librerie e che sia necessario replicare questo ambiene su una seconda macchina. Sulla prima macchina scriviamo:

pip freeze > requirements.txt

se abbiamo prima attivato l’ambiente, oppure direttamente:

bin/pip freeze > requirements.txt

e questo creerà il classico file requirements.txt con l’elenco delle librerie installate. Ora creiamo l’ambiene venv nella seconda macchina con:

python3 -m venv ambiente_venv

poi copiamo il file requirements.txt dalla prima alla seconda macchina, attiviamo l’ambiente venv:

cd ambiente_venv
source bin/activate

ed infine reinstalliamo tutte le librerie necessarie:

pip install -r requirements.txt

enjoy!

Mentre per copiare, ad esempio, tutti i file .txt da locale al server remoto basta:

scp *.txt 10.10.10.10:~/

per fare la copia inversa, occorre inserire il carattere di escape \ prima del carattere *, ovvero:

scp  10.10.10.10:~/\*.txt .

oppure, in alternativa, tutto il riferimento al server/path va racchiuso tra apici o virgolette, es:

scp  "10.10.10.10:~/*.txt" .

enjoy!

Ad esempio, dopo aver fatto il login ed essersi posizionati nel giusto percorso, per copiare in locale tutto il contenuto remoto:

mirror .

o viceversa per copiare in remoto tutto il contenuto locale:

mirror . -R

Il comando mirror ha molti parametri, ad esempio per proseguire in caso di errore e lanciare 10 processi paralleli di copia:

mirror . -c --parallel=10

La procedura di copia può richiedere molto tempo, in questo caso possiamo uscire da lftp e lasciare a lui completare la procedura.

Un’altra cosa comoda che può richiedere molto tempo è la cancellazione di contenuti, che può essere fatta con il comando mrm; ad esempio per cancellare la cartella chiamata AA e tutto il suo contenuto

mrm -r AA

Mentre i dati vengono copiati, premiamo su CTRL+Z e vedremo indicato qualcosa tipo:

[0] mirror . -R & -- 53M/53M (99%)

Scriviamo poi exit nel terminale e torneremo in console con la scritta:

[1692112] Moving to background to complete transfers…

il numero scritto tra parentesi quadre 1692112 è il PID del processo lasciato in esecuzione. Eventualmente non ne prendiamo nota si può ricavare con:

pgrep lftp

Prima che la procedura sia completata, possiamo ricollegarci al pid indicato per vedere cosa accade.

Lanciamo lftp:

lftp

poi scriviamo:

attach 1692112

e digitiamo

jobs

per vedere i processi appesi. Potrebbe essere mostrato qualcosa del genere:

[0] mirror . -R -- 201M/201M (100%)
\mirror wp-content' -- 142M/142M (100%) \mirrorwp-content/plugins' -- 114M/114M (100%)

per fermare il processo:

kill 0

perché nell’elempio precedente il processo ha il numero 0.

enjoy!

Ipotizziamo di voler trasferire portainer.

Innanzitutto scarichiamo il container se ancora non lo abbiamo fatto:

docker pull portainer/portainer-ce:lts

ora lo archiviamo:

docker save -o portainer.tgz portainer/portainer-ce:lts

Lo copiamo sull’altro host e lo importiamo con:

docker load -i portainer.tgz

Nota: qualora sul server di appoggio non serva mantenere l’immagine di portainer, la possiamo rimuovere con:

docker rmi portainer/portainer-ce:lts

enjoy!