Despite enthusiastic use of Bugsee for Chrome by many of our customers over the past six years, we’ve found that there hasn’t been as much demand for this type of service as we anticipated. The Bugsee team is committed to providing world-class bug and crash reporting products for mobile apps. Mobile will continue to be our sole focus moving forward. We apologize for any inconvenience. If you have questions or thoughts about this transition, please feel free to read the FAQs below.

The user experience is golden. Without the user, a mobile app cannot succeed. This is why it is important to ensure bugs do not drive users away.

Bugs ruin the user experience and damage the developer’s brand. Users with low patience and high standards are quick to leave nasty reviews and uninstall. Additionally, in an effort to protect their users, the App Store and Google Play Store will reduce an app’s rankings if it has too many performance issues. Ultimately, bugs can sabotage an app’s success. Thankfully, with Bugsee, developers can protect their user experience and increase their chances of succeeding.

If you’re new to app development in Android, file upload might appear like an uphill task. But in reality it’s just two things -- requesting permission to access the sdcard/camera, and then making API to upload the files. Unless your requirements explicitly ask you to manipulate the files or optimize them in some way, things are fairly straight forward. In this post, we’ll talk about some of the common challenges and some of the best practices to rectify those challenges while creating a file uploader in Android.

You probably wonder whether you need Bugsee and is it any good? Well, let me try to address these here.

VIDEO

Have you ever wondered how your users get to a certain state in your app? Have you ever tried to recreate an intermittent bug? As developers, we deal with these types of issues on a regular basis. That’s where Bugsee can help.

In this article we will see how to manage builds for Swift projects, examplified with PackStream, through Jenkins, an open source build server. We will build it for iOS, macOS, Linux, watchOS and tvOS, and make sure it builds both through the Swift Package Manager, Cocoapods and Carthage.

This tutorial is a revised tutorial we've published earlier, called iOS Ad-Hoc distribution using Amazon S3. The original tutorial achieved the desired effect using s3cmd and a bunch of bash scripts. However, since its publication, Fastlane gained a lot of popularity and gathered quite a following around it, including the ecosystem of plugins. If you are not familair with Fastlane, you should definitely spend some time to get familiar with it, and see how it can help you automate your iOS and Android builds. In the following article we will only focus on one specific task - creating an Ad-Hoc distribution on Amazon S3, and will use one Fastlane plugin for that purpose, called aws_s3.

Debugging is an important process to understand the unexpected behaviour of your application. For this reason, we must know well how to use the breakpoints to reduce the time needed to fix the bugs. Sometimes, a simple breakpoint is not enough.

In this article, I'll explain the main advanced options and generic breakpoints available in Xcode—version 8.3.2 at the time of writing.

We have already covered why certificate pinning in mobile apps is important and have shown how to implement it both in iOS and Android. For the sake of simplicity, we had to omit a lot of nasty details and corner cases from our example. In the real world, the code might get complex with time very quickly, when you have to support various legacy iOS platforms, various popular networking libraries out there etc. Luckily, nice folks at DataTheorem have created and open-sourced a framework for SSL pinning which eliminates that simplifies most of it.

In this day and age more and more user data is stored electronically. Users are expecting end-to-end security from every application they are installing on their devices. Application developers too, are seeking to secure all communications between their apps and backends in order to prevents hackers from reverse engineering their protocols and getting access to their databases.

The most basic form of security when transferring data between the application and the service backend is SSL/TLS encryption, and it is very common for developers today to switch their traffic to https and declare their communications as secure. In fact mobile platforms today make it really hard for developers not to use https. That by itself, however, is not enough. Encryption is useless when communicating parties can not validate the identity of their piers.

While the need to listen to scroll events of arbitrary views in Android has always existed, no such mechanisms were provided by Google until Android API level 23. That is when View.OnScrollChangeListener made its appearance. Until then, some views (e.g ListView) had custom mechanisms to listen to scroll events, but there was no common way. We, at Bugsee, have faced this problem while working on automatic concealment of protected web page elements (see Bugsee Privacy). We had to know when elements change their position, and no such mechanism exists for WebView for earlier Android versions.

Most of the mobile applications these days require some form of a backend. Usually it is used for something trivial, like maintaining user profiles, settings and scores etc. However, most often than not, the application needs to upload some files to your server. The following tutorial will show how to do it securely and efficiently using AWS S3. Why spawn powerful servers that can handle huge amounts of traffic when all they do is get the files and store them on S3 anyway? Files can be uploaded to S3 directly, and S3 infrastructure can scale with our application and adjust to the amounts of traffic required. All we need to do is implement a simple lightweight API endpoint that will instruct the client where to upload the heavy things and let S3 do the heavy lifting.

Remember how we said your Swift or Objective-C code is compiled into ARM pr x86 machine code? Well, that is not entirely true. Before producing actual machine code, compiler first creates an intermediate representation of the code called bitcode. It is not your code, bot not yet a machine code either.

