It seems to me that whenever a Today Widget crashes for any reason it displays the "Unable to load" message (as on the attached screen).
When this happens nothing kicks off in the debugger, nothing appears on the Console. It seems to me like searching for a needle in the haystack. Is it possibl to debug the "Unable to load" message in Xcode in any way?
Xcode version: 8.2
iOS Simulator: 10.2
You can debug you Today Extension by doing the following:
With the application running in your device/simulator, open the widget. Then, when you have your widget open, go to Xcode->Debug->Attach to Process and you should find your widget name.
Note this will only work if you have your widget opened. You can set breakpoints and debug step by step to find out why the "Unable to Load" message appears.
You can simply select the widget's target in XCode and just run the project, and debug it as usual, with breakpoints, etc.
There is a catch: if the widget is already showing "Unable to load", then it means it crashed, and the debugging won't work.
What I found to be consistently working in restarting the widget is changing the device's language.
So, go to Settings -> General -> Change language
Then run your widget's target from XCode on that phone. Wait until the widgets page shows up and scroll down until your widget appears on the screen (that is when the widget gets loaded).
Even if it crashes now, you will see the crash in XCode.
Related
I'm developing WidgetKit extension on iOS 14,
however, the extension doesn't always connect to Xcode debugger after build and run, causing I can't see logs, as this image shows: (But sometimes it'll automatically attach, I don't know why)
If the extension is attached to debugger, it should look like this, and print logs:
Manually attach process to debugger doesn't works, it should be attached at first launch to see logs.
Does anyone know how to properly debug iOS 14 widget?
Xcode 14.1 known issue:
Xcode 14.1 release notes seems to mention a known issue
After Running a widget extension, users will need to manually start the debugging session with Debug -> Attach to Process. (99285608)
Approach (works on simulator and device)
Run app target and widget target at the same time
Attach debugger to your widget
Steps
Select app scheme and run on iOS device (don't stop)
Select widget scheme and run on iOS (don't stop)
So both the targets are running at the same time
Select widget scheme then Debug > Attach to Process > Select your widget target name
On device / simulator add widget
In case above doesn't work:
Delete app from device
Restart device
Quit Xcode
Clear DerivedData folder
Open Xcode
Try original steps
Note:
You need to attach the debugger every time you run (Xcode forgets debugger added for the previous run)
Now your breakpoints should work as expected and you can debug
Log messages
Use Logger to log messages, open the console (Mac app) and view the log messages there. That way you can debug even when you are not running the app / widget
https://developer.apple.com/documentation/os/logger
https://developer.apple.com/wwdc20/10168
Try plugging in your physical device and running it on that instead of a simulator. That fixed the logging issue for me.
To debug, or see print info: (This works for me)
On the top left of Xcode->
Click project name, you can see a list, select widget name, run it
Click widget name, you can see a list, select project name, run it
Xcode: Version 12.3, iPad: iPadOS 14.3
You can log your useful information in local file, just like this:
public func XXLogToFile(_ text: String) {
if let documentsDirectory = FileManager().containerURL(forSecurityApplicationGroupIdentifier: "group.xxx") {
let logFileUrl = documentsDirectory.appendingPathComponent("log.txt")
do {
var logContent = try String(contentsOf: logFileUrl, encoding: .utf8)
logContent = (logContent.count > 0 ? "\(logContent)\n\(text)" : text)
try logContent.write(to: logFileUrl, atomically: false, encoding: .utf8)
}
catch {}
}
}
I am working on an iOS 14 widget which I would like to my existing iOS 11+ app. The whole process is quite cumbersome because it happens quite often that something does not work as expected.
For example the widget shows unexpected data, or is not rendered as expected (e.g. as described here). I assume that something wents wrong when the system requests the widget and its content from my app extension. However I cannot figure out what this might be.
Is there any way to actually debug the widget extension? Seeing when the code is executed and how it works?
I have already tried to hook up the debugger to the widget extension (using the Debug/Attach to process menu in Xcode). While the process is listed there, the debugger shows no log output nor stops on breakpoints.
Using the system console to show the logs of the iOS simulator devices does not work as well. It does not matter if print(...) or NSLog(...) is used. No output reaches the console.
On the top left of Xcode->
Click project name, you can see a list, select widget name, run it
Click widget name, you can see a list, select project name, run it
Xcode: Version 12.3, iPad: iPadOS 14.3
This works for me.
Since I found no other way to debug the widget extension I wrote a logging method which adds the log output to a a file a the apps group folder:
static func logToFile(_ text: String) {
if let documentsDirectory = FileManager().containerURL(forSecurityApplicationGroupIdentifier: "my.app.group.key") {
let logFileUrl = documentsDirectory.appendingPathComponent("log.txt")
do {
var logContent = try String(contentsOf: logFileUrl, encoding: .utf8)
logContent = (logContent.count > 0 ? "\(text)\n\(logContent)" : text)
try logContent.write(to: logFileUrl, atomically: false, encoding: .utf8)
}
catch {}
}
}
Not the best solution but the only one I found so far.
Select your widget target at the top left corner of Xcode, build and run the app,
then the widget process will be able to debug and show logs.
(This example project is downloaded provided by Apple: https://developer.apple.com/documentation/widgetkit/building_widgets_using_widgetkit_and_swiftui)
Seems Xcode bug here.
Quick fix works for me is open log console manually by cmd + shift + y.
And also add breakpoints.
And then run widget to see logs.
I've run into this issue as well. Logs were not showing (or only showing sometimes) when I run my widget extension in Xcode.
After hours of debugging, the thing that fixed it for me was plugging in my actual device (iPhone 12 Pro Max) and running the widget on that physical device instead of the simulator.
Try disabling bitcode in your extensions, I've had a hard time getting logs until I do it.
When I try to build and run my keyboard extension, it sometimes just crashes with a Thread 1: signal SIGQUIT.
I am not able to reproduce the error. Sometimes I can build and run my app but most of the time the keyboard just quits. This happens on an actual device. In the simulator it does not open my keyboard and says Waiting to Attach.
The console does not output any errors at first. However, if I change the dropdown to View UI Hierachy in the Debug navigator I get the following description:
Details: No plist data for fetching view hierarchy: error evaluating expression “(id)[(Class)objc_getClass("DBGViewDebuggerSupport_iOS") fetchViewHierarchyWithOptions:(id)[(Class)objc_getClass("NSDictionary") dictionaryWithObjects:(id)[(id)[(id)[(Class)objc_getClass("NSArray") arrayWithObject:(id)[(Class)objc_getClass("NSNumber") numberWithBool:1]] arrayByAddingObject:(id)[(id)[(Class)objc_getClass("NSArray") arrayWithObject:#"_UIVisualEffectBackdropView"] arrayByAddingObject:#"_UIBackdropEffectView"]] arrayByAddingObject:(id)[(Class)objc_getClass("NSNumber") numberWithBool:0]] forKeys:(id)[(id)[(id)[(Class)objc_getClass("NSArray") arrayWithObject:#"DBGViewDebuggerUseLayersAsSnapshots"] arrayByAddingObject:#"DBGViewDebuggerEffectViewsToSnapshotAsImage"] arrayByAddingObject:#"DBGViewDebuggerAlwaysEncodeLayers"]]]”: error: Execution was interrupted, reason: EXC_BREAKPOINT (code=1, subcode=0x18daddc34).
The process has been returned to the state before expression evaluation.
Method: -[DBGAbstractViewDescriber handleFetchedViewInfo:fetchError:resultHandler:]
Please file a bug at http://bugreport.apple.com with this warning message and any useful information you can provide.
I also took a screenshot of the processes.
Am I doing something wrong and how could I prevent that my keyboard extension quits all the time when running it? Is it actually a bug as it says in the description?
DISCLAIMER
It seems like something in xCode 8.2.1 is broken and the debugger is not correctly attaching to the correct process or the hosting process is not properly loading the new code.
This is a not a permanent solution but a temporary workaround.
WORKAROUND
I have been able to work around this issue by following the steps below.
Kill any process that is using your keyboard (important!)
Launch the application using the debugger so the latest code is deployed to the device
Navigate to Settings > General > Keyboards > etc.
Remove your custom keyboard
Re-add your custom keyboard
Debug the application once again
The reason this works is because removing the keyboard kills the process that is hosting the extension allowing Xcode to attach to the new binary.
As I understand this is a bug in Xcode 8.2.1. because before update my custom keyboard was working very well.
this is a temporary solution.
Run your code like always!
Bring up your keyboard until the error (SIGQUIT) appear!
Goto xcode > debug > detach
Goto again Xcode > debug > Attach to Process: attach the keyboard (it should be first process)
now, your breakpoints will work. but there are no log output unfortunately! I hope it temporary solve your problem
I got this warning when running my application with HockeyApp integration:
[HockeySDK] WARNING: Detecting crashes is NOT enabled due to running the app with a debugger attached.
Crash reports are not sent and no alert is displayed when opening the app again.
Any one have any idea how to resolve this issue?
This has very simple reasons:
If you are running the app with Xcode attached, your app is connected to lldb, Xcode's debugger. When lldb is attached, it will of course do its job as a debugger and catch any exception or crash that occurs. This means that the crash can never reach the HockeyApp SDK or any other crash reporting SDK while lldb is attached at the same time.
The solution is also pretty simple. If you just want to make sure the SDK is integrated properly and will catch crashes, do the following:
Do a quick "Build & Run" to install the current version of the app on the simulator or device.
Click the "Stop" button in Xcode to stop the debugging session.
Manually start the app on the device or simulator by tapping or clicking the app icon.
Cause a crash.
Restart the app. Now the HockeySDK should process the crash report and show a dialog to approve crash log sending.
One thing to keep in mind: Make sure to not make the app crash immediately after app start as this would not give the SDK enough time to process and send the crash report before crashing again.
Hockey app sdk by default does not send report when a debugger is attached. There is nothing wrong with this.
It will send report when a archive build that release to ur tester cause a crash. I personally think this should and remain as this because you are trying to track crashes from your tester not when you are developing.
I've started a project in PhoneGap which will utilise Sencha Touch 2.
I tried to change the app name from 'app', since I've heard that conflicts with PhoneGap on Android devices. I altered app.js to main.js and that worked, but then I tried changing the Ext.application.name. All I got was a white screen after the loading splash, even with the old name Sencha. Debug console shows nothing at all happening, and the document <body> was empty. This happens with both sencha-touch-all.js and sencha-touch-all-debug.js. Test device is an iPad 1G running iOS 4.3.5.
Aside: To debug this issue, I set up weinre on my Mac and added the appropriate <script> tag to index.html. After making that change, though, the app didn't even launch. It hung on the PhoneGap splash png and I got this message from gdb-remote:
error: failed to launch '<app URI>' -- failed to send the qLaunchSuccess packet
The only reference to that message besides its definition in gdb-remote source that I can find is here, and it's unrelated. I managed to get the issue to go away by restarting the iPad and removing build intermediates.
SOLVED: The issue here was a missing value in the Ext.application definition (key with no associated value), so the whole app definition probably tanked as a result of that. Hence blank screen.