When History Repeats Itself: Is Apple the new Microsoft?

By | Enterprise Mobility

Let me first start by saying I am one of the biggest Apple fanboys that you’ll ever meet. I have probably bought every Apple product they’ve offered more than once in the past decade.

As a developer, iOS is one of my favorite platforms to develop on. The consistency of the devices, paired with Apple’s focus on the user experience made the iPhone the go-to mobile platform for app proof of concepts and initial mobile releases for start-ups.

Although Apple makes awesome hardware, their software and service releases have been less than stellar. Do you remember Ping, mac.com or me.com? Me neither. Raise your hand if a failed time machine backup resulted in the loss of important information. <<hand raised>>

The Death of Windows Mobile

I have spent the last 15 years implementing enterprise mobile solutions for Fortune 500 companies. As part of this experience, I was very involved in the first major project where Microsoft tried to catch up to Apple and Android with Windows Mobile 7, followed shortly with Windows Mobile 8.

The requirements we gathered for this large retailer was to form the release of Windows Mobile 8 for embedded/rugged devices. What made this project fail was that Windows Mobile was controlled by Microsoft’s consumer mobile team. If this team did not agree with a requirement, then the requirement was not included in Windows Mobile.

This team was so hyper-focused on developing the next iOS that they did not care and had no industry experience with enterprise mobile scenarios. Below are some of the examples that were red flags for me.

Microsoft’s Windows Mobile team could not understand why an enterprise organization would want:

  • to programmatically connect to Bluetooth devices. A user should be presented with a screen from which they can then select the device they want to connect with.
  • to programmatically connect to an approved list of WIFI SSIDs
  • to have device-level information such as battery strength, temperature, WIFI signal strength, and installed applications
  • for installed applications to share data

These were the seeds that Microsoft planted that allowed Android to grow into the defacto standard for rugged/embedded mobile device market.

Patterns of Enterprise Neglect

I am seeing a similar pattern of specific enterprise mobile neglect from Apple. Although Apple’s market share of the enterprise mobile space is nowhere near what Microsoft historically controlled, Apple does have a considerable amount of influence with many enterprise companies choosing an iOS centered mobile strategy.

Almost anything was possible in the early days of iOS development. With the way Objective-C is constructed, resourceful developers were able to take advantage of private APIs which provided more control over the device and applications. This was great for enterprises because internal IT teams had some level of deep access to the device and did not need to worry about App Store approvals.

Ever since iOS 7, Apple has been removing the ability for private API access for developers. Removing these capabilities are a part of Apple’s strategy for being the more secure and consumer privacy-focused platform.

Apple’s enterprise strategy has focused on supporting office workers who sit at a desk and use iPhone and iPads as a BYOD (bring your own device) or COPE (company-owned personally enabled) device. Since iOS 8, Apple’s enterprise focus is supporting 3rd party software companies (such as Microsoft Office, Skype, Cisco VoIP), VPN access, and enabling MDM/EMMs adequate APIs for enrolling and managing devices.

Apple has not focused on supporting internal IT teams who are building applications on COBO (company-owned business only) devices that can be shared. Up until this point BlueFletch has been able to work around or through most of Apple’s changes in the name of consumer privacy…but iOS 13 is a tipping point.

iOS 13 Breaks Everything

Having more than 15 years of experience implementing mobile solutions, I know that with any Operating System (OS) update things will break. Typically breaks occur because an API changed, the underlining implementation is being handled differently and/or there is a device issue.

Apple’s iOS is probably the only mobile operating system that removed or significantly reduces features for developers.

What Apple giveth, Apple also taketh away…

  • Since iOS 7, private API access was removed
  • The ability for managed devices to indefinitely ignore OS updates
  • Increased application sandboxing, limiting how apps can share data

