Instabug first launched on HN back in 2013 as a bug reporting SDK for mobile apps. Over the years, we heard from mobile developers that they want more granular metrics about how their apps are performing in the wild, so we released a new APM tool.
We found that most APM products in the market focus on server-side monitoring, so we built ours specifically for mobile developers.
Here is a quick summary of what we launched:
1. UI Hangs: track the performance of each ViewController, Activity, and Fragment in your app.
2. Network Performance: we record the response time of all your network calls, as seen by users and show you the full round-trip with both client-side and server-side errors.
3. Execution Traces: you can define your own traces to track the performance of any logic in your app that can be a bottleneck to your users’ experience.
4. Apdex Scores: a single metric that represents your overall app quality as perceived by your users with a breakdown of satisfying, tolerable, frustrating, and crashing sessions.
5. App Launch: see how long your users are waiting from the moment they open the app until the app is fully launched and accepting touch events, across devices and OS versions.
Building this was a bit tricky for us. APM is the most data heavy and complex product we’ve built (specially that we had to switch to working remotely overnight like most of the world).
And since APM is all about performance, we had to make sure to keep the footprint of our SDK as small as possible, and more importantly, to do so without sacrificing accuracy or taking shortcuts.
We’d love your feedback and please let me know if you have any questions.
Successful is a broad term, but we have tens of thousands of apps on our platform and our SDK is running on over a billion devices. We did YC and raised multiple rounds after.
Good point and sorry to disappoint you! The good news is that we still have a lot to share, this is the first time in six years to dig deeper into our data and share it with the community. I’m sure we’ll do more and more soon. A series about the most common causes of bugs and suggestions on how they could be avoided would definitely be a great start!
You’re right! Thanks for adding your thoughts to clarify. The wording “most likely” could be confusing indeed.
How about we change it to be “Bugs discovered through Instabug are most often resolved within 24 hours of being reported.” Would that be clearer? And also saying that this is percent of all bugs, not percent of resolved bugs
Helpshift is doing a good job indeed. What differentiate us is that we offer one SDK and one dashboard to view bugs, feedback and crashes, and act accordingly on each one (i.e., assign bugs and crashes or forward them to a bug tracker, and reply to feedback). Plus Instabug captures far more details (screenshot, device details and user steps) to help developers trace bugs faster. I'd really love to hear your feedback once you try v3.0
The main change in v3.0 was that we moved the custom statuses into tags. We thought that would be a good idea to automate the workflow and make use of the tags given it's agility. We did the migration but we didn't think it'll break anyone's workflow. That's why we didn't think that we should notify anyone before launching, and that was our mistake. We explained the logic behind the change after we launched but we should have done that before we launched.
Actually yes, we're cashflow positive. But we don't really call ourselves mechanics, we prefer the word "pharaohs".
Would love to hear your feedback once you try the product that the pharaohs have built!
Wow, that does sound frustrating and I'm sorry we let you down. I thought we did enough to communicate those changes, but obviously that wasn't the case. This is a learning experience for us and we'll definitely do better next time. But let me explain the things we did do, because I'm not sure yet how the information didn't reach you.
We've been reacting very quickly (as fast as we could) to this. And we've even applied some of the changes that you've asked for on the same launch day. And this is the way we treat our users in general. We do our best to react fast their requests.
We've made sure to document all the changes (even the statuses) in our blog post. We've sent it to all our users and placed it inside the dashboard to make sure everyone knows what changed and why it changed. What do you think would have been a better way to notify you?
Also, we didn't mean to be protective! On the contrary, we'd love to get your feedback. What would you like to know?
We got the crash reporting disable question more than once and we've added it to our SDK FAQs a few months ago (https://instabug.com/developers).
Anyways, we're truly sorry to disappoint you. And I'd be more than happy to explore a solution for the statuses changes issue, and also let me know if there's anything else we can do to make it up to you.
Currently there's isn't an automated way to see the progress of the bug. The way it works is that when the developers or the support team mark it as closed/fixed, they can reply back to the reporter saying something like "We've fixed it and it will be in our update next week" and you get these replies inside your app with our in-app conversations.
And yes, we've thought about gamification and rewarding users but didn't get a chance to experiment it. We had a few interesting discussions with some of our users and their main concerns was that they're already getting nearly 5x more feedback when using Instabug in their beta apps which is enough, and that it'll add an extra step in the process which is validating that the bug is actually a bug for the reporter to claim the reward. But I'm personally excited about it and I believe we're experiment it soon.
Hi Everyone,
I'm one of the cofounders of Instabug. We’re really excited to show you Instabug 3.0. We've been working on it for the last months, and we’d love to hear your feedback.
We’ve originally launched on HN almost three years ago (https://news.ycombinator.com/item?id=5526949), and since then, we’ve been helping apps get their beta testers engaged and also provide a feedback channel in their live apps. With this update, we’re adding even more details to the reports that we capture, adding the ability to attach multiple attachments, and most importantly, we’re closing the feedback loop by providing our own in-app live support. Give it a try and let us know what you think, we’re excited to hear your feedback
Here is a quick summary of what we launched:
1. UI Hangs: track the performance of each ViewController, Activity, and Fragment in your app.
2. Network Performance: we record the response time of all your network calls, as seen by users and show you the full round-trip with both client-side and server-side errors.
3. Execution Traces: you can define your own traces to track the performance of any logic in your app that can be a bottleneck to your users’ experience.
4. Apdex Scores: a single metric that represents your overall app quality as perceived by your users with a breakdown of satisfying, tolerable, frustrating, and crashing sessions.
5. App Launch: see how long your users are waiting from the moment they open the app until the app is fully launched and accepting touch events, across devices and OS versions.
Building this was a bit tricky for us. APM is the most data heavy and complex product we’ve built (specially that we had to switch to working remotely overnight like most of the world). And since APM is all about performance, we had to make sure to keep the footprint of our SDK as small as possible, and more importantly, to do so without sacrificing accuracy or taking shortcuts.
We’d love your feedback and please let me know if you have any questions.