October 7, 2016 // By Margo Krukonis
Loyal fans celebrate the annual release of a new mobile operating system. For mobile-app development teams the mood can be more somber.
Keeping a mobile application current is a never-ending task that can strain budget and development resources. Magenic recommends a thoughtful strategy to ensure the right proactive measures are taken to exploit new features and to avoid the pitfalls of unexpected changes.
Major OS Releases
Typically announced once a year in the late Spring/Early summer, major releases can contain a mix of new features, defect fixes and enhancements that are generally well documented.
Less well-documented can be some of the potential pitfalls including device incompatibilities, deprecated methods that require developers to modify existing code and new tools that may be required for the development, testing and distribution of applications.
General release to the public is in the September/October timeframe leaving a good lead time for planning, but stable beta versions for download are not generally available until six to eight weeks before the public release.
Minor OS Releases
Minor or point releases are not released on any regular schedule. The lead time between Beta (if available) and general release is typically much shorter and documentation may or may not be released.
How do Notifications happen?
Information on both major and minor Apple releases can be obtained through the Apple Developer web site and the annual Apple World Wide Developer Conference (WWDC).
Information on Major Android releases are typically announced at the annual Google I/O conference.
Minor Android releases typically have no formal announcement and aren’t released on any particular schedule. They can be communicated via social media or pushed out to a limited number of devices at any one time. Subscribing to a twitter feed may help to catch announcements that are not released in larger forums.
Recommend Evaluation Process
Time to review release notes, betas and perform initial OS evaluation should factored into the schedule for every release. Although level of effort will vary based on the release content and risk, evaluation tasks should be included in release planning.
Magenic recommends a careful evaluation of the major version notes first to determine potential opportunities and risks.
Although it is tempting to download an early Beta version to get a jump on testing, many features published in documentation may not be available in these preliminary versions, requiring a duplicate review at a later date.
An initial documentation review can help to identify the effort necessary to evaluate the beta version and the potential risk. In addition, opportunities can be identified that could potentially change the course of planned features.
Both in-development and in-production application versions should be evaluated against the new OS.
Once a stable beta is available, evaluation should be performed on the targeted areas first, and findings reported via a mix of narrative and screen captures as necessary to demonstrate any opportunities or issues that could benefit from a visual representation.
Notes for minor releases should be reviewed whether received before or after the fact.
If any risk areas are thought to exist, testing should be conducted against the appropriate versions of the applications. Opportunities or risks should be reported in a manner similar to the major OS release process.
Time should be considered in every development sprint or cycle to evaluate new OS versions and report findings. Any additional tasks resulting from new OS versions should be prioritized against existing work, based on risk or opportunity.
The timing of releases should be considered against public releases of major versions, so as to exploit new features in a timely manner.
Although OS releases can be frequent and unscheduled, a thoughtful strategy can provide a proactive rather than reactive approach to maximize the benefits of new OS versions and increase the value of mobile applications.