Today we're finally going out of beta and launching Instabug 3.0. We believe it's 10x better than what we had before. You can read why we did this and what's new in it, or you could just try it yourself!
We’re super excited to finally share with you what we’ve been working on for the last months. The reason why we started Instabug in 2013 was to empower apps and mobile development teams to ship better apps. And today, with Instabug 3.0, we’re one step closer to that goal.
Since we started three years ago, all kinds of apps of different scales have been using Instabug, whether it's to gather feedback from beta testers and to enable co-workers to easily report bugs in their beta apps, or to engage end-users in live apps and avoid negative reviews on app stores.
It was difficult building a product that suits all these different use cases. So we initially started with a focus on the beta phase of an app. It's such a crucial phase in the app development lifecycle that was given minimal attention. There were many problems to solve but there were two big ones: First, we discovered that many companies (even some on the top charts) don't do beta testing at all. They rely on third-party QA or internal testers, and the main reason is that beta testers weren't sending much feedback.
The problem lies in the lack of details needed to understand the feedback or debug the problem. Second, most beta testers test apps for free (as early adopters or loyal users), yet they have to do a lot of work to report bugs or send feedback. They had to manually take screenshots, extract logs, and send them in e-mails.
We built Instabug to solve these problems and we believe we did a good job. We've encouraged thousands of companies to start beta testing by providing them with an easy-to-integrate SDK that allows beta testers to send feedback, report bugs directly from the app (easier reporting = more feedback), and the SDK captures all device details in the background (more details = less debugging time).
Over the past year, apps saw the value of Instabug in communicating with their beta testers. They saw how more engaged they've become, they saw how these detailed bug reports can benefit and help them fix bugs faster. And they also saw the value of making the feedback process in-app instead of via e-mails. So some of them thought, "You know what? Why shouldn't we use Instabug to do the same with our actual users in our production apps?" And they sure did.
Thousands of apps started to ship with Instabug's SDK. The effect was unbelievable! Users were more engaged when they knew they could actually talk to the people behind it directly from within the app. And some reported up to 80% less negative reviews on app stores as people were sending their negative feedback through Instabug since they knew their voice would be heard and their problem would be fixed.
So after countless hours talking with our users and building prototypes, we're proud to introduce Instabug 3.0! Here's what's new:
Drop the e-mail composer and start giving your users the exceptional in-app support experience they deserve. Now with Instabug 3.0, you can chat with your users inside your app. Answer their questions, update them on new features, and be closer to them!
We rebuilt our dashboard from the ground up to let you do more with less clicks. We're introducing Smart Filters to replace the old cluttered side filters to let you navigate faster, a redesigned issues page to let you go see your issues' details in one place instead of going back and forth among different pages, and a much smarter and faster search.
We gave our SDK a major facelift (both iOS and Android) and we've added the ability to attach multiple images and a voice recording. We've made sure to keep the same simple integration process and the same minimal footprint.
Since we launched crash reporting last year, we've seen developers migrating to use Instabug for crash reporting for several reasons: less dependencies, having their feedback/bugs/crashes in one place, and, most importantly, for the amount of detail they get, especially with the user steps.
So we've added some improvements under the hood to make sure we capture all kinds of exceptions with the same level of detail. Other than that, we now capture the stack traces of all the running threads on the device while maintaining the server-side symbolication of it.
We've been getting a lot of good feedback about our analytics and how it saves people time to check it at a glance. We decided to expand it both vertically and horizontally. So we're adding more visual graphs for the most requested analytics, which visualize the bugs/feedback semantic analysis to show you what most of the bugs being reported are about.
Apart from that, we added a new category: user analytics. This allows you to keep watch over your app users and know exactly who's upgrading and who's not, who's most actively engaged, and who needs to be engaged with more. We're looking forward to what you'll be able to achieve with the new data that we provide you.
Important updates to existing users:
1. We thought about this a lot, and we're removing custom statuses. Previously, you could add and rename as many statuses as you want. After analyzing the statuses created, we found that custom statuses were being used the way the tags are meant to be used. And having everything customizable was blocking us from making any kind of automation to the workflow. So we've decided that we will stick to only three statuses: New, In-progress and Closed.
To make sure that we don't disturb your already existing workflow, all previous statuses were automatically added as tags to the issues marked with those statuses. This change will allow us to do two important things: First, adding more automation to the workflow to make you do less (i.e. marking an issue as "In-progress" when someone replies to it). Second, we're allowing the use of tags everywhere (you can now create Smart Filters with these tags).
2. We're introducing App Mode. We found out that many of our users create two separate apps, one for their beta build and one for their live build. There were two problems with that: First, users used to pay double the price per app, which was unfair. Second, users had to create their workflow twice for both apps! So moving forward, any app that's created comes with two modes: Beta and Live, each with different tokens but with the same app settings.
The question is how does this affect your current apps? All of the apps that you've already created will now have the two modes. If an app was already running on more than 1,000 devices, we moved it to Live mode. If it had less than 1,000 devices, then we moved it to Beta mode. If you need to merge any of these apps or have any questions about this, shoot us an e-mail at email@example.com and we'll fix it ASAP.