Trying to run a React Native app via Xcode can be very very very slow. Excruciatingly so. I often see messages saying things like Launching app is taking longer than expected. LLDB is likely reading from device memory to resolve symbols. But I see this all the time, if that's what it's doing it never finishes, and does it every time. This isn't just with one phone, its with several. Is it possible there some fundamental conflict between Xcode and LLDB and React Native Metro trying to communicate / load / debug / whatever that slows things down to a standstill?

An app is hanging randomly on app launch, after looking into it, it appears it's hanging on a call to UNUserNotificationCenter.current() calls. I say this because there's logging and the sometimes the last line logged is prior to a call to UNUserNotificationCenter() I have a hang log (.ips file) rom the iPhone and at the bottom it says this. I presume blockingThreadInfo is talking about the thread being blocked, and it identifies the topBlockingProcess as user notifications. "blockingThreadInfo" : { "topBlockingProcess" : "usernotificationsd", The following is the code, why would this code cause a hang? The problem occurs when there's lots of notifications that have been posted i.e. something like 100. [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(appBecameActive) name: UIApplicationDidBecomeActiveNotification object:nil]; @objc func appBecameActive() { method1() method2() } @objc func method1() { UNUserNotificationCenter.current().getDeliveredNotifications { notifications in if SettingsManager.isProductionFinalBuild() == false { // Log notification center contents for notification in notifications { let title = notification.request.content.title let targetId = notification.request.content.targetContentIdentifier let threadId = notification.request.content.threadIdentifier let categoryIdentifer = notification.request.content.categoryIdentifier let identifier = notification.request.identifier let info = notification.request.content.userInfo Logger.trace("Previously delivered notification: title: \(title) identifier: \(identifier) threadId: \(threadId) category: \(categoryIdentifer) target id: \(String(describing: targetId)) userInfo: \(info)") } let matchchingNotifications = notifications.filter({ $0.request.identifier == kMdnAccountNotFoundNotificationIdentifier }) UNUserNotificationCenter.current().removeDeliveredNotifications(withIdentifiers: [kMdnAccountNotFoundNotificationIdentifier]) } } func method2() { UNUserNotificationCenter.current().removePendingNotificationRequests(withIdentifiers: [Constants.kWhatsNewNotificationIdentifier]) UNUserNotificationCenter.current().removeDeliveredNotifications(withIdentifiers: [Constants.kWhatsNewNotificationIdentifier]) }

I'm trying to debug an elusive random probably timing related issue. However I don't know if I can trust the logging output from the console, I keep seeing "Shutting down live logging" in the console output. What does this mean, why is it happening, if its affecting the logging from the app, then how can I stop it from happening?

My app has occasionally randomly started hanging. I have extensive logging in it, so you'd think it'd be easy to find out where its hanging (look at the last line logged etc.) However its hanging at different places each time it runs, so its impossible to debug. I've got several .ips files from off the handset, and they're all different. But a few of them have the same pattern at the top which is: 0 __unlock_wait2 NSLog If I open some in Xcode, it doesn't display any useful info or jump to a line of my code, it shows "deferred_logger". What do these mean? The common theme of mentioning logging can't be a co-incidence? Is there something wrong with the logging, is it being overloaded or something? If I turn off verbose logging to reduce the amount, the issues still persist, implying its not an overloaded logging situation. What could be going on?

I have a hang log, too large to copy past all of it here. It showing [NSNotificationCenter postNotificationName:object:userInfo:] in the stack. Does that mean there was a hang attempting to post a notification? How could that cause a hang, once the app posts a notification its out of its hands and in the hands of the OS. Or is that a red herring? How do I attach the full .ips file? When trying to add it via the Add File option, its grey and not selectable, if I change the extension .txt it says its too large to attach. Also how to format this? Copy/pasting it looks fine, but after hitting the save button all the formatting is lost. Formatting it as quote or code block also looses it all. Event: Timed Out Runloop Hang Duration: 9.99s Duration Sampled: 3.57s Steps: 344 (10ms sampling interval) Report threshold: 2s `Heaviest stack for the main thread of the target process: 344 start + 2240 (dyld + 24012) [0x1d8996dcc] 344 ??? (CallFilter + 69812) [0x10006d0b4] 344 UIApplicationMain + 340 (UIKitCore + 2276456) [0x1b8080c68] 344 -[UIApplication _run] + 888 (UIKitCore + 2278956) [0x1b808162c] 344 GSEventRunModal + 164 (GraphicsServices + 13560) [0x1f91de4f8] 344 CFRunLoopRunSpecific + 608 (CoreFoundation + 210040) [0x1b5c5d478] 344 __CFRunLoopRun + 828 (CoreFoundation + 211096) [0x1b5c5d898] 344 __CFRunLoopDoSources0 + 340 (CoreFoundation + 215996) [0x1b5c5ebbc] 344 __CFRunLoopDoSource0 + 176 (CoreFoundation + 222120) [0x1b5c603a8] 344 CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28 (CoreFoundation + 225580) [0x1b5c6112c] 344 -[FBSMainRunLoopSerialQueue _performNextFromRunLoopSource] + 28 (FrontBoardServices + 41848) [0x1ce0c4378] 344 -[FBSMainRunLoopSerialQueue _targetQueue_performNextIfPossible] + 240 (FrontBoardServices + 42144) [0x1ce0c44a0] 344 FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK + 52 (FrontBoardServices + 42272) [0x1ce0c4520] 344 _dispatch_block_invoke_direct + 284 (libdispatch.dylib + 32072) [0x1bdc24d48] 344 _dispatch_client_callout + 20 (libdispatch.dylib + 17152) [0x1bdc21300] 344 __92-[FBSWorkspaceScenesClient createSceneWithIdentity:parameters:transitionContext:completion:]_block_invoke + 352 (FrontBoardServices + 106380) [0x1ce0d3f8c] 344 -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 168 (FrontBoardServices + 57756) [0x1ce0c819c] 344 __92-[FBSWorkspaceScenesClient createSceneWithIdentity:parameters:transitionContext:completion:]_block_invoke.108 + 280 (FrontBoardServices + 62832) [0x1ce0c9570] 344 -[FBSScene _callOutQueue_didCreateWithTransitionContext:completion:] + 324 (FrontBoardServices + 63188) [0x1ce0c96d4] 344 -[UIApplicationSceneClientAgent scene:didInitializeWithEvent:completion:] + 288 (UIKitCore + 2422752) [0x1b80a47e0] 344 -[UIApplication workspace:didCreateScene:withTransitionContext:completion:] + 508 (UIKitCore + 2423368) [0x1b80a4a48] 344 -[UIScene scene:didUpdateWithDiff:transitionContext:completion:] + 244 (UIKitCore + 1274564) [0x1b7f8c2c4] 344 -[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:] + 216 (UIKitCore + 1274964) [0x1b7f8c454] 344 __64-[UIScene scene:didUpdateWithDiff:transitionContext:completion:]_block_invoke.225 + 612 (UIKitCore + 4964520) [0x1b83110a8] 344 -[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:] + 316 (UIKitCore + 1278672) [0x1b7f8d2d0] 344 _UISceneSettingsDiffActionPerformChangesWithTransitionContextAndCompletion + 224 (UIKitCore + 1279520) [0x1b7f8d620] 344 +[BSAnimationSettings(UIKit) tryAnimatingWithSettings:fromCurrentState:actions:completion:] + 736 (UIKitCore + 1281432) [0x1b7f8dd98] 344 __186-[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:]_block_invoke + 148 (UIKitCore + 1281680) [0x1b7f8de90] 344 -[_UISceneLifecycleMultiplexer uiScene:transitionedFromState:withTransitionContext:] + 248 (UIKitCore + 1281984) [0x1b7f8dfc0] 344 -[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:] + 608 (UIKitCore + 1283672) [0x1b7f8e658] 344 -[_UISceneLifecycleMultiplexer _performBlock:withApplicationOfDeactivationReasons:fromReasons:] + 332 (UIKitCore + 1289296) [0x1b7f8fc50] 344 __101-[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:]_block_invoke + 216 (UIKitCore + 2175308) [0x1b806814c] 344 _UIScenePerformActionsWithLifecycleActionMask + 112 (UIKitCore + 1621112) [0x1b7fe0c78] 344 __101-[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:]_block_invoke_2 + 108 (UIKitCore + 1621280) [0x1b7fe0d20] 344 -[UIApplication _stopDeactivatingForReason:] + 1240 (UIKitCore + 1623808) [0x1b7fe1700] 344 -[NSNotificationCenter postNotificationName:object:userInfo:] + 92 (Foundation + 173988) [0x1b4bee7a4] 344 _CFXNotificationPost + 724 (CoreFoundation + 188728) [0x1b5c58138] 344 _CFXRegistrationPost + 440 (CoreFoundation + 191464) [0x1b5c58be8] 344 ___CFXRegistrationPost_block_invoke + 88 (CoreFoundation + 191648) [0x1b5c58ca0] 344 CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER + 148 (CoreFoundation + 193240) [0x1b5c592d8] Thread 0x403e DispatchQueue "com.apple.main-thread"(1) 344 samples (1-344) priority 47 (base 47) 344 start + 2240 (dyld + 24012) [0x1d8996dcc] 344 ??? (CallFilter + 69812) [0x10006d0b4] 344 UIApplicationMain + 340 (UIKitCore + 2276456) [0x1b8080c68] 344 -[UIApplication _run] + 888 (UIKitCore + 2278956) [0x1b808162c] 344 GSEventRunModal + 164 (GraphicsServices + 13560) [0x1f91de4f8] 344 CFRunLoopRunSpecific + 608 (CoreFoundation + 210040) [0x1b5c5d478] 344 __CFRunLoopRun + 828 (CoreFoundation + 211096) [0x1b5c5d898] 344 __CFRunLoopDoSources0 + 340 (CoreFoundation + 215996) [0x1b5c5ebbc] 344 __CFRunLoopDoSource0 + 176 (CoreFoundation + 222120) [0x1b5c603a8] 344 CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28 (CoreFoundation + 225580) [0x1b5c6112c] 344 -[FBSMainRunLoopSerialQueue _performNextFromRunLoopSource] + 28 (FrontBoardServices + 41848) [0x1ce0c4378] 344 -[FBSMainRunLoopSerialQueue _targetQueue_performNextIfPossible] + 240 (FrontBoardServices + 42144) [0x1ce0c44a0] 344 FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK + 52 (FrontBoardServices + 42272) [0x1ce0c4520] 344 _dispatch_block_invoke_direct + 284 (libdispatch.dylib + 32072) [0x1bdc24d48]

I'm analyzing an app which is doing some processing with contacts, and stress testing it with tens and tens of thousands of contacts which are being processed. The code is being processed within DispatchQueue.global(qos: .background).async {) When the app moves to the foreground the processing starts and continues after the app moves to the background. What I've noticed is that if the app is downloaded from TestFlight, then ~20 seconds after moving to the background, a dialog is displayed saying the App Crashed. Though it hasn't actually "crashed" in the usual sense of crash - there's no crash log present on the device nor in TestFlight if the crash is reported nor is there anything reported to Crashlytics. In addition the is still displayed in the iPhone task manager, also ApplicationWillTerminate() isn't called so it wasn't killed by the OS. This doesn't happen if the app is installed via Xcode and then run (not run via Xcode, installed via Xcode, then run independently from Xcode). When running via TestFlight installation I can see the OS logging" ReportCrash recordCrashEvent; isBeta 1 app stored Received a beta app crash notification. What's going on here, why is TestFlight reporting this? Is it erroneously reporting the background processing after 20 seconds as a crash? Is there anything the app should be doing in this situation that it isn't? Otherwise why is TF popping up that dialog?

When I run my app there's lots of logging in the console appearing, with it appearing with my app's name as the process. My app is accessing contacts, however I'm not logging this, so is the OS? The thing is, I'm testing performance with contacts databases which have thousands of entries in them, not only is this logging cluttering up the console making it difficult to examine, but I think the logging of so many thousands of line is affecting performance. Where is it coming from? Can it be turned off?

If I try to run Instrument's logger for an app downloaded from TestFlight it says "Permission to debug app name was denied". "Recover Suggestion: The app must be debuggable and signed with 'get-task-allow'. How do you make the app debuggable? (I tried creating an archive with the scheme set to Debug, but after uploading that to TestFlight, it doesn't appear. So presumably its not possible to upload an app built with debug scheme builds to TF?). Therefore how can I make a TF build debuggable?, and how to sign it with get-task-allow? Does it have to be a developer distribution .ipa rather than a TestFlight build to enable Instruments/Logger to run it?

I'm looking at some inefficient code that somebody wrote that repeatedly searches contacts within a loop, and that loop can execute hundreds or thousands of times. If I run the app via Xcode then its taking 20-30 seconds to execute, but if the app is downloaded from Testflight and run, the same code runs in less than a second. I'm presuming this difference is due to the scheme being debug for Xcode run but release for the archive scheme? Can the debug scheme really have such an enormous impact?

I want to observe/capture logging from my iPhone app when its not running via Xcode. However when using either the Mac's console app, or the console functionality within Apple Configurator, after about 2 or 3 seconds the logging disappears off the console. How can it be prevented from doing so?

This has been a continual headache for months, ever since Xcode 15 came out. Everything is working just fine, you just made a code change, built and run it, and Xcode installs to the phone nice and quickly and runs it. But them bamn, next time you do the same thing, Xcode displays "Installing to " forever. It just never finishes. I've had this occur numerous times every day, with different versions of Xcode, multiple different iPhones, running multiple different versions of iOS, and even with different Macs. Always the same. It'll be working just fine, then out of the blue, without changing anything, Xcode will suddenly just decide to get into this state where it just hang and during installation, and won't recover even after terminating and restarting Xcode. Please somebody from Apple, what is going on? Is there a work around, how can it stopped from happening? Deleting the app doesn't fix it, restarting Xcode doesn't fix it. Unplugging the usb cable doesn't fix it, Restarting the phone doesn't fix it. What will? Wasted sooo much time with this happening every day for that several months. I've asked this question before and was met with total silence. Must I really raise an official support ticket to get an answer to this? Surely I'm not the only one this is happening to? And if its not "Installing to " that hangs forever then its "Attaching to on <name of phone" that hangs forever, usually both at the same time. (Currently running Xcode 15.2, iPhones are connected via usb).

I created a message filter extension, then edited only a few lines from the template source code (for example to return something in the capabilities query). However no matter what I do, I just cannot get the app to appear in the Settings app - when I turn on "Filter Unknown Senders" there's nothing that appears to select my app. I've tried rebuilding, deleting/reinstalling the app, restarting the phone, it just won't appear. But then I switched to another phone, and with this phone, when I turn on "Filter Unknown Senders" my app does appear and can be selected and enabled. But I still cannot get this to happen on the first phone. Why does the exact same app, exact same build of the app to be precise, appear on one phone but not the other? The phone it works on has iOS 17.2.1 and the phone it doesn't work on has iOS 17.1.1

I'm attempting to build and have lots of code sign dialogs pop up. I'm entering the correct password and selecting Always Allow (selecting just Allow doesn't make any different) but they won't dismiss, instead more appear. I've not found a way of getting rid of them - all the buttons are greyed out. Restarting the desktop doesn't get rid of them. I have to restart the Mac to get rid of them. Why won't they go away and how can I force them to go away? (Sonoma 14.2.1 / Xcode 15.2)

If Xcode is running lots of endless Socstream messages appear in the console: SocketStream read error [0x10cdb3c80]: 1 54 nw_protocol_socket_reset_linger [C172.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] SocketStream read error [0x10cc349e0]: 1 54 nw_protocol_socket_reset_linger [C174.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] SocketStream read error [0x10cd21fb0]: 1 54 nw_protocol_socket_reset_linger [C175.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] SocketStream read error [0x11b734fd0]: 1 54 nw_protocol_socket_reset_linger [C176.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] nw_socket_handle_socket_event [C177.1.1:1] Socket SO_ERROR [54: Connection reset by peer] nw_protocol_socket_reset_linger [C177.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] nw_socket_handle_socket_event [C179.1.1:1] Socket SO_ERROR [54: Connection reset by peer] nw_protocol_socket_reset_linger [C179.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] SocketStream read error [0x11b71b6b0]: 1 54 <snip> I'm running a React Native app and I think these might be due to the Metro connections. But they're very irritating and clog up the console making it difficult to see the app's own logging. Does anybody know if they can be made to shut up?

Ever since Xcode 15 and iOS 17 came out development has quite often been a nightmare of waiting and waiting -Xcode displaying endless circles saying preparing the device, connecting to the device, installing the device. But recently to add to this, installation and launching is just taking really forever. I'm currently running Xcode 15.1 and various versions of iOS 17 (I have several phones) and installing the app from Xcode takes about 7 - 10 minutes (compared to the same app installing in seconds with Xcode 14 for example). Then once its finally installed, it then takes further minutes to launch, Xcode often actually displays a dialog saying its taking longer than expected to launch the app, adding the footnote "LLDB is likely reading from device memory to resolve symbols." What could be reasons, and solutions, for the excruciatingly slow installation time, and launch time? I really need to find a solution to this please - making a code change tweak, running, making another, running, making another, running, just isn't possible given the length of time it takes to install and launch each time. The iPhone is connected via physical cable to the Mac, and the Mac and iPhone are both on the same Wifi network. Xcode 15.1 M1 Macbook Pro Sonomo 14.0 iOS 17.2