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.
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.
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.
The interpreter is native, but the code that runs on top of it isn't.
In interpreted code, something like 'var i = 0;' could result in 100+ instructions, from the compilation/parsing of the script, to the actual running of that statement, and then the final execution on the hardware.
In C, `int i = 0;` WILL result in 2 instructions -
movl $0, -4(%rbp)
movl $0, %eax
By this standard, no interpretted languages are native. That would mean for example that Android has no native apps at all, because they're all written in Java.
There are already terms for what you're talking about: compiled applications, or binary applications.
"Native", to me, simply means an app that does not run in a browser. It is irrespective of language. Reasons this distinction might matter include the degree to which the code is sandboxed, OS and hardware features that the code can access, the distribution method, or the extent to which the app can run without network connectivity.
Well, I guess I think there are kind of two levels of nativity. Operating System native, i.e. uses API's from the OS directly.
But then I think there's also hardware native, which means the IR that the code gets compiled into executes directly on the hardware.
Both Java and C are compiled into a binary IR (Intermediate Representation), C is executed directly on the CPU (provided it's in the proper format: ELF, etc...), whereas Java is run in a compatibility layer, the JVM, which interprets the IR into native machine instructions.
I don't think Java is hardware native,but it can be OS native, making use of features or APIs that are OS dependent.
I feel like Android itself is native, it's compiled into direct machine code by each vendor, but I don't feel that the applications that run on it are hardware native, but they are native to Android, in that Dalvik and Hotspot bytecode are incompatible with each other's respective VM.
I'm no expert but I believe most modern javascript engines now compile Javascript JIT. In fact I think Apple recently added LLVM to their Javascript engine.
Node.js runs Javascript local to the machine in the V8 engine, which compiles it. As I understand it, that is architecturally analogous to running Java locally in the JVM. So I think that practically speaking, Javascript and Java are not so different from one another in how they access the hardware resources of the machine.
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.
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
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.
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.
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%.
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.
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