I personally use Crash Catch for my own projects to identify issues in other products and services that I create and in doing so I found some issues, some of which are bugs, some are usability issues and realised that the user interface is a bit clunky and disorganised.

Therefore, I’ve been hard at work doing a complete redesign of the user interface making it simpler and cleaner.

Before I get onto the visible changes, lets talk a little bit about the background changes. The web interface and API has been restructured significantly, this makes it much easier for me to be able to maintain and add features and fix further bugs as they are found as time goes on.

Background Changes
------------------

Some of the Crash Catch libraries have also been fixed (ReachJS, PHP and Flutter) have been fixed as some bugs were identified where it meant a crash might not get successfully sent. There’s also been some significant changes to the React JS crash processing as it was identified crashes could fail to be resolved and then cause the backend systems to get stuck for further ReactJS crashes.

If you aren’t aware, ReactJS crashes are sent in a minified state, so they are not human readable, at least not without manual work to decode it. When you create a new version for your project, you need to upload a new source map and when Crash Catch receives the crash, it uses the uploaded source map to decode the incoming stack and provide something meaningful that you can use to work out why your project through an error.

The way Crash Catch does this is two apps. One is the engine which hosts the crash submission API, validates the account details, submits the crash, does some other housekeeping jobs etc. There’s a second app called Stack Resolver which is a NodeJS server where the engine can receive the crash and then submit it to stack resolver which uses a third party library to decode the stack. There was nothing wrong with the 3rd party library, but I was fairly new to creating a NodeJS server and it was that, that was causing the problem. For example, if a crash was received but there was no source map, the stack resolver would get stuck and the thread within the engine waiting for a response from Stack Resolver which then meant further processing of ReactJS crashes got stuck and they would just end up in a decode queue and wouldn’t get processed.

To get round this, the Stack Resolver app was completely rewritten and retested to ensure failures within stack resolver don’t affect the engine.

Visible Changes
---------------

The entire frontend has been completely rewritten, making it simpler, easier to follow and the page being less cluttered.

Lets start off with the dashboard you were shown after the login. This page was probably the most cluttered and complicated layout. Instead you are now shown the project dashboard. A screenshot of this is shown below:

![](/api/images/93)

Project Dashboard

The project dashboard, as the name imples, shows you all of your projects in a card view. This shows you the number of errors that have occurred in the last 24 hours for a project along with a bar chart to show you how many crashes have been received through different time intervals within the 24 hour period.

When you click on a project you are taken to the project dashboard, this is a little bit like the original dashboard on the old version, but specific to your project and simplified layout. An example of this is shown below:

![](/api/images/94)

Project Details

This page shows you the number of crashes, how many different users have been affected, a breakdown of the different statuses as well as a line graph showing you the crashes received, and how many active users your project has received over the selected time period.

Under this is a breakdown of the handled vs unhandled crash counts along with a breakdown of the different severities of issues that your project has received.

Under this is also a table of all the different issues that your project has, this is the same as under the issues page as shown below.

On the left hand side is a link to the issues page, this shows you all of the crashes groups that have been received by Crash Catch for all of your projects as shown below.

![](/api/images/95)

Issues

From this page you can filter the issues for a particular project and through a particular time period. You can see the number of incidents each crash group has received, and the number of affected users of the crash group as well as who it was assigned to and the ability to assign a crash group to a member of your team.

When you click on an issue title, you are then taken to the details page, where you can view all of the information relating to the crash as shown below:

![](/api/images/96)

Issue Details

At the top of this page, you can view the exception group, the exception message, whether the issue was handle or not and the severity.

Under this you can see when the issue first occurred and the issue last occurred, the total number of times the issue has been raised, the number of affected, the current status and who it is assigned to.

Under this is the ability to mark the issue as resolved or change to another state such as in progress, under review etc and another option to ignore this crash group. This allows you to stop receiving notifications for a particular crash group for all future occurrences, or stop receiving notifications on crashes for the current project version or below.

Following this are the individual incidents, when that particular incident occurred, the version number and the stacktrace along with the device details of this particular incident.

I hope that you find these changes to be a big improvement to the previous version. Crash Catch is still running as 50% off while in beta, when signing up you receive a 14 day trial no credit card required you can cancel at any time.

If you have any feedback, good or bad, then please let me know, either in the comments, or feel free to drop me an email at chris@devso.io.

