Recently I was asked how a developer can use an ALX file to make sure that the touch-aware version of their app only gets deployed on touchscreen devices. It occurred to me that a lot of apps are still set up with separate touch and non-touch builds. Certainly there have been good reasons to do that in the past – but is it still the case today? Let’s take a look at some of the past reasons why a developer might have set up separate builds, and explain why a separate approach isn’t necessary today.
Reason #1: Touch isn’t supported in that OS
When the BlackBerry® Storm™ 9530 smartphone launched with OS 4.7, it was necessary to have a special touch-only version compiled against OS 4.7 in order to take full advantage of the touch functionality. If you were using the standard BlackBerry UI components, an app compiled for an older OS would probably work fine – but if you wanted to actually capture and use touch events, those methods didn’t even exist until OS 4.7. In this case, not only did it make sense to have a separate touch-only version optimized for the BlackBerry Storm smartphone, it was really the only way to go.
Fast forward a few years, and devices running BlackBerry® Device Software 5.0 and higher are 93% of the market share worldwide for free apps. With paid apps, it’s up to 97%! Since the touch APIs are present in newer OS versions regardless of whether the device supports touch or not, any app compiled for BlackBerry Device Software version 5.0+ (or really 4.7+) can be made touch-aware.