The iOS 13 update to notifications is the straw that breaks the proverbial back of iOS for enterprise applications. To save battery life Apple will throttle and batch notifications in order to squeeze more efficiency out of the battery. Apple is also closing the loophole for using VoIP notifications for a non-VoIP purpose, thus removing the ability to send a notification and guarantee it’s delivery on a device in near real-time. So for scenarios that require immediate delivery in order to support a process (BOPIS picking in retail, notifications for airline workers, tasking updates for warehouse workers, etc.) iOS 13 will randomly break your application.

Billions vs. Millions

Apple is focusing on its core customer: the consumer user. The install base of field end-users is very tiny (millions of devices) compared to the more than 2 billion iOS devices that have been sold to consumers (*1.4 billion active). Although the install base is smaller users in the field, they are just as important as the average customer.

Organizations that have a shared device or COBO strategies should not consider iOS at this time.

The lack of device access, the continued sandboxing of applications, and not having a guaranteed delivery of notifications are core features that are needed to manage enterprise devices at scale.

Apple is really good at including ideas and features that exist in other applications or platforms, such as pull to refresh, swipey keyboard, grouping notifications, etc. Unfortunately for enterprise mobile companies, the features we need to be successful are not added, but continually removed, with every new release of iOS.

My intent with this article is merely to shed light on the fact Apple has lost touch with the enterprise. With each iOS update, we’re seeing new restrictions that limit developers…which ultimately impacts end-users and customers.


If you have any questions about which platform is most suitable for your organization, feel free to reach out at info@bluefletch.com. We’d love to share our experiences and help you find a scalable solution that meets your business needs.

Challenges to Consider with Enterprise Android OS Upgrades

By | Enterprise Mobility

OS Upgrades and Security Patches in the enterprise hardly ever consist of just a simple step. Apps need to be targeted for a new Android SDK, newly introduced settings must be decided on, and mobility extensions may need to be updated. On top of that, there are considerations for the varying environments and device states that must be accounted for. This post will highlight some of the challenges BlueFletch has encountered managing OS Upgrades in hopes to get your team thinking about hurdles that you may experience along the way.

BlueFletch has been tasked with developing a process and deploying OS Upgrades for many large fleets of enterprise Android devices numerous times over the years. Some of the problems are common across the board, and some are unique. In any case, we can group these challenges into three core areas: Network, Device Behavior, and Store Operations.

Networks

  • Poor networks: It’s 2019 and we still see sites with slow network connections resulting in unreliable downloads from limited bandwidth. This is especially true and problematic in rural areas, as we experienced when upgrading devices from inland Australia.
  • Unreliable downloads: Downloading large files from a remote server occasionally leads to partial or corrupted downloads. We have seen multiple retries needed to successfully and completely download the update package. Ensuring that remote servers are scaled properly or using local servers instead reduces the frequency.
  • Network over-utilization: After business hours, systems like POS’s run backup that impact bandwidth during OS Upgrade service windows. It is important to find these windows of limited network utilization and deploy during them to ensure you have reliable download performance. OS Patches can easily exceed 100Mb and when 40 devices concurrently attempt to download, networks quickly go pear-shaped.

Device Behavior

  • Persistence storage: An OS Upgrade will wipe everything from the device unless it is designated as persistent and stored in a secure folder. Unfortunately, some clients overuse this folder and the resulting lack of memory will cause nothing to persist. Ensuring only critical applications and settings are included in Persistence will provide a higher likelihood of success. At a minimum, the WiFi settings and MDM Agent must be persisted to apply to all other desired images.
  • Loss of proxy: When migrating devices from Jellybean (4.1) to KitKat (4.4), we found that the WiFi profile would remain on the device but wouldn’t carry over the proxy settings. The client required proxied traffic to reach the cloud-based MDM, thus all control over the device was lost.
  • AirWatch unenrollment after Upgrade: After an Upgrade, the AirWatch Agent reinstalls and validates enrollment. During a large deployment, we found a bug that affects about 5% of devices. Instead of re-enrolling, the Agent unenrolls the device and the link to the MDM is lost. The device becomes nearly a stock Android device that must be reconnected and enrolled.
  • Battery levels: Android requires at least 30% battery level to apply any patches or OS Upgrades. Ensuring the device is in a cradle increases upgrade success rates, but we have seen clients with not enough cradles to house all of their devices. One client didn’t even have cradles at all!
  • Non-compliant devices: Devices that are not fully compliant will always be an issue with a large enterprise fleet. How will these handle upgrade flow if they are missing a critical component like Zebra Power Manager? We separate these devices off into a different remediation path and clean them up periodically.

