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
Related
Environment is macOS 10.15.5, iOS 15.2 on iPad Pro. Encountering situations where a javafx app works fine with mvn gluonfx:run on macOS, then builds, packages and installs ok for iOS, but when run either with gluonfx:nativerun or launched from the iPad a black empty screen is presented.
I can go through regression approaches of removing change by change to help isolate which one is causing the issue, but due to native builds this is an extremely time consuming and ineffective way of trying to find out / learn what works ok on a jvm on macOS and not on compiled native code on iOS.
Looking through the various device logs with xcode I’m unable to find any run time diagnostic info, e.g. crash logs. Mvn gluonfx:nativerun doesn’t produce any additional info.
Am I looking in the wrong places, is there something I’m missing in terms of understanding how to see where stack traces or other stderr / stdout info might live while running on device, are there live debug capabilities or approaches while the native app is running on device that I haven’t discovered during all the reading of docs?
I’m confident this knowledge gap is entirely due to my newb status building javafx apps with gluon for this environment, there must be some way to collect runtime logs from the final app that I’ve missed.
I have an iPhone app where I use Firebase Crashlytics.
The following happened:
I build a new version of my app and uploaded it to Testflight.
After that I stopped working for the day :)
The next day I saw a crash report in crashlytics for this new app version, dating to approx. 15 min after my upload the previous day. The data says the crash was recorded on an iPhone 7.
So at this point, this specific app version was only available to me and Apple.
I am sure, that I did not open the app (or experienced a crash) at this time AND I do not even own an iPhone 7.
I highly doubt that Apple Beta-Reviewers are using an iPhone 7 to review an app, after all it's 2021. Also a review 15 min after upload seems not very likely.
Does anyone have an explanation for this? Is the crash even real?
Is it possible that crashes are falsely reported to/by Crashlytics? If so, how?
I've never heard of such a thing tbh.
No, Crashlytics can’t generate crash reports when no one has run the app. Someone ran it.
The fact that you just uploaded it for review makes it very likely that Apple did run it. We have a collection of old devices with various iOS versions for testing our apps in real world scenarios, on less capable devices. I would not be at all surprised if Apple does the same thing.
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
I am interested in evaluating performance to an external iOS app. Can I use instruments only with binaries?
Is also around non-apple tools to do this?
thanks,
You should be able to use Instruments with your device and attach it to any running process.
Launch the app yourself and then attach to it from the Attach to Process... command in the Target menu in the Instruments window
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.