Mobile enterprise has climbed the summit, literally and figuratively, and can now be found in your local retail store, school or ski resort. I have personally been to Copper Mountain several times, and it is easily my favorite ski resort in the Summit County area. So when I recently stumbled upon an article about how Copper Mountain utilized rugged to empower staff, I was very interested. I was most impressed by the challenges the developers had to face for this mobile deployment: extreme temperatures, extreme elevation, rugged terrain and a sheer volume of 10,000 scans per day. In the world of software development, releasing is only half of the journey, and supporting apps in the enterprise realm presents its own unique challenges and opportunities.

Today we are going to discuss how you can make supporting enterprise applications as a developer less frustrating and more productive.

The Humble Crash Log

As any developer knows, a crash log and its accompanying stack trace are one of your best allies. Reviews, user comments, etc are nice, but they are not always very informative sources. A crash, however, gives it to you straight. While crashes can be frustrating when they show up unannounced—especially from an app in production—the crash log’s honesty is what sets it apart from the aforementioned less empirical sources. Being able to log into iTunes Connect, Google Play Store or The Windows Store and fetch these logs is crucial to tracking down and fixing bugs for apps that are deployed to their respective store. However, in the enterprise world, most apps are not deployed to the store which removes the easy access to the crash information that developers need.


iTunes Connect even provides fancy graphs on your crashes.

Saving Trace 

Luckily for mobile devs in the enterprise arena, all hope is not lost. There are several workarounds and tools to help you get access to these stack traces. In the early days of mobile, developers were limited to using remote logging to track their exceptions and crashes. While this was better than nothing it certainly was not an ideal solution. To begin with, you would either need a server setup to collect these crashes or have your app create a crash report then prompt the user to email it to you. Clearly neither solution is elegant.

The former requires extra work on the developers’ part, while the latter badgers the users. Eventually services such as Hockey and Testflight(now part of iTunes Connect) started to pop up which automated much of this work. They enabled developers to push beta and enterprise builds that reported their crashes to an easy-to-access service that allowed the developers to see their crash reports. These services even started to include remote logging options. While these tools are very useful, they do have their shortcomings. Not every bug can be found in a crash log and crash logs only tell part of the story.

The Rest of the Story 

One of the more frustrating parts of deploying and supporting enterprise apps from the developers’ perspective is the crashfree bug. Sometimes users or employees will simply say that the application does not work and naturally everyone looks at the dev team. As a developer, if we do not have any crash reports then fixing the issue can be very challenging. Sometimes it can even be impossible.

Consider a retail store using an app for inventory management. If an access point in a store’s wifi network goes down the only symptom a user might see is the application failing to pull up information on an item. This frequently results in a call to the developers, causing them to chase a bug that they cannot reproduce. Also consider cases where new app updates are given out and several users experience shortened battery life or poor device performance. Sadly, there are no crash reports to help dev teams address these issues, but with a bit of ingenuity and patience, or the use of the right tool, these issues can be fixed before the dev team is sent on a wild goose chase.

Take a Walk on the Wild Side

When developing for the app stores, there is a nice, safe path set out for developers to follow. We pay our yearly dues, collect our crash logs, and follow the rules to the letter lest we have our apps rejected. In the enterprise world, though, some rules can be bent and others can be broken.

To begin with, collecting detailed device data unusually involves the use of private libraries, which is enough to have an app rejected from the app store. But, if we are not going to be submitting our apps to the store, why not consider using these private libraries?

For example, information on an iOS device’s battery cycle, installed applications, current connections to outside servers, current active application, and connection state, including access point and signal strength, is available if you are able to find it. (Alas, this post isn’t the best way  for me to go into too many details about finding this information, but for anyone feeling adventurous here is a start: iOS Runtime Headers. This little gem of a repository contains updated headers on the iOS frameworks, including the private ones. However, these headers are simply providing method names with little to no context on their expected arguments or return types, so lots of patience and trial and error is needed.)

Shameless Sales Pitch

If you are not the adventurous type you can still gain access to useful metrics through a third party app or library such as Optiko. Optiko gleans detailed system level metrics from your user’s devices, and therefore takes some of the unknowns out of bug fixing. Armed with detailed performance metrics, you can be sure that you are not spending time attempting to fix issues that are not actually software-related.

Fancy Optiko Graphs


optiko graph2