Can we “save” your next unplanned Mobile App release?

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 , 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. apps All too often, the reason for these unplanned releases has to do with slow app speed and poor performance. A few such reasons include: : 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. Slow Mobile Networks : Mobile apps are getting more and more sophisticated through the use of 3rd party services. The average mobile app uses about 8 SDKs for variety of services such as monetization, segmentation, and reporting. Using these services in run-time means calls to 3rd party domains that developers have no control over. Too Many Domains/SDKs logging : 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 CDNs : 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. Legacy Web Protocol 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 t ). There is no need for any other code changes. his video Once integrated and deployed, Mobile IQ provides near real-time information from end user devices on multiple app KPIs, including: · User and Request information · Network errors · Throughput Elapse time (i.e. latency) Connection disconnects Mobile IQ was designed for ease of troubleshooting and to have mouse-driven filters that allows users to drill into any of the following dimensions: Geography 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: — During development time there is no way for developers to know what will be the underlying network in run time, 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. Http Connection Optimization — 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. URL Redirect — 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. Domain Blocking 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. Reducing Error Rates — — Unlike lab testing, when measuring content download speed in production from multiple geographies and over different networks it is easy to notice high variability in the time it takes to accomplish certain functions (e.g. loading the main screen, downloading a high quality image, playing a video Ad). Once again, there is very little that an app developer can do to control this behavior. In cases of poor performance, Mobile IQ could be used to replace the new modern protocol for a certain percentage of users and benchmark the differences. 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. Accelerating Content Download — As mentioned earlier, 3rd party services are more popular with app developers these days. Unfortunately, when using the legacy Http over TCP we have less control over things such as the number of connections and the order they will be executed. Mobile IQ allows developers to try a new modern networking protocol that in addition to improved performance and reliability can specify the order of Http requests based on a priority list. If ads rendering is the top priority — simply set the Ad Network domain at the top of the list to ensure that the ads are fetched and rendered before any other domains are called. Domain Prioritization The relationship app developers have with the two main app stores is often complicated. While they love the app stores’ ability to distribute their apps and drive app discovery, it can be frustrating whenever there’s the need to update their apps with even the smallest of tweaks, which often arise from issues related to mobile networking and app performance. Fortunately, many unplanned app releases can now be avoided by making changes affecting app performance directly through Mobile IQ. Check out this . product overview video