Mobile App Development Strategy for Data-sensitive Demography Date:   Tuesday , August 23, 2016 Headquartered in Bengaluru, Goodbox is an online platform that enables the businesses to host their menu on the portal by creating a business profile and have an app presence in less than five minutes. If you\'re into mobile app development that\'s mainly targeted towards the Indian consumers, then certain Internet behaviour would strongly stand out - - Highly sensitive to data consumption - Flaky internet/mobile connections - Fewer automatic app-updates - Side-loading of apps via \'Share-It\'. With this background, sending frequent app updates will not achieve what one would want - rollout newer features/capabilities to existing users. What this results in is a fragmented set of users of your app. This makes it difficult to obsolete certain parts of the app or give new functionality to entire userbase. One of the approaches tried was to open a mobile website inside a very thin wrapper app. This way, you could always rollout new features form the server and a user never needs to update the app to get them. However, this has a major drawback of making the app completely useless without the internet. What would be desirable is to release new features to existing userbase without forcing them to update to latest app, but still keep the app usable without internet. Hybrid App with Webviews Both Android and iOS allow you to load any html content and show it as part of the app. One approach is to build a \'hybrid\' app. There are some controls given to the app developer with respect to navigation of links, loading of the pages, page origins, as well as where to load the content from. So you could load a html file from local filesystem on the app. This fileset can be periodically downloaded from the server to get new functionalities. Since it is locally loaded, it will always load successfully, independent of network connectivity. For this strategy to succeed, it is essential to make a good \'js-bridge\' available. This js-bridge is a way for the webpages to access native code which otherwise isn\'t accessible. So, things such as getting app-version, user-info, application-state and logging are the kind of things you\'d expect in this bridge. A good thought out js-bridge can make app releases redundant for a long-time. Progressive Webapp Enhancements in Webviews Slightly sophisticated approach that does not need to build any client side file syncing mechanism is to make use of the Progressive Webapps advancements made in browsers. Newer versions of Chrome support - a concept \'Service Worker\' that gives full control to the web developer over the network behaviour of requests in the webpage. Think of it like a programmable network proxy. When the page loads for the first time, it can register and \'install\' the service worker. At this moment, the service worker can go ahead and cache all the required assets and API calls and then load the page. Once cached, it would never need to download them again for the page to load. Further on, every network call would go via this service worker and it can make a decision as to send it over the network or load from cache. You can code it to use last successful output in the absence of internet. If slight staleness is acceptable, the service worker can also be coded to use the last successful output and trigger a new network request to server to get latest content ready for the next call. Here, the UI is functional even when there\'s no network utilizing lowest possible network resources. Good thing about this is that this requires no change on the app side and can be done with existing apps. However, this is limited to newer versions of Chrome on Android only (Android versions prior to 4.0 rolled out with Chrome 33 which does not support this. Also, iOS Safari browser does not support this yet). React Native Powered Screens Both the approaches above suffer from a drawback. As they are rendered inside a webview, user experience of webview components is not as smooth as native UI components. Enter React-Native, a new framework by Facebook team that gives rich native experience along with the power of server-side rollout. Originally released for iOS, this is starting to gain wide acceptance after the release of support for Android. It takes JavaScript-based code with special mark-up language packaged as a file called bundle, which will be loaded from the file system locally and rendered natively. This bundle file can be refreshed from server periodically. Thus, you can rollout an entirely new set of capabilities, workflow, logic or even a new UI, and the experience would be similar to that of a native app components. However, this does add an additional 3-5 MB to your application size. Conclusion: Prior efforts of cross-platform development were done with code-reusability in mind. But it can be used for a different purpose. All three approaches above are trying to solve the problem of rolling-out new capabilities to mobile applications without needing full application updates, while still keeping the offline-experience to be acceptable by making different tradeoffs on application-size, compatibility, first-load experience, development complexity and user-experience. You can always be creative and use different strategy for different parts of the app and apply the most-suited approach to give the best possible experience to the ever-data-sensitive consumer of your app.