What's the problem with old but excellent Mac apps?
christiantietze.de
christiantietze.de
I am sort of starting to maybe substitute Scrivener for it. Which is a super-amazing native app designed for writers that sets a pretty high bar for anyone who wants to "continue to improve writers’ workflows in the coming decade and innovate in that space".
Most of the apps I've installed on my Mac lately are to change the way the OS behaves, to be honest. Like, Bartender is useful and makes dealing with all the little utilities that want to live in the menu bar a lot easier. I'm an artist and Illustrator is my main medium; Time Sink's tracking tells me that I've spent about 3.3 days in Illustrator so far this year, and 9.5 days in Safari, and everything else is measured in hours and kinda looks like a rounding error compared to those two apps.
Call it 2factorpass or soemthing.
So the endgame is probably resigning to having lousy non-native software until/unless there once more comes a time with a single dominant/monopoly platform where people just make a single native app for everyone.
I went from a shitty cli and a laggy browser extension to an excellent native feeling 1password app that is fully integrated into my desktop environment. I don't notice any lag, in fact it feels snappier than the native windows version on my handful of years older laptop.
Unlike many other apps I use (Spotify, vscode, intellij, Firefox) I don't notice any difference in system load when it's running too.
[0] And, for that matter, most of their other operating systems.
[1] WindowScene, technically
[2] Astute fans of macOS history might remember this sounding quite familiar. When Steve Jobs bought Apple with Apple's money, he wanted to basically continue NeXT as it was (even the Windows NT port) and replace System 7 entirely with lightly-rebranded OPENSTEP 5 and a VM (dubbed the "penalty box"). This failed so dramatically the whole project was cancelled/rebranded as "OSX Server", and Apple announced Carbon to provide Classic APIs with minimal changes on OSX.
Regarding point 2, that was thanks to Adobe and Microsoft pressure to keep targeting Mac platforms. Sean Parent from Adobe / C++ fame was a key person in this process.
- Microsoft: Don't break existing APIs, period. If the existing one can't be extended, write an entirely new system to replace it (e.g. XAML, UWP XAML) and leave the old system in the OS forever.
- Google[1]: Don't complicate your code with backwards compatibility. If some change would make the code better, scan the entire Google monorepo and recompile the world against your new version, and then tell our AppEngine customers they have about a week to transition.
[0] Carbon wasn't deprecated until 64-bit Intel support happened, and was only removed alongside 32-bit Intel support. A Carbon universal binary can target a disturbingly large range of macOS versions - basically Mac OS 8 up until macOS Catalina.
[1] Mercifully, the Chromium and Android teams actually don't buy into this.
Perhaps I should have said feature frozen on-the-way to deprecation instead. All new development in lang/ux is happening in Swift/SwiftUI.
https://medium.com/geekculture/swift-5-uikit-is-dying-14b475...
https://medium.com/geekculture/swift-5-uikit-is-dying-part-2...
Also at WWDC 2021 there were a few Objective-C talks.
> The Web is far more stable than native UX widgets, breaks less often nowadays
I got a good laugh on those fibs.
Objective-C isn't going anywhere, and AppKit has been mostly unchanged for longer than nearly any front-end framework you can name has existed.
Native Mac dev on the other hand is another matter. The situation has improved some since then, but it's not too different from when I picked up Objective-C + Cocoa/AppKit back in the early-mid 00s, where nearly all instructional material came in the form of print or random tidbits scattered across various developer blogs.
There are some individual doc pages that seem to be auto-generated and a bit sparse when it comes to useful context.
For instance, sometimes X object cannot be instantiated on its own according to its relevant doc and you need to use Y internal API that provides it instead. However, there's no explanation as to why or what can be done instead, which doesn't help someone who's very new to the architecture and frameworks.
It's not like people are developing using their mobile device. I'm sure the online docs are assumed to be read by people on a non-mobile device. I can't imagine trying to read docs on mobile while banging out code on a laptop. Seems pointless, especially if the docs have links for downloading something or what not.
It’s really some of the only documentation I’ve come across that can’t be read on mobile, and it’s all because of a sidebar which isn’t even a good reason.
The pdf reader scenario is just one of many cases the desktop on other OS's became a vector to spread ads while the linux has only improved over time. Considering the popularity of android, it has the same problems as windows in terms of apps being just a way to spreads ads; fortunately f-droid saves me from these.
So, I hope things will continue to improve on the FLOSS desktop. Hope it brings more users too.
With regard to the electron apps... With 4 cores and 8GB of RAM, I really don't care that much about the performance loss. It feels a bit inconsistent sometimes, but I like to know that I'm using the same app as my colleagues on other OS's.
What’s shocking to me is how bad first party software is getting. Acrobat DC kills the battery on my MBP doing, among other things, constantly running some cloud updater thing. It’s worse at browsing PDFs than a decade ago. Same thing for Outlook. They’ve started integrating a bunch of web technologies into it. It actually has less features now than before (tasks and notes redirect you to the website).
And I don’t just mean that the latest version is slower on older hardware. It’s vastly slower on current hardware than the old versions were on the hardware that was contemporary at the time. My work machine is a ThinkPad i7 that boosts to 4.2 GHz. Just hitting Win-Right to snap Outlook to one half of the screen causes it to visibly spasm.
Just apt-get installed xfig. Still works pretty well.
https://skim-app.sourceforge.io/
(For Windows there is SumatraPDF: https://www.sumatrapdfreader.org/free-pdf-reader)
It's good.
• rcmd for faster app switching (https://lowtechguys.com/rcmd)
• Lunar for adaptive brightness on monitors so I can stop fussing with monitor buttons (https://lunar.fyi)
• Soulver for converting between units/currencies and testing math formulas
• Cleanshot for annotating screenshots (because showing people what button to press to solve their issue is faster than explaining it in words)
• TextSniper for copying uncopyable text
• HyperKey for turning that useless caps lock key into some kind of global modifier
• NotePlan for writing stuff down while still being able to back reference it by day
• MateTranslate for super fast menubar language translation
I guess I have a bit of compulsion to always make my every day work more efficient, while in fact I spend quite a lot of time testing these new apps and readjusting my workflow for them.
Now I feel that they’re an essential part of my workflow, and I feel like everyone’s life would be better if they’d use them.
But actually I have mostly met people who, like the article author, rarely get out of their work routine and don’t need more apps because they don’t encounter new annoyances.
Slack, for example, can be absolutely ridiculous.
Unfortunately the companies behind these apps have elected to not allow users to make this choice, so once Universal Control is released these apps will be permanently moving to my iPad.
To clarify the situation for any unaware readers, you can indeed run iOS/iPad apps on M1 Apple Silicon devices however not all. From memory, the policy was actually that everything was allowed to be installed by default with developers having to opt out of allowing users to install their iOS/iPad apps on macOS devices.
There used to be workaround that may still work, but I haven't tried it in some time. You can use https://imazing.com (you'll just have to look past the marketing site for a minute...) to download apps you own as IPA files. Once you've got those, you can use the built-in macOS IPA installer to install those apps, even if developers have marketed them as not installable via the App Store.
https://www.theverge.com/2020/11/18/21574207/how-to-install-... for a bit more info on the process
What did they get right that everyone else fails to?
Most Electron apps are cost cutting measures and this is reflected in the quality of their teams and the priorities of the company. They’re made to check a box, not to be good.
The author has a blog post about how he made it so fast: https://keminglabs.com/blog/building-a-fast-electron-app-wit...
As long as you never quit VSCode it’s pretty snappy.
We have a cross platform GUI app at work which is just a library that wraps the native GUI (Win32/X11 calls). The core interface is basically maintained by one person, but these tech companies seem to struggle with teams and teams of people working on their (say) Slack desktop apps.
How many useful features does, say, slack add? Certainly none that I'm using.
My point isn't that it should be easy, but rather than these companies are utterly directionless and obsessed with solving scaling issues they either haven't hit yet, or don't know enough about to come up with a solution for.
Electron as a UI layer is hands-down excellent.
But that doesn't mean I want to be running performance critical code in JS. Electron supports native addons just fine (and can call out to c/c++ fairly easily), but most companies don't take advantage of it.
Hell - Slack goes from like 40% of my CPU to less than 1% if I just disable emoticon images (seriously - preferring the plain text over the rendered GIF make an INSANE difference in how crappy it is).
You might have the best developers around but using electron will always make your app worse. It bundles all of chromium which is an outrageous waste of space. Chromium in itself is really ram intensive and the new contributions of Microsoft edge to chromium aren’t even added there anyway.
If you need a web front end make a progressive web app and use web assembly technology. Or use a lighter framework like neutralino or tauri JS. You do not need to bundle chromium in every single application.
I literally give almost no fucks how bad electron apps are, because I'm painfully aware of what it was like to try to run a linux box as a daily driver as an employed software developer before Electron - Hint, it involved booting a windows VM. You want to guess what's more of a resource hog?
So, you can go poopooing "that damned new app on my block" all you want, but you don't matter.
Between an electron app, and no app... I will pick electron. if that means I need to spend an extra 15 bucks on ram or hdd... oh the horror!
Would I be happy to see linux native ports? Sure.
But as someone who's not an a blind foolish zealot, I can do some quick math to understand exactly what the cost/benefit of native linux ports are, and I don't really blame companies for skipping them, and I'm thrilled they pick stacks like electron so I get first party support.
Would I like to have more PWAs? Absolutely - go take it up with Apple, who's been a stick in the mud on this front for literally decades now.
Do I think Neutralino or Tauri actually solves this problem? Nope - because it depends on the native webview implementation, system support is a nightmare (it's a modern take on DLL hell from windows - just this time it's missing browser features. You want to guess how many times I still see enterprise machines running ie8/11 as the default webview? It's a fuck load more than you might expect)
Otherwise... take a deep breath. You will survive this "hugely trying ordeal" of having someone ship a slightly larger binary in this day and age of multi-terabyte drives.
Ex: Yes, you can run vscode in a browser, but it has a lot of caveats, and behaves much more like a remote client.
For others - Just having Electron to target is the reason they work in the browser at all. Skype used to require either a windows vm, or a crappy 3rd party linux client - now it's electron native and also works in the browser, and Teams targeted electron out of the gate, making it browser compatible early (although I wouldn't call teams a shining example of a decent app unless you held me hostage)
Etcher is another example - Yes, with WebUSB, you can flash usb devices in a normal tab, but there's just really no reason to have a server to hit at all - the whole process is client local, and having you download it as a local application just makes more sense all the way around (not to mention, gets offline access for free, rather than having to implement it with a service worker).
Another reason to keep them local is that you get a new chromium profile by default. I run discord on a few work machines, but I don't want it to run in the browser profile I use for work, and I'm already juggling 3 other work profiles (dev, staging, qa) and my personal chrome profile - they have a specific set of extensions and settings. It's easier to just treat it like an app if I want it running most of the day - happy to load it in a tab when I'm out and about on other computers, though.
Yeah it's totally cool that we all get to suffer so some masochist linux desktop users get some apps
People keep forgetting that VSCode was born as Web app and only brought into the desktop as means to kill off Atom momentum.
Now Microsoft owns both.
Thanks to Apple we haven't yet replaced Web Developer with ChromeOS Developer on CV requirement listings.
I have taken a deep breath already, since Azure Cloud OS is how I use Linux.
Windows and Mac users aren’t starved though and won’t quietly accept being fed junk apps.
Are you sure about that?
You can get edge or chrome on Mac too.
The problems with WebKit compatibility is more about the functionalities, which is what framework like tauri try to adresses.
Look, I will concede that maybe there’s some specific app where electron really make sense, but there’s no way that applies to all the apps. There’s no way that Trello needs electron, there’s no way that your new pomodoro app need electron. There’s no way postman needs electron too cause there’s literally some people who made an open source PWA version of it, and to get local host support you can just get their chrome extension.
It is no longer : it’s better than no app, cause there are definitely way better alternatives for most electron use cases.
I’ve also downloaded chrome less, which enables me to get a wrapper for figma and Trello. I choose to make them use my safari browser, and both of them takes way less space and are reaaallly faster.
I'd rather use one of the flock of old Scintilla editors.
So why is Microsoft Teams so terrible?
They moved it from Electron to Edge WebView2 on Windows, and said doing so would cut memory usage in half.
https://blog.thoughtstuff.co.uk/2021/06/electron-to-webview2...
VSCode is slower than Emacs/Vim at e.g. syntax highlighting a large file by a factor of three. It’s slower on a search and replace by a factor of seven. It’s slower than those editors by about the same ratio as Atom is slower than VSCode.
I can't say search and replace has ever taken a noticeable amount of time for me, on all my projects and devices it's perceptually instsnt, unless I'm doing a project wide search and forgot to exclude node_modules or something, a performance problem vim avoids by... not having project wide search.
I sped up the RegEx in my application earlier by an astounding 99.92% on average. I run several dozen various RegEx on a string once every few seconds - sometimes even slower. Execution for the end users already _appeared_ near instant and after the improvements it... doesn't feel any faster for the end users. Because the efficiency of my RegEx doesn't really matter at the rate strings are being parsed and for the small size of the strings (<150 characters often in the 30-50 range).
The way now is to use jlinker and create an application specific runtime.
You can run that old software in an emulato if that's all you want. And abandonware is free.
Native Mac apps tend to require recompile and updates for every minor os upgrade. Electron is slow, wastes battery time, and is usually unsafe, but it'll shield the developer from Apple's aggressive api deprecation.
In my experience this varies a lot depending on the type of app. Your typical CRUD app (which the vast majority of apps are) will probably work fine for many releases in a row without needing significant changes to source or even a recompile, but if you're doing anything fancy with hardware or lower-level APIs you're more vulnerable.
Rate of change in AppKit/Cocoa is glacial relative to just about any front end or even back end web framework. Not too long ago I got an early-2000s open source Mac app compiling and running on current macOS over the course of a weekend… there were deprecation warnings all over the place but it worked fine. Meanwhile when I unearthed an early-2010s RoR project, resurrecting it was an exercise in futility.
You could write a combination of Photoshop, Microsoft Office, and AutoCAD, and put it on the iOS app store for $2.99 and people would complain about the price.
1) the absolute number who might pay
2) how much they might pay
3) what sort of software will they pay for
4) how much competition is there to get that customer
Sure, the average developer will target the bigger slice of the pie. But as a user, I don't give a damn about the average developer, I only care about the very best software I can get. And the few developers that targeted MacOS benefitted from having very loyal customers that appreciated high quality software.
Edit: Although it's been a long time since I tried it, this could not be true anymore.
To be completely clear: this isn’t just a “web apps being limited by the browser” issue, because the same problems exist in electron apps.
The core problem I think for new Mac apps is the market for apps that charge enough to cover dev costs has shrunk considerably.
The App Store model encourages software that is priced far too low to be cover costs unless you sell in sufficient quantities, but at the same time it’s created the idea that apps should be less than $10 even on non-mobile platforms. The result is that if you’re not a triple-A game with marketing to match you’re unlikely to be able to charge $60.
That means an indie dev needs to serve as many people as possible, as cheaply as possible. Whether Mac users like it or not that will in general mean things like electron or crummy iOS ports. Even apple’s own catalyst apps can be annoyingly buggy, what hope does an indie dev have?
I continue to experiment and tinker with new tools but after using it, buying/pro/premium it, and I begin to realize I just need to learn a little more with the native apps and I can do that smoothly enough that my muscle memory kicks in. Well, I even subscribed to SetApp[1] and use less than 5 App there at most.
My approach these days is -- I need to be able to own and/or control the content but use any tools, and be able to walk of the tools when needed. I try to keep a note about it and will update that -- https://oinam.fyi/digital/apple/
There’s a lot of “junky eye-candy” out there. Cool-looking apps that actually fall flat, in their primary reason for existing. I will often try one out, then let it lie fallow. Every now and then, one deserves a place in my canon, but it’s rare.
I guess mine would be Typinator. I just picked up a license which is a one-time cost. The product is solid and so is the support. I wish I knew of other types of products like this because I would most likely buy them without hesitation. I'm tired of seeing so many damn subscriptions on my bank statement.
Surely that can't be a good thing?
Even the name gives it away: catalyst is like Carbon or Rosetta — intended to be transitional.
Catalyst is helpful for the near term (next few years?) to bring over more complex iOS apps that use the iOS UI framework. That gives developers a product now while they work on a SwiftUI version or whatever direction they end up going.
But I also agree that SwiftUI is very promising, and I like what I've seen a lot. It's just not there yet.
You can indeed write a multiplatform app in SwiftUI nowadays.
That’s what I’m doing with Volum (https://lowtechguys.com/volum) which easily shares 95% of the code between macOS, iOS and iPadOS, and only platform specific code like keyboard shortcuts or volume OSD is isolated.
But you kinda have to start with that multiplatform mindset from the start, otherwise you’ll soon find out you used too many custom NSViews and Cocoa APIs, your UI is not designed for portrait mode, and it’s a burden to place #if os(macOS) guards all over the place now.