
DefaultApp - Amorymeltzer
https://tyler.io/default-app-for-mac-ios/
======
andymatuschak
There's a lot of discussion in the comments here about Electron vs. native
apps. But last year's Catalyst project, which allows you to ship iOS-based
projects on the Mac, opens an important new path. I've been surprised not to
see many people discuss it!

In particular, this means that you can use React Native to build native macOS
apps. You still get live reloading, hot code push, pleasant abstractions, etc.
Most importantly, though, these apps can use straight-up AppKit controls on
macOS and straight-up UIKit controls on iOS. Better still, you can use react-
native-web to ship such projects on the web too.

You will+should, of course, have many platform-specific branches. But I find
that the vast majority of my code is shared, and there's a _world_ of
difference in being able to use the same development tools to ship polished
software on desktop, mobile, and web.

My most recent project builds to macOS, iOS, Android, and web out of the same
Typescript project. There was certainly some toolchain chicanery involved in
this, but now that it's set up, it's delightful.

Many of the companies shipping Electron apps on desktop are shipping React
Native apps on mobile. I would very much like to see React Native-based
desktop apps replace Electron apps.

~~~
sgt
As a user I don't want a React app. I want a native app.

I can understand why you as a developer don't have time to maintain the
different platforms, but for a UI app running on my laptop or desktop I care
about one platform and that is macOS.

It's okay if it's Mac only and many apps are.

~~~
scarejunba
Yeah, but let's be honest. Most users don't want a specific app. They want
functionality. They'll pay for functionality in a React App while eschewing a
native app without the functionality. The practice of this means solving the
problem the fastest is the most important part. And if someone can rapidly
build a native app so be it, but if they can only rapidly build React apps
that's what they should do.

Or they can do otherwise and they'll learn.

~~~
franga2000
> Yeah, but let's be honest. Most users don't want a specific app. They want
> functionality

True, but they also want to be able to run it without bringing their crappy
laptop to a crawl. Devs excuse their inefficient code with "modern hardware is
fast enough", but it ceases to be fast enough when the majority of your apps
are inefficient. Try running Slack, Discord, Skype, Spotify and a couple
Chrome tabs on a last-gen laptop. And now try to run something actually useful
(Office, a game, whatever). You can't.

I've seen completely non-technical users say "ugh, another web app".
Alternatives are few, so users won't use something else, true, but that's not
an excuse to keep making inefficient apps.

(I realize this doesn't apply nearly as much to React Native, but only React
was mentioned above and this is a rant I've had prepared for a while now...)

------
alxlaz
Reading the comments here, I find it very distressing that people in our
industry can _simultaneously_ say the following two things:

1\. Consistency is extremely important for UX and one of the cornerstones of
user-friendliness

2\. Users who aren't developers probably don't care too much about "native
look and fell".

If users, indeed, don't care if some applications don't look and can't be
handled like other applications, maybe it's time we judged designs more in
terms of innovation and usability, and less in terms of compliance. I haven't
seen a new icon set, application theme or website that didn't look like any
other icon set, application theme or website in years.

If they _do_ actually care, then maybe let's admit that. I'm not advocating
for burning all JavaScript to the ground, but it would certainly help if we'd
treat inconsistencies as bugs, so that we could use frameworks like Electron
to write better (i.e. more consistent) applications, rather than hand-waving
them as unimportant, except in topics about UX rather than Electron, in which
case they're totally important.

~~~
_fat_santa
I think that there is a way these two points can live in the same universe.
One the one hand users expect a consistent UI, especially on mobile. While
apps are free to define their own user interface and style, they should follow
certain patterns that other apps in the past have established.

When I hear the other point that users dont care about UX what that boils down
for me is they don't see all the little things that we see. They still expect
a consistent user interface but seeing a menu not render exactly where it
should, an animation that stutters for one frame or other small things. These
are all things that we as developers scrutinize but the user doesn't notice
all that often.

Now we should still scrutinize those little things. I feel like the thing that
makes some apps feel more "magical" than others is how polished those little
details are.

~~~
dmitriid
> They still expect a consistent user interface but seeing a menu not render
> exactly where it should, an animation that stutters for one frame or other
> small things. These are all things that we as developers scrutinize but the
> user doesn't notice all that often.

I find it's the other way around. Quite often it's the developers who don't
care if a menu is out of place or if an animation stutters.

The users, however, _do_ see these things. They might not be able to
articulate it, but they _will_ see it. And call your app slow (animation
stutters), unpolished (menu not rendered where it should) etc.

That's why, for example, MacOS has been getting so much flak these past years:
they've stopped sweating the little details, and people _noticed_.

------
h4il_s4t4n
> Native Mac apps feel like a dying breed that are succumbing to janky web
> views

Yeeaaahhhh, not really. I was a diehard "native" person until recently and I
can't believe just _how much better_ developing for web technologies is than
writing native Mac.

If you're experienced enough to write a polished Mac app (and that is a non-
trivial undertaking) you're experienced enough to write a polished front end
in Electron.