Operational

  • Non-business hours: Deploying during non-operating hours becomes tricky when dealing with stores across multiple time zones. Having the ability to phase deployments across local times will maximize service windows and give the most runway for Upgrades. Ideally, sites and devices are already grouped for the waves.
  • User interaction (barcode scan): We’ve experienced some scenarios where a process cannot be completed entirely over-the-air. For example, a client needed to connect to a proxied network to receive download and install commands so a StageNow barcode scan was required to add to the network. Barcodes should also be on-hand for remediation activities when a device does not re-enroll correctly or WiFi does not connect.
  • End of shift process: Stores should already be cradling their devices on close of business, but if they are not a huge opportunity to service devices in an ideal state is being missed. Enforcing proper device check-in ensures they are charging, close to WiFi, and most importantly – accounted for. Extra communications should be broadcast to cradle during the OS upgrade service window.
  • Automation in MDM: An OS Upgrade is rarely composed of just one .zip file to update the operating system. Many times there are driver updates, application updates required, and new settings that must be applied. Being able to automate these through triggers and inclusion rules will reduce breakpoints and minimize service time. A device should be able to have a “one-click” process that is thoroughly tested and escape proof.
  • Cleanup of old files: Devices may have gone through upgrades in the past already. Legacy files from prior OS upgrade activities sometimes are not cleared off and space needs to be made for the download of new packages. Surveying device storage ahead of time indicates if files need to be deleted early in the process.

Many of these challenges we’ve experienced can be overcome in a variety of creative ways. However, some required us to write code to handle them programmatically. We decided to combine all the solutions into a single OS Update Tool for Zebra. In my next blog post, I will address how our tooling solves these problems in detail. If you are interested in learning more, feel free to visit our microsite for our OS Update Tool or contact us at info@bluefletch.com

Best Practices for Mitigating Device Loss

By | Enterprise Mobility

As enterprises decide to invest in purchasing modern rugged devices, they should also be taking steps to mitigate devices from being lost or stolen. The true cost of losing a mobile device (including laptops, tablets, and smartphones) goes far beyond the price of replacement and poses many dangers to an organization if the right measures aren’t in place.

Device loss happens in a variety of ways. Some of the most common include:

  • Employees misplacing them in the store (e.g. left in a box, behind items on a shelf, in a locker or drawer)
  • Employee theft
  • Public theft

It’s important to understand and communicate to stakeholders that device loss is not 100% preventable. Occasionally devices get misplaced by an employee or stolen by a curious customer wanting to resell the hardware on eBay; point being, sometimes things happen that are beyond our control. You can, however, put measures in place that mitigate device loss and protect you from security risks. 

Device Accountability

Putting device accountability measures in place is a great way to mitigate device loss for companies of all sizes. Let’s walk through a few measures that can help your organization begin mitigating device loss.

Device Level Single Sign-On

Single sign-on involves users logging in and logging out of whichever device they are using during their shift. Each time a user logs in and logs out of the device an auditable trail, known as check-in and check-out, is created. Having an auditable trail in place often helps reshape employee behavior by improving the level of care they put into handling and securing devices throughout the workday.

Device Telemetry Data

Telemetry data captured on devices can be used as breadcrumbs to hone in on a device’s current or last-known location. It’s especially useful for the warehouse use-case, where finding a misplaced device is difficult due to the large space and noisy environment. Let’s say a device has not checked in since the previous night and an employee during the morning shift needs the device to do their tasking. If the device administrator has access to battery information and network information, along with the check-in/check-out data, they would be able to see who had the device last, when the device was last seen on the network, which network access point the device was pinging and it’s signal strength. With those data points, the admin could begin a more informed search for the device.

