Logging is an essential part of just about any PHP-based application; whether in a script or a larger application. However, how little is too little and how much is too much to log? If we don't log enough information, when something goes wrong, as it invariably does, then we won't have enough information available to determine what went wrong so that we can fix the problem. However, if we have too much information, then we'll be unable to filter out the white noise.

Many of us have experienced the feeling of hopelessly digging through log files on multiple servers to fix a critical production issue. We can probably all agree that this is far from ideal. Locating and searching log files is even more challenging when dealing with real-time processing applications where the debugging process itself can be extremely time-sensitive.

Welcome to the winter Bugfender newsletter. We hope you’re feeling refreshed after the holidays. We’ve had a fair few updates in the last quarter that we’d love to share with you to kick start the New Year!

Whenever I meet an engineer and chat with him about Bugfender, one of the questions I get asked most often is: what does it take to build a log aggregation tool like Bugfender? What’s behind it? When processing millions of log lines per day for several thousand users, coming from millions of devices, good architecture is key to enabling uninterrupted high-speed processing and growing the platform as new users sign up.

When you start a new project, everything is very easy and agile. You can develop, commit code and publish new versions quickly, without much testing. You probably don’t have a QA team, your test data is similar to your production data and you don’t develop multiple features at the same time. But as the project grows, it starts to become more and more complex.

When Apple introduced SwiftUI back in July we immediately knew it was going to generate a lot of expectations. As app developers ourselves, we are very aware about the complexity of User Interface development in iOS. UI has been keeping apps especially expensive and error prone along the years. Many frameworks were created to improve this situation like ComponentKit, Texture or even React Native.

It’s nearly five years since we started Bugfender as an offshoot of our software company Mobile Jazz. We’d gotten tired of chasing users who were experiencing problems with our apps and wanted to build an internal remote logging tool that would feed the information straight to us. It really was a garage project back then. We were running code sprints on our own time, so we wouldn’t have to dig into our savings. But we soon realized this could be much more than an internal experiment.

This month we have released one of our biggest UX updates since Bugfender 2, the new viewer. We are quite excited because we have been working on it over several months, we hope you like it!

Conditional Breakpoints and their variants, Exception and Symbolic Breakpoints are powerful tools for advanced debugging, applicable to both iOS and Android. We’ll explore them in this article. In the first post of our How to Debug from Zero series we learnt the basics of breakpoints. At this point, you should know how to add a new breakpoint and how to use the “step over”, “step in” and “step out” commands.