True Version Comparison (More than just Crashes), Visibility into all Bad Sessions, and much more

We’re thrilled to announce we just released a major update to our dashboard with a ton of new features and an entirely new look!


Version Comparison
The most important event for any app is the launch of a new version, and we now have a page in the dashboard to show your app’s overall health and how it’s changed version to version. We track fluctuations in your crash percentage, sessions that ended in frustrating ways (see Bad Sessions” below!), App Moment performance, and lots of other useful metrics to let you know just how your new release is performing.


App Moment Performance
Our brand new performance page breaks down the success and failure rates of your App Moments. We show how often the most critical interactions in your app are failing, crashing, or just taking longer than they should. We also surface sessions that were impacted so you can retrace your users’ steps and find the root cause.


Bad Sessions
One of the things that makes different is that we know there’s more that frustrates users than just crashes. Bad Sessions is how we break down all the sessions that end in unpleasant ways for the user: User Terminated” is when users get frustrated and force quit apps in the task switcher, OOMs” or Out of Memory” is when the OS terminates the app due to improper resource usage (and it looks just like a crash to the end user!), and regular old crashes due to uncaught exceptions. Watch these metrics trend over time and dive in to affected sessions to start debugging.


Screenshots by App Moment
Many of you have requested this, and we’re happy to announce you can now filter the Screenshots page by App Moment, which should make discovering issues and debugging frozen apps much easier.


Network Alerts
As some of you have seen, we’re now automatically detecting and sending alerts based on HTTP request errors into our community Slack workspace. We’re eager for your feedback, and will soon be rolling out more advanced controls for telling us exactly which alerts matter to you.


Team Management
Have anyone in your organization who isn’t on but should be? You can now invite them from directly in the Settings page. We’ve also surfaced API tokens for our dSYM upload script, which you can add to your app to make the stack traces in exception and error logs drastically more useful.
We’ve also put in a huge effort to modernize and refine the look and feel of our dashboard, and we hope it makes it easier and more enjoyable to use. We’d love to hear any feedback you have, and we’re excited to share more changes with you in the coming months!

“Hunch” Study : Network Calls and their Effect on Mobile Apps

Every good mobile engineer has questions that they wish they could answer, if they only had the time. One of those questions, related to concurrent network calls, goes something like: “How many calls can my app do and not impact app performance?” Until recently, no one had actually measured to figure it out — then we did!

Hop in the time machine with us and we’ll explain how it happened . . .

Timehop is a nostalgic social networking app with tens of millions of downloads on iOS and Android. We worked with the Timehop team to understand how technical choices impact users’ experiences within their iOS app, and identified suboptimal areas to focus and improve upon. For purposes of this calculation, we focused on 3 days in October during which we collected data globally from over 7.5 million experiences, spread across over 2.5 million devices.

Let’s start with the common culprits.  SDKs are often the primary hunch for the cause of suboptimal experiences on mobile.  Knowing the hunch, most app developers still initialize *all* their SDKs on startup (somewhat of a standard practice).  Like all apps, Timehop embeds a lot of SDKs; 47 to be exact, ~16 from 3rd parties vendors.  (Please note that SDKs are not limited to 3rd parties, like analytics, ads, Google, FB, Twitter and the like, but are also many of the libraries that we use out of the box, like Bolts, Appirater, and SocketRocket). Starting the app with this many SDKs obviously impacts the quantity of network calls that occur during start-up.  

When initializing the app with all of these SDKs *plus* your own 1st party network calls, you’ll get a logjam, and many of these calls (3rd or 1st party) will block your app from progressing. In Timehop’s case, we focused on startup time and a very slow benchmark of 5 seconds.  We figured-out that the number of slow startups increased to 6% with ~6 concurrent network calls.  The number increased to 13% of startups with 10+ concurrent network calls.  Getting a bit more granular, we helped Timehop sort out that a user with any network call of over 2.5 seconds during startup correlated to an increase of +27% chance of that user leaving the app.

Further, we found that 3.3% of users were experiencing a slow startup (over 5 seconds), and 2.9% had a stall (e.g. what amounted to a freeze from the user’s perspective) at startup. We were also able to pinpoint that Mixpanel and StatHat were the primary sources of HTTP errors during startup. Timehop has been able to take this info, tweak their startup, and reduce user churn as a result.

The moral of the story? With a little time, good technology performance becomes good business.

You can’t change how many, or how fast, network calls occur, BUT you can control how well you have built your app. cures app blindness.  We make your app’s performance visible for each user and segment, leading to better user experiences, and improved business outcomes.

We are here to help. Let us know how we can for you.

–    Eric


Live Event Debugging, Memory Improvements, Feedback turned into Reality

We are excited for our latest release focused on taking the first step towards live feedback and continuing to make our SDK have as small a footprint as possible.  

  • Live event mode! 

