Mobility Evolution

A decade ago, in 2013, IBM's mobile app development platform was renamed from Worklight to IBM MobileFirst to leverage the growing trend of mobile device adoption and the increasing reliance on mobile technology to create better customer experiences and improve business processes. The MobileFirst axiom spread like wildfire through the IT landscape as the fascination with the potential of mobile apps grew exponentially.  The thrust behind the MobileFirst axiom centered around the notion that any IT initiative should begin with implementing a mobile strategy first, hence the concept of MobileFirst. It prioritized mobile devices and experiences within an organization's IT strategy. The excitement about the MobileFirst strategy waned as companies realized that mobile dividends did not live up to the billed expectations. To be sure, the mobility revolution continued on its track, but the ability to leverage this sea change fell short of its potential.  Mobile initiatives failed to d

Creating your mobile app within an enterprise setting can be challenging. You start with an idea at the beginning and a clear intention of a functioning mobile app at the end of your process. Along the way, you face the complex task of integrating the app with your data stack within your enterprise. For consumer-facing apps, the process is linear: beginning with the user stories and refining them into Figma designs. Once the workflow finalizes, you start the development process by creating a UI that interacts with public cloud services through APIs. This process works well if the app does not interact with the enterprise data stack stored behind a firewall. Once we cross into the enterprise domain, the development process becomes more complex. The linear design from dev to deployment no longer produces a smooth transition from one process stage to another. The Linear Approach to Creating a Mobile App The linear enterprise app development process often comes to a screeching halt when it

Embarking upon a mobile app development project poses a vital, if not a critical, question at its very inception: does the project require the native dev approach, or does it merit utilizing a common dev framework? As everyone knows by now, the native choice necessitates the development of two sets of code, one for Android and another for iOS, to be maintained ad infinitum separately throughout the project’s life. On the other hand, a mobile development framework provides the convenience of developing and running your app through just a single code base. At first glance, one would wonder why anyone would want to select the native approach, given the inefficiencies in maintaining two code sets. Even with that significant consideration which sets back the cause of native app development, most apps today are developed natively. Why do decision-makers choose native over cross-platform? The answer is not as cut and dry as you might think, and the element of risk management plays a prominent

Android and iOS have de facto become predominant platforms in today's mobile app universe. Therefore, it is a foregone conclusion that a mobile app must support iOS and Android versions to reach the most extensive possible user base. Developing and maintaining two versions of your app on each platform takes considerable work. You would need two technical teams, each with unique skill sets to focus on continuously delivering quality outcomes. Not only can this be a costly proposition, but it also presents tremendous technical challenges in keeping the development effort in sync for both platforms. Another daunting complexity is the addition of a third tier which heaps on the support of the web platform to bring on board the non-mobile (desktop/laptop) users to take advantage of the same app functionality mobile users do. Therefore, depending on the complexity of the user base, as many as three platforms, iOS, Android, and web, needs to be supported to deliver identical functionality