MacGap – Build Native OS X Apps with Web Technologies
macgapproject.github.io
macgapproject.github.io
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
Edit: how about responding instead of downvoting?
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
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.
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 guess I'm just a pedantic dickweed :|
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.
At the end of the day it enables developers to access native APIs such as notifications or file writing through their language of choice.
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
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.
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.
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.
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.
The technology used to deliver that experience is utterly immaterial so long as the experience is there.
I'm sure the GP and I are not the only two people who feel this way.
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.
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.
Maybe it could be better with a performant view layer like React, but I'm not sure. In the end, native apps win.
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.
(This isn't an area i'm familiar with.)
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/
You can also apparently just roll your own if you want: https://github.com/lostdecade/web_view_example
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.
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.
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%.