The truth of life of a Quality Assurance engineer is there will always be edge-cases developers might have missed in the process of creating an iOS app, the result of which are unwanted bugs.

To help our QAs fight the nasty pesty little bugs, we’ve created the bug-reporting iOS library Bugsnatch.

That’s where QA engineers come into play, their sight set on snatching and exterminating those bugs early on.

Having identified a bug, a QA engineer should have an intuitive and easy-to-use method of reporting it back to the developer. At Infinum, we’ve tried multiple approaches to this, and stuck with the one we’ve created – the Bugsnatch library.

In most companies, QA engineers use some project management tool to create a task describing the encountered problem.

In addition to that description, the task usually contains some kind of boilerplate device and app info, including summarized debug information. That helps developers narrow down and pinpoint the problem’s root cause. If you want to become best friends with developers, learn how not to suck at writing bug reports.

All things considered, it could take an experienced QA engineer up to a few minutes to extract and write debug info by hand in the bug report, and it isn’t just a once- or twice-a-day occurrence. This means engineers spend a lot of time writing instead of testing.

Bugsnatch collects all debug info and empowers QA engineers to send it via email with just a few taps. In addition to the email version, there is a version of Bugsnatch which automatically syncs with the project management tool Productive, which we use to keep track of all the work at Infinum.

Productive keeps all of the company’s business processes centralized. From resource planning and project management, to time tracking, organizing sales and profitability monitoring.

It’s also the place where QA engineers create tasks to share information about discovered bugs to developers. Let’s see how Bugsnatch helps them.

The main feature of Bugsnatch is extracting debug info from your apps. It covers the basic application and device info, such as:

To see the basic setup for the email version of Bugsnatch in AppDelegate in action, check out this example:

Now that that’s done, you’re ready to go snatch some bugs.

Some projects require additional debugging info, e.g. the type of user (guest or registered), user’s country or some other user setting. We’ve thought of that, which is why Bugsnatch features support for adding extra debug info dynamically.

To use it, all you need to do is conform to BugsnatchExtraDebugInfoDelegate and implement the computed property called extraDebugInfo.

An example of how to do this can be seen here, in the AppDelegate extension:

If you don’t need any additional debug info, just leave out the extraDebugInfoDelegate argument when initializing BugsnatchConfig, and you’re good to go.

While your app is running, Bugsnatch can be triggered by any one of the available triggers at your disposal.

When configuring the Bugsnatch configuration, simply choose which trigger to use, since Bugsnatch comes out of the box with two kinds of triggers:

If these are not your cup of tea, you can also create custom triggers, or trigger Bugsnatch directly from your code when needed.

To create a custom trigger, you will have to conform to the Triggerable protocol, which requires implementing a delegate of TriggerDelegate type.

Declaration of Triggerable protocol can be seen here:

That way, when you want to trigger Bugsnatch, the custom trigger should just call the delegates’ didTrigger() method.

Here you can see how it looks like for ScreenshotTrigger implementation:

An important feature of Bugsnatch is the possibility to use screenshots of your application when snatching bugs.

In the email version, screenshots are automatically attached to mail for quick dispatch.

In the Productive version, Bugsnatch automatically saves the screenshot to the device. The captured screenshots help reproduce a certain bug later on and make debugging sessions easier.

Bugsnatch contains labels and buttons with hardcoded text values. By default, these are displayed in English. If you need more language options, we’ve made this easy by supporting String localization.

When configuring Bugsnatch, you can change the String values for every label and button that will be displayed when starting the Bugsnatch library.

For supporting localization, simply pass BugsnatchLocalizationConfig with your own data as the localization argument when initializing BugsnatchConfig.

Here you can see a simple example of changing two values:

If you set up the email version, triggering Bugsnatch launches the native iOS email-sending form. The subject is filled with an auto-generated title, the text body is filled with debug info, and the screenshot is attached automatically.

The only thing left for the QA engineer to do is to fill in the recipient’s email address, and optionally, add further explanation of the bug.

In case the Productive version is set up, triggering Bugsnatch launches the Productive web page for creating a new task in a web view. Debug info is then automatically entered in the task creation form, and all other information related to the task, as well as the screenshot saved to the device, can be manually added.

