I've got an AppleWatch app that is working fine in Simulator and Device, but when I call openParentApplication, it appears that the parent app is crashing immediately because I see this in the console output:
The UIApplicationDelegate in the iPhone App never called reply()...
When I try to manually launch the parent iOS app in the Simulator it crashes there too immediately. I don't have time to attach the debugger (which is already attached to the AppleWatch app) to see what is crashing it. Note that the parent app runs fine when the AppleWatch is running and I'm using a real iPhone. I can also run the app fine on the Simulator when not debugging the AppleWatch app.
I've tried resetting the Simulator, but problem persists.
I'm just not sure how to debug this. Any help is appreciated.
Start an explicit background task in handleWatchKitRequest. Otherwise, your app gets killed before it reaches reply().
Refer to this post for a code example on how to create a background task.
In turns out that after commenting out all code in the parent app's didFinishLaunching and stripping almost all code out of the watch extension, the problem was indeed at a lower level.
The Simulator has a
Debug | Open System Log...
menu option that showed the crash logs, which contained:
Dyld Error Message: Library not loaded:
#rpath/MyCore.framework/MyCore Referenced from:
/Users/me/Library/Developer/CoreSimulator/Devices/A2061705-DDDF-477C-9AAA-E50GG43A6350/data/Containers/Bundle/Application/DEB7FB25-8233-4B9F-8DAB-9FF8AE42BF33/MyApp.app/MyApp
Reason: no suitable image found. Did find:
/Users/me/Library/Developer/CoreSimulator/Devices/A2061705-DDDF-477C-9AAA-E50FF43A6350/data/Containers/Bundle/Application/DEB7FB25-8553-4B9F-8DAB-9FF8AE95BF33/MyApp.app/Frameworks/MyCore.framework/MyCore:
mach-o, but wrong architecture
My Swift app has a few dependent Swift projects that are used by the app and extension. Getting the Swift frameworks to link has been a major pain. I've included the dependent frameworks (compiled in the same workspace) as embedded binaries. This works when running on the device, or on the Simulator, but not when running in this hybrid watch app + parent app Simulator context.
I changed the embedded binary references to point to the frameworks under ...DerivedData...Debug-iphonesimulator, as opposed to ...DerivedData...Debug-iphoneos, and the problem went away.
Still hoping the Swift framework story will improve.
Are you seeing an actual crash? That message has appeared for me plenty of times without the host app crashing.
99% of the time, that error appears because developers aren't opening a background task to complete their work in handleWatchKitRequest. Without the background task, the OS kills your app in the background before it has a chance to reply.
Related
After working just fine on both iPhone and iPad for a month, my Xcode 9 app has consistently started crashing causing me the following fatal problem: When I build & run it on an iPhone (simulator or device) Xcode completes loading the app and then crashes too fast for me to copy/paste the error from the debugger. When I run on iPad it works fine leading me to believe this is a result of something related to the split master/detail view.
If I use either an exception breakpoint or an "all C++ exceptions" it will stop at the AppDelegate class and crash if I hit play. If I use only an "all Objective-C exceptions" it will crash as before.
In the debug view hierarchy I get the following errors as well:
Error: Unable to capture view hierarchy.
Details: Log Title: Data source expression execution failure.
Log Details: error evaluating expression “(id)
[[(Class)objc_getClass("DBGTargetHub") sharedHub]
performRequestWithRequestInBase64:#"...
Log Method: -[DBGDataSourceConnectionLibViewDebugger
_executeLLDBExpression:forRequest:onPotentialThread:iteration:]
_block_invoke_2
Method: -[DBGViewDebugger updateDebugHierarchy]_block_invoke_2
I have tested other apps and this issue is unique to the app I am working on. Any ideas or debugging tips for how to proceed? I might just have to redo this whole project again if I can't even find the root cause of this! Appreciate any help.
Quick solution: Reset Simulator Device
I managed to resolve the above issue thanks to some serious digging. First, to resolve the instantaneous crash problem, I set a breakpoint at every line in the app delegate. That allowed me to narrow the error to a memory handling problem. From there I started running the code on one of each device available, and realized the crash only occurred on devices I had used earlier in development. Resetting those devices solved the problem.
The core issue here is that when you clean/rebuild your xcode program, it updates the app code on the device, but not necessarily the data model information. So when I changed my data model by including new data and renaming old data it was not properly updated.
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 am trying to run in Xcode both the main App (which is active in background) and the WatchkitApp (which sends requests to main App through the watchkit extension). Everything works fine in standalone, but no way to make it work simultaneously.
My main concern is to understand this message when trying to attach a process: what does this mean ?
Xcode couldn't attach to "myApp"
"myApp" does not support a debuggable architecture
Thank you.
Edit:
I just read that main app in ObjectiveC and watch app in swift is a problem: https://mkswap.net/m/blog/How+to+debug+an+iOS+app+while+the+WatchKit+app+is+currently+running+in+the+simulator
It happened to me when an extension process was hanging around refusing to terminate. Find and kill it in the Activity Monitor.
Actually, I had that same error message, and I fixed it by resolving a bug that crashed my phone app on launch.
I didn't think to run just the phone in debug so I got confused too.
I'm running ObjC on the phone and Swift on the Watch App.
I've got an app that crashes even before the debugger can connect.
I placed a break point on the first line of main(). (I added an NSLog statement as very first statement in main() and set the break point there.
The app seems to start. The main screen with some ui elements becomes visible on the screen. Then it disappears.
There is no crash log found on the devices.
Xcode message:
Could not launch "appname"
process launch failed: failed to get the task for process xyz
Debugging is enabled of course.
The same for the profiler Instruments.
Code signing works fine so that the app can be deployed to the devices.
(Same for enterprise distribution. And the app validates for store submission.)
It does work on the simulator though.
The app used to work fine. I was just about to build it for the store. For final tests on iOS 8.1 I upgraded to Xcode 6.1 with SDK 8.1. But the problem did not occur directly after the upgrade. It worked just fine.
Then it crashed when building for release for enterprise distribution.
The AppStore build crashed in the same manner (according to Apple, the app was rejected of course.)
But it ran nicely in debug modes.
Now I was trying whether compiler options for optimization may make all the difference and I was trying to build in release mode with debugging enabled etc and end up with a debug build crashing as well. (No optimization in debug).
So it may well be that the migration to Xcode 6.1 did cause it but the problem may have come effective only after Xcode cleaned and rebuild the project in response to changes to compiler settings for code optimization.
Sorry for the long text. I tried to put everything in that may be of importance.
Reason is most likely some incompatibility of Crackify and iOS 8.1.
Therefore it may be of interest for others, altough my problem along with these symptoms may be very special.
Very early within AppDelegate didFinishLaunchingWithOptions we have had the following statement.
if ([Crackify isCracked] || [self isCertificateUnvalid])
exit(173);
That, as such, is not really well designed. The app is just terminated rather than any error message displayed to the user. Thus, it appears as if the app has crashed. But it has not crashed and therefore no crashlog is provided.
For reasons which I don't yet understand and which may not be related to this error, my debugger did not manage to hook up into the executed app. Once that was overcome (suddenly the debugger worked without any changes made to any of the debugging related settings) the error was found rather quickly.
This is Crackify: https://github.com/itruf/crackify
Within Crackify it was this code sniplet that caused the problem:
static NSString *str2 = #"ResourceRules.plist";
BOOL fileExists3 = [manager fileExistsAtPath:([NSString stringWithFormat:#"%#/%#", bundlePath, str2])];
if (!fileExists3) {
return YES;
}
For reasons that I did not further investigate, the file, that is tested here, apparently does not exist in iOS 8.1 any more.
My iOS app runs correctly in the simulator and debugging device but when running on an ad-hoc allocated device, the app crashes and according to the app called "console" the app crashes with signal 9, killed 9 and also the app is killed with for termination assertion. I'm lost at this point as what to do. Let me know if you need more information.
Here's the link to the code: https://www.dropbox.com/s/ch48v8uiyx7wiqh/Animal.zip
Besides the other answers, which are good suggestions, a common root cause of this problem is that the Debug configuration can sometimes mask dangling pointer memory bugs. Do the following:
Run the app in the simulator with release configuration. If it crashes. . .
Use log statements and reruns to narrow in on the cause (debugger won't be available).