Use a lightweight framework (e.g., Vue), be sensible about what you're asking
Chromium to draw for you and unless you're doing something really simple -- be
ready to write a backend in C++ or equiv.

I'm not saying that is easy, but in terms of complexity it's a wash. The
upsides are substantial:

1\. Multi-platform with very little additional work

2\. Modern web standards + a good IDE are _so much fucking better_ to work
with, really

3\. Easy to drop into WebGL if you need it

4\. Less vendor lock-in

The only place I see it making sense is if you're _only_ working with a single
platform -- of course, you have to ask yourself how good of a business
decision that is.

~~~
vintagedave
This is a judgement on cost, and you're advocating for cheap app development
for you.

But what about the cost for the users of your app?

* Huge memory impact for your app

* Non-native look and feel (no, neither Vue nor anything else give a native app experience)

* Possible security holes, as Electron is patched behind Chrome, and your app therefore behind Electron

* and more.

What you're asking is that to ease your job, you give your customers a non-
native UX (subjectively "bad", but that judgement is something I think most HN
readers would agree with); and you value their computer resources very little
(ie you don't respect your users' computers and are happy to waste their
computing memory and CPU.)

Electron is the solution when a developer values themselves over their
customers. Now, you can make an argument for that, such as getting your
minimum viable product out to market quickly. Over time, as the app develops,
the attitude of happily giving your user lower UX quality and wasteful
applications is harder and harder to justify ethically, though I admit that's
only true if predicated on a foundation that you should respect your customer
or have pride in your work.

~~~
autoconfig
> Electron is the solution when a developer values themselves over their
> customers. Now, you can make an argument for that, such as getting your
> minimum viable product out to market quickly. Over time, as the app
> develops, the attitude of happily giving your user lower UX quality and
> wasteful applications is harder and harder to justify ethically, though I
> admit that's only true if predicated on a foundation that you should respect
> your customer or have pride in your work.

You're entitled to hold this opinion but preaching it as if it is an objective
truth and thereby disrespecting other developers is just obnoxious. Luckily
the users can decide for themselves what is unethical or not. I have 5
electron apps open right now (Spotify, Slack, Figma, VS Code and Notion) and I
find it absolutely absurd calling the devs unethical because of their choice.
They have provided me with some fantastic value. Is it great that they take up
~100MB of memory each? No but it's not even close to as big of a problem as
some devs try to make it out to be. 8 gigs of RAM is around 30 bucks. Get off
your high horse.

~~~
ubercow13
The RAM thing is disingenous. Even on a desktop it could be more expensive
than that to add more RAM, say if all your memory slots are populated. If you
have a Macbook with soldered RAM, it could cost you a new laptop and thousands
of dollars to get more RAM. But I guess Spotify is worth it.

~~~
autoconfig
Nowhere did I mention upgrading. The example was meant to give a general
estimation of how much RAM costs and establish a frame of reference for
statements like "huge memory impact". If RAM still cost say $100 per GB the
situation would be entirely different.

~~~
ubercow13
I don't see how that's relevant. Upgrading is the point - previously the
user's PC was sufficient, and now it is not as it is runing slow. Now the user
has to buy a new computer. In the past they might have to do this to use the
lastest games or such. Now it's necessary in order to run Spotify and Slack.

