Recently, a few members of our team—Front-end development lead Luke Askew, Mobile lead Steve Zeidner, and Strategist Josh Amer—weighed in with some of their thoughts on the “web v. mobile” debate in the hopes that we could shed some light on how the two can coexist and when you should be using one or the other, or both. We covered a lot, so we broke things out into a series of posts. In part one, we took a look at where the web lags behind native (and vice versa) and explored the idea that the web is for information and native apps are better for tasks. In our part two, we explore hybrid apps, using a service-oriented architecture, AI, and the future of this debate.
The Right Way to Build an App
Josh Amer: We’ve been talking about web or mobile, but if you focus on mobile, there are further “either or both” types of decisions you have to make. Like whether you build only for iOS or Android, which really isn’t much of a question our clients ask, or if you build purely native or use something like Xamarin or PhoneGap.
And then there’s the aspect of using web services and a Service-Oriented Architecture (SOA). Let’s start there, since that’s where we tend to land when we’re developing apps. Why are we so focused on SOA?
Steve Zeidner: A Service-Oriented Architecture allows data and business logic to live outside of your application, but be accessible by your application or multiple applications. What that means, is that you can have multiple apps pulling the same data. This lets you, for instance, create iOS and Android apps that are really focused on UI. The data and some business logic live outside of the app and get called in from a service. This is really the way to go if you want to be able to distribute data across your website, apps, and even third party apps.
Luke Askew: I would say that this conversation is a symptom of a larger movement in how digital things are published and consumed. Smartphones, and consuming the internet on devices other than your desktop, really started when the iPhone came out. Before then, we didn’t really have this concept of digital content published anywhere other than a webpage or maybe a CD-rom.
What that means, is that people now have a desire to consume content on more devices, or publish content, and trigger actions to publish content on any device be it a computer, phone, watch, or an IoT device. When you look at all of the platforms, and ways things are consumed and published, that’s where you get into the service-oriented conversation.
That really seems to be where we are headed.
The architecture that allows you to consume information on a phone or a web page also allows you to send and receive information from any device that’s connected to the internet.
If you want your content to be accessible by any device, whether that device exists today or not, then you really need a service-oriented architecture.
JA: In other words, if you want your content to be accessible by any device, whether that device exists today or not, then you really need a service-oriented architecture.
SZ: Absolutely. But, it’s more that that. We really are decoupling data and UI. Once you do that, you can ask some really interesting questions. For example, if you take a news website, you can start to question whether you even need a homepage anymore.
People are looking for the articles, not the homepage. And they find those articles through Facebook, search, whatever. The vast majority aren’t going to yoursite.com and browsing. Articles are distributed by people on different platforms. So, does the concept of having a homepage still make sense? Is it still necessary when the content people want lives in a service and can be published in whatever format a user wants it in? You can just send the content to an app, format it for Apple News, Facebook Instant Articles, AMP, etc. The user behavior has changed, but the industry, for the most part, still designs sites like it hasn’t, like users are still going to your homepage to browse the latest news.
SOA can really come into play, and change the way we think about our work, in big information-heavy sites. The idea of the web is really shifting to “Get the information out there in a way that it’s consumable in any way you want to consume it.” We can really separate the data from the UI and let people consume the content however they want.
Is there Room for a Hybrid?
JA: So from a data and business logic standpoint, we’ve got a great way to serve multiple platforms from one place in SOA. On the UI side of the house, another big thing people are thinking about and asking about, are hybrids and tools like Xamarin that allow you to build the UI of an app without relying solely on native code.
Intuitively this makes business sense. One of the drawbacks you hear about native is that you have to maintain two separate apps—every time you add a new feature, you have double the work. So you’ve got solutions—like Xamarin—that are trying to fit in-between traditional web development models (build once, access from anywhere) and the current model for developing cross-platform mobile applications (build separate iOS and Android apps). The hook is that you can use languages you already know, create an app once and deploy multiple times. What are your thoughts on that?
SZ: Really, Xamarin is the big player. There are also things like Phonegap that wrap a web app, but when you talk about the single codebase idea, it’s Xamarin. There are some things that it makes pretty simple. Like if you are building a form application or anything else where the focus is less on custom UI and more pure function, Xamarin can make those apps really well. You can really build once and Xamarin will distribute across a bunch of platforms.
But, one of the downsides is the fact that the UI and the experience is really the focus of native applications, and Xamarin Forms isn’t as great for developing UI since you aren’t customizing the UI for each platform.
But, one of the downsides is the fact that the UI and the experience is really the focus of native applications, and Xamarin Forms isn’t as great for developing UI since you aren’t customizing the UI for each platform. You end up having a codebase with all of the business logic, which mostly lives in services, and then separate UI codebases for Android, iOS, and other platforms. You still have a lot of maintenance. It’s also running on one more VM. The performance is pretty decent with Xamarin in most cases, but you do have a little more spin up time. Another issue with Xamarin is that, while they are pretty quick to adopt new APIs, there is some lag time if a new version of an OS comes out because all of the APIs have to be wrapped so that a Xamarin user can use it with C# and not just the native Cocoa or Android libraries.
LA: It really only makes sense, to me, to use Xamarin or Phonegap app if you have a very information heavy or form heavy application that in experience is better suited for the web, but needs to access device APIs, like camera storage, in a more meaningful way than you can get with the browser. So maybe something like a home inspection tool, where it’s a line of business application and you aren’t super concerned with experience, but you want to access offline storage, camera, geolocation or other phone APIs in a more robust way. It makes sense to build that as a webpage, for speed and maintenance, then wrap it in Phonegap and deploy it to your entire fleet.
LA: I would say though, in any situation, when you are using a language or platform in a way that it isn’t intended to be used, you have to design around that. It takes a lot of collaboration, a lot of consideration into the technology, design, and UX. There has to be give and take. You cannot expect the great experience of a native app if you are loading something in Phonegap. There are certain things you have to give up, but you will gain in terms of universality and speed to market.
Should you Just Make a Bot?
JA: Let’s switch gears a bit, but still focus on mobile. We’ve talked now about web and native apps, but those aren’t the only tools in our toolbox. One of things that I am continually reading about is the influences of chatbots and AI and the growing roles these will have in the digital ecosystem. In some cases, these could almost be a replacement for a native app. Instead of building a new native app, maybe you just build a bot that can access your services and integrate it into an existing chat app. You see some shades of this from things like Uber integrating into Facebook Messenger. Sure the Uber app was already there, but theoretically you could start a business like Uber today and have it live only inside of Messenger. Is that viable yet?
SZ: I think the viable layer, currently, is really around chat and APIs and combining things to get tasks done. You’ve got things like Zapier, which is a bunch of APIs you can tie together, like If This Then That, that allows you to automate tasks that a person would normally have to do. For example, let’s say you have a recruit coming in. You could just put a calendar entry on their calendar, and then because of that calendar invite a room gets booked, and lunch gets ordered. And you aren’t doing all of these tasks separately; one is triggering the next. That kind of chain can then be integrated into some messaging services. Maybe you use a chatbot to set up the first calendar event, and then the rest all just happens. This is really being used heavily with messaging platforms. Slack is the big one, but HipChat is also a big player. It’s really all about the APIs right now.
JA: Part of what I’m thinking is that there’s this barrier with apps, where people are downloading zero apps per month. But, I’ve probably already got some sort of messaging app. Is it better for me to spend more of my time integrating with that, or creating my own app? Domino’s does this kind of thing with ordering pizza, you can request an Uber from Messenger, Amazon Echo offers a number of opportunities. The list of things you can do without an app or the web, seems to be growing daily.
SZ: Yeah, those tie-ins are really all about making services available. It’s less about chat, unless that’s your core business or you’re making a concierge app for something like healthcare or hospitality, where you might want to just type and get someone to chat with you. It’s more just about the services and creating ways to access.
JA: Right, I’m thinking about AI and its growing role and the growing role of chat bots. These are all ways for customers to continue to access your content and services. And just like we saw a shift from “you can only use the web” to “now you can use the web or native apps” now we are adding further that you might connect with a company via chat.
LA: It fits into an omnichannel strategy.
SZ: All of the AI tools and things like Siri, Google Now, etc. those are all hitting web services to get data back to the app. This conversation really furthers support for the idea we talked about earlier. SOA needs to be a central part of anyone’s digital toolset so you can plug into new opportunities as they come about.
The Future of this Debate
JA: We’ve come to our last question: the future. What do you think this conversation—web or mobile—looks like in five years?
SZ: I think AI becomes much more important. There’s more that’s of interest there than questions about the best way to build an app. That’s what we’ll be talking about in terms of capabilities.
I don’t see much changing in a year on the web or mobile front, maybe ten sure. It’s a slow process, particularly for the web.
The web really suffers from having a standards group. The web standards groups are part of what makes the web great, but also holds the web back. The standards process needs to be better and more efficient. I think if anything changes in the coming years, that’s where you’ll see some change coming from. You’ll have more rapid adoption of standards and implementation of standards so that things can change more quickly.
There are things like battery APIs, vibration APIs, and real-time communication APIs that want to land in the browser, that will allow us to do more experience heavy things on the web. Things currently only done in apps will be doable on the web.
LA: If you look at the standards currently in draft, it’s pretty cool to see what the standards groups are working towards. There are things like battery APIs, vibration APIs, and real-time communication APIs that want to land in the browser, that will allow us to do more experience heavy things on the web. Things currently only done in apps will be doable on the web. But the standards process and the browser vendors and the adoption process is what slows us down. It’s getting better, but it’s going to be years before you can realistically think about using a gyroscope API in the browser reliably across the market.
SZ: Yeah, if you see change it’s going to come from efficiencies in that process.
JA: That’s really interesting and part of the beauty of the web. Even if it is a slower process, you’ve got this standards body, you’ve got people to support the web, it’s hard to imagine it going away. Whereas with apps, you’re really at the mercy of a couple of companies. I mean, Microsoft is possibly completely abandoning Windows Phone, so time spent developing Windows phone apps is now wasted time to an extent. Or even looking further back, Blackberry was the platform of choice for a long time. Now, you’ve got Google and Apple, theoretically either or both of them could kill the idea of apps tomorrow and you’re out of luck. That’s never going to happen with the web.
SZ: Right, you really are choosing between a couple of platforms, and while they are good platforms, there are still profit-focused companies behind them. The iPhone continues to be hugely profitable, but you could imagine a scenario where that’s not the case and support falls off. That’s the good and bad of it. The platform is governed by a company, which can move faster than a standards body, but it’s still building on a platform and you still have to follow the guidelines put out by a company.