Any way to capture DYLD_PRINT_STATISTICS inside the application?

We are trying to capture & tag the performance of our app. In Debug mode we are able to log App Launch time in console using DYLD_PRINT_STATISTICS.

We would like to capture the same data inside the application. Is there any work around to achieve this?

Replies

We would like to capture the same data inside the application. Is there any work around to achieve this?

On what platform?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

We are building app for iOS. using XCode 8.2.1

We are building app for iOS.

I can’t think of any way that an iOS app can capture this info programmatically.

Is this something you want to do on standard customer devices? Or just during testing? If it’s the latter, an enhancement request against our test infrastructure would make sense.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

We are trying to do this on testing devices. if it is possible, are we allowed to do put this in app for appStore?

We are trying to do this on testing devices.

Xcode’s testing infrastructure (

xcodebuild test
) definitely lets you set environment variables when you run your tests (via the scheme you target). I don’t know if it also lets you get the console log entries generated by the test — I don’t have a lot of experience with testing from the command line — but if it did then this would be a good way forward on this front.

If you can’t get this to work then you should definitely file an enhancement request against Xcode. This seems like a very useful feature.

if it is possible, are we allowed to do put this in app for appStore?

I can’t think of any way to do this in a production app. If that’s your goal then you’ll have to file an enhancement request to that effect.

If you do any up filing any bugs, please post their numbers, just for the record.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thank you, reported here: https://bugreport.apple.com/web/?problemID=34054878
In other way, Can we get the timestamp when the app icon is tapped to open the app?

Can we get the timestamp when the app icon is tapped to open the app?

No. Again, this’d make a fine enhancement request (you could imagine it being included in the options dictionary passed to

-application:willFinishLaunchingWithOptions:
.

Alternatively, You might be able to get the start time of your process. macOS has a nice way to do this (NSRunningApplication’s

launchDate
property) but that’s not available on iOS. The only alternative that springs to mind is the
p_starttime
value return by
sysctl
(with the MIB
CTL_KERN
>
KERN_PROC
>
KERN_PROC_PID
> yourPID).

IMPORTANT In recent years the iOS sandbox has increasingly restricted

sysctl
’s access to the process list, so I don’t know if this will currently work.

WARNING If you do end up going down this path, make sure that your app handles failure well. It’s fine to use this suggestion for debugging, testing and analytics, but I’d hate for your app to crash somewhere down the line as

sysctl
gets even more restrictive.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hi Quinn,


Hope you don't mind my replying to this post 2 years later, but I wanted to ask your opinion on something.

I was following this blog here, which extracts the `p_starttime`, converts to relative time from absolute and calculates the time difference.


- Sometimes these values can get pretty high in the wild. Would you have any insight into how that could happen? Doesn't springboard axe any process that hangs for longer than 10 seconds?

- There is a second code snippet in this blog that extracts how long the main thread has spent running, which if executed before `UIApplicationMain` could get you your "premain" time as well. This value is, from all my testing, far lower than the former strategy. Could this be used instead as the blog infers?


Thanks!

Miles