Major Redesign to Crash Catch Now Now Available

I’ve been hard at work fixing bugs, making performance improvements, fixing screen layouts and improving the design over the last couple of weeks, but also adding support for a new Pro+ subscription.

Before I get on to plan, lets take a look at the visual changes of Crash Catch - mostly around the dashboard view that you see when you first login, although before we get into the details, you might notice in the screenshots (and if you are looking at this blog post) its now [Devso](https://devso.io/), instead of Boardies IT Solutions. As of January 2022 Boardies IT Solutions rebranded to [Devso](https://devso.io/), and you can find more information on our blog post at [https://blog.devso.io/boardies-it-solutions-becoming-devso-in-2022/](__GHOST_URL__/boardies-it-solutions-becoming-devso-in-2022/). Now that’s out of the way, on to the dashboard.

Dashboard Improvements
----------------------

This is a little embarrassing, but I only just noticed that the dashboard layout, especially on smaller laptop devices didn’t fit properly as shown in the screenshot below:

![](/api/images/84)

Original Crash Catch Dashboard on Smaller Screen

There were a couple of things wrong with this page. First of all, the time period options and the screen title in the header was pushed in to the main content, secondly, the scrolling was a little quirky as the whole page scrolled, but the then the project table and the recent activity scrolled separately which made the scrolling a little awkward.

This has been fixed so only the whole page scrolls so you haven’t got numerous scrolling areas which can get a bit confusing, and the layout has been improved to better support devices big and small, as shown in the screenshot below:

![](/api/images/85)

New Crash Catch Dashboard

Performance Improvements
------------------------

I also identified there were a couple of issues with things getting loaded when there was a large amount of data, so I’ve done some performance improvements with within the website itself, but also within the backend database so hopefully will notice improvements in this area, or when things are a taking a little bit of time, it nows shows that its loading so you’re not left wondering if something is happening or not.

Pro+ Plan
---------

On to the biggest news, the new subscription plan, Pro+, giving 4 different options to best suite your needs, Solo, Startup, Pro and Pro+. Pro+ is mostly the same functionality but brings with it data increases, such as the amount of crashes you are allowed to report and the data retention period.

You can now submit 1 million requests crash reports under your account per a month and have 12 months worth of data retention.

You can upgrade and downgrade at any time, and the Pro+ plan is available for £25 a month, but if you sign up now (or if you already signed up) you can still get the 50% off discount while Crash Catch is still in its beta release so this offer is for a limited time.

If you want to sign up or if you want more information then please visit https://crashcatch.com or feel free to get in touch with me in the comments or on twitter at [https://twitter.com/chrisboard\_](https://twitter.com/chrisboard_) or [https://twitter.com/crashcatch](https://twitter.com/crashcatch)

Improved Dashboard and Pro+ Plan Subscription for Crash Catch

I recently did a post about an upcoming migration for Crash Catch where its backend rewrite is complete and getting released along with some website improvements. More information can be found about what to expect by checking my previous blog post titled "[Crash Catch Backend Rewrite Release](__GHOST_URL__/crash-catch-backend-rewrite-release/)".

In the previous blog post it mentioned how the client libraries (the libraries that you can add to your projects to send crashes and errors to Crash Catch) will need to be updated.

The reason for this, the new backend crash submission is now JSON posted content, where originally it was form url encoded.

This will mean that any projects will need to be updated to ensure you main compatibility with Crash Catch. But don't worry, you don't need to update straight away I've maintained backwards compatibility. So, what I have done to ensure this, lets have a bit of deep dive into the previous backend and the new backend.

### Previous Data Flow and Architecture

The previous version of Crash Catch data processing engine, what I can the engine is responsible for the crash submission API, processing crash queues, sending email alerts, clearing old data etc. This engine was originally written in C++ and received HTTP request in form url encoded format, processed the crash and added it to an internal FIFO (First In, First Out) queue (I fixed that as well, which I'll talk about briefly later on) to then be processed and stored in the database. Below is a diagram showing the current data flow:

![](/api/images/79)

Current Data Flow

### New Data Flow and Architecture

The new backend is done in C# .Net Core which makes the build and release a lot simpler compared to using C++ and using the in built API instead of my own custom built HTTP handler as I had within the C++ engine. The .Net Core API prefers JSON as do most APIs nowadays use JSON over form-url-encoded hence why there's a requirement for the client libraries to be upgraded.

What I created to maintain backward compatibility is a small Python script that will receive the data from the Crash Catch client and check the HTTP request. This is what I refer to as the API proxy. It will check if the Content Type is application/json which if it is, it will just forward the request to the engine, and then return a response back to the client. If the Content Type is form-url-encoded it will then adapt the HTTP POST data to be a JSON object and update the HTTP headers accordingly and then forward to the engine. The new data flow is shown below:

![](/api/images/80)

New Data Flow

This API proxy is only a temporary connection to remain backwards compatible to give users a changes to update their projects to the latest version.

I'll make the new versions of the libraries available once the new release has been installed and will send out a notification email when they are available.

I don't have any timeframes as yet but the plan would be to remove this API Proxy at some in the not too distant future, I want to see how it goes first before I start adding a deadline and cause potential problems for existing projects.

### FIFO Queue Changes

As mentioned above, and shown in the diagrams, part of the engine rewrite was changing the crash processing queue. The reason for the queue is to ensure the API performs as quickly as possible, we don't want any slight delay in us processing the crash and storing the crash to cause a delay in the response, therefore putting that delay into your own projects and apps and services. The idea is the API will receive the crash, perform some basic validation and then submit to the query, and then return an HTTP response, hopefully HTTP 200 OK to say the crash was received, anything else, means the crash submission failed. Then a separate thread within the engine is polling the FIFO queue to do the nitty gritty grunt work of processing the crash and storing it in the database.

Although this never happened, I realised this had a fundamental flaw. If we received a crash and had several crashes queued up within the internal crash queue and the engine itself crashed all of those crashes would be lost, which I didn't like.

Instead what will happen is the crash comes into the engine, does the same validation check but instead of adding it to an in memory queue within the engine itself, it passes it over to Redis all of the details and again, a separate thread within the engine is looking for new crashes in the redis queue, pulls them off and processes. In this scenario, if the engine crashes, when it starts back up again, it will still have access to the submitted crashes in the queue and continue to process them.

Of course this is not completely fool proof, as Redis is running on the same local server as the engine and if Redis, or the server itself crashes or unexpectedly restart the engine will still lose the crashes that were in the queue, but I think this is less likely and I don't believe there's a way of avoiding this completely, apart from maybe a synchronised redis server but I think that's a tad unnecessary - at least at this stage.

So, there you have it, there's a little bit of background on the engine rewrite and what to expect upon the release of Crash Catch later on this month. If you have any questions or comments then please let me know, and as always if you have any feedback about Crash Catch, good or bad, then again please let me know.

Thanks  
Chris

New Crash Catch Libraries and Remaining Backward Compatibility

A while ago I did a blog post detailing the future plans of Crash Catch which included doing a backend rewrite. You can find more information on that particular topic by see the blog post "[The Future of Crash Catch - Converting the API to Laravel](__GHOST_URL__/the-future-of-crash-catch-converting-the-api-to-laravel/)".

This post will detail some of the improvements, and changes to the frontend.

### Backend Rewrite

You may not notice that much difference in terms of the backend rewrite, but from my point of view, it will make maintainability and implementing features and fixing bugs much quicker to implement.

The crash processing engine is now done in C# .Net Core instead of C++ which makes the build process and installation of that much easier, so it should take me far less time to implement features relating to the crash processing, such as adding new project types.

### Changes to Crash Catch Libraries

Due to the changes in the crash processing engine the way HTTP posts are submitted will be slightly different. The current engine uses form-url-encoded POST request, whereas the new backend uses the more common place nowadays JSON POST request.

This means that when the new version of Crash Catch is released there will be new version of the Crash Catch libraries for all available project types. But don't worry, we're maintaining backwards compatibility so you don't need to update straight away.

We will do another blog post on how we implemented this in the not too distant future, so watch this space.

Frontend Improvements
---------------------

Although the main purpose of this release is for the backend rewrite, I have also made some improvements to the frontend as well as detailed below.

### Performance Improvements

Overall there's been significant performance improvements over the frontend, this is mostly caused by me originally being a numpty. I didn't realise ReactJS and more specifically react-router-dom had a special <Link> component to change between pages, so I was using a normal <a href> which meant every link did a full window page reload instead of just switching the component. Changing this makes the Crash Catch website much more performant and faster at switching between various views.

### Form Changes

On the current version of Crash Catch, forms used to aggressively validate, e.g. as soon as you started typing an email address it would show a validation error and make the form resize and move various elements on the screen up and down as the validation error appears and disappears.

Instead on the new release, when you submit the form, the validation is then before and each text box is highlighted with the error message to show why the field was validated. This means you have a chance to enter information in, without being complained at, the first character and avoids the page jumping up and down.

![](/api/images/76)

Old form validation

![](__GHOST_URL__/content/images/2021/12/Sizzy--crashcatch.dev.local-01Dec-18.57.gif)

New form validation

### Billing Page Improvements

The billing page currently has somewhat limited functionality, all it provided was the ability to update card details and see your next billing cycle and your current plan. On the new version however, this is much more usable. You can easily switch between your plan, close your account, see the last 4 digits of your payment card and update payment and billing address details. An example of the new billing page can be seen below.

![](/api/images/77)

Billing Page Improvements

### When will the upgrade happen

Good news not long, you might have seen on our Twitter account that we scheduled several maintenance windows covering different areas starting on Monday 6th December 21:30 to UTC to 7th December 03:30 UTC.

This will cover the upgrade of Crash Catch to the latest version bringing these improvements and I can't wait to get this released and see what you think.

These changes to the backend of Crash Catch does result in a change to the libraries that submit crashes to your projects. Don't worry though, we've ensured backwards compatibility so you have time to update your apps and websites. We will be posting a new blog post soon with information about this change and how we're ensuring backwards compatibility.

Crash Catch Backend Rewrite Release

[Crash Catch](https://crashcatch.com) was released in March and have been I've been waiting for the day to get my first user. In case you are not aware, [Crash Catch](https://crashcatch.com) is our new crash monitoring solution for every developer, every platform and every programming language.

I almost got my first user a couple of months ago when someone signed up but didn't continue, unfortunately didn't get any feedback as to why - its annoying when that happens.

But towards the end of August I got a signup to the Pro plan with a new Android project being created and started receiving initialisations and crashes from their project.

This was the first real user and was delighted that everything worked without any issue (apart from a slight glitch in the backend not incrementing crash count quotas correctly, but it was in the users favour so wasn't a massive issue and was a relatively easy issue to fix).

Within a few days, they had processed 100,000 and hit their plan crash quota limit. This was more to do with that they left the test crash in place that is suggested during the project creation and released the app which meant everytime someone loaded the app, or went to a particular screen the test crash would be submitted.

I contacted the user a couple of times, one within a couple of days of them signing up, to welcome them and see if they needed any help or have any feedback and then another email to warn them about hitting the quota limit due to the test crash (offered to remove those test crashes so the quota was lower and they would continue to receive crashes but unfortunately never got a reply).

Towards the end of their trial I saw they had actually converted and submitted their card details for payments and I was ecstatic that I had my first user convert which gave me hope that although I haven't been marketing Crash Catch recently (due to some backend rewrites that were started before this user signed up - so not as a result of any issues - I did a blog post at about the reasons about this rewrite at [https://blog.boardiesitsolutions.com/the-future-of-crash-catch-converting-the-api-to-laravel/](__GHOST_URL__/the-future-of-crash-catch-converting-the-api-to-laravel/)).

But unfortunately I then got a notification from stripe that the payment was declined with the message "The bank does not support this type of transaction".

Shortly afterwards they raised a support ticket (not about the payment failure but something else) which I responded to but again no reply from them.

I contacted them separately stating the issue that I can see from Stripe regarding the payment and extended the trial by 7 days to give them chance to resolve but again no reply.

Then noticed they removed the original project, and created a new project for a separate Android app which received a few crashes - around 1000+ over the 7 day trial extension but unfortunately the trial period has been reached again and there's been no contact from the user unfortunately.

Therefore I think I've lost this user due to a bank issue outside of anything I can do, but again no feedback for improvements, what worked and didn't work etc.

Although I am at least happy, that although there's been no recent marketing, I had someone find Crash Catch, sign up and did convert to a paid user even if it didn't work out its a good sign, so hopefully once the backend stuff has been re-done and released, I can hopefully do a bit of a marketing push (pretty useless at marketing so that could be interesting) and hopefully have a bit more luck for any future signups.

At the time of writing, Crash Catch has processed **290,000+** devices and **17000+** unique devices.

If you want more information, or want to sign up to Crash Catch, you can visit [https://crashcatch.com](https://crashcatch.com) or feel free to drop me in an email at chris@boardiesitsolutions.com.

Crash Catch Got Its First Sale - Almost ?

Well, to be more precise, nearly two months but it was supposed to be after a month it was a bit later than I had intended.

Anyway, here is the update on Crash Catch, and unfortunately its a little disappointing. Crash Catch was released on 24th January 2021. At the time of releasing there was around 10-15 people that had signed up in early interest of Crash Catch but even after nearly 2 months, there hasn't been any signups, and the annoying this, zero feedback so I'm a little stuck as to if there's a specific reason or something that's missing or something else.

![](/api/images/66)

A week after the initial launch I put Crash Catch on [product hunt](https://www.producthunt.com/posts/crash-catch?utm_source=badge-featured&utm_medium=badge&utm_souce=badge-crash-catch) and over the course of the 24 hours since launching on product hunt it received 23 upvotes. This was relatively good, my previous crash monitoring attempt (CritiMon which was released on a bit of a whim) only received 2 or 3 upvotes from what I remember. But again, although it had been upvoted no feedback so again at a loss at how to proceed.

This is something I've never really understood about places like product hunt, why upvote something if you have no intention to use the product or service or provide any  feedback.

Below are the stats from [Plausible](https://plausible.io) showing visits to the landing page since it launched

![](/api/images/67)

One of the import things I believe about building a product is you have to use it yourself, and in doing so you can find little oddities or improvements that can be made that you might not discover during the build process, but when you actually start using it realistically instead of just testing, you can find little gotchas or improvements that can be made to the UX (user experience).

I'm therefore planning on doing some small improvements to some of the usability and navigation around the site. One of the main tasks to do next is to implement other crash reporting libraries starting with iOS. iOS was recently released and is now available, with the caveat that it can't do unhandled exceptions. We did a [blog post about the reason for this](__GHOST_URL__/crash-catch-ios-library-unhandled-exception-handling-or-not/).

The next library is Flutter. I've already had a look at Flutter and so far really like it and it looks like its going to be really easy to implement the library for Crash Catch so watch this space flutter developers out there ?.

After that, I want to focus on the user interface. Currently it doesn't support mobile layouts, its currently only been designed for desktop use. Although there is a plan to release a mobile app version, this will be quite a long way away so making the website is the best option. To do this however, I am going to remove bootstrap and replace it with [Tailwindcss](https://tailwindcss.com/). The reason being I only recently discovered T[ailwindcss](https://tailwindcss.com/) and find it much easier to implement user interfaces including for responsive designs than bootstrap, its much easier to customise and more user friendly, I've found bootstrap to be very verbose in comparison and tailwind is much easier to customise.

There's lots of exciting things to come in the future and I can't wait to see how Crash Cratch evolves and we hope you feel the same.

We are still offering 50% off the lifetime of your subscription if you sign up for any plan at [https://crashcatch.com](https://crashcatch.com).

Any questions then please let us know and if you have any feedback good or bad please let me know.

Chris

Month Update of Crash Catch ?

If you've been following me on [Twitter](https://twitter.com/boardy89) or the live streams on [Twitch](https://twitch.tv/boardy89) then you may be aware that I've been working on the iOS library for [Crash Catch](https://crashcatch.com), and you may also be aware that it hasn't been a particularly easy task.

Crash Catch currently supports Android (Java), ReactJS and PHP but before Crash Catch, was my initial attempt, CritiMon. With CritiMon I created crash reporting libraries for the following libraries - these will be ported over to Crash Catch in the not too distant future.

*   Android (Java & Kotlin)
*   PHP
*   Vanilla Javascript
*   C++
*   C# (.Net Framework and .Net Core)
*   Python
*   Ruby

All of these languages and frameworks were relatively straightforward and I could get basics working within a few hours, and get the library pretty much completed within a couple of days, even languages I hadn't previously worked with such as Python and Ruby.

Creating the iOS library, unfortunately has not been the same at all, its been weeks, if not more than a month to get this far and I'm not happy with the progress and that I am having to create this post, but here we are.

Unfortunately, although Crash Catch will now support iOS error reports from Swift applications, it will not receive automatic reports for unhandled exceptions, e.g. exceptions that trigger the app to actually crash and shutdown.

I've not previously done any iOS development so I can't 100% guarantee that what I am saying is correct, but from what all of the research and attempts I've made at creating this library, this is what I believe to be the case, however, if there are any experts out there who wants to advice, I'd be more than willing to hear from you.

How does crash reporting work for Crash Catch and iOS
-----------------------------------------------------

Lets start off with handled errors, e.g. errors that you catch yourself and report if and when you want to such as within try/catch blocks.

iOS and Swift seems to do this very differently compared to other languages that I've dealt with. Every other language I've dealt with the exception is basically a class that extends a base class, e.g. for Java, the base class is called "Exception" and you can have another exception type class such as "Java.lang.NullPointerException". Because each exception class is an extension of "Exception" the exception class, no matter what it is, can be provided to the Crash Catch Library where it can get the exception name (the class name) and the error message, as well as the stack from the exception.

Swift however, doesn't seem to work like this, at least I couldn't find any reference to an exception being part of a base class that I could access, and from looking at how other services do this, this does seem to be the case.

Therefore to report on a handled error, you need to know from your code an error condition where you want to report, this can still be within a try/catch however, but there is no base information from the exception object that Crash Catch can receive. Therefore, you need to create a CCException with the details you want, and then pass this to the library.

However, this doesn't include the stack and this brought a whole other set of issues.

There are methods within Swift, such as you can call [Thread.getCallStack](Thread.callStackSymbols)(), the issue with this is you get a mangled stack which is basically unreadable to a human, and if you did get a proper crash stack, this would usually just be list of hex addresses and/or mangled stack lines, and the stack would need to go through a symbolication process. In order to do this, you need access to a physical device in order to create an archive, and this creates what's called a dSYM file, and then there's a couple of commands you can use to symbolicate the crash report and return a human readable stack.

This had some issues, one this has to be done from a MacOS PC and the dSYM file would need to be uploaded. This wasn't too much of an issue, I've had to do something similar with ReactJS except there is there alot more information on that, Apple seemed to keep all of this information very secret. The next problem was all of the servers for Crash Catch run Linux, I was considering having to get a MacOS server to do this process, however, there's very little information as to the spec of the dSYM file, plus this process only really works from a crash report by the Apple App store reports, and not by me manually getting the stack programatically.

Thankfully I stumbled upon an open source project on GitHub call [RCBacktrace](https://github.com/woshiccm/RCBacktrace) which provides me a demangled stack that I could retrieve and process to give me the information that I need for Crash Catch, such as the class file and the file and the method that triggered the error.

So that was the start of the issues I was having in getting this project done. Next step was unhandled exception reporting.

This is where I hit a massive brick wall. Most languages I've used have some sort of listener that you can register for catching and then handling unhandled exceptions, i.e. exceptions that you have not caught yourself using a try/catch method.

I didn't make much progress in this regard, but this was mostly because finding information as to how this is actually done was next to impossible. Every article I found (and there was several regarding people asking the question about making their own crash reporting service) was just don't do it. Most of them saying its a bad idea, its next to, if not actually impossible to implement correctly, likely not to be able handle certain critical failures.

Due to this, I've made the difficult decision to not implement this specific area and instead, you should rely on the Apple App Store crash reports for unhandled exceptions, but Crash Catch can be used for bugs within your code where you can report on specific issues that you catch yourself within the code.

I want to ensure that Crash Catch, and what is offered is the best that it can be, and yes I know there are other services that claim to be able to report on unhandled exception, and I am only saying claim, because I've not tried it, or know whether it works 100% of the time, therefore I don't want to implement something where its not guaranteed to provide the service that you are expecting.

I hope to revisit this in the future if possible and see what options might be available, but in the meantime, I hope you understand the reasoning behind this and this doesn't put you off from using Crash Catch.

Crash Catch is still currently in beta, and we are offering 50% off the lifetime of your subscription if you sign up, and if you don't like it, you can cancel your account at any time.

You can sign up at https://crashcatch.com.

If you have any questions, or advice, feel free to leave a comment here, email me at chris@boardiesitsolutions.com or you can DM me on [Twitter](https://twitter.com/boardy89)

If you've been following me on Twitter or the live streams on Twitch then you may be aware that I've been working on the iOS library for Crash Catch, and you may also be aware that it hasn't been a particularly easy task. 

Devso Blog

Tagged