Why The WebView Is The Future Of Mac OS X Apps

Caught between building a web app and a native Mac OS X app, the engineers behind Macaw decided to go hybrid. Here’s why more developers will follow in their footsteps.

Why The WebView Is The Future Of Mac OS X Apps

Twenty years out of date and kludgy, current design tools like Photoshop and Illustrator force designers to create mockups manually. Frustrated by what they felt was an Adobe design monopoly, the creators of Macaw set out to build a totally new kind of design tool.


But when technical challenges popped up, it was an open source project from Adobe itself that saved them–and convinced them that their technology was headed in the right direction.

“We were just a couple of guys who were sick of the way the industry was being run by some of the big companies,” says CEO Tom Giannattasio. “It definitely feels like we were revolting against the options we had.”

“Hybrid” Desktop Apps Use WebViews, Just Like Some Mobile Apps

Historically, there have been two ways to build an app. The first is to create a native app that runs locally on a device–the best choice when performance and native features (like offline mode) are required. The second is to create a web app using HTML, CSS, and JavaScript that lives entirely online, usually a better choice when the app needs to work across multiple platforms or devices.

However, there is a third choice. Building a hybrid app–a native app shell that contains a web app, hosted somewhere else–has been common on iOS for years. If it’s built right, a hybrid app can be fast, smooth, and work cross-platform. The best of all worlds.

“We actually started as a web app so that it would live inside of a normal consumer browser–you would log in, work, configure files on a server somewhere,” says Giannattasio. “And we started realizing that normal consumer browsers have a lot of restrictions, and don’t make for the best user experience for people. We were building a tool for pros, so we thought experience of the utmost importance that it be fast and streamlined for those users.”

The team decided to build a native OS X app, with a UI component called UIWebView displaying the web app they had built. The goal: Get some of the added performance of native software, but still have the flexibility of building a web app hosted somewhere else. But problems popped up right away.


“We started running into problems because Apple throttles performance that you get inside of those WebViews. It was just killing our performance. This was probably the biggest hurdle that we hit. And we were like ‘Well shit, what do we do?’ We know it needs to be native but we can’t get the performance we need,” says Giannattasio.

Talking To Adobe, They Discover The Brackets-Shell Framework

How did they find their solution? Ironically, it was from the company were rebelling against.

“We were so frustrated one night that we left, and I went and had drinks with a product manager from Adobe. He was asking what we’re built on. I told him, and he’s like ‘We’ve got this framework that’s open source.’ And I was like… I did not know that. We literally went in the next day and completely transitioned the app onto this new framework. Now we can suck all the performance that we need out of it and we can start really customizing it. It’s funny right? Because I think our biggest competitors are Adobe, number one, and Google is number two because they entered the space as well,” Giannattasio explains. “We are built on both Google and Adobe’s frameworks: chromium embedded framework. It’s Chrome, just stripped down. And that’s open source. Adobe took that, repurposed it for the big built apps in the same way that we wanted to, and they open sourced that. It’s called brackets-shell.”

This speaks to the weird nature of open source, where bullies are also the benefactors. It also points to a shift happening in business–from competition to coopetition.

“Everyone is helping everyone else. Especially all the small players. We all know each other,” Giannattasio explains. “That’s something about our industry; it’s very community-based and we’re all very friendly. These are just problems that we feel Adobe hasn’t addressed properly.”

Why Are Hybrid Apps On The Rise?

“These hybrid apps–I think people are going to start seeing a lot more of them,” says Giannattasio. “A lot of mobile apps have started to move in that direction and desktop apps are starting to do that as well. I did a lot of work with Apple before starting Macaw and a lot of their core applications are basically just HTML based. I don’t think a lot of people know that.”


Having a hybrid helps work around some of the cons of having a native app that just lives on the computer. App updates don’t need to be downloaded by users, since developers can change the app on the backend. And teams don’t have to have a developer who specializes in each different platform to create the app (since most development is done with web technologies which are cross-platform). It is a little like Java’s tagline “write once, run anywhere,” except it actually (mostly) delivers on the promise.

In addition, as one designer friend mentioned to me, there is a psychological legitimacy to native/hybrid over web. No serious designer is going to open Chrome to design something. It just doesn’t feel like a product unless it has an icon in your dock.

And as Giannattasio points out, more developers can build this way. Since hybrid sites are made with standard web technologies, even people with basic dev skills can manage. “HTML continues to grow really rapidly, and so the possibilities are just growing and growing. People with normal web dev skills can start to build really really advanced applications,” he says.

Why Old Tools Don’t Meet Modern Design Needs

So why does Macaw require a native shell to run? Its because it has twin engines that require a lot of processing power: a layout engine and a design-to-code engine called Alchemy.

“The first layout engine was very similar to Photoshop’s layout engine. It used absolute coordinates,” he says. “But we quickly realized that that makes no sense when it comes to the web, and it wasn’t sufficient for a web designer’s needs. So we moved toward a real-time layout engine that calculated the margins, floats, clears and all the necessary layout logic for you on the fly.”

People refer to this type of tool as “The Holy Grail” because it’s design tool that knows how to code, says Giannattasio. “Basically what we’re doing is we’re hunting down all these relationships in the document in the same way that a developer would. We’re doing is finding relationships between elements and automating that.”


Macaw is the newest, but not the the only player in the space. Both froont and Bohemian Coding’s Sketch app are similar tools–and they have had more time to improve on them. All these tools are working toward the same end: conflating design with development, so that designers can create apps without writing much code.

“It’s really important that we automate the coding process, and implement best practices because, Why not?” Giannattasio argues. “Why should we have to sit there and write out all this stuff when 80-90% of it is the same stuff that we write for every other project? If Macaw understands enough of those best practices, why can’t it just do that for us?’”