Hide unwanted Logs printing - in Xcode 9 - ios

I already set OS_ACTIVITY_MODE to disable, but after migrating to Xcode 9 there was some unwanted logs printing like the below.
Edit: I already referred Hide strange unwanted Xcode logs, but doesn't work for me in Xcode 9.
=================================================================
Main Thread Checker: UI API called on a background thread: -[UIApplication registerForRemoteNotifications]
PID: 1303, TID: 27861, Thread name: (none), Queue name: com.apple.usernotifications.UNUserNotificationServiceConnection.call-out, QoS: 0
Backtrace:
4 N-Gal 0x000000010b058211 _T05N_Gal11AppDelegateC29registerForRemoteNotificationyyFySb_s5Error_pSgtcfU_ + 193
5 N-Gal 0x000000010b0574d3 _T0Sbs5Error_pSgIxyx_SbSo7NSErrorCSgIyByy_TR + 115
6 libdispatch.dylib 0x0000000111a4c3f7 _dispatch_call_block_and_release + 12
7 libdispatch.dylib 0x0000000111a4d43c _dispatch_client_callout + 8
8 libdispatch.dylib 0x0000000111a5595b _dispatch_queue_serial_drain + 1162
9 libdispatch.dylib 0x0000000111a562df _dispatch_queue_invoke + 336
10 libdispatch.dylib 0x0000000111a5207d _dispatch_queue_override_invoke + 733
11 libdispatch.dylib 0x0000000111a591f9 _dispatch_root_queue_drain + 772
12 libdispatch.dylib 0x0000000111a58e97 _dispatch_worker_thread3 + 132
13 libsystem_pthread.dylib 0x0000000111f141ca _pthread_wqthread + 1387
14 libsystem_pthread.dylib 0x0000000111f13c4d start_wqthread + 13
Couldn't register: Error Domain=NSCocoaErrorDomain Code=3010 "remote notifications are not supported in the simulator" UserInfo={NSLocalizedDescription=remote notifications are not supported in the simulator}
Couldn't register: Error Domain=NSCocoaErrorDomain Code=3010 "remote notifications are not supported in the simulator" UserInfo={NSLocalizedDescription=remote notifications are not supported in the simulator}
Couldn't register: Error Domain=NSCocoaErrorDomain Code=3010 "remote notifications are not supported in the simulator" UserInfo={NSLocalizedDescription=remote notifications are not supported in the simulator}
22
Can Anyone help me to hide these logs....? Thanks in advance!

It's not just a log. It's a warning. [UIApplication registerForRemoteNotifications] must be called on the main thread. You should move call of this method to didFinishLaunchingWithOptions of your AppDelegate.

It's not an unwanted log.
You need to call registerForRemoteNotifications() in main thread.
Replace code as below.
let center = UNUserNotificationCenter.current()
center.delegate = self
center.requestAuthorization(options: [.sound, .alert, .badge]) { (granted, error) in
if error == nil{
DispatchQueue.main.async {
UIApplication.shared.registerForRemoteNotifications()
}
}
}

Related

How can I diagnose and resolve a crash on WCSession sendMessage(_:replyHandler:errorHandler:)?

