If user select distribute crash log with App Developers, we can see code level analysis where crash happens. But need to wait for log half a day.
If device is in our control, could we speed up this process?
If it's a debug / development build you should be able to extract the logs through XCode by connecting the iOS device to your Mac. In XCode open Window > Devices and Simulators and select the device.
For App Store / Enterprise builds you may want to consider a 3rd party exception / crash reporting tool which supports iOS. For example:
Bugsnag
Sentry - Available as a hosted product or open source
Firebase Crashlytics
Related
Goal:
Connect iOS device (physical device) to macbook
Use Appium / IntelliJ / or any other software to capture app errors from the device
I run automation tests using simulated devices, however, it's proving to not be as affective as manual testing for I'm getting different results. What I want is to simply connect my device to my macbook, run something to log app errors as I interact with my test device.
My current set up to run automated tests:
Appium
IntelliJ - Using simulated devices (No longer wanting to do)
To view what's going on in the device, you'll need to use Xcode. The easiest way to obtain that is to use the Mac App Store application.
If you're able to build your app there is a lot more debugging you can do, but I'm assuming you're not able to do that based on what you've written and won't provide instruction on that.
Attach device
Launch Xcode
Click Window menu
Click Devices and Simulators
Unlock device
Click Open Console if you're looking to see live activity of the system (this is very noisy and unlikely to be of much use) or View Device Logs to see any crash reports.
I have a beta tester who is experiencing a crash upon launching my app. I have Flurry Crashlytics enabled, but I guess it isn't lasting for long enough for those reports to be sent out.
He's a remote user, so I can't plug his computer into my computer, and I doubt he has XCode or any other development tools installed on his own computer.
How could I get the crash log from his phone so I could have a better idea of where the issue lies?
You can have him access the logs directly on the device under Settings, Privacy, Diagnostics & Usage, D&U data. Here it lists the crash logs. You could have him copy and paste the log to send it to you.
In the old TestFlightApp, there was an SDK that allowed developers to log info on the device and then access those logs from the TestFlight website.
After the Apple takeover of TestFlight, I'm not seeing an option to do this through iTunes Connect.
Does anyone know of a way to do this using Apple's new version of TestFlight? Or does anyone have any recommendations for a simple approach to viewing device logs during beta testing?
If you can get your beta testers to send you log files manually, you have a few options. You used to be able to use the iPhone Configuration Utility to view device log files, but it no longer works as of iOS8. The only OS X tool to view device logs other than Xcode that I've been able to find is iOS Console from Lemon Jar Labs (http://lemonjar.com/iosconsole/). It's a very nice tool and I actually prefer it to the Xcode console log - I especially love the filtering ability. I've also seen reference to iTools (http://www.itools.cn/) that works under Windows being able to access device log files, but have no personal experience with it.
I have an iPhone app that I have developed and tested on my iPhone 4S. The app is released on the market and some users claim that the app is unusable as it crashes on start up.
I have done exactly the same things as the users have to their devices, running the same version of the app on my iPhone 4S and I cannot get it to crash.
I have been to the houses of users and plugged their phones into my computer to get the log read out and when I do, I get errors that I am not getting on my phone and my mac.
I am completely at a loss as to how I start to find the solution to a problem like this. Does anyone have even the faintest ideas?
A good start will be to integrate a crash log collecting, crash reporting SDK in your app like HockeyApp, TestFlight, Crittercism or QuincyKit.
This will send you the crash logs to you so you don't have to collect them manually. These tools can also automatically symbolicate the crash logs for you so you can find the source of the crash in your code.
You should test a release build before you ship it. Archive a release build and distribute it as an Ad-Hoc build. You can load a saved IPA file to your iDevice using iTunes or Organizer. The thing is that you can test a release build which is the same you would ship to the App Store (they are signed differently but the build configuration is the same unless you changed that).
iPhone 5S ships with 64-bit A7 processor. Your iPhone 4 is a 32-bit device. Most likely processor architecture is not the case but as Apple says: Before you distribute your app, you must test it on actual hardware. Some of the runtime changes can be detected only when the app is running on a device. I recommend you updating your set of test devices with different models. I still own an old iPhone 3GS which is great for spotting performance issues.
The general comments others have posted are correct. Add crash logging into your app with a pre-made SDK and test on an actual device. I can't add much more to those points, but I will tell a short story about a similar bug that I found in one of my apps in the hopes it helps you with your issue.
Our app was predominately iPad2 users. When the iPad4 was released, waves of our users upgraded and they started experiencing an issue that was not present on iPad2. Two network requests were fired off at the same time and the result from one of them was crashing. We eventually found out it was a concurrency bug. The result of the first request was being processed "too quickly" and the code was getting to a critical section of code that was not thread-safe with the other request handler.
While this bug was still possible on the iPad2 if the network latency fluctuated just right, it never happened that way. The iPad4 made it happen almost every time.
You can use https://github.com/CocoaLumberjack/CocoaLumberjack lib to collect crash data logs from users.
Have you considered installing a crash logger in your app? There are plenty out there (Flurry, TestFlight, Crittercism, Hockey App, etc).
Most are fairly straightforward to install - add a framework and a couple of lines of code. Once you've done this, you'll (hopefully) be able to see exactly where your app is crashing on the users' devices, without having physical access to them.
I really like developing for iOS more than Android.
However, android SDK has a great tool for profiling, called Traceview:
It can not only help to find bottlenecks, but can also show which method was running in specific moment in each thread. This can be very helpful in profiling and debugging. For example, if my app crush at some moment, I can easily see what was happening before the crash in each thread.
Is there are any tool for iOS that can do similar things?
I tried TimeProfiler and Sampler in Instruments, but the could not find how to do this.
Detecting crash stack traces:
This is possible if you have a debug build on your device and that crashes. Attach the device to Xcode and from Xcode start the app. Once it crashes Xcode will show you the stack trace.
In any case iOS writes a crash report with detailed stack traces of all threads. Once you connect the device to Xcode and start the Organizer, it will automatically import all crash reports and symbolicate them. Please note that you need to have the exact build and dSYM archived on your Mac that caused the crash on the device. When you use the archive feature, this is automatically done. If this is a debug build and you did create another debug build in Xcode for the device and not the simulator (no matter if any device is connected or not) then the files are not available to any more. Symbolication will translate the memory frames into class, method and line numbers. To get line numbers, the dSYM is mandatory!
You can also use 3rd party crash reporters to detect crashes, send them to a server, get them grouped together and symbolicated (if the dSYM is uploaded and the server is capable of doing that). This works for debug, beta and app store builds. Some examples are shown here: Including custom data into iOS crash dumps
Profiling - The tool Instruments provides lots of functionalities to profile your app, like:
Memory Usage
Leaks
CPU Usage
Zombies
and many more
You can find more detailed information about Instruments in the iOS developer documentation: https://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40004652