Can You Eliminate the Need for an Unplanned Mobile App Release?
Can You Eliminate the Need for an Unplanned Mobile App Release?
See how monitoring your mobile application's performance can prevent the kind of surprises that lead to unplanned releases.
Join the DZone community and get the full member experience.Join For Free
Surprises can be good in some situations, but when it comes to an unexpected app behavior, or worse -- a bad App Store review -- we would all gladly pass. Unfortunately, when operating popular mobile apps, developers have little control over the app after they submit it to the store and users start downloading. If something goes wrong with the app or the developer need to make any tweaks to it, there’s little they can do other than submit an all-new version to the App Store and go through the release process all over again.
All too often, the reason for these unplanned releases has to do with slow app speed and poor performance. A few such reasons include:
Slow Mobile Networks: There are simply too many unknown variables in the way mobile devices access the cloud using hundreds of mobile and Wi-Fi networks around the globe. Users in Southeast Asia or Latin America will most likely use the app over a slower and unsound cellular connection, while those in more developed countries will get a better signal but higher packet loss in crowded cities.
Too Many Domains/SDKs: Mobile apps are getting more and more sophisticated through the use of 3rd party services. The average mobile app uses about 8 SDKs for a variety of services such as monetization, segmentation, logging, and reporting. Using these services in run-time means calls to 3rd party domains that developers have no control over.
Legacy Web CDNs: Content Delivery Networks (CDNs) helped the Internet scale two decades ago and still provide some value for mobile apps. Unfortunately, these services were not designed for mobile developers and weren’t required to route all the application traffic through their network, limiting the developer control. In addition, Web CDNs cannot help with 3rd party services unless they already work directly with these vendors.
Legacy Web Protocol: TCP was designed three decades ago and has served us very well to date. Sadly, TCP has multiple weaknesses that makes it inefficient over mobile networks, but it offers little to no control for developers. Behavior such as domain prioritization, connection timeouts, and number of concurrent connections cannot be adjusted.
To have some visibility, many developers add timers to monitor important app functions and send alerts when the app is experiencing odd behavior. To save face during a production crisis, developers add kill switches to disable 3rd party services and certain app functionality. More often than not, they are not quick enough and shorthanded so they end up developing and building a special software patch to resolve an issue.
Can we do better?
PacketZoom is a group of Mobile Networking experts. We spent the past four years developing a new mobile network stack for apps, and we are selling it successfully for enterprises that need a faster and more reliable solution for their apps.
As developers, we want to help other developers build better apps and gain more control over apps even after they are submitted to the app stores. To do so we developed a free solution that can put you back behind the driving wheel. We call the solution Mobile IQ.
Mobile IQ is an SDK that for most of the platforms requires a single line of integration code. Most developers are able to complete the integration in a few minutes (as demonstrated in this video). There is no need for any other code changes.
Once integrated and deployed, Mobile IQ provides near real-time information from end-user devices on multiple app KPIs, including:
User and Request information
Elapse time (i.e. latency)
Mobile IQ was designed for ease of troubleshooting and to have mouse-driven filters that allow users to drill into any of the following dimensions:
Domain (i.e. server)
Network type (WiFI, LTE, 3G, 2G)
Actual Carrier (e.g. AT&T, T-Mo, Vodafone, etc.)
Mobile IQ offers a simple way to set up thresholds for any type of data or data trend. Once a threshold is violated an alert will be fired using email or slack integration.
Becoming aware of an issue in a timely manner is a major step. Having the ability to perform a quick Root-Cause Analysis is even better, but now what?
Mobile IQ includes access to a few important app network control functions that could save you unnecessary pressure, reduce risk and perhaps permanently eliminate a networking challenge. These functions include:
HTTP Connection Optimization – During development time there is no way for developers to know what will be the underlying network in runtime, so we use the default connection parameters that were basically designed to handle the least common denominator. Unfortunately, this means that the timeout parameter, for example, is too high for fast network and too low for slow networks. By letting PacketZoom override the default parameters you would basically customize each HTTP connection to the user network environment.
URL Redirect – From time to time, redirecting traffic from a given URL to another for debugging, troubleshooting or as a temporary pain relief could become handy. Since PacketZoom SDK serves as an in-app proxy, this is a simple and handy function.
- Domain Blocking – In case of service issues affected by a single or multiple domain PacketZoom SDK could be used to block (temporarily or permanently) certain calls. Such functionality could be used to “control” 3rd party service providers that have operational issues.
Reducing Error Rates – Unlike application errors, network errors are beyond the app developer control and as such could become a source of frustration. In cases of higher than desired 400’ or 500’ network errors, Mobile IQ could be used to replace the legacy protocol with a new modern protocol (aka PZ Protocol) for a certain percentage of users and benchmark the difference. This could be accomplished by simply defining a content filter (using regular expression) and when specific calls match the filter they will be executed using the PZ protocol for selected users.
Opinions expressed by DZone contributors are their own.