back
54 comments
Hi, as a project contributor and early adoptor I can tell you the following:

Macgap has evolved to Macgap2 which is a complete rewrite thanks to Tim Debo. It's a very fast and lightweight solution that won't get in your way for app store submission.

With Macgap you can also mix native code and html components. I personally prefer it over node webkit which is a very heavy shell (80mb compared to macgaps 1mb).

Overall it's another option to code desktop apps with a web toolbelt. You can throw your favorite js libraries into the mix and get full steam ahead.

Now that swift is out the barrier to go fullstack native is lower than ever but for the one or other there might be a good reason to use web technologies.

Cheers Bijan

I really think this is a terrible idea and wish people would stop making toolkits for these. Also no one should be allowed to claim these are native apps. Its false advertising.
What is so terrible about tools like MacGap, Node Webkit, Atom Shell, etc? They are great prototyping tools and especially useful for things like 'in-house' apps where tools can be rapidly developed and updated as needed.

While the argument could be made that Node Webkit and Atom Shell aren't necessarily 'native' apps, MacGap on the other hand needs to be compiled with Xcode just like any other mac app and can be modified/extended to use any native library/functionality one wishes to use. Ultimately it's simply a starter project with an API built in to communicate from js to obj-c via a webview. It's unclear how this no longer makes it not a 'native app'. If that's the case the Mac App store is not a native app either since it uses a webview i.e. html, css, js for the store's content

Native means code is compiled down to binary and run on the bare hardware. This project says it is explicitly run through the WebView, which is a HTML interpreter/renderer - by definition not native.

Where did he said the App Store is native? He didn't. He said claiming interpreted apps are native is a terrible idea and false advertising, which it is.

So by your definition, any app that contains any code that requires any type of interpreter is no longer a native app? That's just silly.

Nowhere does it say that it has to be run exclusively through the webview using only HTML/JS. Only the javascript API is run through the webview. Whether you choose to use only a webview is up to you, you're not limited to strictly HTML like many other similar solutions.

My definition of a native app excludes applications that are mere wrappers for 90% of the application code. If the majority of an application is written in JS/HTML/CSS, which I have no problem with, then don't call it native, because it's not.

Why would you use a tool if you're not going to make extensive use of it? It may not say that it has to be run exclusively through webview, but if you're only putting 2% of the application through it, why wouldn't you just configure your own web view control?

A native application means the entire application executes on barebones hardware. Web Browers are native, since they don't actually comprise of the web-pages that they run, the web browser is limited to the actual native code that interprets, executes, and renders the HTML/JS/CSS.

I think it's fair to say there is more than one definition of 'native'. When discussed in a performance context, it usually means "compiled not interpreted", as you suggest. But in a different context, it just means an app that you have in your Applications folder, as opposed to something you access by visiting a URL in your web browser. Whether you like it or not, this latter definition is what a lot of people mean when they use the word native. It's certainly how I read the word on the MacGap site - I never thought for a moment that they are claiming to somehow 'compile' HTML into machine code. So I don't think it's false advertising.
How do you feel about things like EVE Online then? IIRC, the game client is mostly python, with the performance-critical bits written in C++ (or is it C? I forget).
Edit: In the context that they're using the word to mean "An Application Available in their Applications/ Folder," I really have no problem with that (as Pointed out in a response to this comment).
It is a native app, in that it can be launched and run natively on the host environment.

Whether it uses GTK, X11, Cocoa or HTML to render its views, it might contain quite a bit of Objective C code. Besides, not every routine needs to be blazing fast and written in Assembly.

Totally agree. What matters most in my opinion is the user's experience. Does the app blend in with the underlying OS? Things like context menus, filesystem access, appearance on taskbars, etc.. are what determines whether it's "native" or not.

The technology used to deliver that experience is utterly immaterial so long as the experience is there.

It's a native window container and plumbing to run an HTML web page. Nobody except you considers that a native app.
The commenter above does :)
Somebody better call up the Slack devs and let them know they're doing something terrible. It's really going to hurt their image.
I know you're being sarcastic, but I hate the Slack mac app. It's very annoying to me to see claims they have a "native" app when it's a shitty web wrapper.

I'm sure the GP and I are not the only two people who feel this way.

Can you please explain why you think it is a terrible idea and why you wish people would stop doing this? If you included that in your original comment it would contribute more to the discussion.
because there's nothing native about HTML/CSS/JS. EVER. It is by definition run through an interpreter, it even directly says "uses webview". So it's NOT native. Calling it native is a LIE.

Edit: how about responding instead of downvoting?

You didn't actually explain why this is a terrible idea?

At the end of the day it enables developers to access native APIs such as notifications or file writing through their language of choice.

