Hello Eskimo. Yes, it crashed when call is accepted, and after that app moved to background, after 8-10 seconds app crashed, debugger didn't stop on breakpoint, and just deattach and that's Crash report didn't generated ( if you mean popup with suggesting to share crash report )

Also, I wanna mention that contact sync is very huge operation, it load CPU for 200% and consume ~300MB memory ( when contact sync is not running, app consuming ~60mb of memory ). It's possible that app just killed by system? If yes, it's possible to catch any crash report about it? And also, if it's because of system kill, why on default qos it's didn't crash?

Hello Eskimo. I mean crashed = application closed by itself ( so, debug just deattached without stoping on crash point ), there is no any crash reports

Sorry, I checked crash reports on device, and found it End time: 2023-04-11 17:41:46.415 +0300 OS Version: iPhone OS 16.0 (Build 20A5358a) Architecture: arm64e Report Version: 40 Incident Identifier: 1F445A43-8DCB-4E8D-96F9-209B10FDBC9C Data Source: Microstackshots Shared Cache: 41C4C004-2ABC-3233-90B1-83787B898BAE slid base address 0x1c6514000, slide 0x46514000 Command: ?? Path: ??? Identifier: ??? Version: ??? Is First Party: No Beta Identifier: E2CAB17F-6D07-443E-992A-4E2DC907A59C Resource Coalition ID: 441 Architecture: arm64 PID: 1213 Event: cpu usage Action taken: Process killed CPU: 9 seconds cpu time over 10 seconds (91% cpu average), exceeding limit of 60% cpu over 15 seconds CPU limit: 9s Limit duration: 15s CPU used: 9s CPU duration: 10s Duration: 9.93s Duration Sampled: 8.13s Steps: 7 Hardware model: iPhone12,8 Active cpus: 6 HW page size: 16384 VM page size: 16384 Advisory levels: Battery -> 3, User -> 3, ThermalPressure -> 10, Combined -> 1 Free disk space: 29.02 GB/59.57 GB, low space threshold 150 MB Preferred User Language: en-BY, ru-BY Country Code: BY Keyboards: ru_RU Russian, en_GB QWERTY OS Cryptex File Extents: 501 Heaviest stack for the target process: 6 ??? (libsystem_pthread.dylib + 2968) [0x2197ddb98] 6 ??? (libsystem_pthread.dylib + 3516) [0x2197dddbc] 6 ??? (libdispatch.dylib + 90756) [0x1d4620284] 6 ??? (libdispatch.dylib + 88684) [0x1d461fa6c] 6 ??? (libdispatch.dylib + 27348) [0x1d4610ad4] 6 ??? (libdispatch.dylib + 29804) [0x1d461146c] 6 ??? (libdispatch.dylib + 16348) [0x1d460dfdc] 6 ??? (libdispatch.dylib + 9396) [0x1d460c4b4] 6 ??? (BIP + 3065980) [0x10258887c] 6 ??? (BIP + 19742016) [0x10356fd40] 6 ??? (BIP + 19742452) [0x10356fef4] 6 ??? (BIP + 10189732) [0x102c53ba4] 6 ??? (BIP + 10187852) [0x102c5344c] 6 ??? (BIP + 18086368) [0x1033db9e0] 6 ??? (BIP + 18082508) [0x1033daacc] 6 ??? (libswiftCore.dylib + 1944068) [0x1c729ba04] 6 ??? (BIP + 18084192) [0x1033db160] 6 ??? (BIP + 18084088) [0x1033db0f8] 6 ??? (BIP + 18084044) [0x1033db0cc] 6 ??? (BIP + 18083996) [0x1033db09c] 6 ??? (BIP + 18083924) [0x1033db054] 6 ??? (BIP + 19122028) [0x1034d876c] 6 ??? (libswiftCore.dylib + 1944068) [0x1c729ba04] 6 ??? (BIP + 19124192) [0x1034d8fe0] 5 ??? (BIP + 19122648) [0x1034d89d8] 5 ??? (BIP + 4782628) [0x10272ba24] 5 ??? (BIP + 4782352) [0x10272b910] 5 ??? (BIP + 8848368) [0x102b0c3f0] 4 ??? (<84DA0320-5E0E-314A-871A-6B65FF5A37B8> + 30844) [0x113b2b87c] 3 ??? (<84DA0320-5E0E-314A-871A-6B65FF5A37B8> + 31544) [0x113b2bb38] 3 ??? (<9E5D4BE8-D37D-39D5-AD92-591942F765ED> + 143564) [0x1102130cc] 1 ??? (<9E5D4BE8-D37D-39D5-AD92-591942F765ED> + 149396) [0x110214794] 1 ??? (<9E5D4BE8-D37D-39D5-AD92-591942F765ED> + 139540) [0x110212114] 1 ??? (Foundation + 107836) [0x1c767653c] 1 ??? (CoreFoundation + 534692) [0x1cd23e8a4] 1 ??? (CoreFoundation + 548664) [0x1cd241f38] 1 ??? (CoreFoundation + 334200) [0x1cd20d978] 1 ??? (CoreFoundation + 388804) [0x1cd21aec4] 1 ??? (CoreFoundation + 72496) [0x1cd1cdb30] Powerstats for: ?? UUID: EF3821FB-7111-3550-8A6A-F359EABEBDD6 Path: ?? Identifier: ?? Version: ?? Is First Party: No Beta Identifier: E2CAB17F-6D07-443E-992A-4E2DC907A59C Resource Coalition ID: 441 Architecture: arm64 Footprint: 214.69 MB -> 243.77 MB (+29.08 MB) (max 298.22 MB ) Pageins: 7 pages Start time: 2023-04-11 17:41:37.975 +0300 End time: 2023-04-11 17:41:46.103 +0300 Num samples: 7 (100%) Primary state: 6 samples Non-Frontmost App, Non-Suppressed, User mode, Effective Thread QoS Utility, Requested Thread QoS Utility, Override Thread QoS Unspecified User Activity: 0 samples Idle, 7 samples Active

I faced with same problem, did anyone have solution for it?

Also, in device logs, after extension is started, I see this error: Could not read values in CFPrefsPlistSource<address> (Domain:group.domain) User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents need refresh: Yes): Using kCFPreferencesAnyUser with a container is only allowed for system containers. detaching from cfprefsd

Today, I found one more error in device logs, can it be related with problem? Requestor: TCCDProcess: identifier=com.apple.nsurlsessiond, pid=109, auid=501, euid=501, binary_path=/usr/libexec/nsurlsessiond is not entitled to check access for accessor TCCDProcess: identifier=*.notificationextension, pid=6292, auid=501, euid=501, binary_path=/private/var/containers/Bundle/Application/8D9CB575-1B13-46F7-B4B2-803EC4A969AC/*.app/PlugIns/*.appex/NSE

Problem was in crash because of memory limit for NSE I thought that if it crashed because of memory, I will see crash report on "Device Crashes" tab, but there was no crashes related to memory. After I check device logs thought Console , I found limit about memory EXC_RESOURCE -> `ProcessName`[8554] exceeded mem limit: ActiveHard 24 MB (fatal)

@mungbeans yes, I received notification, after that web socket get ( from singleton class ) so, after contentHandler is get called, NSE process is still alive, and singleton also continue exist in memory, so, next time when you receive new notification, singleton won't init again, and same instance will be used. It was tested on real device, my NSE process ( and socket connection ) alive about 10 minutes, I think it can alive more, but as I understand from answer, system can kill it anytime