My app got crashed in every first launch from Testflight. It runs perfectly well from debugger. After installing from Testflight, it shows splash screen for more than 20 seconds on first launch, then got crashed. But it works fine on second or third launch. No crash report generated in crashlytics and iTunes.
I created ipa file and installed directly through devices option in xCode and it showing
failed to launch after 20.00s (launchIntent: foreground-interactive)
on first launch. It takes more than 20 seconds to launch in debugger too.
As the app is failing to launch in 20 seconds iOS is killing the process. No 3rd party SDK will be able to provide a crash report for this! You need to check the crash report on the actual device for more details.
You are doing something early in your apps code (most likely applicationDidFinishLaunching) which is taking too long and blocking the main thread.
Related
I have a problem, when I test my iOS App on a real device or when I testing it in the simulator all is working as expected, but when I submit the app to TestFlight and I want to open it on my device the app is instantly crashing on launch. My last changes on the app was that I added the option that the user can pick another App Icon, nothing else. But now the app is crashing in TestFlight. Anybody has an idea what I can do?
Sometimes I get this error:
<NSError: 0x28227d6e0; domain: BSServiceConnectionErrorDomain; code: 3 (OperationFailed); reason: "XPC error received on message reply handler">;and thisMultiple RBSRunningReasonAttribute provided: 13 vs 20254. First one wins, but client should be fixed for assertion 31-112-6223`
I already tried to changes Scheme to Release but nothing changes still works on the simulator and the real device.
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 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.
Our current beta version of the app crashes sometimes, this happens to myself and my colleagues. The beta's are send with Apple's TestFlight app and I build it to my own phone. Phones are iPhone6 running latest iOS8.
When I hook each of them on my mac and load the crashlogs I couldn't find any crashlogs on the time the crash has occurred (also none on other times). I see recent crashlogs of other apps but none of the crashes is our app. Also there isn't an unknown crash at that time indicating a memory issue.
The app crashes after using it a couple of minutes to a hour and seems not to crash each time. So not on startup but somewhere in the middle and not always in the middle. App is using the users-location actively.
Changes in this beta version:
- More MKOverlays on the map
- First time MKMapCamera to position the users location on the map
- Crashes occur while using the map
Any ideas?
Best,
Sjoerd
edit:
After running the app on my phone in xcode for some time I finally found some crashlogs. Perhaps it's the kind of crash?:
Exception Type: EXC_RESOURCE
Exception Subtype: WAKEUPS
Exception Message: (Limit 150/sec) Observed 300/sec over 300 secs
Triggered by Thread: 19
Seems that I had memory crashes at another time. Weird.
I ran the app on my own phone (not simulator) in debug and found out that is was a memory crash. Now the memory crashlog was there with the right time now
Not sure what happened before and why the time wasn't right.
Also memory crashlogs appear as unknown. See the first one:
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).