------
karakanb
Shameless plug: I did a similar thing for browser extensions to have a fully
functional browser extension with Vue and Tailwind in under 30 seconds:
[https://gumroad.com/l/XUPxA](https://gumroad.com/l/XUPxA)

I actually like the idea of opinionated starter kits a lot, especially when
built out of experience over multiple projects they show a lot of maturity,
tailored for a specific workflow. Depending on the developers, these kinds of
kits are mostly made for specific use-cases, and they pick the technologies
already so that once the project is kicked off most of the non-crucial
decisions are already made. Most of the time I have found myself thinking
about which database library to use, what Docker image to deploy, which UI
framework to use and all these kinds of decisions that have not much value add
if all the other alternatives are getting the job done as well. If I were to
start building a native macOS app, I'd definitely go for something like this
because I just want to get to the core of the thing, not spending time on
choosing libraries or thinking about where to put files.

Great job!

~~~
misiti3780
What do you think of Tailwind - about to pull the trigger and buy it

~~~
karakanb
Overall I enjoy it a lot, it gave me a big productivity boost. Everytime
someone talks about Tailwind there is a huge discussion going on here, but I
just gave it a try a couple months ago and I really enjoyed it. The thing I
love the most is, I can get something going without thinking about what
padding to use, how to align things, what color palette to use and all that
kind of stuff, while also having all the flexibility to change things at the
end. YMMV, but I think you wouldn't lose much by trying that out, the worst
case is you spend couple of hours and you don't like it, but a better outcome
is you spend couple of hours to save yourself tens of hours, so I think it's a
good bet.

~~~
misiti3780
thanks, i just bought tailwindui!

------
Klonoar
Welp, if we're gonna do the same tired arguments (Electron, etc), I guess I'll
go ahead and inject another HN-meme into this thread. Let's talk about Rust.

I, like many, want to write the same code across platforms. I do not want to
use the JS toolchain (the modern one, Webpack & co). I don't want to use C,
because writing C feels contrarian outside of certain cases given the options
available today. I want something that's fast, safe and mostly cross-platform.

So I started porting AppKit to Rust. There's an example you can see here -
it's meant to feel similar to writing native UI in Swift.

[https://twitter.com/ryanmcgrath/status/1238285152771440640](https://twitter.com/ryanmcgrath/status/1238285152771440640)

I plan to put this in a longer blog post, but effectively I don't think write-
once-run-anywhere UI works for the class of products I want to build. I don't
mind rebuilding the app UI using GTK, AppKit, or what have you... provided I'm
not running some ridiculous setup just to get code shared across platforms.
Rust and Cargo do incredibly well with this.

I'm building my next product in this as a way to dogofood and force the
functionality in. If you're interested in following along, you can check out
the repo below - note that it's still experimental, the example app
(Subatomic) has not been updated for recent changes yet, and the main repo
doesn't have docs being built just yet (though I'll probably have this later
this week).

Anyway, that's my bit - wondering if there's a better way to achieve cross
platform code without the headache, so consider this another foray into
getting there.

[https://github.com/ryanmcgrath/appkit-
rs](https://github.com/ryanmcgrath/appkit-rs)

------
weiming
Tangential: we've been using xcodegen
([https://github.com/yonaskolb/XcodeGen](https://github.com/yonaskolb/XcodeGen))
to generate our projects from a simple yaml file. Don't need to muck around
with Xcode toggles, easily repeatable, and .xcodeproj literally stays in
.gitignore. Never know why Apple consistently shyes away from more
programmatic generation of stuff.

------
tbergeron
The fact that we need such boilerplate solution to start building a simple Mac
app without having XCode in the way in 2020 means a lot about the current
state of native app development.

~~~
Klonoar
Eeehhh, this kind of comment erases a lot of the default things you get with
Cocoa/AppKit (document handling, system integration, etc). These concepts
aren't as widely understood as the concepts in web-dev-land because they're
implementation specific, but they're pretty well designed and genuinely very
powerful once you use them.

Xcode just hides them away from you, is all.

------
yingw787
Is there anything like this default app framework maintained for GTK or TCL or
whatever the native KDE / GNOME framework is available for desktop Linux? I
exclusively use Ubuntu as my OS for three computers, and I'm building out some
front-ends for myself, and native desktop clients aren't cheap to make (in
time and effort).

------
ashishb
Great idea. I created a similar template for my personal projects which use
`Go + Docker + Google Cloud run` stack - [https://github.com/ashishb/golang-
template-repo](https://github.com/ashishb/golang-template-repo)

------
gregoriol
Nice! A lot of the things included are helpful.

Title should mention that it's about macOS though.

------
tptacek
_While it certainly works for me and serves as the basis for all of my apps, I
don’t know yet if it will work well for others the way my PHP framework has
over the years._

It will definitely work better for people if the source code isn't all tagged
"All rights reserved", in conflict with the MIT license. :)

~~~
JoshTriplett
While it's confusing, "All rights reserved" isn't actually a license and
doesn't conflict with MIT; it's effectively just a (now-redundant) part of the
copyright notice. It's been redundant for a long time (since the Berne
convention), but doesn't strictly speaking do any _harm_.

~~~
antoncohen
This is correct. "All rights reserved" was a way of claiming copyright,
similar to the © symbol. Open source non-public domain code still has a
copyright, it is just licensed for use under an open source license.

[https://en.wikipedia.org/wiki/All_rights_reserved](https://en.wikipedia.org/wiki/All_rights_reserved)

------
fulldecent2
In a similar effort, here is a minimal Swift module (i.e. a reusable code
package) which can be used a starting point for new projects:

[https://github.com/fulldecent/swift5-module-
template](https://github.com/fulldecent/swift5-module-template)

------
simon1573
Does something similar exist for, lets say, iOS or Android? A good foundation
to build upon.

------
jeffkeen
Tyler! I knew I recognized that name/company. I bought VirtualHostX eons ago
and it helped me out a lot. This sounds like a great project, this guy makes
good stuff.

------
s3cur3
I've been toying around with a macOS app idea for awhile. This looks like a
great starting point for someone like me with no macOS native dev experience.
Thanks!

------
uk_programmer
I do the same. I have my own for flask website setup with SQLite with user
signups etc all configured. I also have some JavaScript SPA projects
configured. I can clone the git repo and start doing something useful in a few
minutes and all my scaffolding work is done.

While there are scaffolding tools already available sometimes those scaffolds
are a bit too bare bones and you need to add some other common bits and
pieces.

------
worldsayshi
There's no mention about how it is licensed?

~~~
tylerhall
OP here. Thanks for pointing out that omission. It's MIT like all my other
stuff. I've updated it.

------
debt
Should add support and all the boilerplate for NSDocument and CoreData. That's
a bit more robust DefaultApp.

Love this though.

------
spxcxlxxs
I created something similar for front end js applications
[https://github.com/spicalous/webpack-
scaffold](https://github.com/spicalous/webpack-scaffold)

using: webpack, babel, sass, auto-prefixer, eslint, chai, karma, mocha

------
Jaruzel
I have something similar I use in Visual Studio - it's a module file full of
useful functions, that saves me rewriting the same code over and over again
for each new app.

For example, I have GetFile() and SaveFile() functions which I use ALL the
time, also as I'm on windows, I've wrapped up a bunch of Registry code into
nice 'SaveRegValue' and 'GetRegValue' functions.

All in all there's about 50 or so functions in the module. Personally, I
thought every coder did this?

Edit: I'm not dissing the OP, just surprised that there's value in sharing
these things.

~~~
masklinn
That seems to be a very different thing. You’re talking about a utils file /
module you’re carrying around, OP is about a ready-made application template
(à la cookicutter).

~~~
tasogare
Did you read the article? It mentions "Two helper classes that make building a
typical macOS source list easy." which is exactly what OP is talking about. So
helpers classes, while not being all the project presented here, are an
important part of it.

~~~
masklinn
> Did you read the article?

I'm wondering if you did.

> It mentions "Two helper classes that make building a typical macOS source
> list easy."

TFA goes much further than that, it's an actual working application in a box.
You can copy the template, build it, and it runs.

A template can include utilities, not the other way around.

> So helpers classes, while not being all the project presented here, are an
> important part of it.

They're an important but relatively minor sub-set of the whole.

------
me551ah
Native apps beat Electron/Web Apps anyday. There are many areas where Native
apps have the upper hand w.r.t Electron.

Memory Usage

A few years ago while trying to figure out why I was running out of RAM, I
stumbled upon chrome’s task manager. Gmail was using up 700MB of RAM and all I
had open was the Inbox. No fancy search box or Compose, the Inbox was taking
up 700MB of RAM to display lines of text in a Tabular format. I’ve been a
heavy user of Email clients and if you pick any of the native clients
(Thunderbird, Outlook, Apple Mail) and open a bunch of searches and compose
windows the memory usage will still stay below 100MB. I used mIRC a few
decades ago to connect to multiple chat servers, run my own bots, serve files
over DCC and run scripts all while staying under 20MB of Ram. These days to
send a text message over Slack I need over 1GB of RAM. Even basic apps with
all of their trackers, external javascript scripts and doms take up 100s of
MBs in memory. And the most common solution to running out of memory is to
close chrome windows.

Battery/CPU Usage

DOM is slow. Updating layout and repainting is even slow. Javascript being a
dynamic language is slow. Web apps are anything but simple these days and
since they have to work under the limitations of all the slow components, the
CPU ends up making up for it. Chrome is almost always present in my Macbook’s
‘Using significant energy’ tab. On the other hand, I rarely if ever see native
apps in the battery bar unless I’m doing something which should actually
consume a lot of CPU cycles like running multiple synths in Ableton or
Compiling. When apps are built for mobile, battery usage is a major area to
optimize on. But nobody even gives it a thought for web apps

60 FPS

Mobile apps run on 60fps, Native desktop apps run at 60fps, Games run ( or at
least are designed to) run at 60fps. Instagram on chrome starts at 2-3 fps and
usually hovers around 30fps. My laptop which is supposed to be more powerful
than my mobile phone is only able to churn out half the frame rate even though
they are both running at the same resolution! Web apps are not buttery smooth
and can be jerky at times. Sure somebody can work really hard and optimize a
website to run at 60fps at all times, but it needs a lot of effort. Mobile
apps run at 60fps out of the box without much effort. Mobile and native apps
use the GPU a lot more efficiently. Since they have a lot more information
about which controls are being used, they can recycle items a lot better and
do a much better job at hardware acceleration via the GPU. Not to mention that
you have access to raw graphics APIs in case you want to push UI performance
even further.

Runtime Environment

You can build desktop apps in a plethora of languages and even for mobile apps
you have many cross-platform frameworks. But building for the web(and
electron) forces you to HTML/Javascript(and derivates). Javascript is a
dynamic prototypical language that was not designed for the scale of apps that
are being built in it today. It has no type safety, memory leaks are common
and it’s slow due to its dynamic nature. While there have been many efforts to
improve performance like V8s JIT, it still lags behind a lot of major
languages. WASM seems promising, but it’s still has a long way to go. And it’s
laughable how weak the browser platform itself is. SQLite is available on
raspberry pi, embeddable systems, mobile platforms and just about every other
platform on the planet. You can store data, run complex relational queries and
do more with so less. But it is not available on the most widely used platform
on the planet, the browser.

With the rise of electron apps, big and bulky web apps have started making
their way onto the Desktop. There are some who are even trying to get the same
apps on mobile via PWAs. While the web has the advantage of easy
accessibility, IMO we have sacrificed too much in terms of user experience for
that one convenience. If you built an app with the same UI and functionality
in a native language and as a web app, the native app will run circles around
it.

------
mrunkel
Thanks for sharing. For me getting started is always the hardest thing, so
something like this helps a great deal.

------
sgt
This is very useful - definitely bookmarking this to remember for the next
time I write a macOS app.

------
julius_set
I’m sorry to knock down OP here but I’ve been doing Mac development for a long
long time.

A default app to me as a bare minimum involves:

• Custom Application class • URI specifications • Custom NSDocument • Custom
window controller • Customized NSToolbar • CoreData support • “Feature”
targets / I.e. Todo target

I’ve written a script which sets and generates all this for me:

macapp new —with-ui —styles

~~~
tylerhall
OP here. I think we're aiming for the same thing - though with slightly
different priorities.

Of your list of minimums that DefaultApp omits:

Not every app adheres to a Document-based pattern. The apps I personally build
typically fall into a "shoebox" style where explicit documents aren't used.

And there are other data layers than CoreData, which is why I didn't add that
- especially since even with CoreData everyone has their own favorite
library/framework. So that's easy enough to drop-in for those who want it.
(That said: probably 95% of the apps I write use CoreData, so )

A customized NSToolbar would be great, but, again, there are so many
implementations out there, which one would you pick that would satisfy the
majority of apps/developers?

Anyway, like the accompanying blog post says, this project is "highly
opinionated". It's just what I've cobbled together over the years. I'm not
going to die on a hill for any of my particular choices. Do what works best
for you.

------
nerder92
My 2 cents, Flutter for the desktop will disrupt this market in the near
future.

------
Timpy
I've never worked in macOS before, is there something exceptionally difficult
about decent boilerplate code?

------
eximius
I think the real sentiment I see in the comments about "using web tech instead
of native is selfish/unethical/etc" is:

why isn't there a desktop technology that can compete with the ease of
development as using web technology?

I feel this very much. I'm building a _reeealy_ simple app and I'm looking at
Svelte Native (Svelte + Nativescript) to get things going. But even that's not
quite native. But Android and iOS development are also a mess.

~~~
pjmlp
Qt and wxWidgets come to mind.

Definelty easier than making divs pretty with CSS spaghetti.