I’m thrilled to announce that Bugsee is on Product Hunt today. Can’t wait for the Product Hunt community’s feedback and thoughts.

Why Today?

Last year we won the #1 crash reporter award by CrashProbe — the ultimate benchmark for mobile crash reporters. And that’s before our video, network and logs leading up to the crashes. And therefore, we’ve decided — it’s time!

Bugsee can officially be called The Best Crash Reporting tool for iOS. Bugsee marks higher than the competition in Crashprobe, the ultimate crash reporter benchmark.

Crashprobe benchmark was developed and is maintained by HockeyApp (now owned by Microsoft), it is open source and available on Github. The test suite consists of 44 tests (22 different crash types that have to be tested both on armv7 and arm64 platforms). The results of each test are judged by completeness and accuracy of the produced report. Crashprobe also has a straightforward submission process for other reporters to submit their results. That we did. And after a quick validation of our results by the Crashprobe team, we made it to the first place!

In the previous post, we've learned what is symbolication process and why it is needed. In this post we will dive deeper and learn how to make sure a dSYM file is generated and see how we can manually use it to symbolicate crash reports.

How do I make sure dSYM is actually being generated?

XCode has several settings that may affect dSYM generation, let's review them one by one.

First of all, let's make sure that debug information is being generated:

Many developers use Bugsee for its great crash reporting capabilities. In fact, Bugsee crash reporting has recently been ranked the highest among all iOS crash reporting services when it comes to accuracy and the amount of details in the report. Bugsee doesn't stop there, however, it also presents video of user actions, console logs and network traffic that preceded the crash.

In the following series of posts we are actually going to focus on the crash log itself, explain the magic behind it and show how to properly set it up.

We’ve achieved an important milestone last month — Bugsee joined the One Comma Club, as more than 1,000 companies had signed up for Bugsee since our start just this April. Coincidentally, we believe we’re ready to graduate from a free product to a paid service.

When we’ve started, our goal was always to make the service as frictionless as possible. It manifests itself in the vast feature set Bugsee delivers to our customers by adding just one line of code. You don’t need to think ahead of time what info you might need when you debug the next bug or crash.

Back a few months ago, we’ve sponsored a couple of Core Intuition podcasts to both support the fine work Manton Reece and Daniel Jalkut do for the developer community and to get the Bugsee word out.

Since we’re new to the sponsorship game, we didn’t really know what to expect.

At first, both Manton and Daniel signed up to Bugsee to try out the product before the first sponsorship aired. So we got two super cool customers right on the spot (that was before we announced our pricing, so both of them got special early adopter deals).

Then the episode aired with a super positive conversational narrative about our service. This is unique, as most other sponsorships will just read your message as is, which usually doesn’t sound as nearly as appealing as what Manton and Daniel do.

Back in early September, Lyle Troxell from GeekSpeak invited Dmitry and myself to his ad-hoc studio at Netflix in Los Gatos to record an episode for his podcast.

Interestingly enough, we didn’t realize we were actually going to do the recording then. We thought we were just meeting Lyle to discuss a future interview. Imagine our surprise, when we walked into a regular Netflix conference room and saw Lyle setting up his recording equipment.

We had a fantastic time chatting with Lyle. We covered a wide variety of topics. We started with the importance of titles in a startup, then went to talk about our early days working in embedded space with cameras, DVDs and phones. Then talked through our previous adventure and how it eventually, with a bit of help from Goldman Sachs, led us to the birth of Bugsee.

Hello world!

Today, we are introducing Bugsee corporate blog, ran by our engineering team under the helm of our CTO, Dmitry Fink.

We plan to cover a wide variety of technical topics about iOS, Android, browser plugins, web front-end and back-end development and deployment.

We will also write here about Bugsee news and updates, as well as, feature our customers’ and friends’ guest posts.

If you wish us to write about a certain topic, please let us know at support@bugsee.com.

Applications today are rarely being built without 3rd party libraries and SDKs. There are libraries for integrating remote backends into your app. Libraries for effective image caching and loading. Libraries for gathering analytics and libraries for pushing messages. Libraries that help your users report issues, help you debug and analyze crashes. (Yes, that last one is Bugsee)

It is also a common practice for developers to maintain more than flavor of the application during active development. A debug version of the application may require a new version of the backend server which also might be under development still, it might send analytics data to a different service or it may need to include a helper library that is not necessary in the release version.

This following tutorial describes several options for maintaining different build configurations.

Every iOS developer at some point in their life is challenged with a task to distribute their awesome app to a group of loyal beta testers. Apple does not make it easy. The reasons for this are clear. We all care about security and greatly appreciate the fact that iOS platform is much more secure than its main competitor, but it is still a problem that needs to be solved. There are services out there that try to automate the ad-hoc distribution process, but sometimes it is not desirable or even possible to use them. Thus, there is a need to bake an in-house distribution system.