I'm building a watchOS app that needs to periodically request information from a companion iPhone app to refresh a complication.
To achieve this, I have a WKApplicationRefreshBackgroundTask that runs periodically. It uses sendMessage(_:replyHandler:errorHandler:) from WatchConnectivity to request the information from the iPhone app, process the reply, and update the complication.
This works reliably for many users most of the time, however, I’m seeing Apple Watch crashes in Xcode related to sendMessage(_:replyHandler:errorHandler:) and I worry this is leading to missed complication updates for users. Some users have been complaining about the complication not updating, so I'm trying to identify if there are issues outside of the regular limitations on how often a complication can refresh in watchOS.
Does anyone have any suggestions on how I can fix this issue? Or, do you have any suggestions for how I can better troubleshoot what's going wrong to cause the crash and figure out how to prevent it?
I've included a full example of one of the crashes at the bottom, along with the code that handles the background task and the code that handles sending and receiving values from the paired iPhone.
I’m never sending a message without a replyHandler, so while others have seen problems because the delegate method for a message without a handler was not implemented on iPhone, I don’t think that’s the issue here. To be safe I implemented the delegate method on iPhone as an empty method that does nothing.
UPDATE 30 January 2020: A friend suggested that maybe the issue is that the task is being marked complete by the 10 second timer while it's still in progress, causing a memory issue when something that's pending finishes, but wasn't sure what could be done about it. Maybe that's core to the issue here?
Here's my background refresh code from ExtensionDelegate:
func handle(_ backgroundTasks: Set<WKRefreshBackgroundTask>) {
for task in backgroundTasks {
switch task {
case let backgroundTask as WKApplicationRefreshBackgroundTask:
// set a timer in case it doesn't complete
// the maximum allowed is 15 seconds, and then it crashes, so schedule the new task and mark complete after 10
var timeoutTimer: Timer? = Timer.scheduledTimer(withTimeInterval: 10, repeats: false) { (timer) in
self.scheduleBackgroundRefresh()
backgroundTask.setTaskCompletedWithSnapshot(false)
}
// schedule the next refresh now in case the request crashes
scheduleBackgroundRefresh()
WatchConnectivityManager.shared.requestDataFromPhone()
ComplicationManager.shared.reloadComplication()
// as long as the expiration timer is valid, cancel the timer and set the task complete
// otherwise, we'll assume the timer has fired and the task has been marked complete already
// if it's marked complete again, that's a crash
if let timerValid = timeoutTimer?.isValid, timerValid == true {
timeoutTimer?.invalidate()
timeoutTimer = nil
backgroundTask.setTaskCompletedWithSnapshot(true)
}
default:
// make sure to complete unhandled task types
task.setTaskCompletedWithSnapshot(false)
}
}
}
private func scheduleBackgroundRefresh() {
let fiveMinutesFromNow: Date = Date(timeIntervalSinceNow: 5 * 60)
WKExtension.shared().scheduleBackgroundRefresh(withPreferredDate: fiveMinutesFromNow,
userInfo: nil) { (error) in
if let error = error {
fatalError("\(error)")
}
}
}
And here is WatchConnectivityManager:
import Foundation
import WatchKit
import WatchConnectivity
class WatchConnectivityManager: NSObject {
static let shared = WatchConnectivityManager()
let session = WCSession.default
private let receivedMessageQueue: OperationQueue = {
let queue = OperationQueue()
queue.maxConcurrentOperationCount = 1
return queue
}()
private func process(messageOrUserInfo: [String : Any]) {
receivedMessageQueue.addOperation {
if let recievedValue = messageOrUserInfo["ValueFromPhone"] as? Int {
DispatchQueue.main.async {
ViewModel.shared.valueFromPhone = recievedValue
}
}
}
}
func requestDataFromPhone() {
if session.activationState == .activated {
let message: [String : Any] = ["Request" : true]
let replyHandler: (([String : Any]) -> Void) = { reply in
self.process(messageOrUserInfo: reply)
}
let errorHandler: ((Error) -> Void) = { error in
}
if session.isReachable {
session.sendMessage(message,
replyHandler: replyHandler,
errorHandler: errorHandler)
}
// send a request to the iPhone as a UserInfo in case the message fails
session.transferUserInfo(message)
}
}
}
extension WatchConnectivityManager: WCSessionDelegate {
func session(_ session: WCSession,
activationDidCompleteWith activationState: WCSessionActivationState,
error: Error?) {
if activationState == .activated {
requestDataFromPhone()
}
}
func session(_ session: WCSession,
didReceiveUserInfo userInfo: [String : Any])
{
process(messageOrUserInfo: userInfo)
}
}
Example crash:
Hardware Model: Watch3,4
AppVariant: 1:Watch3,4:6
Code Type: ARM (Native)
Role: Non UI
Parent Process: launchd [1]
OS Version: Watch OS 6.1.1 (17S449)
Release Type: User
Baseband Version: n/a
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x00000004
VM Region Info: 0x4 is not in any region. Bytes before following region: 638972
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
__TEXT 0009c000-000ac000 [ 64K] r-x/r-x SM=COW ...x/App Name
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [377]
Triggered by Thread: 9
Thread 0 name:
Thread 0:
0 libsystem_kernel.dylib 0x4381f864 semaphore_wait_trap + 8
1 libdispatch.dylib 0x436dac26 _dispatch_sema4_wait + 12 (lock.c:139)
2 libdispatch.dylib 0x436db09a _dispatch_semaphore_wait_slow + 104 (semaphore.c:132)
3 FrontBoardServices 0x46de503e -[FBSSceneSnapshotRequestHandle performRequestForScene:] + 408 (FBSSceneSnapshotRequestHandle.m:67)
4 FrontBoardServices 0x46de96ac -[FBSSceneSnapshotAction snapshotRequest:performWithContext:] + 218 (FBSSceneSnapshotAction.m:168)
5 FrontBoardServices 0x46da4320 -[FBSSceneSnapshotRequest performSnapshotWithContext:] + 292 (FBSSceneSnapshotRequest.m:65)
6 UIKitCore 0x5ba6a000 __65-[UIApplication _performSnapshotsWithAction:forScene:completion:]_block_invoke_3 + 168 (UIApplication.m:7655)
7 FrontBoardServices 0x46de9568 -[FBSSceneSnapshotAction _executeNextRequest] + 244 (FBSSceneSnapshotAction.m:135)
8 FrontBoardServices 0x46de91e0 -[FBSSceneSnapshotAction executeRequestsWithHandler:completionHandler:expirationHandler:] + 244 (FBSSceneSnapshotAction.m:87)
9 UIKitCore 0x5ba69f20 __65-[UIApplication _performSnapshotsWithAction:forScene:completion:]_block_invoke_2 + 238 (UIApplication.m:7650)
10 UIKitCore 0x5ba69696 -[UIApplication _beginSnapshotSessionForScene:withSnapshotBlock:] + 772 (UIApplication.m:7582)
11 UIKitCore 0x5ba69e16 __65-[UIApplication _performSnapshotsWithAction:forScene:completion:]_block_invoke + 112 (UIApplication.m:7648)
12 UIKitCore 0x5b2c1110 -[UIScene _enableOverrideSettingsForActions:] + 40 (UIScene.m:1206)
13 UIKitCore 0x5b2c1330 -[UIScene _performSystemSnapshotWithActions:] + 112 (UIScene.m:1230)
14 UIKitCore 0x5ba69b90 -[UIApplication _performSnapshotsWithAction:forScene:completion:] + 382 (UIApplication.m:7647)
15 UIKitCore 0x5be89586 __98-[_UISceneSnapshotBSActionsHandler _respondToActions:forFBSScene:inUIScene:fromTransitionCont... + 146 (_UISceneSnapshotBSActionsHandler.m:54)
16 UIKitCore 0x5ba68fd4 _runAfterCACommitDeferredBlocks + 274 (UIApplication.m:3038)
17 UIKitCore 0x5ba5b3da _cleanUpAfterCAFlushAndRunDeferredBlocks + 198 (UIApplication.m:3016)
18 UIKitCore 0x5ba82702 _afterCACommitHandler + 56 (UIApplication.m:3068)
19 CoreFoundation 0x43b63644 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 18 (CFRunLoop.c:1758)
20 CoreFoundation 0x43b5f43c __CFRunLoopDoObservers + 350 (CFRunLoop.c:1868)
21 CoreFoundation 0x43b5f956 __CFRunLoopRun + 1150 (CFRunLoop.c:2910)
22 CoreFoundation 0x43b5f23a CFRunLoopRunSpecific + 370 (CFRunLoop.c:3192)
23 GraphicsServices 0x46973cd0 GSEventRunModal + 96 (GSEvent.c:2246)
24 UIKitCore 0x5ba61580 UIApplicationMain + 1730 (UIApplication.m:4773)
25 libxpc.dylib 0x438fbcf0 _xpc_objc_main.cold.3 + 152
26 libxpc.dylib 0x438eca34 _xpc_objc_main + 184 (main.m:126)
27 libxpc.dylib 0x438ee934 xpc_main + 110 (init.c:1568)
28 Foundation 0x443f3156 -[NSXPCListener resume] + 172 (NSXPCListener.m:276)
29 PlugInKit 0x4b58b26c -[PKService run] + 384 (PKService.m:165)
30 WatchKit 0x52e9dafe WKExtensionMain + 62 (main.m:19)
31 libdyld.dylib 0x43715e82 start + 2
Thread 1 name:
Thread 1:
0 libsystem_kernel.dylib 0x4381f814 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x4381eece mach_msg + 42 (mach_msg.c:103)
2 CoreFoundation 0x43b63946 __CFRunLoopServiceMachPort + 152 (CFRunLoop.c:2575)
3 CoreFoundation 0x43b5f9de __CFRunLoopRun + 1286 (CFRunLoop.c:2931)
4 CoreFoundation 0x43b5f23a CFRunLoopRunSpecific + 370 (CFRunLoop.c:3192)
5 Foundation 0x443bf398 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 180 (NSRunLoop.m:374)
6 Foundation 0x443bf2b4 -[NSRunLoop(NSRunLoop) runUntilDate:] + 76 (NSRunLoop.m:421)
7 UIKitCore 0x5badf012 -[UIEventFetcher threadMain] + 140 (UIEventFetcher.m:637)
8 Foundation 0x444c1b60 __NSThread__start__ + 708 (NSThread.m:724)
9 libsystem_pthread.dylib 0x438ad1ac _pthread_start + 130 (pthread.c:896)
10 libsystem_pthread.dylib 0x438b3f28 thread_start + 20
Thread 2 name:
Thread 2:
0 libsystem_kernel.dylib 0x43836d04 __psynch_cvwait + 24
1 libsystem_pthread.dylib 0x438b02c2 _pthread_cond_wait + 496 (pthread_cond.c:591)
2 libsystem_pthread.dylib 0x438aca4a pthread_cond_wait + 38 (pthread_cancelable.c:558)
3 Foundation 0x444381f0 -[NSOperation waitUntilFinished] + 446 (NSOperation.m:737)
4 Foundation 0x444a5302 __NSOPERATIONQUEUE_IS_WAITING_ON_AN_OPERATION__ + 22 (NSOperation.m:2610)
5 Foundation 0x444222ee -[NSOperationQueue addOperations:waitUntilFinished:] + 128 (NSOperation.m:2618)
6 WatchConnectivity 0x53f9871e __47-[WCSession handleUserInfoResultWithPairingID:]_block_invoke.491 + 540 (WCSession.m:1440)
7 WatchConnectivity 0x53fa5608 -[WCFileStorage enumerateUserInfoResultsWithBlock:] + 1564 (WCFileStorage.m:505)
8 WatchConnectivity 0x53f984ca __47-[WCSession handleUserInfoResultWithPairingID:]_block_invoke_2 + 284 (WCSession.m:1430)
9 Foundation 0x444a4794 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 10 (NSOperation.m:1541)
10 Foundation 0x443d2f7a -[NSBlockOperation main] + 74 (NSOperation.m:1560)
11 Foundation 0x444a63e2 __NSOPERATION_IS_INVOKING_MAIN__ + 22 (NSOperation.m:2184)
12 Foundation 0x443d2b96 -[NSOperation start] + 578 (NSOperation.m:2201)
13 Foundation 0x444a6b7c __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 22 (NSOperation.m:2215)
14 Foundation 0x444a6798 __NSOQSchedule_f + 134 (NSOperation.m:2226)
15 libdispatch.dylib 0x436d9846 _dispatch_call_block_and_release + 10 (init.c:1408)
16 libdispatch.dylib 0x436da8b8 _dispatch_client_callout + 6 (object.m:495)
17 libdispatch.dylib 0x436dc6f8 _dispatch_continuation_pop + 330 (inline_internal.h:2484)
18 libdispatch.dylib 0x436dc08c _dispatch_async_redirect_invoke + 520 (queue.c:803)
19 libdispatch.dylib 0x436e6eac _dispatch_root_queue_drain + 540 (inline_internal.h:2525)
20 libdispatch.dylib 0x436e73e0 _dispatch_worker_thread2 + 98 (queue.c:6628)
21 libsystem_pthread.dylib 0x438aecd2 _pthread_wqthread + 158 (pthread.c:2364)
22 libsystem_pthread.dylib 0x438b3f10 start_wqthread + 20
Thread 3:
0 libsystem_pthread.dylib 0x438b3efc start_wqthread + 0
Thread 4:
0 libsystem_pthread.dylib 0x438b3efc start_wqthread + 0
Thread 5:
0 libsystem_pthread.dylib 0x438b3efc start_wqthread + 0
Thread 6 name:
Thread 6:
0 libsystem_kernel.dylib 0x43838c6c kevent_qos + 24
1 libdispatch.dylib 0x436f2b74 _dispatch_kq_poll + 204 (event_kevent.c:736)
2 libdispatch.dylib 0x436f280a _dispatch_kq_drain + 96 (event_kevent.c:809)
3 libdispatch.dylib 0x436f2196 _dispatch_event_loop_poke + 162 (event_kevent.c:1918)
4 libdispatch.dylib 0x436e32b8 _dispatch_mgr_queue_push + 110 (queue.c:5857)
5 WatchConnectivity 0x53f9aa26 -[WCSession createAndStartTimerOnWorkQueueWithHandler:] + 150 (WCSession.m:1803)
6 WatchConnectivity 0x53f90790 -[WCSession onqueue_sendMessageData:replyHandler:errorHandler:dictionaryMessage:] + 382 (WCSession.m:674)
7 WatchConnectivity 0x53f901da __51-[WCSession sendMessage:replyHandler:errorHandler:]_block_invoke.256 + 190 (WCSession.m:630)
8 Foundation 0x444a4794 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 10 (NSOperation.m:1541)
9 Foundation 0x443d2f7a -[NSBlockOperation main] + 74 (NSOperation.m:1560)
10 Foundation 0x444a63e2 __NSOPERATION_IS_INVOKING_MAIN__ + 22 (NSOperation.m:2184)
11 Foundation 0x443d2b96 -[NSOperation start] + 578 (NSOperation.m:2201)
12 Foundation 0x444a6b7c __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 22 (NSOperation.m:2215)
13 Foundation 0x444a6798 __NSOQSchedule_f + 134 (NSOperation.m:2226)
14 libdispatch.dylib 0x436e4c02 _dispatch_block_async_invoke2 + 80 (queue.c:525)
15 libdispatch.dylib 0x436da8b8 _dispatch_client_callout + 6 (object.m:495)
16 libdispatch.dylib 0x436dc6f8 _dispatch_continuation_pop + 330 (inline_internal.h:2484)
17 libdispatch.dylib 0x436dc08c _dispatch_async_redirect_invoke + 520 (queue.c:803)
18 libdispatch.dylib 0x436e6eac _dispatch_root_queue_drain + 540 (inline_internal.h:2525)
19 libdispatch.dylib 0x436e73e0 _dispatch_worker_thread2 + 98 (queue.c:6628)
20 libsystem_pthread.dylib 0x438aecd2 _pthread_wqthread + 158 (pthread.c:2364)
21 libsystem_pthread.dylib 0x438b3f10 start_wqthread + 20
Thread 7:
0 libsystem_pthread.dylib 0x438b3efc start_wqthread + 0
Thread 8:
0 libsystem_pthread.dylib 0x438b3efc start_wqthread + 0
Thread 9 name:
Thread 9 Crashed:
0 libdispatch.dylib 0x436eacec dispatch_channel_cancel + 6 (source.c:1020)
1 WatchConnectivity 0x53f909c6 __81-[WCSession onqueue_sendMessageData:replyHandler:errorHandler:dictionaryMessage:]_block_invoke + 42 (WCSession.m:675)
2 libdispatch.dylib 0x436da8b8 _dispatch_client_callout + 6 (object.m:495)
3 libdispatch.dylib 0x436dc6f8 _dispatch_continuation_pop + 330 (inline_internal.h:2484)
4 libdispatch.dylib 0x436ea81e _dispatch_source_invoke + 1758 (source.c:568)
5 libdispatch.dylib 0x436e6eac _dispatch_root_queue_drain + 540 (inline_internal.h:2525)
6 libdispatch.dylib 0x436e73e0 _dispatch_worker_thread2 + 98 (queue.c:6628)
7 libsystem_pthread.dylib 0x438aecd2 _pthread_wqthread + 158 (pthread.c:2364)
8 libsystem_pthread.dylib 0x438b3f10 start_wqthread + 20
Thread 10:
0 libsystem_pthread.dylib 0x438b3efc start_wqthread + 0
Thread 11:
0 libsystem_pthread.dylib 0x438b3efc start_wqthread + 0
Thread 9 crashed with ARM Thread State (32-bit):
r0: 0x00000000 r1: 0x80000000 r2: 0x00000001 r3: 0x7fffffff
r4: 0x16548f40 r5: 0x00000000 r6: 0x00000110 r7: 0x3f057e58
r8: 0x00000000 r9: 0x00000000 r10: 0x00000000 r11: 0x00401600
ip: 0x66e39628 sp: 0x3f057e30 lr: 0x53f909c7 pc: 0x436eacec
cpsr: 0x80000030
I assume your friend is right:
When you set your background task as complete, the system will suspend your app, see here.
And the system can purge suspended apps without warning, see here.
So if this happens, replyHandler or errorHandler cannot be called, and the app crashes.
You can therefore not rely on sendMessage to wake up the iOS app and to call replyHandler in time.
I suggest that you initialize the transfer of complication data on iOS. To do so regularly, you could use silent push notifications that wake up your iOS app, and send new complication data using transferCurrentComplicationUserInfo(_:)see here. This userInfo is received even if your watch app is not running, and the complication data can be updated as required.
EDIT:
While my solution above might work, there might be a much simpler solution:
Maybe it is not required to update your ViewModel in respond to sendMessage, only the complications. If so, you could simply use sendMessage with replyHandler and errorHandler set to nil.
sendMessage is guaranteed to wake up the iOS app in the future, even when the watchOS app is already inactive. The iOS app could then send complication data, and these would be displayed immediately.
Additionally, the iOS app could send the userInfo that updates your ViewModel as application context. It would then be available when the watchOS app becomes active again, and you can update the ViewModel.
If this fits to your use case, you could simply remove the timer and complete the background task immediately after sendMessage.

Xcode 10 Main Thread Checker: Cordova Camera Plugin

Following iOS13 release, I'm testing a hybrid app using Cordova. Launching the camera is very slow and generates the following:
=================================================================
Main Thread Checker: UI API called on a background thread: -[UIImagePickerController init]
PID: 1347, TID: 618928, Thread name: (none), Queue name: com.apple.root.default-qos, QoS: 0
Backtrace:
4 0x0000000100f1bba0 +[CDVCameraPicker createFromPictureOptions:] + 124
5 0x0000000100f15d54 -[CDVCamera showCameraPicker:withOptions:] + 108
6 0x0000000100f15570 __25-[CDVCamera takePicture:]_block_invoke_2 + 336
7 AVFoundation 0x00000001b76178f8 2BC0C357-314E-3AE8-B006-C28528B87512 + 710904
8 TCC 0x00000001b35dfbf8 85A762AF-99DB-3B4C-B24B-09600CC17196 + 7160
9 TCC 0x00000001b35e3de4 85A762AF-99DB-3B4C-B24B-09600CC17196 + 24036
10 libxpc.dylib 0x00000001acfe3804 79A1F1AD-9CB4-3334-91D9-E1ED6B1032A3 + 104452
11 libxpc.dylib 0x00000001acfd72c4 79A1F1AD-9CB4-3334-91D9-E1ED6B1032A3 + 53956
12 libdispatch.dylib 0x000000010109b3b4 _dispatch_client_callout3 + 20
13 libdispatch.dylib 0x00000001010b7000 _dispatch_mach_msg_async_reply_invoke + 392
14 libdispatch.dylib 0x00000001010ada8c _dispatch_kevent_worker_thread + 1436
15 libsystem_pthread.dylib 0x00000001ad0e6adc _pthread_wqthread + 336
16 libsystem_pthread.dylib 0x00000001ad0ecc7c start_wqthread + 8
Xcode 10.3
cordova-plugin-camera version 4.1.0
running on iPhone X, iOS13
Eventually the camera opens and allows me to take a photo but the UI is not displayed correctly afterwards. I've tried creating a brand new app with only the camera plugin added and the same thing happens.
How this can be resolved?
It would seem that UIImagePickerController needs to be called in the UI Thread.
Fortunately, the code is already ready for that change!
Just move the cameraPicker init section into the main thread section:
dispatch_async(dispatch_get_main_queue(), ^{
// UI MainThread execution
CDVCameraPicker* cameraPicker = [CDVCameraPicker createFromPictureOptions:pictureOptions];
weakSelf.pickerController = cameraPicker;
cameraPicker.delegate = weakSelf;
cameraPicker.callbackId = command.callbackId;
// we need to capture this state for memory warnings that dealloc this object
cameraPicker.webView = weakSelf.webView;
...
}
D.

Xcode build running on device but failing on simultor

I'm using CocoaPods with a React Native app. I've had various errors when running builds in the Xcode simulator. I don't have issues running it on my device. Here's one that I get when I have breakpoints enabled:
- (void)ensureOnJavaScriptThread:(dispatch_block_t)block
{
RCTAssert(_jsThread, #"This method must not be called before the JS thread is created");
The error here is green (yet breaking, thanks Xcode) and it says com.facebook.react.JavaScript (9): breakpoint 1.2
I get two errors when I disable breakpoints, this is one:
void Instance::loadApplication(std::unique_ptr<RAMBundleRegistry> bundleRegistry,
std::unique_ptr<const JSBigString> string,
std::string sourceURL) {
callback_->incrementPendingJSCalls();
SystraceSection s("Instance::loadApplication", "sourceURL",
sourceURL);
nativeToJsBridge_->loadApplication(std::move(bundleRegistry), std::move(string),
std::move(sourceURL));
}
with the red error on the callback_-> line reading EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
the second is this a signal SIGABRT error from this code:
int main(int argc, char * argv[]) {
#autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
I think i've fixed that issue before by enabling zombies. When I do that, I see this in the console:
2018-07-11 16:56:08.326 [info][tid:main][RCTRootView.m:293] Running application Mapp ({
initialProps = {
};
rootTag = 11;
})
=================================================================
Main Thread Checker: UI API called on a background thread: -[UIApplication setNetworkActivityIndicatorVisible:]
PID: 34682, TID: 5546845, Thread name: (none), Queue name: com.mixpanel.20e6d2c2b6c431dfecfdfaa100ec0a11.0x7fa94db06940.network, QoS: 0
Backtrace:
4 Mapp 0x0000000103a31dd9 -[MPNetwork updateNetworkActivityIndicator:] + 121
5 Mapp 0x0000000103a2ec09 -[MPNetwork flushQueue:endpoint:] + 985
6 Mapp 0x0000000103a2e7b0 -[MPNetwork flushEventQueue:] + 64
7 Mapp 0x0000000103a10418 __32-[Mixpanel flushWithCompletion:]_block_invoke + 312
8 libdispatch.dylib 0x000000010e3f47ab _dispatch_call_block_and_release + 12
9 libdispatch.dylib 0x000000010e3f57ec _dispatch_client_callout + 8
10 libdispatch.dylib 0x000000010e3fdbe5 _dispatch_queue_serial_drain + 1305
11 libdispatch.dylib 0x000000010e3fe4fa _dispatch_queue_invoke + 328
12 libdispatch.dylib 0x000000010e3fa344 _dispatch_queue_override_invoke + 726
13 libdispatch.dylib 0x000000010e40136c _dispatch_root_queue_drain + 664
14 libdispatch.dylib 0x000000010e401076 _dispatch_worker_thread3 + 132
15 libsystem_pthread.dylib 0x000000010e920169 _pthread_wqthread + 1387
16 libsystem_pthread.dylib 0x000000010e91fbe9 start_wqthread + 13
This to me is unreadable. I don't understand what's wrong. Reminder: this build runs without breaking errors on my device, even when breakpoints are enabled. Is this something I should worry about? Please help!
Because in your code UI API called on a background thread. So please disable the Main Thread Checker of xcode. it will work.
Edit Scheme --- > Diagonstics --- > Runtime API Checking ---> Main
Thread Checker (un-check this setting)
Note: Always update the UI inside below method on a background thread
Or
Put your [UIApplication setNetworkActivityIndicatorVisible:] Method inside DispatchQueue.main.async
DispatchQueue.main.async { // Correct
UIApplication.shared.isNetworkActivityIndicatorVisible = true // in swift 4
[UIApplication setNetworkActivityIndicatorVisible:]// in objective-C
}
https://developer.apple.com/documentation/code_diagnostics/main_thread_checker

Xcode 9.0 Swift 04 (Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Only run on the main thread!')

Main Thread Checker: UI API called on a background thread: -[UIView init]
PID: 460, TID: 62011, Thread name: (none), Queue name: com.apple.root.background-qos, QoS: 9
Backtrace:
4 IQKeyboardManagerSwift 0x00000001025c8274 _T0So11UITextFieldCABycfcTO + 28
5 IQKeyboardManagerSwift 0x00000001025a8360 _T0So11UITextFieldCABycfC + 68
6 IQKeyboardManagerSwift 0x00000001025a7e90 _T022IQKeyboardManagerSwift0aB0CACycfc + 5196
7 IQKeyboardManagerSwift 0x00000001025a838c _T022IQKeyboardManagerSwift0aB0CACycfcTo + 28
8 IQKeyboardManagerSwift 0x00000001025a6a3c _T022IQKeyboardManagerSwift0aB0CACycfC + 32
9 IQKeyboardManagerSwift 0x00000001025c5920 globalinit_33_1804EA4A44CDC62F5B66EAD58B4692DC_func2 + 24
10 libdispatch.dylib 0x00000001043e545c _dispatch_client_callout + 16
11 libdispatch.dylib 0x00000001043e617c dispatch_once_f + 120
12 IQKeyboardManagerSwift 0x000000010259c4cc _T022IQKeyboardManagerSwift0aB0C06sharedB0ACyFZ6StaticL_V02kbB0ACfau + 56
13 IQKeyboardManagerSwift 0x000000010259c46c _T022IQKeyboardManagerSwift0aB0C06sharedB0ACyFZ + 24
14 eBeePartners 0x0000000100c9ef7c _T012eBeePartners11AppDelegateC11applicationSbSo13UIApplicationC_s10DictionaryVySC0F16LaunchOptionsKeyVypGSg022didFinishLaunchingWithI0tFyycfU_ + 52
15 eBeePartners 0x0000000100bd18c0 _T0Ix_IyB_TR + 48
16 libdispatch.dylib 0x00000001043e549c _dispatch_call_block_and_release + 24
17 libdispatch.dylib 0x00000001043e545c _dispatch_client_callout + 16
18 libdispatch.dylib 0x00000001043f6cd8 _dispatch_root_queue_drain + 1004
19 libdispatch.dylib 0x00000001043f6880 _dispatch_worker_thread3 + 136
20 libsystem_pthread.dylib 0x0000000181dab130 _pthread_wqthread + 1268
21 libsystem_pthread.dylib 0x0000000181daac30 start_wqthread + 4
2017-09-22 12:36:11.268059+0800 eBeePartners[460:62011] [reports] Main Thread Checker: UI API called on a background thread: -[UIView init]
PID: 460, TID: 62011, Thread name: (none), Queue name: com.apple.root.background-qos, QoS: 9
Backtrace:
4 IQKeyboardManagerSwift 0x00000001025c8274 _T0So11UITextFieldCABycfcTO + 28
5 IQKeyboardManagerSwift 0x00000001025a8360 _T0So11UITextFieldCABycfC + 68
6 IQKeyboardManagerSwift 0x00000001025a7e90 _T022IQKeyboardManagerSwift0aB0CACycfc + 5196
7 IQKeyboardManagerSwift 0x00000001025a838c _T022IQKeyboardManagerSwift0aB0CACycfcTo + 28
8 IQKeyboardManagerSwift 0x00000001025a6a3c _T022IQKeyboardManagerSwift0aB0CACycfC + 32
9 IQKeyboardManagerSwift 0x00000001025c5920 globalinit_33_1804EA4A44CDC62F5B66EAD58B4692DC_func2 + 24
10 libdispatch.dylib 0x00000001043e545c _dispatch_client_callout + 16
11 libdispatch.dylib 0x00000001043e617c dispatch_once_f + 120
12 IQKeyboardManagerSwift 0x000000010259c4cc _T022IQKeyboardManagerSwift0aB0C06sharedB0ACyFZ6StaticL_V02kbB0ACfau + 56
13 IQKeyboardManagerSwift 0x000000010259c46c _T022IQKeyboardManagerSwift0aB0C06sharedB0ACyFZ + 24
14 eBeePartners 0x0000000100c9ef7c _T012eBeePartners11AppDelegateC11applicationSbSo13UIApplicationC_s10DictionaryVySC0F16LaunchOptionsKeyVypGSg022didFinishLaunchingWithI0tFyycfU_ + 52
15 eBeePartners 0x0000000100bd18c0 _T0Ix_IyB_TR + 48
16 libdispatch.dylib 0x00000001043e549c _dispatch_call_block_and_release + 24
17 libdispatch.dylib 0x00000001043e545c _dispatch_client_callout + 16
18 libdispatch.dylib 0x00000001043f6cd8 _dispatch_root_queue_drain + 1004
19 libdispatch.dylib 0x00000001043f6880 _dispatch_worker_thread3 + 136
20 libsystem_pthread.dylib 0x0000000181dab130 _pthread_wqthread + 1268
21 libsystem_pthread.dylib 0x0000000181daac30 start_wqthread + 4
2017-09-22 12:36:22.758673+0800 eBeePartners[460:61967] [BoringSSL] Function nw_protocol_boringssl_input_finished: line 1389 Peer disconnected during the middle of a handshake. Sending errSSLFatalAlert(-9802) alert
2017-09-22 12:36:22.813732+0800 eBeePartners[460:61967] TIC TCP Conn Failed [2:0x1c0166900]: 3:-9802 Err(-9802)
2017-09-22 12:36:22.848609+0800 eBeePartners[460:61719] [MC] Lazy loading NSBundle MobileCoreServices.framework
2017-09-22 12:36:22.854700+0800 eBeePartners[460:61719] [MC] Loaded MobileCoreServices.framework
2017-09-22 12:36:22.864960+0800 eBeePartners[460:61719] [MC] System group container for systemgroup.com.apple.configurationprofiles path is /private/var/containers/Shared/SystemGroup/systemgroup.com.apple.configurationprofiles
2017-09-22 12:36:22.898137+0800 eBeePartners[460:62011] *** Assertion failure in void _UIPerformResizeOfTextViewForTextContainer(NSLayoutManager *, UIView<NSTextContainerView> *, NSTextContainer *, NSUInteger)(), /BuildRoot/Library/Caches/com.apple.xbs/Sources/UIFoundation/UIFoundation-543/UIFoundation/TextSystem/NSLayoutManager_Private.m:1619
2017-09-22 12:36:23.117424+0800 eBeePartners[460:62011] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Only run on the main thread!'
*** First throw call stack:
(0x18217fd38 0x181694528 0x18217fc0c 0x182b0ec90 0x18c65a70c 0x18c65a194 0x18c689e4c 0x18c689b08 0x18c6b3f88 0x18b8ebf28 0x18b5b1218 0x18c1e697c 0x18b6613ec 0x1025c8274 0x1025a8360 0x1025a7e90 0x1025a838c 0x1025a6a3c 0x1025c5920 0x1043e545c 0x1043e617c 0x10259c4cc 0x10259c46c 0x100c9ef7c 0x100bd18c0 0x1043e549c 0x1043e545c 0x1043f6cd8 0x1043f6880 0x181dab130 0x181daac30)
libc++abi.dylib: terminating with uncaught exception of type NSException
(lldb)
How to debug this code?
I also had this error ONLY AFTER upgrading to Xcode9/Swift4. As mentioned in comments, the reason is calling ui-operations in background thread. I don't know why it has been working until upgrading.
How to debug
You are seeing this error on Xcode which process frozen by debugger, right? Then, the left side panel (called "debug navigator") is showing call stack and indicating the line where the app crashed. You can click one of them and get the code.
In my case
The cause of error is performSegue attempted to run on the main thread in my case.
func downloadHandler() {
DispatchQueue.global(qos: .default).async(execute: {
DispatchQueue.main.async(execute: {
self.labelMessage.text = "Unzipping downloaded data..."
})
/* Unzipping something... */
// WRONG: This causes error
// self.performSegue(withIdentifier: "toViewController", sender: nil)
// FIXED: performSegue should be run on main thread.
DispatchQueue.main.async(execute: {
self.performSegue(withIdentifier: "toViewController", sender: nil)
})
})
}
Double check your DispatchQueue. It would be better to start at where debugger stopped.

Firebase App configuration crash

I have a custom keyboard for iOS that uses Firebase for analytics. The Firebase app configuration is done at the initializer with a dispatch_once clause with the token as a global variable.
var token: dispatch_once_t = 0
class KeyboardViewController: UIInputViewController {
// ..
override init(nibName nibNameOrNil: String?, bundle nibBundleOrNil: NSBundle?) {
super.init(nibName: nibNameOrNil, bundle: nibBundleOrNil)
dispatch_once(&token) {
FIRApp.configure()
} // line 90
}
// ..
}
This is working fine but I am receiving many crash reports that indicate crashes on many devices when the app is configured. I am stuck for days trying to figure out the cause. Here is a part of one of the crash reports stack trace:
Exception Type: EXC_CRASH (SIGQUIT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Quit: 3
Termination Reason: Namespace SIGNAL, Code 0x3
Terminating Process: launchd [1]
Triggered by Thread: 0
Thread 0 name:
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x000000018fab6338 __semwait_signal_nocancel + 8
1 libsystem_c.dylib 0x000000018f9e20dc nanosleep$NOCANCEL + 200 (nanosleep.c:104)
2 libsystem_c.dylib 0x000000018fa0568c sleep$NOCANCEL + 44 (sleep.c:62)
3 libsystem_dnssd.dylib 0x000000018fa6e7d4 ConnectToServer + 832 (dnssd_clientstub.c:607)
4 libsystem_dnssd.dylib 0x000000018fa6ff44 DNSServiceCreateConnection + 76 (dnssd_clientstub.c:1785)
5 libsystem_network.dylib 0x000000018fb2d318 __nw_resolver_set_update_handler_block_invoke + 872 (resolver.m:1031)
6 libdispatch.dylib 0x000000018f9711c0 _dispatch_client_callout + 16 (object.m:455)
7 libdispatch.dylib 0x000000018f97e860 _dispatch_barrier_sync_f_invoke + 84 (queue.c:3457)
8 libsystem_network.dylib 0x000000018fb2ce78 nw_resolver_set_update_handler + 208 (resolver.m:1275)
9 SystemConfiguration 0x0000000190f8a16c __SCNetworkReachabilityRestartResolver + 260 (SCNetworkReachability.c:1711)
10 SystemConfiguration 0x0000000190f891c8 __SCNetworkReachabilitySetDispatchQueue + 764 (SCNetworkReachability.c:1823)
11 SystemConfiguration 0x0000000190f88ccc SCNetworkReachabilityScheduleWithRunLoop + 504 (SCNetworkReachability.c:1586)
12 CustomKeyboard 0x000000010013f630 -[FIRReachabilityChecker start] + 196
13 CustomKeyboard 0x000000010013abac -[FIRNetwork init] + 156
14 CustomKeyboard 0x0000000100132e28 -[FIRClearcutLogger init] + 416
15 CustomKeyboard 0x0000000100132c68 __35+[FIRClearcutLogger sharedInstance]_block_invoke + 36
16 libdispatch.dylib 0x000000018f9711c0 _dispatch_client_callout + 16 (object.m:455)
17 libdispatch.dylib 0x000000018f971fb4 dispatch_once_f + 56 (once.c:57)
18 CustomKeyboard 0x0000000100132c40 +[FIRClearcutLogger sharedInstance] + 108
19 CustomKeyboard 0x0000000100137214 +[FIRApp initClearcut] + 60
20 CustomKeyboard 0x0000000100136688 +[FIRApp configureDefaultAppWithOptions:sendingNotifications:] + 132
21 CustomKeyboard 0x000000010013643c +[FIRApp configure] + 316
22 libdispatch.dylib 0x000000018f9711c0 _dispatch_client_callout + 16 (object.m:455)
23 libdispatch.dylib 0x000000018f971fb4 dispatch_once_f + 56 (once.c:57)
24 CustomKeyboard 0x00000001000e314c _TFC19CustomKeyboard22KeyboardViewControllercfT7nibNameGSqSS_6bundleGSqCSo8NSBundle__S0_ + 1500 (KeyboardViewController.swift:90)
25 CustomKeyboard 0x00000001000e3270 _TToFC19CustomKeyboard22KeyboardViewControllercfT7nibNameGSqSS_6bundleGSqCSo8NSBundle__S0_ + 112 (KeyboardViewController.swift:0)
26 UIKit 0x00000001971f7688 -[_UIViewServiceViewControllerOperator __createViewController:withContextToken:fbsDisplays:appearanceSerializedRepresentations:legacyAppearance:traitCollection:initialInterfaceOrientation:hostAccessibilityServerPort:canShowTextServices:replyHandler:] + 2216 (UIViewServiceViewControllerOperator.m:1732)
27 CoreFoundation 0x0000000190aee160 __invoking___ + 144
28 CoreFoundation 0x00000001909e1c3c -[NSInvocation invoke] + 284 (NSForwarding.m:2948)
29 CoreFoundation 0x00000001909e66ec -[NSInvocation invokeWithTarget:] + 60 (NSForwarding.m:3019)
Apparently, the call trace after calling FIRApp.configure() is going through system libraries.
One observation from the stack trace is that the crash has something to do with checking the reachability of the device. However, I tried to reproduce a scenario where there is no internet connection but it's working fine.
Please note that all the crashes are happening on iOS 10 and most of them on iPhone 6.
Any help to figure out the cause of the crashes would be appreciated.
It is not recommended to use Firebase Analytics in an extension as the SDK does not support extension well. App extensions have limited functionalities compared to a full app so Firebase Analytics may not work well under some conditions, like the network in this case. The team is looking into supporting extensions better later.
It seems like the network is not available on custom keyboard as stated by Apple
"By default, a keyboard has no network access and cannot share a
container with its containing app. To enable these things, set the
value of the RequestsOpenAccess Boolean key in the Info.plist file to
YES. Doing this expands the keyboard’s sandbox, as described in
Designing for User Trust."
https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/CustomKeyboard.html#//apple_ref/doc/uid/TP40014214-CH16-SW1

Resources