IOS avvierà la mia app in background se è stata forzatamente chiusa dall'utente?

Sto attivando un recupero in background utilizzando la content-availablebandiera su una notifica push. Ho il fetche remote-notification UIBackgroundModesabilitato.

Ecco l'implementazione che sto usando nel mio AppDelegate.m:

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler
{
    NSLog(@"Remote Notification Recieved");
    UILocalNotification *notification = [[UILocalNotification alloc] init];
    notification.alertBody =  @"Looks like i got a notification - fetch thingy";
    [application presentLocalNotificationNow:notification];
    completionHandler(UIBackgroundFetchResultNewData);

}

Quando l'app è in esecuzione in background, funziona benissimo. (La notifica viene ricevuta e l'app ha attivato la notifica locale "sembra che ho ricevuto una notifica", come dovrebbe fare il codice sopra).

Tuttavia, quando l'app non è in esecuzione e viene ricevuta una notifica push con il content-availableflag, l'app non viene avviata e il didRecieveRemoteNotificationmetodo delegato non viene mai chiamato.

Il video del WWDC Novità del multitasking (n. 204 del WWDC 2013) mostra questo:

Dice che l'applicazione viene "lanciata in background" quando viene ricevuta una notifica push con il content-availableflag.

Perché la mia app non si avvia in background?

Quindi la vera domanda è:

IOS eseguirà attività in background dopo che l'utente ha chiuso forzatamente l'app?

UPDATE2:

È possibile ottenere ciò utilizzando il nuovo framework PushKit, introdotto in iOS 8. Sebbene PushKit sia utilizzato per VoIP. Quindi il tuo utilizzo dovrebbe essere legato al VoIP, altrimenti c'è il rischio di rifiuto dell'app. (Vedi questa risposta ).

UDPDATE1:

La documentazione è stata chiarita per iOS8 . La documentazione può essere letta qui . Ecco un estratto rilevante:

Utilizza questo metodo per elaborare le notifiche remote in arrivo per la tua app. A differenza del application:didReceiveRemoteNotification:metodo, che viene chiamato solo quando l'app è in esecuzione in primo piano, il sistema chiama questo metodo quando l'app è in esecuzione in primo piano o in background. Inoltre, se hai attivato la modalità in background delle notifiche remote, il sistema avvia la tua app (o la riattiva dallo stato sospeso) e la mette in background quando arriva una notifica push. Tuttavia, il sistema non avvia automaticamente la tua app se l'utente l'ha forzata ad uscire. In tale situazione, l'utente deve riavviare l'app o riavviare il dispositivo prima che il sistema tenti di riavviare l'app automaticamente.

Sebbene ciò non sia stato chiarito dal video del WWDC, una rapida ricerca nei forum degli sviluppatori ha rivelato questo:

https://devforums.apple.com/message/873265#873265 (è richiesto il login)

Inoltre, tieni presente che se uccidi la tua app dallo switcher (ovvero scorri verso l'alto per uccidere l'app), il sistema operativo non riavvierà mai l'app indipendentemente dalla notifica push o dal recupero in background. In questo caso l'utente deve riavviare manualmente l'app una volta e da quel momento in poi verranno invocate le attività in background. - Pmarcos

Quel post era di un dipendente Apple, quindi penso di potermi fidare che queste informazioni siano corrette.

Quindi sembra che quando l'app viene uccisa dallo switcher dell'app (scorrendo verso l'alto), l'app non verrà mai avviata, anche per i recuperi in background pianificati.

È possibile modificare le impostazioni di avvio del target in "Gestisci schema" in Wait for <app>.app to be launched manually, che consente di eseguire il debug impostando un punto di interruzione application: didReceiveRemoteNotification: fetchCompletionHandler:e inviando la notifica push per attivare l'avvio in background.

Non sono sicuro che risolverà il problema, ma per il momento potrebbe aiutarti con il debug.

La risposta è SÌ, ma non utilizzare "Recupero sfondo" o "Notifica remota". PushKit è la risposta che desideri.

In breve, PushKit, il nuovo framework di iOS 8, è il nuovo meccanismo di notifica push che può avviare silenziosamente la tua app in background senza alcun avviso visivo anche se la tua app è stata uccisa scorrendo dallo switcher di app, sorprendentemente non puoi nemmeno vederla dal commutatore di app.

Riferimento PushKit di Apple:

Il framework PushKit fornisce le classi per le tue app iOS per ricevere push dai server remoti. I push possono essere di due tipi: standard e VoIP. I push standard possono inviare notifiche proprio come nelle versioni precedenti di iOS. I push VoIP forniscono funzionalità aggiuntive oltre al push standard necessario alle app VoIP per eseguire l'elaborazione su richiesta del push prima di visualizzare una notifica all'utente.

Per distribuire questa nuova funzionalità, consultare questo tutorial: https://zeropush.com/guide/guide-to-pushkit-and-voip : l' ho testato sul mio dispositivo e funziona come previsto.

In realtà, se è necessario testare il recupero in background, è necessario abilitare un'opzione nello schema:

Un altro modo per testarlo:

Ecco le informazioni complete su questa nuova funzionalità: http://www.objc.io/issue-5/multitasking.html

Ho provato diverse varianti di questo per giorni e ho pensato per un giorno di averlo riavviato l'app in background, anche quando l'utente ha strisciato per uccidere, ma no non riesco a replicare quel comportamento.

È un peccato che il comportamento sia piuttosto diverso rispetto a prima. Su iOS 6, se hai ucciso l'app dalle icone jiggling, verrebbe comunque risvegliata sui trigger SLC. Ora, se uccidi scorrendo, ciò non accade.

È un comportamento diverso e l'utente, che continuerebbe a ottenere informazioni utili dalla nostra app se le avesse uccise su iOS 6, ora non lo farà.

Dobbiamo spingere i nostri utenti a riaprire l'app ora se hanno fatto scorrere per ucciderla e si stanno ancora aspettando alcuni dei comportamenti di notifica che abbiamo usato per dare loro. Temo che questo non sarà ovvio per gli utenti quando trascinano via un'app. Dopotutto, potrebbero sostanzialmente ripulire o voler riorganizzare le app mostrate minimizzate.

Questo potrebbe aiutarti

Nella maggior parte dei casi, il sistema non riavvia le app dopo che sono state forzatamente chiuse dall'utente. Un'eccezione sono le app di localizzazione, che in iOS 8 e versioni successive vengono riavviate dopo essere state forzate a uscire dall'utente. In altri casi, tuttavia, l'utente deve avviare esplicitamente l'app o riavviare il dispositivo prima che l'app possa essere avviata automaticamente in background dal sistema. Quando la protezione con password è abilitata sul dispositivo, il sistema non avvia un'app in background prima che l'utente sblocchi il dispositivo per la prima volta.

Fonte: https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html

For **iOS13**

For background PUSHES in iOS13 you must set below parameters
apns-priority = 5
apns-push-type = background
Required for WatchOS
Highly recommended for Other platforms 

Il link del video: https://developer.apple.com/videos/play/wwdc2019/707/