By Madison Moore
Like DevOps and agile practices, “mobile-first” development is changing the way developers approach building applications. Of course, the industry doesn’t need another buzzword, but this one accurately describes the way teams are thinking about user engagement and developing quality digital experiences.
Plenty of digital organizations are shifting their efforts and making mobile development more than just an afterthought, and the evidence is right there in the tooling that exists for developers today. Some experts might argue that the plethora of choices and platforms can be a bit overwhelming, but the technology isn’t the challenge.
Instead, a common roadblock is how to get design teams, project managers, and business leaders involved from the start. It requires collaboration and a change in culture, and many organizations are not prepared for that level of feedback from the development cycle.
For this year, companies need to be ready for mobile-first development, because the usage of mobile apps and devices doesn’t show any signs of stopping. In fact, Flurry Analytics reported that 2016 was the last year of the first decade for mobile apps, where overall app usage grew by 11% and time spent in apps grew by 69%.
Mobile usage hit a critical mass in 2016, but mobile’s decelerating rate of growth either means the market has matured, or perhaps we are seeing the end of the “app gold rush,” according to senior vice president at Yahoo Simon Khalaf.
Before the mobile app market is disrupted again, developers need to communicate with other teams involved in mobile development processes, sift through analytics, and consider how mobile affects the entire SDLC. Only then will they be able to master the world of mobile-first.
Design comes into focus
Teams within organizations are facing additional mobile pressures from a design standpoint because they need to create optimal experiences for their users, which means the design teams are involved from the very beginning of the software development process, said Daniel Jebaraj, vice president at Syncfusion.
There are other, more internal problems, he said, where they might not be under pressure on the design aspect, but instead they face pressures for performance standards. This is especially true for enterprise applications, which tend to focus more on performance, structure and functionality.
Companies should also consider Material Design, which is a comprehensive guide for visual, motion and interaction design across Android platforms and devices, according to Matt Story, CTO of Handshake.
According to an XDA Developer report, Material Design has seen an “extremely stunted growth on Apple’s mobile platform, primarily because it is viewed as Android’s design language.” But, with the proliferation of Material Design for Android, Story said users are really starting to expect a Material Designed application, not one that has just been adapted from an iOS application, he said.
Since most users want an application that looks and feels like an Android application, companies may have to develop and design their Android apps from the ground up. Story says this is critical for the success of the Android platform.
The unforgiving mobile user
From banking apps to messaging and social apps, people expect their brands to have a mobile presence. Brands that lack a solid digital offering or a mobile presence altogether will see their customers heading over to the next competitor, since it often costs them nothing to switch over, said Thom Kenney, CTO of Applause.
Plus, it doesn’t take much for a user to delete a mobile application, and when it comes to user experiences, many mobile users are unforgiving. Consumer-facing apps, which are still built purely native using Xcode or Android Studio, do not want to sacrifice an amazing user experience for a functional one, according to Michael Facemire, application development and delivery principal analyst for Forrester Research.
For example, applications do not need to have an “Angry Bird experience to do an expense report on a phone,” he said, so enterprises are more likely to make that trade-off. Functionality for applications and getting things done quickly across platforms are more important to the user in this instance, he said.
While mobile users can be pretty unforgiving when it comes to buggy or slow apps, if they are attached to a product, they will usually continue to use it despite persistant problems, according to Jeffrey Hammond, an application development and delivery principal analyst for Forrester Research.
For instance, Facebook fans do not have an alternative to the popular social networking application, so they are forced to keep an application that drains their battery and causes performance issues on their mobile device, writes Russell Holly in an Android Central report.
“People tend not to be very tolerant about quality problems that are not getting rapidly resolved,” said Hammond. “So if somebody takes time to leave a review about your application on the site, and you completely ignore that, then that’s a sign to them that you don’t care and you’re not interested.”
It’s not just the bugs that brands need to worry about, says Kenney. Apps and digital experiences that fail to match a user’s true needs can be just as damaging to the company as bugs in the app, if not more so, he said.
“The stakes are high as people who encounter digital experiences that may work—but don’t necessarily meet expectations—will immediately go to a competitor,” said Kenney.
Testing for mobile-first
The amount of devices, emulators, platforms, operating systems and environments that exist for mobile applications creates a whole set of challenges for testing, and in a mobile-first world, that challenge is only going to persist.
According to Kenney, “emulators can only solve a finite number of problems quality assurance, product, or engineering teams encounter,” which means an app could work just fine in a lab, but fail when a user orders ahead via the Starbucks app on their way to work.
Kenney suggests moving a portion of testing into the wild, so developers can identify bugs specific to each combination of devices, and prevent “show-stopping” bugs from reaching mobile users.
“True in-the-wild testing is the only way to launch digital experiences that consistently work in the hands of users to meet their expectations,” said Kenney. “It is also the only way for developers to really know what the true customer experience will entail since it is testing with real people, on real devices, doing the unexpected things that real people do with their apps.”
Since developers can never test for all the combinations of mobile devices and applications out there, it puts pressure on teams to “test smart,” said Hammond. This means they should do all of the testing that is practical, and skip doing exhaustive amounts of testing.
“They really need to get smart and strategic about what they do and how they do it,” he said.
Testers also need to consider all of the digital experiences offered today, along with the speed or “the necessity of speed,” which leaves them with not a lot of time to test, said Forrester’s Facemire.
He said that teams simply do not have the time to spend three months building an app, followed by three months of it in system tests or functional tests. His solution is to test “on the fly,” with more testing in production.
“That means we don’t spend three months building something and just throw it out there without testing,” said Facemire. “It means we build smaller things, we build more quickly, have smaller iterative updates, and we start relying heavily on analytics and real-time feedback to get details about how well things are working.”
When it comes to device differences, teams developing consumer-facing applications are well aware of the challenges. But enterprise companies are just starting to catch up, according to Syncfusion’s Jebaraj. However, teams that develop consumer-facing applications or enterprise applications need to figure out how to test and target a wide variety of devices and form factors, he said.
This is where Continuous Testing comes into play, especially when dealing with monolithic systems and loosely coupled systems, said Jebaraj. He said that with these systems, teams will look at certain items that deal with functionality end-to-end, because breaks are more likely and underlying issues with code can hide—especially in areas where test coverage isn’t as strong.
Jebaraj added that he sees customers moving toward Jenkins or putting in continuous integration systems so they can trace breaks and make fixes quickly. He said most teams are fortunately able to do much of UI testing for mobile on the back end with automated and unit testing. UI testing can be challenging, he said, but it helps when applications are loosely coupled.
Mobile is also giving a new definition of what it means to be a tester, said Applause’s Kenney. No longer is a tester just a desk job in one location; it’s a global profession where testers can work remotely from anywhere in the world.
“Testing all of the possible variations of devices and locations is daunting for any company trying to do it on their own, so more brands are now tapping into the growing global community of mobile testing,” he said.
Finding developer talent
Another mobile-first trend that Hammond sees has to do with a gap in the number of mobile developers or experienced mobile developers that enterprises can hire. He said developers would be willing to work for large enterprises, but the companies are doing work that some developers are just not interested in.
“There are a lot of opportunities to build all kinds of apps out there,” said Hammond. “Apps for enterprises or apps for employees in enterprises tend to get the short end of the stick from an interest and from a budgeting standpoint.”
Then there is the increase of Android adoption, which leads Story to believe that the industry is going to see more Android-first companies going forward. He said his company noticed that in the past, mobile-first really meant iOS-first, and now the market needs to get ready for companies ramping up their Android application development.
This causes a major problem in some areas, like in New York, said Story. He’s noticed that many companies and startups are looking to build Android apps, but there are not enough Android developers to build them at the moment. A recruiter once told him to plan on waiting six months or so to hire one.
“I know what a lot of companies are starting to do is say, ‘We’re just going to train within.’ That seems to be a pretty common strategy right now, just because the market is so thin,” said Story.
The big challenge in a mobile-first world will continue to be talent, he said, and he recommends hiring managers who think about what their team will do if they can’t hire an Android developer right away, and must consider the alternatives to building out an application.
When to use offline-first application design and development
On airplanes, in subways, or passing through rural networks and congested cities, it doesn’t matter where: Mobile users expect their mobile applications to just work.
This poses an interesting challenge for today’s mobile-first developers, as they now need to approach development from an offline-first perspective and consider things like resource constraints and how to build their applications to work in that environment first.
Bradley Holt, a developer advocate for the IBM Watson data platform, said that there are a few advantages to the offline-first approach of app development.
“Offline is obviously a huge advantage of it, and also for developing countries or places where you have limited or no connectivity, the offline approach is highly valuable in those settings,” said Holt. “I think the actual exciting thing about offline-first actually has nothing to do with offline, and it’s that you can make your application work must faster.”
The offline-first approach actually allows developers to make their applications work faster because they can store all of the content and data locally on the device, which means all of the data access is happening locally, said Holt.
“This makes it really fast to clear your data or update your data or create new records, so you are actually making a really high-performance, responsive application,” he said.
Since mobile users tend to attribute network connectivity issues to the application itself (instead of to Internet access or cellular network availability), it’s important that apps always have access to the core data types and core data that the user needs to be able to use their apps, said Handshake’s Story. This will improve app retention rates, since typically a user will look for a replacement application if apps do not work in low-connectivity areas like subways, he said.
“I think that is becoming the expectation: The app will always work all the time as long as your iPhone or iPad is still functioning,” said Story.
There is of course no one-size-fits-all solution for developing an offline-first application. Mark Murphy, founder of CommonsWare (an Android app development, training and consulting company) said that from a tools-and-techniques standpoint, the issue for developing apps with an offline-first application design “is mostly tied to how much the app is publishing content, versus consuming it, and to what extent others are also collaborating on that same content.”
The appropriate tools to develop a Twitter client app, for example, would need things like offline caching, offline queuing, and a way to know when connectivity comes and goes, including when the app is not directly being used, which is key for any platform, said Murphy.
According to Holt, the abundance of tools, solutions, technologies and even platforms offers additional challenges to developers, who might become overwhelmed with the choices for their company or application. Teams should consider building hybrid or native applications, progressive web apps, and iOS or Android (or both) apps, and then they can navigate the tooling choices that will best fit their needs, he said.