Hello all. I noticed, that NSE living more than 30 seconds ( that described in doc ). When app receive notification, it created process NSE, and send notification to didReceive function, after this, app have 30 seconds to call contentHandler closure, after contentHandler is called, I expected that NSE process is killed, but it's not. If app using singletons in NSE, they won't dealloc after contentHandler is called, so, after new notification received, singletons still alive. Does it legal to not drop connection to websocket after contentHandler closure get called? For example, notification received, NSE process is loaded, websocket manager signleton is initialzied and started session, after few seconds contentHandler closure get called, so, system won't kill NSE because of 30 seconds timer, and my web socket connection will alive so long as possible, so, I not need to open it each 30 seconds, is that legal or not?)

Hello all. I face problem with Notification Service Extension. User mobile receive notification without any problem, payload contain mutable-content:1 inside it ( also, full example of payload is attached ), but, NSE didn't run correctly, also, original content of notification didn't saw ( in case, and there is a crash because of something wrong in app ) I checked device logs, and I see next errors: [*] Mutated notification request is nil, will supress original content; notificationRequest=7019-8D60, error=Error Domain=NSCocoaErrorDomain Code=4097 "connection from pid 487 on anonymousListener or serviceListener" UserInfo={NSDebugDescription=connection from pid 487 on anonymousListener or serviceListener}, runtime: 0.410339 [*.notificationextension] Service extension connection encountered an error: sessionUUID=88D39801-67DF-4DC7-AA70-2AD7E8634369, error=Error Domain=NSCocoaErrorDomain Code=4099 "The connection from pid 505 on anonymousListener or serviceListener was invalidated: client is gone." UserInfo={NSDebugDescription=The connection from pid 505 on anonymousListener or serviceListener was invalidated: client is gone.} example of payload: "aps": { alert = { "loc-args" = ( msisdn ); "loc-key" = "key"; }; badge = 1; "content-available" = 1; "mutable-content" = 1; sound = "pnsound.aiff"; }, "m": CFG, "j": msisdn, "t": id, "n": M] This problem is face from time to time, I can't catch this problem on same build and same environment, also, this problem can occur for some time, and after that everything will be fine

Hello. I had some problems related to objectID, let me try to describe it. I had 3 managed object contexts: context A - root private context of persistentCoordiantor, used for write changes to persistentStore. retainsRegisteredObjects = false context B - main context, parent context - A. retainsRegisteredObjects = true context C - background private context. parent context - B. retainsRegisteredObjects = true When I add new MO to coreData, it saved succesfully to all contexts , but, when I check registeredObjects of context B and C, objectID for new MO is temporary, this is problem for me, because I had some work with coreData from NotificationServiceExtension, and I use fetch persistent history to get updates that was made in NSE and apply them to main app, but, in fetch history I get changes for MO that have permanentID, but in my context B and C there is still temporaryID. It was strange for me, so, I set retainsRegisteredObjects to context A, after that, I noticed, that after save new MO to coreData, permanentID is set only in context A for that MO, in contexts B and C MO still have temporaryID, does it correct behaviour of coreData or it's bug? I expect that when I save MO to coreData, it will automatically update ID as permanent for MO in all context for this MO if it exist in registeredObjects of certain context

Hello. I found a bit strange behaviour in app. My app using linphone library for in app calls, also, app have addressbook contacts sync flow ( to add contacts from addressbook to app DB ). I found strange behaviour: if I accept call and after that move app to background while contacts sync flow is processing on own queue with QoS less than default, after ~10 seconds app crashed and deattach from debug ( without any error ) also, firebase crashlytics doesn't catch this crash, but, If I process contact sync flow on queue that have QoS default or high, there is no any crash and all going well. Could please anyone explain this behavior?