
MacGap – Build Native OS X Apps with Web Technologies - ingve
http://macgapproject.github.io/
======
hit8run
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

------
laveur
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.

~~~
EGreg
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.

~~~
juliangregorian
It's a native window container and plumbing to run an HTML web page. Nobody
except you considers that a native app.

~~~
EGreg
The commenter above does :)

------
taylorlapeyre
For reference, the Slack OSX App uses MacGap.

~~~
zippergz
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.

~~~
trose
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.

------
bwindels
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.

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

[https://github.com/rogerwang/node-
webkit/issues/936](https://github.com/rogerwang/node-webkit/issues/936)

------
liamk
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.

~~~
dubcanada
Is that why it is being reposted? Cause macgap is really old. There are much
much better solutions now and days.

~~~
goatforce5
What are some of the other solutions?

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

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

Chromium Embedded Framework
[https://code.google.com/p/chromiumembedded/](https://code.google.com/p/chromiumembedded/)

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

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

node-webkit [https://github.com/rogerwang/node-
webkit](https://github.com/rogerwang/node-webkit)

TideSDK [http://www.tidesdk.org/](http://www.tidesdk.org/)

~~~
joeblau
Tide Doesn't look like it's been updated in a while. Looks like it's at the
same version from ~2 years ago.

~~~
bonif
They rebranded as Tidekit [0] , I've been following their Twitter account for
~ a year now, but it's still vaporware

[0] [https://www.tidekit.com/](https://www.tidekit.com/)

------
teleclimber
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?

~~~
tjsix
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

~~~
teleclimber
Ok thanks. Sounds like I need to study up.

------
tmikaeld
Hm, what is the advantage to using node-webkit that works on several other
operating systems as well as OS X?

~~~
callum85
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.

~~~
tmikaeld
Thanks, now it makes a LOT of sense.

------
WorldWideWayne
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%.

~~~
bonif
write c/c++/c#/java then

~~~
WorldWideWayne
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.