One of the primary reasons we kicked-off (only) last year was to provide true visibility to the mobile team, especially the developers.  The ability to see technical details and reproduce sub-optimal experiences on any device is not limited to when then app is live.  Development has many similar pains, and we are happy to take the first step to provide 100% visibility when in that mode.

Live Event Debugging : For any app running with the debugger attached, watch “Live Events” roll by for you or any other user.  Test your integration to watch log messages and app moment events in real-time.  Select a Device via the dropdown for anyone attached – QA, developer or product.  As we iterate on this feature, our plan is to expose other device information so you can see in-app information fly by!

(Click to for a high-res view of the Live Event Debug Mode)

  • Run your app in the background?

The SDK now provides additional context around when your app is running or unexpectedly dies in the background.  Admittedly, we never thought of background as a primary use-case because users of an app are by definition not viewing the app.  Our minds were changed when customers explained that many of their use-cases relied on being in the background; for example, playing an audio/video file or tracking the movements of a driver.  

  • Memory management improvements

We will continue to improve our iOS and Android SDKs to reduce their footprint while bringing as many features to each customer as possible.  (Its a true balance!)  In this release of the iOS SDK (2.6.0,) we focused on reducing the SDK footprint around memory thereby making the app startup even faster

Please let any of us know whether you have any questions via Slack, Email or Twitter.

Thanks for all the support!

– Eric

There’s more to life than just crashes!

Mobile teams are singularly focused on crashes. Understandably so — they are the simplest to identify and diagnose. BUT crashes account for less than 1% of your issues! You still find errors and your users are still complaining.

With mobile apps, we are conditioned to think of all performance issues as ‘crashes’. That’s because a) there’s a tendency for users and business people alike to rush to the term ‘crash’ when it may not really apply, and b) there are limited tools on-par with their desktop counterparts for identifying and diagnosing mobile app performance issues.

So, even though the performance issue may deal with an inhibited experience (the app is taking so long time to load that it appears frozen), it’s treated like a crash. Ask yourself:
When you fix a crash, how often does it really impact the experience of any user?
How often is it in the background?
How often does it affect a small number of users who don’t contribute to the app or app community?
How often does a user just re-open the app anyway?

The truth is, most crashes are a fender-bender, but we treat them like 50 car pile-ups.

Instead of solving every issue, shouldn’t we be focused on solving the most important ones? If you are constantly distracted with minor performance issues that affect just a few low-value users, then you’re not spending time improving experience and heading off a serious error that could kill-off lots of high-value users.

The logic is the same whether you’re an engineer or a business person: focus on what matters and de-emphasize what doesn’t. This brings us right back to the need for mobile-first tools purpose-built to help engineers and their mobile teams quickly assess and resolve performance issues.

One of the unique things that Embrace does is let engineers stitch together user sessions. So, if the user experienced a crash, but then just immediately re-opened the app and all was fine, maybe it’s not worth solving that problem right now. We surface that data and visualize it so the engineer, product manager, or other member of the team can easily dig in and decide the appropriate course of action.

This ensures the most mission critical performance issues get the attention they deserve, relieves pain for engineers, and keeps users happy. And that’s what it’s all about.


To put it simply, we love mobile.  Mobile is the center of our lives and will continue to be the center.  Three simple examples of why:

  • Apps: Over 80% of people prefer apps to mobile web experiences.  While web is here to stay, native is so much better for more utility, work, and social experiences.  We will have an app for everything and this won’t change;
  • IOT: How do you plan to control all those devices? Your phone is the definitive remote; and
  • VR: In 2 or 3 years, do you think you’ll be plugging that headset into a computer, or running it on its own? No, it’ll be plugged into your next gen phone.

While my team and I enjoyed building apps, we find it much more fun to work with a ton of developers.  Everyone loves giving advice and now it’s our full-time job. Not only that, but we back it with real data streaming from each mobile device.  

We know the specific user who had a spinner of death. We know when a marketing or advertising SDK is blowing up a segment of users. We know when a 3rd party network call for a purchase isn’t working . . .  we know a ton.  I wish I had this level of visibility when I built Dice With Buddies, instead of finding stuff out after the fact via complaints, lower retention curves, or banging on all the devices strewn across my desk.  

Nothing is more ‘fun’ than grabbing one of those phones, walking over to the lead mobile developer, and asking, “Why is the startup taking so damn long?!?”  Then they say, “Can you reproduce it?”, or “Can I plug your phone in?”, or “Wait a few days and I’ll see if I can dig into the log files or [MixPanel / Omniture / Flurry / <Insert ill-suited marketing analytics tool here>]”.  The answers to all three are far from ideal!

As a B2B company, our goal is to make customers love us.  While we’ve built an awesome platform and team to advise you, the mobile team and developer, we want you to ask us anything!  We’ve used every mobile tool on the market, we’ve mastered IAP and Ads, we know user acquisition, and LTV, and CPI calcs.   

We’re happy to be of service, make your lives easier, and your users happier! Just ask.