6 ms·

Show HN: Create a custom macOS app from a group of websites

170 points by hkgumbs 6y ago

hundchenkatze 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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.
  - jaflo 6y ago
    Did you have experience developing for MacOS before?
    - hkgumbs 6y ago
      I built a few Swift CLIs before, but this was my first time working with AppKit (the macOS GUI framework)
  - hundchenkatze 6y ago
    Yep the macOS + Xcode dependency is quite annoying. If you want a, kind of, in between solution, the true dependency is on the command-line tools[0]. These can be installed independent of Xcode. You could piece together your own build scripts or use something like Buck[1] to build it. If you still want a full-blown IDE, checkout AppCode[2] from JetBrains. It still depends on the aforementioned commandline-tools though. [0] https://developer.apple.com/download/more/ https://developer.apple.com/download/more/ (you'll need an AppleID) [1] https://buck.build/setup/getting_started.html https://buck.build/setup/getting_started.html [2] https://www.jetbrains.com/appcode/ https://www.jetbrains.com/appcode/ * edit: formatting & it looks like Buck doesn't have macOS targets.
  - macintux 6y ago
    Make sure you see this comment (I take no blame or credit for its accuracy). https://news.ycombinator.com/item?id=23277219 https://news.ycombinator.com/item?id=23277219 Very cool project, thanks.
jitl 6y ago
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 6y ago
  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/0e3aef8559b634cea28c08559d8e338bc21eb419/DarkNight/main.swift#L13 https://github.com/saagarjha/DarkNight/blob/0e3aef8559b634ce... > 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/DetailsViewer/Swizzler.swift https://github.com/saagarjha/DetailsViewer/blob/master/Detai...
  - hkgumbs 6y ago
    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 6y ago
      Yeah, an actual Info.plist is much better :)
tribeca18 6y ago
This is really cool! The inspiration behind creating this reminds me of another app too: https://getstack.app https://getstack.app
archildress 6y ago
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 6y ago
  Where does that fit into this macOS app?
- ngcc_hk 6y ago
  Don’t get this. Anything to do with this macOS app?
toomim 6y ago
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.
- aantix 6y ago
  The JS performance in mobile safari is pretty incredible. What can native do currently that js/html would have difficulty with?
  - toomim 6y ago
    Did you read the article? This has nothing to do with mobile.
- hadtodoit 6y ago
  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.
  - IggleSniggle 6y ago
    While I don't entirely disagree with your sentiment, this is pretty distinctly not middleware/crossplatform/electron. The closer analogy here is the iOS ecosystem, where folks ship apps that are really just Safari WebViews inside an app icon, and who would probably be perfectly happy to ship a PWA if users weren't thoroughly trained to use the AppStore.
  - M5x7wI3CmbEem10 6y ago
spilk 6y ago
Sounds similar to the old Fluid website wrapper for MacOS X ( https://fluidapp.com/ https://fluidapp.com/ )
- gwbas1c 6y ago
  I love fluid apps! One thing I've always wanted is a Chrome plugin to redirect links into a dedicated fluid application.
shp0ngle 6y ago
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
econcon 6y ago
Those with Mac development experience. What's the earliest way to make a screenshot app?
- saagarjha 6y ago
  Depends on what you're trying to screenshot, but CGWindowListCreateImage is probably the function that you want in most cases.
stevewillows 6y ago
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

170 points by hkgumbs 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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.
- jaflo 6y ago
  Did you have experience developing for MacOS before?
  - hkgumbs 6y ago
    I built a few Swift CLIs before, but this was my first time working with AppKit (the macOS GUI framework)
- hundchenkatze 6y ago
  Yep the macOS + Xcode dependency is quite annoying. If you want a, kind of, in between solution, the true dependency is on the command-line tools[0]. These can be installed independent of Xcode. You could piece together your own build scripts or use something like Buck[1] to build it. If you still want a full-blown IDE, checkout AppCode[2] from JetBrains. It still depends on the aforementioned commandline-tools though. [0] https://developer.apple.com/download/more/ https://developer.apple.com/download/more/ (you'll need an AppleID) [1] https://buck.build/setup/getting_started.html https://buck.build/setup/getting_started.html [2] https://www.jetbrains.com/appcode/ https://www.jetbrains.com/appcode/ * edit: formatting & it looks like Buck doesn't have macOS targets.
- macintux 6y ago
  Make sure you see this comment (I take no blame or credit for its accuracy). https://news.ycombinator.com/item?id=23277219 https://news.ycombinator.com/item?id=23277219 Very cool project, thanks.

jitl 6y ago

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 6y ago
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/0e3aef8559b634cea28c08559d8e338bc21eb419/DarkNight/main.swift#L13 https://github.com/saagarjha/DarkNight/blob/0e3aef8559b634ce... > 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/DetailsViewer/Swizzler.swift https://github.com/saagarjha/DetailsViewer/blob/master/Detai...
- hkgumbs 6y ago
  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 6y ago
    Yeah, an actual Info.plist is much better :)

tribeca18 6y ago

This is really cool! The inspiration behind creating this reminds me of another app too: https://getstack.app https://getstack.app

archildress 6y ago

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 6y ago
Where does that fit into this macOS app?
ngcc_hk 6y ago
Don’t get this. Anything to do with this macOS app?

toomim 6y ago

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.

aantix 6y ago
The JS performance in mobile safari is pretty incredible. What can native do currently that js/html would have difficulty with?
- toomim 6y ago
  Did you read the article? This has nothing to do with mobile.
hadtodoit 6y ago
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.
- IggleSniggle 6y ago
  While I don't entirely disagree with your sentiment, this is pretty distinctly not middleware/crossplatform/electron. The closer analogy here is the iOS ecosystem, where folks ship apps that are really just Safari WebViews inside an app icon, and who would probably be perfectly happy to ship a PWA if users weren't thoroughly trained to use the AppStore.
- M5x7wI3CmbEem10 6y ago

spilk 6y ago

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

gwbas1c 6y ago
I love fluid apps! One thing I've always wanted is a Chrome plugin to redirect links into a dedicated fluid application.

shp0ngle 6y ago

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

econcon 6y ago

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

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

stevewillows 6y ago

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