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.
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)
> 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...
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)
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 :)
[+] [-] toomim|5 years ago|reply
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|5 years ago|reply
[+] [-] jbroman|5 years ago|reply
[+] [-] aantix|5 years ago|reply
What can native do currently that js/html would have difficulty with?
[+] [-] jitl|5 years ago|reply
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|5 years ago|reply
> 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...
> 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...
[+] [-] spilk|5 years ago|reply
[+] [-] gwbas1c|5 years ago|reply
One thing I've always wanted is a Chrome plugin to redirect links into a dedicated fluid application.
[+] [-] tribeca18|5 years ago|reply
[+] [-] hundchenkatze|5 years ago|reply
[0] https://kofi.sexy/blog/multi
[+] [-] hkgumbs|5 years ago|reply
[+] [-] shp0ngle|5 years ago|reply
edit: oh I see... single notifications and simple switcher. OK, seems reasonable enough
[+] [-] stevewillows|5 years ago|reply
[+] [-] econcon|5 years ago|reply
[+] [-] saagarjha|5 years ago|reply
[+] [-] archildress|5 years ago|reply
[+] [-] rasen58|5 years ago|reply
[+] [-] ngcc_hk|5 years ago|reply