I've got a crash occurring at app launch time, its crashing too early for Crashlytics to have a chance to send off its stuff to its website. The person on who's phone it is crashing is tech savvy so we've managed to extract the Apple crash report and the Crashlytics directly full of loads of stuff. The Apple crash report is very useful, but I'd like to supplement the information obtained from the with that from Crashltyics (not the actual crash stack, Crashlytics can't improve on what Apple do) but some breadcrumbs that Crashlytics ought to have. I've opened all the files but there's nothing human readable, I asked this question of their customer support but they never replied. Anybody happen to know if the raw Crashlytics files can manually be munged into a human readable form, or manually uploaded to the Crashlytics web site?

I've been constantly having this problem for the past few months, using the various Xcode 15 betas and the iOS 17 betas, but the problem is still present with Xcode 15 release and iOS 17.0 release (and indeed with 17.1 beta). The issue is Xcode constantly says "Connecting to the phone" when attempting to run an iOS app from Xcode. Once it says this it never stop. Terminating and restarting Xcode doesn't fix it, disconnecting the phone and re-connecting doesn't fix it. If I restart the phone then Xcode will switch to saying "Preparing the phone" and it'll never stop saying that (even though the phone might have been attached for hours and has previously been prepared). I think the problem is actually iOS 17 or iOS 17 in combination with Xcode 15 because I don't have an issue with Xcode 15 and iOS versions less than 17. Nor in 13 years have I ever encountered a similar problem before. So for the past few months I've been avoiding using iOS 17 because of this issue it's literally impossible to develop. But it's becoming harder to avoid using iOS 17. So restarting the phone doesn't fix it, disconnecting the phone from the Mac doesn't fix it, restarting Xcode doesn't fix it. Are there suggestions for something else to try? Apple are there any logs I can get to provide you that will help diagnose this issue?

I'm trying to report a crash report. Originally it was about 30,000 characters so I hoped it down until it was < 7000. But when I try and post I get a message saying the post is empty and the character could is negative. Tried multiple times, just can't post.

I'm occasionally getting a crash (on iOS) after a hang and termination by the OS. While reproducing it and watching the Mac console I don't see any obvious cause of the issue. There shouldn't be anything synchronous and long running in the main thread. Verbose logging is turned on, is it possible too much logging is causing this (its using NSLog for the console and also echoing logging to Crashlytics.log())? If so why is it not deterministic in its reproducibility? Here's a crash stack: > Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: FRONTBOARD 2343432205 <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:[application<com.appname>:3315] failed to terminate gracefully after 5.0s ProcessVisibility: Unknown ProcessState: Running WatchdogEvent: process-exit WatchdogVisibility: Background WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 4.260 (user 2.150, system 2.110), 11% CPU", "Elapsed application CPU time (seconds): 0.022, 0% CPU" ) reportType:CrashLog maxTerminationResistance:Interactive> Triggered by Thread: 0 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libsystem_kernel.dylib 0x1dd27b7dc __ulock_wait + 8 1 libsystem_platform.dylib 0x1fe05efb0 _os_unfair_lock_lock_slow + 176 2 CoreFoundation 0x19e3a6648 _logToStderr + 148 3 CoreFoundation 0x19e421500 __CFLogCString + 84 4 CoreFoundation 0x19e34fc8c _CFLogvEx2Predicate + 344 5 CoreFoundation 0x19e35e548 _CFLogvEx3 + 252 6 Foundation 0x1986195c0 _NSLogv + 124 7 Foundation 0x198617f58 NSLog + 56 8 AppName 0x1042dd480 +[Logger trace:] + 70784 (Logger.m:48) 9 AppName 0x104311ae4 CallExtensionManager.appBecameActive() + 285412 (<compiler-generated>:0) 10 AppName 0x104312004 @objc CallExtensionManager.appBecameActive() + 286724 (<compiler-generated>:0) 11 CoreFoundation 0x19e2f2590 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 12 CoreFoundation 0x19e396828 ___CFXRegistrationPost_block_invoke + 88 13 CoreFoundation 0x19e3798b8 _CFXRegistrationPost + 440 14 CoreFoundation 0x19e306afc _CFXNotificationPost + 700 15 Foundation 0x1985d1d18 -[NSNotificationCenter postNotificationName:object:userInfo:] + 92 16 UIKitCore 0x1a05b61e8 -[UIApplication _stopDeactivatingForReason:] + 1236 17 UIKitCore 0x1a05b5c98 -[_UISceneLifecycleMultiplexer _performBlock:withApplicationOfDeactivationReasons:fromReasons:] + 280 18 UIKitCore 0x1a05b5a84 -[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:] + 620 19 UIKitCore 0x1a05b5634 -[_UISceneLifecycleMultiplexer uiScene:transitionedFromState:withTransitionContext:] + 252 20 UIKitCore 0x1a05b5500 __186-[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:]_block_invoke + 148 21 UIKitCore 0x1a0ca2a68 +[BSAnimationSettings(UIKit) tryAnimatingWithSettings:fromCurrentState:actions:completion:] + 736 22 UIKitCore 0x1a0d41074 _UISceneSettingsDiffActionPerformChangesWithTransitionContextAndCompletion + 224 23 UIKitCore 0x1a0462c70 -[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:] + 316 24 UIKitCore 0x1a08d41ac __64-[UIScene scene:didUpdateWithDiff:transitionContext:completion:]_block_invoke.223 + 556 25 UIKitCore 0x1a0533c60 -[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:] + 216 26 UIKitCore 0x1a0533ad0 -[UIScene scene:didUpdateWithDiff:transitionContext:completion:] + 244 27 UIKitCore 0x1a0533910 -[UIApplicationSceneClientAgent scene:handleEvent:withCompletion:] + 336 28 FrontBoardServices 0x1b4340ac8 -[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] + 420 29 FrontBoardServices 0x1b4340904 __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2 + 152 30 FrontBoardServices 0x1b4344120 -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 168 31 FrontBoardServices 0x1b434403c __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke + 344 32 libdispatch.dylib 0x1a578beac _dispatch_client_callout + 20 33 libdispatch.dylib 0x1a578f91c _dispatch_block_invoke_direct + 264 34 FrontBoardServices 0x1b434e24c __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 52 35 FrontBoardServices 0x1b434dde8 -[FBSSerialQueue _targetQueue_performNextIfPossible] + 220 36 FrontBoardServices 0x1b4350694 -[FBSSerialQueue _performNextFromRunLoopSource] + 28 37 CoreFoundation 0x19e38e128 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 38 CoreFoundation 0x19e39a7b4 __CFRunLoopDoSource0 + 176 39 CoreFoundation 0x19e31f648 __CFRunLoopDoSources0 + 340 40 CoreFoundation 0x19e3350d4 __CFRunLoopRun + 828 41 CoreFoundation 0x19e33a3ec CFRunLoopRunSpecific + 612 42 GraphicsServices 0x1d985035c GSEventRunModal + 164 43 UIKitCore 0x1a06c6f58 -[UIApplication _run] + 888 44 UIKitCore 0x1a06c6bbc UIApplicationMain + 340 45 AppName 0x1042dfbf0 main + 80880 (main.m:7) 46 dyld 0x1bd86cdec start + 2220 Can't get the stack trace for Thread 0 to display nicely

If I turn on (my company supplied VPN access) and then attempt to build with Xcode then that has the consequence that all the dev/distribution certificates in the keychain turn red and say "certificate is not trusted". Turning off VPN doesn't reset them back and of course re-attempting to build will fail. However if I reboot my MacBook, then the keychain is back in a good state again. However as I work remotely I constantly have to flick VPN on and off throughout the day, and having to reboot endlessly is a pain. Is there something I can do to reset the Keychain's certs to a good state without having to reboot? (and without having to delete them all and re-add them all back to the keychain).

In this section of this web site https://developer.apple.com/account/#CodeLevelSupportCard its possible to view a historical list of submitted TSIs, but there's nothing in their content which is clickable. Looking around elsewhere, there doesn't appear to be anywhere or anyway to view the original question and the responses in submitted TSIs? Is that really the case, or is there a bug in the Apple web site and they are supposed to be viewable?

I have a lot of phones and constantly switch between them, its very very annoying that when a phone is connected via cable, and then swapped out with another one, then Xcode will continue to install/run with the phone that's just been switched out, not the one that's just been connected by cable. This is because Connect via network it turned on and there's no way to turn it off. In previous versions of Xcode you could turn this on/off as you wished, not so with Xcode 15, it decides to turn it on for you and won't let you turn it off because its always disabled.

In the console app, there is an option to turn on/off the displaying of Info and Debug message levels: However I don't see an equivalent to do likewise with Xcode's console. Is there one?

I've gone through several tutorials, and the documentation, it seems there's no way to adjust the logging level dynamically, or even at build time for that matter. i.e. there is apparently nothing that exists such as: static let logger = Logger(subsystem: subsystem(), category: category()) logger.setMinimalLevel(.Warning) logger.trace("I won't get displayed because minimal level is debug") Am I mistaken and there is something like this?

I'm getting loads of these appearing in my console, I can't find anything for it from googling. What does it mean?

My goal is to try and get a unified logging system set up where logging from an iOS app and its extensions (primarily a notification service extension) get written into one central repository. So I was planning on setting up CocoaLumberjack in the app and the extension to use the same file path/name, adding the group capability to the app and the extensions and specifying the shared group directory as the file path. By default, for an app, CocoaLumberjack writes its files to: var/mobile/Containers/Data/Application/05464D4A-20F6-4E1F-9DBC-3109C053A1E8/Library/Caches/Logs/ On a Mac using an application such as iExplorer the above file and be located and viewed and copied etc. For an extension, it writes them to: /var/mobile/Containers/Data/PluginKitPlugin/5542F5EA-EB3A-4728-B33E-4E57C1B7B3B4/Library/Caches/Logs/ Now if I configure Cocoalumberjack to instead write the logger file to the shared group directory, then that will be at: /private/var/mobile/Containers/Shared/AppGroup/6CD5AF2C-54C9-46EF-B831-997B1DD6664F/ However its not possible using iExplorer to access this location. Using a Mac connected to the iPhone, is there an app or tool etc., that will enable me to locate the log file if it's created in the above AppGroup location?

Our app has some Crashlytics & Localytics reporting to collect metrics for diagnostic and info gathering. One thing I'm noticing recently is that if a user has version m of the app installed and updates to version m+1, then for some users, the app has detected and reported that the push token obtained with version m+1 is different from that of version m (for the same handset). That's fine - if the app has detected the change to the token it can send the new one to the server so the server can update. But my question is - if the user didn't explicitly launch the app and thus present the app with the chance to send the new token to the server, then what will happen to the pushes sent by the server using the old token? Presumably they won't get delivered if the token has changed, but if the user has no need to launch the app then they're never going to receive any pushes from the server until they do launch the app. However there's not necessarily any reason why a user should repeatedly launch an app once it's been set up (depending upon what it does and how it delivers info to the user and how the user interacts with it, there's no reason why a user should have to launch the app after initial installation and launch). If so then this seems like a gap in the design of push notifications? If they can change on the same handset, or another scenario is the user backs up their device to iCloud and then restores to a different handset, then in that case the push tokens will have definitely changed, yet any apps using push don't get the chance to send the new token to the server until the user launches the app, meanwhile all pushes from the server will be dropped.