So, now you know about Bugsnatch, a simple but effective iOS library which helps QA engineers identify as many errors as possible and save precious minutes. It proved really useful in many of our projects and we are already exploring ways to expand and improve it.

We’re excited to share it with the community, so please test it and feel free to share your improvement suggestions!

Are you a mobile developer and always wanted to visit the Swiss Alps? There’s a great way to combine these two seemingly unrelated things! I just came back from App Builders, a conference for iOS and Android developers.

The 2019 edition took place last week in Lugano, and I felt inspired to write a quick recap from the perspective of an iOS developer.

This year’s conference was held in Palazzo dei Congressi. The venue is located in the center of the city, on the shore of the lake by the wonderful Parco Ciani. The park combines the experience of staggering views over the lake, colorful flowers, friendly ducks and swans, the sound of birds chirping, and fresh Alpine air.

There were roughly 400 attendees and 25 speakers. Lectures were mainly split into two tracks – iOS and Android, and they were held simultaneously in two conference halls. Some talks were not platform-oriented; they were concerning software, technology, and business in general.

There was delicious food, coffee, and other refreshments. Conferences tend to make people hungry, right? An official after-party was organized after the first day; a great opportunity to meet fellow mobile developers and mingle over a few beers.

There were many great talks. I’ve decided to cover some which I found the most interesting. Remember, I’m an iOS developer, so no Android, sorry.

Scott Chacon is one of the founders of GitHub. Now, he’s CEO at Chatterbug, a venture he also founded. He provided useful business tips stemmed from his experience as an entrepreneur.

1. Use your product and care about it. He has been a GitHub user ever since he started it. Apparently, everyone at GitHub uses GitHub, even lawyers and finance teams. Scott remarked: Airbnb founder Brian Chesky rented his own apartment on Airbnb so he could understand his own product better.

2. Listen to your customers. Make it easy for customers to give feedback. Don’t ever reply with a no-reply email, it removes the possibility to give feedback. For example, he had a problem with Dropbox Paper, he sent a bug report and got back a no-reply and couldn’t follow up on it.

3. Augment human beings instead of replacing them. He gave a brilliant example of customer service that bots can’t replace. It goes: “Name a profession and I’ll tell you how computers could make humans better at it, not how you could replace human beings with technology”.

Guilherme Rambo, an iOS developer, and a 9to5mac author talked about privacy and security. There’s a heated debate on privacy in tech so I found this lecture quite interesting. Rambo presented key aspects and techniques for preparing iOS apps with user privacy in mind.

He talked about how developers shouldn’t ask for permission until specific data is needed within the app. The key takeaway here is that transparency is important – always be honest with users, and tell them how and when you plan on using their data.

There was a word on external SDKs and how developers need to be careful with using them. It’s a developer’s obligation to know how an SDK uses user data. Apple’s CloudKit was mentioned as a good practice for storing user data, for example for saving names.

He talked about how transparency is important and what are some best practices to explain privacy implications. Users should be given the control to disable analytics, access their data, and an option to remove data. For us Europeans, that’s standard GDPR stuff, but it’s a set of good practices worth restating.

Soroush showed us how to use Swift protocols to abstract behaviors with an example of a network manager class. He taught us that we should be refactoring common structures, not common blocks of code.

Nicolas and Joseph from Ubique gave an interesting lecture regarding sharing code between platforms. They showed us how to share C++ code with the help of Djinni; Java code using J2ObjC and Kotlin/Native code which has LLVM backend and runs natively on iOS. They also pointed out the advantages and disadvantages of each approach and code sharing in general.

Cecilia from Spotify had a great session with a similar topic as the aforementioned one. She showed us how to add support for non-Swift libraries and explained how communication between C, C++, ObjC, and Swift works. She showed how to add dependencies and wrappers for supporting non-Swift libraries.

Brandon from Point-Free talked about some problems regarding Swift protocols and how to solve them. He showed the process of de-protocolization: conversion of a protocol to a struct using protocol witnesses.

Lugano is a beautiful city. If you have some spare time, you should spend it embracing nature. You can take a walk on the city’s lake-side promenade. I would recommend taking a boat trip and exploring the lake. You can take the funicular to the Monte Bré or the Monte San Salvatore.

I definitely recommend it. It’s a complete experience, a great mix of education, and a beautiful location with an opportunity to meet developers from around the world. Did I mention the Swiss chocolate?