The problem for me is as much that excellent Mac apps are being replaced by shitty Electron crap as anything else. I relied on Evernote for ages but then it got rewritten as a sluggish web app and now it's just utterly unusable and I have not found anything that fits its place of being a notebook that lives in native apps on my Mac, iPhone, and iPads, and lets me collaborate on some things with my friends who use Windows and Android.
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.
Desktop apps today are just such a huge regression compared to the past. I was recently looking at software for PDF reading and note taking. I tried all these Electron apps that ran like crap and made the fans spin up on my 2020 MacBook Pro with 32GB. Meanwhile they have far fewer features than a 1990s shareware app. I used Scrivener for a bit but it’s pretty crap about sync so I switched to Emacs with org and pdf-tools. It’s a total hack of elisp and C but it’s vastly more functional than any of the $10/month SaaS note taking platforms out there. Do you remember the essay “worse is better?” Web apps are a manifestation of that.
Interesting, the linux desktop landscape has moved on the opposite direction. Still has a long way to go but has been improving consistently. I often see windows users using aberrations to read PDF's with ads and trying to persuade the user to join an online service like foxit or adobe. On linux, evince has gained very discrete features over the years but works very very well, actually better than before; it probably eats a bit more memory because of the newest libs. Okular is on the same direction but is more feature rich, not surprising considering the KDE heritage.
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.
Yeah, the latest Fedora is getting pretty nice between Gnome and Wayland.
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.
Anyone who’s tried to learn native app development, especially on Mac or iOS, will know that it’s a massive pain in the backside. Documentation is sparse, located in exactly one place, not readable on mobile (!!! the ultimate in irony), formerly available but now deleted, or only available in live video presentation format. I blame the OS vendors as much as anyone.
Native iOS dev is pretty easy to get started on these days, there's loads of material for both UIKit and SwiftUI. From my view it's easier than getting started on native Android dev by a good measure.
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.
I'll mostly +1 this as someone who got into iOS dev and went straight to SwiftUI for the past 2 months.
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.
I had to go bug people I knew who had worked on QuickTime frameworks BITD to get anything done when I worked at Apple the first time, in 2004. It's not and never has been simply an external problem.
Well, nothing now is as confusing as QuickTime 7. I don't think it's possible to write something against that without bugs even if you have the source.
All three of those are orders of magnitude harder to learn than web technologies, which have been backwards compatible for something like the past 2 or 3 decades and see little churn in the APIs. Not saying it’s better, but it is a lot easier to learn, so the vendors need to work a lot harder if they want to compete, which they don’t do, which is why Electron is so popular.
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 only pointless if you don’t believe the iPhone is a revolutionary communication tool that changes how we interact with the Internet, which seems like a strange position to be held by someone on the iOS team.
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.
I don't care how revolutionary one may or may not think it, but it is an extremely horrible tool for a developer actively working on a project and referencing the docs.
To replace Evernote I'm actually really happy with Apple's own Notes app. It's native, it syncs with iCloud, you can read your notes on the web, it supports rich text, per-note encryption, checklists, and multiple folders.
It also runs on Linux and Windows now with only a single codebase. They're not doing this for no reason; it may well just not make economic sense to develop native Mac apps anymore.
That's the key problem, the conflict of interest as separate native apps are much better for users but a single cross-platform app (often web/Electron based) is much better for the developer due to cost, compatibility and maintenance issues.
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.
That's the problem from your point of view. For me, a lousy cross-platform app is a direct upgrade from "no app at all", so I don't anticipate that very many software engineers are going to spend their time designing a bespoke version of their app for >20% of their target audience, even if the experience on that one platform is better. If we lived in a perfect world, every app would have a Qt, GTK3, GTK4, SwiftUI, Winforms and Fluent Xaml version that makes everyone happy. Somewhere you've got to draw the line though.
Linux has native GUI toolkits. If those lazy developers didn't just sit around all day developing Electron clients that worked, we could have a SwiftUI, Catalyst, WinForms, GTK and Qt version that everyone can hate! What a waste of developer resources, amirite?
I've had a totally different experience as a Linux 1password user.
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.
Apple has been busy improving the functionality of iCloud Keychain, including stuff like adding a better UI than Keychain Access, compromised password alerts, 2FA token support, etc.
Apple decided to deprecate Objective-C and AppKit. The Web is far more stable than native UX widgets, breaks less often nowadays and has a larger pool of developers so its Electron all the way for everyone.
And deprecating is not the same thing as breaking or removing. It does signal the preparation to remove. However, Objective-C (last I checked) still works very well.
Furthermore... how would one even remove Objective-C? It's the glue that holds everything together in macOS[0]; removing it would be like removing COM from Windows. Apple would need to rewrite all of their public frameworks in Swift and remove the Objective-C bridges... and, at that point, why stop at just removing Objective-C? Why not kill AppKit while we're at it and make UIKit the only way to present a window[1] to the display? At that point, nobody is going to bother rewriting their apps[2], and the Mac loses all it's developer support.
[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.
Furthermore, like COM is pretty much alive (thanks WinDev), some newer Apple frameworks like Metal are actually written in Objective-C (with C++ for the shaders), Swift API for Metal are just bindings.
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.
Also, as much as Apple gets a rep for putting developers on an upgrade treadmill and breaking old apps, they actually aren't the worst offenders. Their internal rule is "don't break existing APIs without a good reason", and that's something they learned from the Rhapsody dustup[0]. You can contrast this with Microsoft and Google, who follow opposing philosophies:
- 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.
Well, the documentation for Objective-C/C++ has mostly been removed. It's all Swift based how-tos, videos and learning material. You have to hunt Google for getting anything. You get better material for Objective-C/C++ on the LLVM home page. Most of the old Objective-C links are dead.
Perhaps I should have said feature frozen on-the-way to deprecation instead. All new development in lang/ux is happening in Swift/SwiftUI.
I was really loving Scrivener, then I switched to windows and found out I had to buy a new license to use it on windows, back to just simple text files i guess
If you’re ok with something a little more barebones, I highly recommend Bear App. Been using it for years. It’s super minimal, while at the same time allowing you to achieve everything you need to do. One of those tools that just gets out of the way and you never fuss with it. Also great performance and you can sync it across devices seamlessly.
There is still Evernote Legacy, which is the native Evernote prior to the upgraded nightmare version. I have no idea how long they’ll keep it around, but it’s out there.
• 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.
If I could run the Slack or Discord iOS apps on macOS I absolutely would, along with several other apps that have both Electron and iOS apps. Are Catalyst apps as good as true designed-for-mac AppKit apps? Not usually, but they’re still several steps up from Electron apps and I’ll take what I can get.
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.
> If I could run the Slack or Discord iOS apps on macOS I absolutely would, along with several other apps that have both Electron and iOS apps.
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.
It’s a bit more complicated than that. First you need to dump the unencrypted app from its IPA (you can do this on an M1 Mac when SIP is enabled, or a jailbroken iOS device). Then, take the resulting IPA and resign it with a valid provisioning profile and you can then double-click to install it. I’ve been using Slack and Discord this way for months and apart from some minor bugs it’s a great experience.
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.
VSCode is slower than vim, this is true. So are Xcode, Visual Studio and MonoDevelop, so it's hard to say that being native would automatically fix it. But at the same time, VS Code is doing more for syntax highlighting than out of the box vim, and heavily plugin modified vim can get slow too.
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.
But you don't actually feel those differences unless you (a) measure it or (b) have such an absurdly large project or file as to actually encounter these problems. Many people aren't working on supermassive/monolothic projects and VS Code works just fine for my little 100-500 lines-per-file projects. I don't really care if it takes 0.0002 seconds instead of 0.00009 seconds because the end result is that it feels instantaneous either way. Sure if my files were 1,000,000 - 5,000,000 lines of code per file and I was working on massive projects the 8 seconds vs 0.004 seconds would begin to make a massive difference. I don't though and so it doesn't matter.
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).
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.
Look - bitch all you like, but... An electron app is now the most popular editor on the planet. Further - because of Electron I can use every required work app on linux.
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.
You do realize that PWA support on MacOS Is a 100% and on par with windows right?
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've had a linux desktop/laptop for twenty years now and never used an Electon app to my knowledge, so don't care either way. Just curious why both of you seem to think they are required? The "apps" mentioned so far work fine in a browser, or have native alternatives.
For the most part - I agree that electron apps are also usable in the browser, a few of them struggle with the sandboxing that browsers place around file system access.
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.
> 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?
Yeah it's totally cool that we all get to suffer so some masochist linux desktop users get some apps
It amazes me how bad many so called tech companies tech is.
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.
No. It's a simple app, but it's basically not maintained by any one person.
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.
The team behind VS Code are all-stars and they’re backed by an established company with plenty of money to throw and no hard deadlines to meet for profitability. VS Code is also central to Microsoft’s strategy to rebrand themselves as a “good guy” to the dev community.
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.
I haven't used VS Code, but on the other hand, Teams is also Electron and is one of the worst pieces of software I've ever used both in terms of UI and resource consumption.
Teams is much more of a "box checker" cost-cutter sort of project. Microsoft's enterprise customers are already captive, so Teams doesn't need to be good, it just needs to exist to prevent desertion due to lack of a Slack counterpart.
I was amazed when I saw that Finda is an Electron app. It's a single-author Mac-only utility that finds things much better than Spotlight: https://keminglabs.com/finda/
You're supposed to bundle a slimmed-down Java runtime with your app these days, so end-users don't have to deal with updating a system-global "JRE" (which technically doesn't exist anymore, officially).
Other than a couple professional apps, the actual Mac apps I use on the regular are Ulysses, the Affinity suite, nice, little tools like Soulver, and built-ins like Pages. I very much miss the old days of software, not just Mac software — paying for software that was purpose-built, tested, and often, it seemed, liked by its creators was much easier, even at 80s & 90s prices, than dropping $3-$100 on what today is a crapshoot that will likely move out from under your feet with an update six months from now.
Perhaps, though I doubt it. Modern software may have more features and functions, accumulated over time, but what it so often lacks is a good way to encourage discoverability (and can make it much worse — e.g., the Office Ribbon) while making things work better through internal consistency (though that internal consistency was often at the expense of being applicable application-to-application). It's funny how much paid software is so much worse than FOSS options when it comes to actually using it — the FOSS stuff may not look as nice, but it does the job, gives more and better options, and has something resembling documentation. Old software is much closer to FOSS tools than modern paid software in spirit, and much has been lost in the quest for paid-but-cheap.
Isn't the wider issue that developers follow the money. What's a few million Mac users compared to 100s of millions of iOS users? I can charge a buck and sell a few 100K iOS sales but where is the market for MacOS apps to sell? Is there one?
When the Mac market was much smaller in decades past, there were several extremely high quality developers keeping their lights on by focusing on Mac only software.
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.
Well, the main difference is that Mac users are still largely willing to actually pay for software -- they don't demand that everything be "a buck".
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.
Fully agree. And in general, developers won't want to spend too much money on osx-only work because other platforms have (like you said) much more users and also a lower maintenance burden.
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.
> 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.
It's funny to me that there's no acknowledgment that high fidelity web apps and electron apps are taking the wind out of the sails of platform specific desktop app development.
Indeed — they often don’t respect the keyboard shortcuts I’ve come to expect, tab behaviour for keyboard navigation, UI signals that show default enter/space key actions, drag and drop, non-native UI designs, right-click context menus, amongst countless other things. Electron apps “work” but they are noticeably inferior on macOS (and probably on every other platform too).
“High fidelity” web apps, and their electron kin are pretty terrible at basic macOS tasks - they generally use non-Mac shortcuts, and lack many of the standard Mac-isms that make mac software pleasant (for Mac users - obviously matching windows behavior for windows users is fine).
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?
That may be true today but it feels like it's changing, though. And I think it kind of aligns with what the authors are talking about. Apps started today are natively collaborative and they're written with web technology.
I try to stay with the default native apps and programs that comes with the OSes (currently Apple) as much as possible. I have begun to ponder upon and want to go linux once I retire from active work. I try to keep backups of the content in either open or universal formats to be able to move and decouple from Apple smoothly, if needed.
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/
I’m a BBEditer. Have been, since the days of MacOS 7 or 8. Other editors have come and gone, in that time, but I have never found a compelling reason to switch.
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 love BBEdit. One of the very few paid Mac-only apps I use. Almost everything else I use is either free, cross-platform or Electron-based, or a web app.
Anybody have a list of these so called "old but excellent" Mac apps?
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.
Skill sets are being lost. At one time desktop development was the thing. Now its not. Things get memory holes as technology advances.
Not many brick layers around anymore that could build Brunelleschi's Dome.
I think they serve different purposes.
Catalyst is mostly used when you’ve already written your iPad app (either in UIKit or iOS specific SwiftUI) and now you want to make that app available on Mac without rewriting parts of the code.
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.
Agree with the others: SwiftUI is a long, long way from being ready for prime time at this point. In practice you're going to be stuck using a nasty, ugly mixture of SwiftUI and AppKit/UIKit for anything beyond the most basic design, and that way lies madness (at least for me).
But I also agree that SwiftUI is very promising, and I like what I've seen a lot. It's just not there yet.
SwiftUI is still a little rough in some places though it is growing fairly quickly. If you are doing simple UIs where there are already UI components built, it works well, but if you need more custom or more complex you get into the weeds pretty quickly.
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.
To the title I respond: its the same answer as any planned obsolecense argument. People don't like paying for sustainability. Would you wan't to just pay someone to keep using your 1956 Kitchen Aide mixer? Just cause it ain't broke yet? Perfection is not a good business model.
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.