The previous betas have all been ok, but beta 6 is for me totally and utterly unusable because it keeps hanging forever during the installation and attaching phases when trying to run an app (attached physically via cable, not bluetooth). The first time or two of making a code change, then running, its ok, but then its guaranteed to hang eventually, it gets stuck on the "Installing app to iPhone" phase. If I restart the phone and try again it might get past that, but then it just gets stuck on "Waiting to attach to app on iPhone" phase. I know its beta software and not expected to be perfect, but its unusable and previous beta versions are no longer available to rollback to. Has anybody encountered this before and knows of any tricks to get it to stop hanging and load/run the app? (Restarting Xcode, restarting the phone, re-building, does not fix it for me)

I've been successfully using CXProvider.reportNewIncomingVoIPPushPayload() as follows: a (non VoIP) push is sent to the handset this is intercepted by a notification service extension the extension calls CXProvider.reportNewIncomingVoIPPushPayload() (the extension has the required com.apple.developer.usernotifications.filtering entitlement) this results in the app delegate's implementation of PKPushRegistryDelegate:didReceiveIncomingPushWithPayload getting called (the app is launched if terminated) This all works as expected, in particular when the app is terminated it still works. However its suddenly stopped working since my phone got updated to iOS 16.6 (I can't remember exactly what was on it previously, 16.5 or 16.4). Now with iOS 16.6 the behavior is that PKPushRegistryDelegate:didReceiveIncomingPushWithPayload() only gets called if the app is not terminated. If the app is terminated then calling CXProvider.reportNewIncomingVoIPPushPayload() results in the app getting launched and didFinishLaunchingWithOptions() getting called BUT didReceiveIncomingPushWithPayload() is not called when launching from a terminated state. As a consequence of didReceiveIncomingPushWithPayload() not getting called, the app isn't calling reportNewIncomingCallWithUUID() and so after a few runs the OS stops launching the app entirely saying: "Application will not be launched because it failed to report an incoming call too many times". When didFinishLaunchingWithOptions() is called the launchOptions are nil, i.e. there is no way to distinguish the app from being launched as a consequence of reportNewIncomingVoIPPushPayload()(*) being called and therefore it is not possible to call reportNewIncomingCallWithUUID(). So this feature is totally broken apparently from previous behavior. Any comment? TIA (*)Well actually, the extension could write a flag to a shared group and the app read that on launch, but what a hack, and should be unnecessary.

Apple this is dead easy and quick to reproduce. Just create an app and then add a target of type background download. Xcode automatically assigns a group id to the target and generates a corresponding entitlements file like so: However the extension will not build, there is this error: You can bugger about in the developer portal as long as you want, ensuring the group identifier exists, ensuring provisioning profiles have this group capability, etc. etc. nothing will make this error go away. Now, what is unique about the download extension's entitlements file is the com.apple.developer.team-identifier key. This does not get generated for other extension - go ahead and see for yourself, create an action extension and give it a group, the result is its group appears in the entitlements file but not this com.apple.developer.team-identifier. If you try to print out $(TeamIdentifierPrefix) (via echoing it in a build script), you get this /Users/me/Library/Developer/Xcode/DerivedData/experiments-clpwbtcvdpqwuodxzwmsxwpztguo/Build/Intermediates.noindex/experiments.build/Debug-iphoneos/backgroundDownloadExtension.build/Script-243C9904292461BC001FDE14.sh: line 4: TeamIdentifierPrefix: command not found Hmm, command not found, but if you change the echo to ${TeamIdentifierPrefix} guess what gets printed, yes the team identifier i.e. in my case MV8J9D3236. Now if in the entitlements file I add the team identifier explicitly, like so Then magically the error about automatic signing and the provisioning profile goes away. Change it back to $(TeamIdentifierPrefix) and the error appears, change it to be explicit and it goes away. So by tweaking the entitlements file its possible to get the extension to build, however all is not well, now that it builds, if the extension is installed and run, the OS says: "Event (1) dropped for client (com.company.experiments) failed because the app and extension do not share any application groups." It says that despite the fact the app and extension both do have the same group capability. This is driving me nuts - the auto generated entitlements file is stopping the extension from compiling, but if you fix the build, it can't run. (Xcode 14.1, iOS 16.2)