Acabo de hacer una pregunta similar ; el mío fue sobre cómo Apple solucionará esto, no necesariamente lo que hace el error que hace que el teléfono se bloquee.
Como sugirió @LvB, parece ser un error en el procesamiento de texto de notificación de SpringBoard, donde el programa lee infinitamente la cadena Unicode en la memoria, ocupando toda la memoria disponible. Luego, el SpringBoard lanza un fallo de segmentación cuando intenta asignar la memoria que posee el kernel. Parece un reinicio 'rápido' porque solo se reinicia el SpringBoard.
Apple no ha publicado ningún detalle, pero esta es mi salida de Settings/Privacy/Diagnostics & Usage/Diagnostics & Usages Data/LatestCrash.ips :
Hardware Model: iPhone4,1
Process: SpringBoard [395]
Path: /System/Library/CoreServices/SpringBoard.app/SpringBoard
Identifier: com.apple.springboard
Version: 50 (1.0)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2015-05-27 13:59:33.737 -0400
Launch Time: 2015-05-27 13:36:16.197 -0400
OS Version: iOS 8.3 (12F70)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x403c0a40
Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 CoreText 0x28bf2264 0x28b54000 + 647780
1 CoreText 0x28bc2e64 0x28b54000 + 454244
2 CoreText 0x28bc37f8 0x28b54000 + 456696
3 CoreText 0x28b8fb9c 0x28b54000 + 244636
4 CoreText 0x28b91350 0x28b54000 + 250704
5 CoreText 0x28b64716 0x28b54000 + 67350
6 CoreText 0x28b644f6 0x28b54000 + 66806
7 CoreText 0x28b64372 0x28b54000 + 66418
8 UIFoundation 0x332561ca 0x331fb000 + 373194
9 UIFoundation 0x332585ec 0x331fb000 + 382444
10 SpringBoard 0x00320f9c 0x89000 + 2719644
11 SpringBoard 0x00321084 0x89000 + 2719876
12 SpringBoard 0x003212e0 0x89000 + 2720480
13 SpringBoard 0x002bbb6c 0x89000 + 2304876
14 SpringBoard 0x003020a8 0x89000 + 2592936
15 SpringBoard 0x00301052 0x89000 + 2588754
16 SpringBoard 0x0025d472 0x89000 + 1918066
17 SpringBoard 0x0025d374 0x89000 + 1917812
18 SpringBoard 0x0025d3e6 0x89000 + 1917926
19 SpringBoard 0x0025d724 0x89000 + 1918756
20 SpringBoard 0x0025d52a 0x89000 + 1918250
21 SpringBoard 0x0025c2ba 0x89000 + 1913530
22 CoreFoundation 0x2823b850 0x2812d000 + 1108048
23 CoreFoundation 0x28165fe8 0x2812d000 + 233448
24 libdispatch.dylib 0x36831c80 0x36830000 + 7296
25 libdispatch.dylib 0x36831c6c 0x36830000 + 7276
26 libdispatch.dylib 0x3683d54e 0x36830000 + 54606
27 CoreFoundation 0x281fc884 0x2812d000 + 850052
28 CoreFoundation 0x281fafa4 0x2812d000 + 843684
29 CoreFoundation 0x2814699c 0x2812d000 + 104860
30 CoreFoundation 0x281467ae 0x2812d000 + 104366
31 GraphicsServices 0x2f91f1a4 0x2f916000 + 37284
32 UIKit 0x2b8d1690 0x2b862000 + 456336
33 SpringBoard 0x000908b4 0x89000 + 30900
34 libdyld.dylib 0x3686faac 0x3686e000 + 6828
Esto es solo a través del subproceso 0 (el que se estrelló) porque el resto no es realmente importante.
Desde el registro de fallos puede ver que la aplicación que se bloqueó fue SpringBoard, y la causa es un SIGSEGV (falla de segmentación). Luego, el seguimiento de la pila (ignorar la llamada al sistema en la línea 34) sugiere que fue causado por:
33 SpringBoard 0x000908b4 0x89000 + 30900
Toma esto con un grano de sal. Ya que no sé cuál es el código fuente, y Apple ocultó sus registros de bloqueo con direcciones en lugar de nombres de función (que solía dar nombres de función), solo se puede adivinar por el seguimiento de la pila y el comportamiento del bloqueo.
También podría ser un problema con la forma en que CoreText procesa la cadena antes y la pasa a SpringBoard, no lo sabemos porque no diseñamos las aplicaciones internas en CoreServices.