
Show HN: Create a custom macOS app from a group of websites - hkgumbs
https://github.com/hkgumbs/multi
======
toomim
I'm into this. I've wanted to build something like this before, too, but never
finished it.

This feels closer to how app building _should_ work. If I have a web app, it
_should_ be simple to give it an icon, with notifications.

And if I want to build that, I _shouldn 't_ have to figure out all of XCode. I
should be able to just quickly make a webview with native controls.

And I _shouldn 't_ need to download all of electron. An OSX webview should
only need a few kb as a standalone app.

~~~
hadtodoit
Please, no. Your application belongs on the web. I can already tell when
applications are written with middleware, cross-platform tools, electron, etc.
because they _always_ run like trash. They offer no benefit over a website and
only open up your machine to new attack vectors. I know I'll catch flack for
this, but we shouldn't lower the bar to entry here. Native app development is
not significantly more difficult than web and it's drastically better for the
end user.

~~~
toomim
It sounds like you didn't read the blog post:
[https://kofi.sexy/blog/multi](https://kofi.sexy/blog/multi)

The problem this solves is that web apps don't have (1) cmd-tab icons or (2)
decent notifications. And it does that _without_ using "cross-platform tools"
or "electron". That's why it's cool.

~~~
comex
The web _is_ a cross-platform tool. It's fine for what it is, but it can't
provide an experience that feels native, or runs nearly as fast as native.

~~~
ta17711771
PWA is coming.

------
jitl
See also the blog post:
[https://kofi.sexy/blog/multi](https://kofi.sexy/blog/multi)

The swift-only, programmatic approach without Xcode or the typical app
framework is very cool! Assembling those parts seems like a great learning
experience.

(More interesting to me than the actual functionality)

~~~
saagarjha
A couple of nitpicks about the process:

> NSMakeRect/NSMakePoint

Generally I prefer the actual constructors.

> NSWindow.BackingStoreType.buffered/NSApplication.ActivationPolicy.regular

You can just use .buffered/.regular.

> let _ = NSApplication.shared

Just _ = NSApplication.shared works:
[https://github.com/saagarjha/DarkNight/blob/0e3aef8559b634ce...](https://github.com/saagarjha/DarkNight/blob/0e3aef8559b634cea28c08559d8e338bc21eb419/DarkNight/main.swift#L13)

> Rizwan Sattar wrote a neat workaround that monkey-patches NSBundle, which
> I’ve translated to Swift 4 below

Don't do this, it will stop working (crash!) once you update your Swift
version and the compiler is smart enough to start making direct calls. As far
as I am aware, this is the correct way to do it:
[https://github.com/saagarjha/DetailsViewer/blob/master/Detai...](https://github.com/saagarjha/DetailsViewer/blob/master/DetailsViewer/Swizzler.swift)

~~~
hkgumbs
Thanks, these are nice clean ups! I added a note in the blog post that points
to your Swizzler example. The final version of Multi didn't end up needing
that NSBundle monkey-patch though since it was a "proper app" with an
Info.plist file.

~~~
saagarjha
Yeah, an actual Info.plist is much better :)

------
spilk
Sounds similar to the old Fluid website wrapper for MacOS X (
[https://fluidapp.com/](https://fluidapp.com/) )

~~~
gwbas1c
I love fluid apps!

One thing I've always wanted is a Chrome plugin to redirect links into a
dedicated fluid application.

------
tribeca18
This is really cool! The inspiration behind creating this reminds me of
another app too: [https://getstack.app](https://getstack.app)

------
hundchenkatze
This is pretty neat :) I read the blog post[0] about it too, and I definitely
feel your multiple chat app pains. I'm curious to hear more about why you
avoided Xcode and ViewControllers. In general I know many people dislike
Xcode, but I've been doing iOS dev for a while now so I guess I'm used to it
(it's a love have situation for me at times)

[0] [https://kofi.sexy/blog/multi](https://kofi.sexy/blog/multi)

~~~
hkgumbs
Thanks! Honestly my reasoning for avoiding XCode is fairly thin—I just hadn't
used it before and didn't have it installed when I started. I imagine if I
took the time to learn it, it would be fine. But I do also feel a bit weird
about how developing for certain platforms requires you to use a specific IDE.
I thought that was part of the goal of Swift (vs ObjC), but I may be just
reflecting my own biases :)

~~~
cerberusss
Recently I wrote a script in Swift, on macOS. It can be developed and run
without Xcode, in plain vi if you so wish. It's pretty great, and I liked it a
lot.

~~~
hkgumbs
Yup, that was exactly my workflow as well! And for building CLIs it's quite
nice. Once I started using AppKit though, it felt like I kept running into
things that weren't quite finished.

------
shp0ngle
I’m probably missing something... what’s the positive of using this instead of
just opening a few browser tabs?

edit: oh I see... single notifications and simple switcher. OK, seems
reasonable enough

------
stevewillows
pretty slick. For web apps, I've been using this as a zsh alias to launch
whatsapp and a few other similar sites without any toolbars (etc)

    
    
        /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --app=https://web.whatsapp.com --kiosk

------
econcon
Those with Mac development experience. What's the earliest way to make a
screenshot app?

~~~
saagarjha
Depends on what you're trying to screenshot, but CGWindowListCreateImage is
probably the function that you want in most cases.

------
archildress
The iOS image recognition, done on-device as I understand it, is one of the
coolest things that it seems no one talks about.

~~~
rasen58
Where does that fit into this macOS app?

