This is a little update about the progress of CritiMon for our next release, specifically regarding our official Apple iOS (iPhone and iPad) library.

Unfortunately this post is a bit of a bad news post, at least bad news for now. Last week (Saturday 5th) I retweeted a Twitter post from my personal account from the Boardies IT Solutions Twitter account as shown below.

This might be a small clue as to what library we'll be adding to https://t.co/i01UvuhFru on the next release ? https://t.co/Q2v6mrNZqa

— Boardies IT Solutions (@BoardITSolution) October 5, 2019

We also did a post saying we're working on a new version of CritiMon that includes many changes, but also adding support and official libraries for Ruby and Python. As we support many commonly used programming languages and platforms, including Android, it made sense that we also supported Apples iPhone and iPad devices and this was our intention, hence the tweet above where we bought a second hand Mac Book Pro in order for us to develop the library as unfortunately to build for Apple, you have to use an Apple device as a development machine (I use Windows). So you are aware, I have not done Apple development previously, to be honest, I'm not a huge fan of Apple and not used any of their devices in the past so this was a bit of a learning curve. Therefore, if you find what I say below is wrong, or there's ways around my problem, then please feel free to get in touch.

I progressed fairly well and got the library to Initialise with the CritiMon service where I then started working on build the crash data so that it can be sent to CritiMon, and it was here where I hit the problem.

It started with getting the stack trace. With the other languages I've done this for, the Stack trace is then parsed to get the class/file name and the line number that triggered the exception. In every language I've done this it was pretty straight forward and only in C++ was there a little bit of a difference to get it into a human readable format. However, with Swift (the programming language for iOS) this wasn't the case, as shown in the example stack trace below.

0 TestApp 0x000000010de45519 $s11Lib0aB0C9sendCrash9exception8severityys5Error_p_AC8SeverityOtF + 1449 1 TestApp 0x000000010de42185 $s15TestApp14ViewControllerC16sendHandledCrash6senderySo8UIButtonC_tF + 2053 2 TestApp 0x000000010de423f4 $s15TestApp14ViewControllerC16sendHandledCrash6senderySo8UIButtonC_tFTo + 68 3 UIKitCore 0x00007fff47163d19 -[UIApplication sendAction:to:from:forEvent:] + 83 4 UIKitCore 0x00007fff46b55599 -[UIControl sendAction:to:forEvent:] + 223 5
UIKitCore 0x00007fff46b558e3 -[UIControl _sendActionsForEvents:withEvent:] + 398

As you can see from the above, that isn't actually human readable and doesn't really tell you where the exception occurred.

From a bit of a Google, I found that in order to make it readable you have to "symbolicate" the app. This involves updating the build settings so that it doesn't strip symbols and that it used Dwarf and dSYM format.

From what I understand the dSYM file is used to parse the symbols from the stack trace into a human readable trace, therefore, in order for this to work, this dSYM file would need to be uploaded to CritiMon and then CritiMon would then be able to use this file to create a readable stack trace. This is where the problem begins. First of all, just building the app doesn't generate the dSYM file, instead to do this, you need to create an archive of the app, and the archive then creates the dSYM file. Unfortunately, I only bought a mac book, and relying on the iPhone simulator to test the library. Unfortunately, if you are only using the simulator, you can't generate an archive, therefore I haven't got access to the dSYM, in order to create the archive, you need to have a physical device connected in order for it to be done, hence the problem.

What's Next

Unfortunately, due to the above reasons, I have taken the difficult decision to not add support for Apple iOS, for now, and I can't stress that enough, it is definitely a temporary measure.

The reasoning behind this is currently CritiMon is very new and in a beta release while we iron out issues and add features as and when they are requested. We also, as yet, aren't making any revenue from the service, so currently I've self funded the project including the Mac Book so therefore I don't really feel that it is feasible to spend even more money on a platform who might not have demand as iPhone developers may prefer something else for all I know, if the project ultimately fails.

The plan is, if at some point CritiMon does generate enough revenue, and/or if there is a high demand for iPhone/iPad support we will look again into adding official support.

Of course, if you do want to send crashes from your iOS device, there is of course the option to do so using our custom crash API and if you let us know we'll add a link to our website.

Of course, if you want to work with us in order to put together an official library to support iPhones and iPads, we will of course consider this as well. We unfortunately wouldn't be able to pay you however, but if you wanted an account for CritiMon we would provide you a lifetime pro account for free.

So what about the next release?

I'm glad you asked, this is of course still planned to be released within the next couple of weeks all going well. We'll keep you updated on our Twitter account. The release will include official support for Ruby and Python which is done and all working with the CritiMon service but there's a couple of other things that we need to do first such as update screen shots, re-create promo video and update the landing page.

I will of course keep you up to date with the progress of the next release and I can't wait to see what happens next.

If you have any questions or issues, then please feel free to drop us an email at [email protected], or if you want to sign up to CritiMon you can create a free account at https://critimon.com.

Chris Board
Founder/Developer
https://boardiesitsolutions.com
https://critimon.com