It's a native wrapper, so their use of the word native is completely fine. I don't think they're trying to trick anyone here...
by than definition ALL apps are "native". Because if there wasn't some "native" code involved then nothing would run at all.
I really think people should give their reasoning behind such opinions or threads like this become useless flame wars.
For reference, the Slack OSX App uses MacGap.
I'm not shocked. Slack felt to me like one of the least native, and most "just a browser without all the chrome" of any app I've installed in a really long time. It immediately turned me off.

I don't think this kind of technology is inherently bad, and not everything needs to have a perfect native interface. But I don't think people should be mislead into thinking that this will allow you to make apps that feel just like truly native Mac apps.

What? I find the Slack App to be fantastic and I prefer it to using slack.com. The biggest benefit to me is that macgap allows them to use native desktop growl notifications instead of WebNotifications which feel clunkier.

If you already have a great web app and want to allow users to install locally instead of having to keep a browser tab open macgap is fantastic. You can do a minimal amount of work to add great functionality and you dont need to hire a bunch of objective-C devs to clone your web app.

I wish they made a native client. The software seems nice but our team couldn't jump off Skype for performance reasons. Slack always felt just a bit more sluggish than I can tolerate.

Maybe it could be better with a performant view layer like React, but I'm not sure. In the end, native apps win.

Interesting, though the file api is not so useful beyond very basic needs, and tcp/udp seem to be completely missing.

I think the selling point for this over something like node-webkit is that your executable will be lighter since it uses frameworks that come with OSX and you might face less problems getting it in the mac app store.

I think the Mac App Store is not the problem it used to be anymore:

https://github.com/rogerwang/node-webkit/issues/936

About 2 years ago, the original macgap project stopped being maintained, so I'm happy to see that someone has forked it and maintaining it.
Is that why it is being reposted? Cause macgap is really old. There are much much better solutions now and days.
What are some of the other solutions?

(This isn't an area i'm familiar with.)

"Better" will depend on your needs, but things to look at:

Chromium Embedded Framework https://code.google.com/p/chromiumembedded/

Atom shell (based on CEF) https://github.com/atom/atom-shell

Brackets Shell (also CEF based) https://github.com/adobe/brackets-shell

node-webkit https://github.com/rogerwang/node-webkit

TideSDK http://www.tidesdk.org/

More: http://www.trueinteractions.com/

You can also apparently just roll your own if you want: https://github.com/lostdecade/web_view_example

Tide Doesn't look like it's been updated in a while. Looks like it's at the same version from ~2 years ago.
One of them is node-webkit (https://github.com/rogerwang/node-webkit)
Meteor and Ionic
Meteor & Iconic create web & mobile apps, not desktop applications.
Does anybody know how one would go about tracking down problems with your app when using this? If a user reports a problem but they are using a different version of OSX, then they are probably using a different version of Webkit. If the problem is a rendering issue (or some other browser-quirk) how can I emulate their environment and trace the problem? Or do I have to keep a bunch of old Macs around to test on?
The version of webkit would be based on the sdk used and build target of the app, not the end users osx version. So for example, if your build target is 10.9, it will only run on 10.9+ and use webkit from 10.9
Ok thanks. Sounds like I need to study up.
Hm, what is the advantage to using node-webkit that works on several other operating systems as well as OS X?
I just tried building a blank app with node-webkit, and the .app file came to around 100MB. It includes the whole Node/Chromium runtime thing.

With MacGap it's only 1MB for a blank app, apparently. It presumably uses OS X webviews, which don't need to be distributed with it.

Obviously node-webkit has a lot more things going for it, like Node/NPM, and cross-platform support. But the size thing does matter. If you are making a basic little utility app, people are going to be suspicious of a very large download size.

Thanks, now it makes a LOT of sense.
From the docs, "The project exposes a JavaScript API for OS X integration, such as displaying native OS X 10.9 notifications."

The set of extra OSX-related facilities appears to be pretty limited for now. Apart from that, it also uses Webkit, but it uses the one provided by OSX, so it does not need to be distributed with your application. The coolest thing would be if node-webkit could also use OSX's Webkit API, but that seems improbable since it's Objective-C only.

It's one megabyte instead of 80.
This version is Mac App Store compatible.
I don't really want to use a document-centric platform like HTML to build native apps.

If I had to do it though, I certainly would not want those apps to be further limited to just OS X, which hardly anybody wants to use in the first place judging by it's global market share of less than ~6%.

write c/c++/c#/java then
There are a lot more choices than that. I can see using HTML/CSS and JS to build hybrid apps...it sucks, but it can be made to work well...but combining that suckiness AND only being able to deliver on one minor OS? That's a whole bag of nope for the vast majority of developers.