Device Tracking

In an age where consumers are accustomed to being able to “find” their devices by simply logging into a portal and clicking a button, it should come as no surprise that Enterprises would want the same level of convenience. Device tracking in real or near real-time is another great way to mitigate device loss and as a result, becoming standard requirements for more and more enterprises.

Audible Alerts

If you own an iPhone or Android smartphone, then you are likely familiar with their respective “Find My iPhone/Device” features. When a device goes missing, the user logs into a portal and sends a command to the phone to force it to play an audible sound, usually at a high volume to make it easier to locate.

Some top-tier solutions, such as BlueFletch EMS, take this feature a step farther by utilizing automatic alerts. Automatic alerts can be leveraged through baked-in configurations that cause devices to play an audible sound whenever certain criteria are met, such as:

  • Predetermined battery threshold is reached (e.g. 15%), the device has not detected movement, and it’s not charging.

We’ve heard the stories before – an employee leaves a device on a shelf in the stock room, accidentally misplaced on top of a box, or left inside a locker with no eyes on it. Automatic alerts to the rescue right? Well, just like the tree falling in the woods, if no one is around to hear it, then…you see where I’m going here? Luckily, there’s a solution for that, and it’s a concept known as broadcasting.

Broadcasts

In a similar vein to the configured automatic alerts, broadcasts occur when certain criteria are met. But instead of dispatching an audible noise, the device sends a notification in a number of different formats, such as:

  • Email
  • Text
  • Notifications to dashboard

Broadcasts are especially advantageous for supply chain, warehouse-centric, or other industries that have large outdoor spaces where hearing an audible alert may not be possible.

Visual Tracking

