Low-code for mobile: Toys or tools?

https://ift.tt/eA8V8J

Mobile developers tend to be skeptical about the effectiveness of low-code tools when they know exactly what native iOS and Android development takes. In fact, some developers are so turned off by low-code platforms that the very mention of them triggers a passionate response.

“Low-code is bad enough, but low-code for mobile is even worse. The speed benefit is a farce with platforms like React Native,” said Dary Merckens, CTO of custom software development firm Gunner Technology. “The device integration is often way, way, WAY worse than React Native as well because so many low-code platforms just use stuff like PhoneGap to wrap a mobile web experience into an app form.”

RELATED CONTENT: Low-code/no-code development heats up

Since writing custom Swift or Kotlin code can be “brutal” enough that one could argue in favor of low-code platforms on that basis, low-code is still a no-go from where Merckens sits.

“Heck, writing a PWA is a better option than low-code solutions at this point, but I’m sure low-code companies don’t want people to know that because they’re making bank duping people,” he said.

One size does not fit all
There’s an entire range of low-code/no-code platforms aimed at different audiences including professional developers, web developers and business power users, which their UIs and features reflect.

“If I define myself by the act of writing code and crafting code, really get into the details and the weeds, I’m going to have an incredible amount of skepticism that lets someone who’s not as skilled as I am accomplish the same result,” said Jeffrey Hammond, VP and principal analyst at Forrester. “If you look at something like Quick Base, which is being used by business users, the tool is actually building React Native applications, it’s just not doing it from the command line like a professional developer would do.”

So, if native code is the end result, producing the exact same outcomes that could be written manually, what’s the difference? Granular control.

“The benefit of native development is you don’t have any constraints, but then again, you’re having to develop two applications for iOS and Android,” said Mark Runyon, principal consultant for software architecture and development firm Improving. “Most of the low-code I’ve run into used Cordova, which is a hybrid platform. With a hybrid, you’re developing one-shots that are not necessarily as clean and performance-enhanced as a native approach.”

Experts agree that there is room for low-code and no-code solutions in an enterprise, but say thought should be given to where they’re most likely to provide the best return.

“There are many platforms available and each has their own learning curve. They also have different, often cluttered UIs, with [so] many options to choose from that it can get overwhelming,” said Ahmen El Awadi, lead developer at web development firm Best Response Media. “Businesses with complex app development logic and compliance needs may find it inconvenient to integrate these low-code tools into their existing stack.”

Why a developer would choose low-code
Speed is the obvious benefit of using a low-code platform. When the demand for application development and maintenance exceeds what the development team can deliver, options must be considered. Some of the work might be outsourced. Alternatively, mobile developers might write a progressive web app (PWA) or use a low-code platform to avoid writing apps for individual platforms.

“It’s really an intersection of different technologies with a different approach to building the application and you see lots of different takes on how to do that,” said Forrester’s Hammond. “The reason to pick a low-code tool is to accelerate development efforts.”

More professional developers might be more inclined to use low-code tools if they could see what they’re capable of doing and how they’re doing what they do. Then again, there has been an explosion of developer-oriented productivity enhancements among tools generally over time. Arguably, low-code platforms are just another time-saving alternative. 

“It’s the same reason people picked up Visual Studio for C and C++. Some are happy to accept a higher level of abstraction for speed,” said Hammond. “Business users don’t care about how beautiful the code is which is why they are most likely to accept low-code tools. They’ll use something like Betty Blocks or Quick Base and maybe a web developer with PHP or HTML experience will choose Mendix or OutSystems.”

Still, mobile developers aren’t exactly plentiful. According to Forrester surveys, the average number of mobile developers at a large company is only 10 to 15. 

“That’s enough to build two apps, so you can build your customer-facing application and maybe one more strategic application for employees or business partners,” Forrester’s Hammond said. “Who’s going to build the other 50, 70, or 100 things when you need to mobilize your business processes or you need an app that’s going to support a workgroup? It’s not going to be mobile developers, so as long as we have this supply and demand problem, there’s going to be a market for low-code tools that help people who aren’t professional mobile app developers build apps.”

No-code tools are aimed at business users, while low-code tools are aimed at professional developers or web developers. Neither Forrester nor Gartner recognize “no-code” tools as a product category. In their view, low-code tools fall along a spectrum of low-code and lower code. The latter is visual, while the former is more likely to support command-line coding where necessary.

“Low-code platforms have not matured enough in the capabilities required to design and develop the native app functionality that mobile users like and have come to expect, whether it’s consumer or mobile apps,” said James Hoshor, senior mobile strategist at technology consulting and reseller Anexinet. “I have yet to see mobile apps in the public app stores or used in enterprises that provide native functionality, support complex business processes [and deliver] the functionality needed by enterprise mobile users today.”

In his view, low-code falls short of native code and mobile app development platforms (MAPDs) in several ways, including performance, delivery of native app/device functionality, responsiveness to different form factors, the ability to implement asynchronous operations and the ability to easily perform and manage iOS and Android OS updates. 

Glenn Gruber, another senior mobile strategist at Anexinet, said there are other ways to improve efficiencies without using low-code tools, such as Swift UI and Kotlin, which create more efficient and declarative code since what used to take hundreds of lines of code can now be done with dozens of lines of code.

