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

Mobile app developers use webviews primarily to embed web content (HTML/JS) into a native mobile app (iOS or Android). There are three main applications of webviews that conform to mobile app development best practices: Showing Web Content: If your app has embedded web links (URLs) that require rendering web pages within your app, then this takes place within a webview container. Displaying Advertising: If the mobile app displays advertising banners, web view containers are embedded with native views to render the advertising content from remote sources. Mobile App Enabling a Web Application: When you are distributing a web application within a mobile app container, the webview serves as the medium where the web application resides and executes its functionality. The first two applications of webviews are the original intent of availing webviews within a native mobile app, and developers utilize webviews for these purposes without any significant complications. The third application

Do you have a roadmap for your enterprise mobility journey? Here is a quick overview of the most salient areas of concern that you would need to address throughout your journey: Establish a Product Plan: Focus on user experience to devise the most viable approach to achieving the intended goals for your mobile app. Begin with an MVP approach and evolve toward a more feature-rich solution in the long run. The look and feel of each platform should be maintained throughout the design process. Choose the Most Suitable Framework: Native, cross-platform native, hybrid, or possibly a multi-experience development platform. Choosing a dev framework has longstanding implications and must be carefully evaluated based on the short and long-term needs of the project.  Robust Architectural Design: Focus on maximizing app performance through data caching/memory management and multi-threading processes. Create the most optimal approach to an efficient and easily maintainable code base—effectively us