Arguably the most complex form of device tracking is visual. Visual tracking usually involves a real or near real-time visual representation of devices overlayed on a map or diagram of the site where the devices are deployed. There are a number of factors that need to be considered in order to make visual tracking successful, such as:

  • Sites need to be mapped and recorded, including updates and changes to the layout
  • Strong network infrastructure to support triangulation via access points
  • Define the level of precision that is required
  • Impact study how items stored in a location may affect signal strength (e.g. walking through an aisle of packaged liquids will affect signal strength at certain frequencies
  • Availability of GPS

Device-to-device locating is a more recent development of Visual Tracking. Think of it as using one device as a homing beacon or metal detector to locate another. Solutions can be innovative by leveraging augmented reality (AR) to guide the user towards the missing devices, or as simple as displaying a map or diagram of the site on the screen, which is more in line with the traditional method of visual device tracking.

Final Thoughts

Although there are a number of valuable solutions currently available to help mitigate the loss of enterprise devices, protecting against the loss of enterprise devices starts with employee training around device use best practices. Employees should be responsible for taking simple actions such as:

  • Putting devices on their cradles/chargers whenever an employee finishes their shift
  • Using holsters or lanyards for devices when carrying devices on their person
  • Avoid putting devices down in random places throughout the day
  • Avoid placing devices in drawers or lockers

Rugged enterprise devices are not only expensive to replace, they may be carrying valuable and sensitive data which, if breached, can be costly to the organization in ways that money alone cannot cover.

If you’d like to learn how BlueFletch can help you mitigate device loss, please contact info@bluefletch.com.

Device Loss and Potential Threats to Your Organization

By | Enterprise Mobility

Rugged devices from Zebra Technologies, Honeywell and Samsung are closing the gap in performance to their consumer counterparts, which is allowing enterprises to gain operational efficiencies and provide better customer experiences. However, with the continued adoption and replacement of legacy mobile devices, the security threat that lost devices create should not be ignored.

A recent study from Kensington reveals 4.5% of company-issued smartphones are lost or stolen every year. To put that in perspective, some of your favorite brands managing over 100k devices could be losing nearly 5k devices each year if the organization is not properly protected. IT systems are vulnerable to threats if they don’t facilitate a comprehensive security strategy that includes protocols for lost or stolen devices. 

Below are 3 critical impacts from a lost or stolen device that all organizations with shared devices should prepare against:  

1. Exposure of Company Data

Data should be encrypted at rest and encrypted in motion. Period. Having a device within your 4 walls or only on your network is not enough protection. Data encryption at rest prevents the visibility of business-critical information in the event of its unauthorized access or theft. Many applications, especially on cellular devices used in the field, will need to collect, store and transmit data once a connection is available. Is your data currently protected?

Data encryption in motion has become very commonplace. All the major cloud providers by default support HTTPS connections to ensure that consumers are securely accessing data. However, many enterprises are still hosting APIs on-premise on self-managed infrastructure. Are all connections over HTTPS for your organization?

Questions to consider:

-Are all data connections for the organization over a secure protocol? e.g. HTTP
-When is the last time the organization has conducted an audit of how, where, and what type of data is stored on device?
-If a data breach did occur, how nervous would the organization be?

2. Financial Impact

Lost or stolen devices can also be a financial drain on an organization. Replacing a lost rugged device is not cheap. Many of the rugged devices from Honeywell and Zebra Technologies have a list price north of $1,000 per device. Gartner also estimates that the cost of an unrecovered mobile phone is at least $2,500 per device. These costs are based on the value of the data on the device – the loss of intellectual property and the impact of potentially compromised proprietary data.

When you consider the cost implications of employee downtime, the financial impact rises even further. Lastly, device loss drains IT resources for large organizations, as they would typically have to outsource the break/fix support functions to resellers like Stratix. These additional costs can be saved with the right solutions in place.

Questions to consider:

-What is the ROI for reducing lost and stolen devices by half the organization?
-Does your organization have the correct tools to support lost or stolen device scenarios?

3. Network Vulnerabilities

Back to my earlier point that data must also be encrypted in motion. Why? Not encrypting data in motion gives a bad actor the opportunity to reverse engineer how data is transmitted to APIs and possibly see how devices are connected to your network or access points.

Many software developers use reverse engineering to improve their own code or to improve interoperability between programs. However, a bad actor looking to gain business intelligence or inject malware into a system could begin the reverse engineering of an organization’s infrastructure with a lost or stolen device.

A lost or stolen device can become the key to your network if left unprotected. In December of last year, Blue Cross Blue Shield of Michigan had to inform nearly 15,000 members of its Medicare Advantage health care plan that their personal data was at risk due to the theft of a device containing their data.

Questions to consider:

-If a rogue device gained access to the network, would that intrusion be detected?
-How often is the network’s firm and access updated?

Enterprise mobility is at the core of what we do at BlueFletch. Typically when organizations bring us in for mobility transformation engagements, preventing lost or stolen devices are not at the top of the priority list. Having the correct processes, procedures and solutions in place are key to protecting IT systems and your mobile investment.

Device Accountability vs. Device Tracking – How They Differ

By | Enterprise Mobility

Rugged devices enable employees to streamline daily tasks and deliver excellent customer service in more efficient ways than ever before. As a result, companies are making wise investments in rugged devices and mobile strategy. 

But what happens when those investments disappear? Well, when they disappear for good, we call that device loss. If they happen to reappear, we call that luck…unless you have good tools in place to mitigate the loss. We won’t go in depth about how to mitigate device loss in this article, but instead, I’d like to set a baseline for two key concepts: Device Accountability and Device Tracking, which together are part of what we will call Device Visibility.

Device Accountability and Device Tracking are often used interchangeably, and understandably so. A few weeks ago, I was sitting in a meeting where I was talking to some clients about Device Accountability and how our EMS product can help mitigate their device loss. During the Q&A session after my presentation, I was asked about the various features of how our product could help “track” their devices. It was in that moment when I realized that technology and solutions around understanding the whereabouts of rugged devices in enterprises is still emerging, and so are the concepts behind them. That said, let’s dive into the differences between Device Accountability and Device Tracking.

Device Accountability

Think of accountability as an auditable trail of who, what, when, and where the device has been. The “accountability” helps to reinforce associate behavior in how they handle and maintain the devices. Here are some example questions that may be raised during an audit trail of Device of Accountability:

  • Who had it?
  • When did they have it?
  • How long did they have it?
  • Was it returned to its charger/cradle?
  • Where was it last seen (AP, SSID, cell tower)?

Device Tracking

Tracking is pretty much exactly how it sounds. “Tracking” devices focuses on seeing a device’s movements or history of movements through some form of visual representation or through actions that cause the device’s location to be known. Here are some ways tracking devices occurs:

  • Ping the device
  • See the device on a map (from a terminal or another rugged device)
  • Automatic defensive measures on the device itself
    • Device plays audible tones set to configured thresholds and events
    • Device broadcasts an alert or notification set to configured thresholds

Now that you’re well-versed on the differences between the concepts of Device Accountability and Device Tracking, be on the lookout for my next post discussing best practices for how to mitigate device loss.

New Year’s Resolutions for Developers

By | Development, Enterprise Mobility

I am not big on New Year’s resolutions, mainly because if you need to change something, don’t wait till the new year, just make the change. While I was driving home from vacation, stuck in traffic, I started wondering what the development teams I work with can do differently in the coming year.  Thinking about what we should focus our energies on,  I came up with some “resolutions” for the new year. As with any resolution or goal, not all are needed to be completed or followed, but as a developer, if you can accomplish any of these, you will improve your development skills and also help teach the developers that follow you.

Read More

How to Tell When You’ve Been Given a Good Project Estimate

By | Enterprise Mobility, Thought Leadership

Let’s say you are a member of your organization’s IT Department, and you have engaged a third party vendor to develop a customized software solution for your company. When they provide you with a cost estimate for the statement of work, you will have to determine whether the estimate at hand provides good value for your company and can be delivered by the proposed timeline.

Here are five suggestions for how to determine if your software vendor has made a good project estimate:

Don’t Cut Corners During the Design Phase

In the hurry to get a Development SOW signed, design is often taken as ‘easy’ or as a ‘given’; however, rough drawings or high-level descriptions of what software should do does not provide enough information to understand the true complexity of a project. Good design often takes months. Companies who have deep experience in software development will have an active design team that will work hand-in-hand with the project Architect AND end users to detail each and every flow, feature, and edge case for a project. If your software vendor provides you flow diagrams, high fidelity prototypes (such as Invision click-throughs), detailed written requirements, and have had at least two full design feedback sessions with your software end users, you are in a good place. Money spent on design will almost always save you time and expense on the overall project. Read More

NFC Android

Demystifying Enterprise Mobility Management

By | Enterprise Mobility

EMM. UEM. MAM. MDM. There is no shortage of acronyms or options when it comes to managing your enterprise mobile devices. As is usually true with options, sifting through them to find the right ones takes some work. We’ve done the heavy lifting for you by comparing several (but not all) solution providers to help you make the best choice for your organization.

Read More
app design process

Mobile Strategy: Avoid Pitfalls when Migrating from Legacy Devices

By | Enterprise Mobility

Delta Air Lines has a well planned and effective enterprise mobile strategy. Delta employs a healthy mix of devices based on the role, environment and required tasks. The employees in the terminals need business mobility devices as rugged as Thor’s Hammer and for everyone else, there are consumer devices. Their business mobility development team is focused on one hybrid platform, which supports their fleet of Android rugged devices and iOS devices.

Read More

Zebra’s All The Way Down

By | Enterprise Mobility

I recently had the opportunity to participate in Zebra’s Developer podcast hosted by Dan Quagliana and Mark Jolley from Zebra. I spoke a bit about some of our experiences dealing with deploying Software and OS Patches on Android devices in the Enterprise. Here are some of the highlights and notes from the questions that I covered during the discussion.

Read More