“If you’re rebuildling apps that make the business run, I would not go for [low-code] tools,” said Gruber.

App evolution may be a problem
Low-code tools enable organizations to accomplish more in less time. In an era when time to market has become competitive table stakes, organizations, particularly those on the digital transformation path, need to find a way to get everything done.

What isn’t obvious to business users, but what can be blatantly obvious to professional mobile developers, is that low-code applications may be constraining over time if they don’t scale well. Alternatively, an app a business user built with a no-code tool may work fine for workflows, but it isn’t the kind of enterprise-grade app the department or enterprise requires. 

In other cases, mobile developers may inherit low-code or no-code apps built by less-skilled people whose intentions exceeded their capabilities or who became so overwhelmed by their day job they couldn’t continue working on the app.  

“What I usually run into is the client reaches a point where they need the app to do something special. I can’t just take the brick they give me and plug that in,” said Improving’s Runyon. “That’s where it gets a little challenging and tricky coming from a low-code perspective.”

Runyon sometimes needs to rewrite apps entirely from scratch just to ensure the app is capable of doing everything his client wants it to do. 

“I’ve never found a client that’s been able to say, ‘I’m willing to restrain my requirements and I understand that it can’t do this and I’m OK with that,’ ” said Runyon. “In that case, you could use a low-code tool to do a prototype and tell them if they’re good with it we could continue and wrap it up. If you want it to do these specialized things, it’s going to take three to six months.”

Setting expectations is always critical when laying out the respective costs, benefits, and limitations of the various options, whether the developer is a consultant or an in-house developer. Of course, as most experienced developers have learned the hard way, their clients may not know exactly what they want until they see it or they see one set of capabilities that opens their minds to new possibilities.

“I’ve seen use cases in Fortune 500 companies where low-code apps have been built to do one specific thing, they do it well, and it’s perfect for what they need. However, needs tend to evolve over time,” said Runyon. “The devil is always in the details. Low-code is great and it looks good on paper but when you need an app to do that last 10 percent, it can become really hairy and nasty. You just need to be aware that you could potentially hit problems with the low-code approach that you would not have with the traditional development approach. If you need to get to the market quickly and you can constrain the requirements, low-code may be exactly what you need.”

Increasingly, organizations will find themselves with a mix of traditional developers and non-traditional developers all writing mobile apps, albeit not the same mobile apps. Since speed and efficiency requirements aren’t going away, there’s an argument in favor of having an overall portfolio strategy that considers app development more broadly to eliminate such things as app development inefficiencies that may not be apparent otherwise, redundant app development across departments and unnecessary friction between developers and non-developers who build apps.

“[Having a portfolio strategy] is important, especially as things grow. For example, Aetna is a very large Quick Base user. I think they have over 1,000 people building applications inside the organization and because of that they’ve had to build a center of excellence in the IT organization that helps those folks if they get in over their heads,” said Hammond. “The center of excellence gives them advice, shares best practices and puts together some guidelines and things they should be thinking about as they build their applications. As the investment grows in the organization, that level of governance becomes important.”

Although some low-code apps may be difficult to maintain, Kevin Grohoske, practice director of Business Automation at digital advisory services firm Sparkhound, has observed the opposite.

“Most organizations are too over-burdened with ongoing maintenance costs to build new solutions. Some organizations may have to dedicate 50% – 70% of their annual budget just to maintain their existing solutions. Leveraging a low-code/no-code platform can significantly reduce ongoing maintenance costs as the business needs change,” said Grohoske.

However, rather than leading with tools, a sounder strategy is to understand the specific business requirements and then determine if a low-code/no-code platform can provide the desired feature set. If a platform doesn’t support the “must-have” mobile feature, then it may be unlikely that the platform can be extended to achieve the desired feature. Even if the low-code platform can be extended, doing so would reduce the value of using a low-code/no-code platform in the first place, Grohoske said.

Richard Salinas, managing director of Business Automation at Sparkhound, added that storage can also be a problem.

“There’s a limit to the device’s storage with a low-code/no-code app since the underlying platform ‘hosts’ the app,” said Salinas. “A native, purpose-built app has its own storage and can better control its footprint. Low-code/no-code apps are not [appropriate] for every business need since they are typically better suited to single purpose functions with a low storage budget.”

Times have changed
Organizations have always had power users willing to forge their own solutions because they couldn’t wait for IT to build something, although historically that development has been more desktop-based than mobile. In today’s always-on world, mobile devices have become the choice for staying connected and getting things done quickly, which has driven the demand for hybrid low-code tools.

“One of the biggest differences we have now is we have folks that grew up as digital natives. It’s easier for them to articulate what they want to do and how they want to interact than the previous generation, so I think there’s a larger potential market of folks that could use [low-code and no-code] tools compared to what we saw 20 years ago,” said Forrester’s Hammond. “If they’re willing to find the right components or look for the right code samples, even if I want to use something that needs the camera or the microphone or the GPS, I can accomplish that in practically every low-code tool out there.”

The post Low-code for mobile: Toys or tools? appeared first on SD Times.

Tech Developers