When we say “develop for the future”, we do not mean that you should develop apps that will be useful in the future – we mean to develop apps that are ready for the future. By watching for trends from platform providers, such as Apple and Google, and selectively adopting new development guidelines and features as they are announced, your app will be prepared for future releases. Getting an application ready to ship on a short timeframe or otherwise is great, but if you rush, cut corners, or do not plan for later updates, something as simple as a new OS release could cause major problems. A little extra time spent implementing these changes and ensuring everything is "as it should be" in the present can, and usually will, save a lot of time and money in the future.
To better understand the importance of preparing your app for the future, we’re going to take a look at a few past updates and announcements that resulted in full-blown initiatives – features that seemed almost trivial at the time, but are now practically platform standards.
Size classes originally appeared for iOS 8 in 2014. These classes worked with Auto Layout to provide a UI that would work properly no matter what the screen resolution was. This was a pretty significant departure for iOS, as that platform had previously enjoyed a very small number of screen size variations, which made it simple to design to a fixed size. There was some initial resistance from the community; after all, even though size classes existed, we could still design for the phone sizes. With the introduction of multitasking on the iPad in iOS9, however, the value for size classes became more apparent. Size classes allowed developers to build a UI that would work well even with the unpredictable configurations of a changing screen size. By paying attention to size classes when they first appeared in 2014, developers could be more prepared for changes that appeared in 2015.
In July 2011 Android 3.2 introduced screen size buckets. These buckets include constraints like a shortest width demarcation. This was just after the launch of Honeycomb when they realized that tablets were much more varied in size than phones and indeed phones were getting pretty big as well. The existing buckets like "normal" and "large" were too vague and didn't carry a guarantee of a physical size for developers. The shortest width buckets were based on the physical size of the screen measured in density independent pixels which are roughly 1/160". The next year saw the release of the 2012 Nexus 7 which sold like wildfire and popularized the 7" format. Now in 2016 we see multi-window multitasking where two apps are shown at the same time. A 10" screen size might be displaying a phone-sized UI. If you took the hint with the new buckets, you were in good shape for both events.
At Google I/O 2014, Google quietly announced an effort to get Android apps onto the Chromebook. The first demonstration partner for this was the Evernote app. It wasn't a great experience and it was a little clunky. Fast-forward to 2016 and now publicly available Chromebooks run native Android applications right out of the box. Google has largely combined its tablet efforts with the Chromebook OS in something rumored to be called "Andromeda" a combination of the words Android and Chrome. Whether or not this name sticks, Chromebooks from several vendors are already capable of this type of functionality with 10" screens, capacitive multitouch, accelerometers, GPS and other sensors. These devices should behave like a lot like a full-fledged Android device and add the ability to take multi-window multitasking to a new level. Looking back at 2014, the reveal of Andromeda and first-class Android applications on Chromebooks isn't really a surprise.
Also announced at Google I/O 2014 were app-indexing and enhanced deep linking support. At the time this seemed to be related primarily to their desire to index the world's information and play a larger role in app discovery. That in itself is a strong reason to work on deep-linking your app and ensuring your website is set up properly for app indexing. Then at Google I/O 2016, they announced the creation of Instant Apps which would go directly from a search to taking action in a slice of the app. Also, Google Assistant can use these types of links to launch apps directly from chat. If your app and website aren't taking advantage of app indexing and deep linking, you are reducing your app visibility and ease of use.
When we choose a third-party solution, including open-sourced solutions, we assume responsibility for maintaining those libraries. This has become an issue with the release of Swift 3.0, as some frameworks have been either abandoned or slow to update to the new language syntax. Since a project can't simultaneously use Swift 2.0 and Swift 3.0, you can end up with an unexpected level of technical debt as a result. The best solution to this is threefold: First, use as few of these as possible. Secondly, choose ones that have a significantly sized user community for the best chance that it's updated. Thirdly, if all else fails, truly understand how the framework works, so that you are ready to perform any language updates required. Note that this can occur with any language that gets updated, whether that's Swift, Objective-C, Java, or anything else.
Future-proofing is a process, not a feature - and is ultimately something that must be done on a consistent basis. This can only be accomplished by viewing one's apps as living entities – receiving regular updates, not only for features but to ensure they're taking advantage of the latest capabilities of mobile devices and mobile operating systems. By evaluating even the minor advancements of the platforms, one can see future opportunities and get ready to succeed with future environments without scrambling at the last moment.
Contact us today to learn more about future proofing your projects.