I’ve maintained my Mac project for 20 years for free (despite paying $99/year these days) and I can say quite a bit about the experience.
It is a tremendous amount of work, far more than most people would imagine, just to keep up (i.e. zero features, just keeping the code base in sync with the platform). I ported the entire code base from System-6-style to Mac OS 8, complete with fancy Appearance support and a lot of different callback mechanisms and other OS features of the day. I ported networking code away from deprecated layers. I ported from 68K to PowerPC, to Intel 32-bit, and now 64-bit is required. I ported file management code multiple times to entirely different APIs. I added tons of Objective-C. I migrated compilers from MPW, to CodeWarrior, to GCC, to LLVM. I replaced, painstakingly, thousands of lines of Carbon-style code with entirely different Cocoa idioms. I redesigned interfaces that were once described by Rez input files, to use Interface Builder (multiple times, as IB kept changing). I added code-signing. I split a single-application architecture into sub-processes with OS services. And these are just things I can pick off the top of my head; I am sure there are many more. Again, this is just to keep the damn code working as a nice modern app, before you even add work to make it do whatever it’s supposed to do.
Also, in every single case, it is noteworthy that the OS features I worked so hard to adopt were eventually thrown out by Apple anyway. This means I fully expect 10 years from now that even today’s code isn’t going to “last”. Some of the changes were particularly insulting, I would add, since Apple at the time made bold statements about those APIs being “the future”, and such; for instance, after completely redesigning an application to use the Mac HIToolbox “properly” in every possible way, it really hurt when Apple just decided they didn’t give a damn about Carbon to the point where it wouldn’t even compile anymore a few releases back.
I am fine with this because this is the kind of thing I like to work on. I do wish though that more people would realize how much effort software maintenance really is. Unfortunately, a heck of a lot is hidden behind simple-looking UIs and most programs will be a lot more effort to build than they appear to be.
Apple really needs to stop removing documented APIs. If they want to announce that some APIs have been moved to "maintenance mode", that's fine—just make some effort to ensure said APIs keep working.
Apple is the world's most valuable company, and an independent Mac division would still likely rank in the fortune 500. They are much too eager to effectively offload maintenance burdens to much smaller, individual developers.
I'm not even an app developer—just a power user who wants his wonderful mac apps to keep working! Apple seems to think they're protecting users by forcing developers to update their apps, but they're also pushing developers to non-native technologies like Electron, and I'm quite worried about what their iOS portability initiative is going to do to the landscape.
(I will note that legacy compatibility with precompiled binaries seems to be significantly better than with code; I use some apps that haven't been updated in more than a decade.)
Apple really needs to stop removing documented APIs. If they want to announce that some APIs have been moved to "maintenance mode", that's fine—just make some effort to ensure said APIs keep working.
When I was deep into Windows development, I remember how crazy it was that MS refused to deprecate APIs.
Just the concept of a “string” when programming on Windows could be different depending on the API Microsoft had:
- standard C strings: a null terminated character array
- the standard 16 bit wide character string that was null terminated.
- a BSTR - a double byte character array where the first byte is the length.
- the C++ STL string class.
- a CString - not to be confused with the C style string. This was part of the Active Template Library
- CStringT - it’s been awhile. I have forgotten what this is.
Keeping APIs forever leads to bloat, is a maintenance nightmare, and increases the surface area for security vulnerabilities.
One of the earliest security vulnerabilities that I remember was that it was easy to run shell commands on a remote computer just by escaping the command in IE if the site was running IIS because MS overlooked a type of string encoding.
The worst is COM's apartment threading model, which is still in your face to this day despite being pretty much nothing more than an extremely elaborate workaround for the fact that Visual Basic 6 didn't support threads. (VB6 was released in 1998; it became old enough to drink this year.)
I doubt that VB6 is actually the only justification for COM's apartment threading model. If that were the case, then I don't think WinRT would still have ASTA (application single-threaded apartments). I think the real rationale is that making sure certain code runs on the UI thread is something that applications have to do all the time, even today, even on non-Windows platforms.
If I'm not mistaken, CStringT is just the template class for CString, CStringW, and CStringA. Makes perfect sense :)
My personal favorite is the PCZZWSTR type, which I've only ever seen used by SHFILEOPSTRUCT. Basically it's a null-terminated collection of null-terminated strings. And of course, there's a corresponding PCZZSTR for narrow-char paths.
It’s almost impossible to get developers to move to newer APIs as long as you allow them to use old APIs. Fortunately (?) only two third party developers really matter on Macs - Adobe and Microsoft. The rest either have to come along for the ride or get left behind.
iOS on the other hand is ubiquitous enough and there is no one killer app that people can’t live without, Apple can deprecate and then abandon APIs and pull developers forward.
> It’s almost impossible to get developers to move to newer APIs as long as you allow them to use old APIs.
Even if the old APIs requires the user to manually right click the executable, go into properties, and enable compatibility mode? It's not hard for the user to do, but I wouldn't want it to be my users's first experience with something I made.
When the super-geniuses of Redmond devised WinRT which was supposed to be the savior of it all, they tried to fix this problem with a new string type, HSTRING. It had some additional quirks around NULL that the other types didn't have.
On one hand, I understand the commenters frustration over constantly changing API's. I understand that it is difficult and not fun and a lot of work.
On the other hand, as a user, I appreciate the fact that Apple forces people to update their code. I don't know how true it is, but there are roomers that Microsoft didn't release Windows 9 in fear of code that checked to see if the Windows version started with "9". Look at Windows first party apps, you have things like control panel and settings, two apps that have no excuse for being duplicates besides the fact that Microsoft refuses to stop supporting legacy code.
In my opinion, software is something to be maintained. Maintenance is ugly and isn't glamorous (won't see BBEdit on product hunt anytime soon), but is necessary. I think the user and developer experience would be worth is software written 25 years ago ran perfectly on my computer, I don't want that.
When developers update their apps, that's great! But for every developer Apple "forces" to make updates, there's a developer who decides to just target Electron instead, or an old app that simply breaks.
Makechecks comment reads like an psa for just use electron. Which sucks cause electron is a pig but damn. Code shouldn't bitrot this fast.
Also, re Adobe: idiots at the genius bar basically said it's fine and good that using Photoshop cores a brand new mbp on the latest os, and that's not apple's problem because Adobe hasn't certified the new os. We're getting close to buying this employee a windos laptop that is both cheaper and actually runs Photoshop
I am the maintainer of an application that will be 20 years old this year. It has never been completely rewritten. There have been two involved ports to a newer version of the framework it uses. It is cross-platform, and runs on Linux, Windows and macOS.
It is built on Qt, of course.
I wouldn't use a native macOS/OSX/nextStep api for anything more than the tiniest bit of integration; using Apple's native API's is crazy, for an application developer. Because of the crazy churn, because of the infinitesimal market share, because of the generally awful documention.
This is why I like about X11/Motif and mwm. We wrote an application in 1992 for HP/UX. Since then we ported to Red Hat Linux, GCC and 64 bit.
Most of the changes were bug fixes because we didn't read the C standard when we started.
The largest addition was code that serialize all the data structures so that the flat files could be moved between little endian and big endian machines.
Wow, that's impressive. I've always had a soft spot for X11. I still have fond memories for setting up a FluxBox ubuntu partition on an old socket 478 Celeron. With a now ancient 5900SE, that thing would really fly, and I bet it still would today despite being ancient. Compare that to the sad state of the comparatively bloated OSX/Windows/web with new frameworks every two years that are incompatible with each one just before it and it all makes you quite sad.
This is why I love being a Windows programmer. Microsoft really does take backward compatibility seriously, and the last breakage worth mentioning happened when Vista started to enforce roles and permissions.
This is why I personally don't love using Windows. The user is left with duplicate, inconsistent experiences like Control Panel and Settings, Edge and Internet Explorer, all because Microsoft is too afraid to cut off old APIs.
The truth is probably somewhere in the middle, supporting things longer than Apple, and shorter than Microsoft.
I agree with you although at this point I wish MS would start over from zero with an entirely new OS and then just run all old stuff in some VM. There's too much cruft and they really need a reboot like Apple did with OS9 to OSX
I feel this would be the case having done a bit of MS work my self over the years. But at the same time, I'd say it's also the reason MS don't innovate as much as Apple do. Just a personal opinion.
As an iOS developer, I feel the same. To quote Steve Jobs:
“This is a field where one does not write a principia, which holds up for two hundred years. This is not a field where one paints a painting that will be looked at for centuries, or builds a church that will be admired and looked at in astonishment for centuries. No. This is a field where one does one’s work and in ten years it’s obsolete, and really will not be usable within ten or twenty years.”
That seems by design more than anything. Outside of iOS, plenty of software doesn't become obsolete in ten or twenty years. Even on the Mac itself, you still have all the classic Unix utilities. Will grep ever become obsolete? People are still using vi/m after 42 years despite all manners of new text editors and IDEs popping up.
When it comes to hardware (which is probably what Steve was most concerned about), there's still plenty of electronics that can stand the test of time. I'd say the IBM Model M will be admired and looked at in astonishment for centuries - no modern keyboard has managed to make it obsolete it in the last 35 years.
If there's Amigas running infrastructure and DOS boxes still working in the wild, I'd wager there's still some shop somewhere using an Apple II as part of its inventory system.
From what I can tell (the video, ironically, was taken down) he said this in 1994, which was right at an inflection point. 10 years from there in either direction was a huge change. He'd just shipped the fastest 68k NeXT workstation they'd ever build. 10 years earlier was the original Macintosh, and 10 years later was the PowerMac G5. Obviously there's not going to be much compatibility across those systems.
The curve has flattened out, and the number of architectures has shrunk. I'm typing this on a 10-year-old computer, and it's running modern software just fine.
We're not building systems like we used to. We're taking maintainability into account. Performance is good enough that applications rarely publish hardware requirements. Continuing to assume that everyone is going to throw out their computer (and its entire architecture) in 5 years, so we might as well make developers rewrite everything, is just going to lead to a lot of frustrated developers. A little more care inside Apple could save a ton of time outside of it.
Apple is great at long-term thinking in some respects, and terrible in others.
While grandparent's comment shows an extreme situation, I agree with the quote.
I occasionally see comments here complaining about the ephemerality of the work we do... but I see no other alternative outside of a few domains. I fully accept that the code I will write next week when I get back from vacation won't exist in less than five years.
I have the same experience, to keep up with OS updates alone is a ton of work.
I just realized that the text editor I wrote together with friends in University (still usable and open source) Tincta turns 10 this year. Maybe it's time for some serious update with support for the new programming languages that came out, as well as some UI overhaul. With Tincta we also went through some porting pain, like changes to NSTextStorage, which broke with 10.6 for us and the bug report was answered with "wait for 10.7..." and before that the swift introduction and deprecation of GC.
While I still enjoy writing software for macOS, actually more than for iOS, it's hard for Indie developers. I also wish that people would realize how much work it is to create and maintain software over years and why $1.99 is not enough for every app.
And that’s not really a good thing. Windows is so full of hacks that it is bloated and impossible to maintain. Apple has been able to port the base of MacOS to phones, tablets, watches, tv devices, etc. MS can barely make Windows run well in a Docker container.
Edit:
If anyone thinks this is just me being facetious, they need to read Raymond Chen’s blog with entries about all of the hacks they had to do to keep badly written programs from breaking.
It is your problem - the inconsistent APIs, the slow as molasses updates for Windows, security vulnerabilities etc.
There is a reason that all of the energy and money when it comes to applications has moved to mobile and the web.
Any platform creator has three priorities.
1. The company
2. The Users
.
.
.
.
3. Developers.
Developers will go where ever the users are. You don’t have to make life comfortable for developers. Windows Mobile was a joy to develop for compared to any other platform, but it didn’t matter.
For 11 years I’ve been selling a Mac app I created. It does get monotonous working on the same code base for so long. I find it unenjoyable having to update the app to keep up with modern UI trends, and to cope with changes to the OS.
Things that have happened in the last 11 years include the death of PowerPC support, the introduction of GateKeeper, the introduction and apparent temporary neglect of the Mac Apple Store, the switch to make codesigning effectively required, and the end of life of Apple’s own Java distribution (which was bundled with macOS until a few years ago).
Dealing with these takes time but doesn’t really make my product better. I typically need to have an update ready by the time Apple releases a major OS update, or I’ll have frustrated customers.
This is something I didn’t realise I was committing to when I created version 1 back in 2008.
Of every platform I've used, macOS makes this the toughest.
I appreciate that I have to put in work to add features, fix bugs, and support new OS functionality. But Macintosh is the only one I use where a new OS release means a method call that worked fine with a default param value for the past 8 years causes an instant crash with the latest major OS (with no indication of any change in the documentation or release notes). I'm not even at the point where I can support the latest macOS functionality, because I'm still working around the previous round of deprecations. There are big sections I simply have to rewrite because the old way is going away, and the new way has a completely different structure.
It's also the only system where I basically need to upgrade my (OS, IDE, compiler, language) tuple all at once -- which means this is all tied to the hardware, too. Never before have I had to do a firmware upgrade in order to use the latest syntax in a programming language. My graphics card won't be powerful enough to run the next version of the compiler, even though the software generally gets more efficient with every release. Zany.
It really does seem strange when a new CPU architecture is the least significant change I've ever had to deal with as a developer.
Of course not. If you're developing software, you want to spend the time on improving your offering, not porting to the latest, greatest fad. Every minute I, as a software developer, have to spend on porting my application to a new version of the platform is a minute I'm not improving my application. It's churn, it's waste, it's fire-and-motion: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
It's easier developing for the web, where your code is less likely to break or require drastic changes over time. But yes, almost all businesses need at least some ongoing maintenance.
Try running a PHP app from 2008, today, and let me know how that works for you. There are decent odds it wont run well on modern versions - I can go down and look at every other web technology and point out the same thing - no computer program lives in stasis (except possible on z/OS)
OTOH, an ASP.NET web app written in 2008 and not touched since then would probably still run happily now if you bumped its version up to .NET 4 or 4.5.
C# has had Linq and lambdas since 2007 so there's a decent chance the code would be decently pleasant to work with, too.
Some devs might find 2008 Web Forms apps a bit crufty in 2018 but if you squint and pretend your .aspx is inside a render method issued of a separate file, the mental model isn't all that different from a SPA.
With .net core the writing is on the wall that the full .net framework will go the way of .net 1.1 (the .net team highlighted that it is too burdensome to maintain both frameworks in parallel). I am not sure that the new Microsoft has the same commitment to support legacy code than the Microsoft of the last 20 years.
They've made it clear that .NET Framework will be supported for many, many years. It just won't be getting as many new features. The point of the discussion here is about depreciating and removing and breaking existing tech, which will almost certainly not happen with .NET anything. Note that even VBScript still gets security updates. It's unimaginable that anything targeting .NET Framework will break (short of a bug) for at least a decade, and probably much longer.
That's still just one runtime needing support at a time. OS upgrades happen in waves, and at a cadence you don't choose. Hosted server products, you choose when to update the server stack and you can stop supporting older versions.
for static semantic html its stable. but for dynamic web sites with JavaScript there can be breaking changes. it can get tricky when you do hacky stuff in order to support all platform and older browsers.
I've been using BBEdit since OS9. I love precisely 2 things about it: it takes care to not break, and it takes care to avoid trends.
Everyone used TextMate, then everyone switched to Atom, then Sublime, now VS Code. I've played around with them and it's always a question of spending time trying to get the keymaps "right" and which plugin do I use on X to replicate the functionality of X-1.
You want to yell at Bare Bones and say, you must implement .tmLanguage or .tmTheme support now! You must support Python as a scripting language and get rid of AppleScript! You must, you must, you must!
But BBEdit doesn't break, and when it does release a feature comparable to the rest of the pack, it's solid and "fits", aesthetically and functionally. (Their recent "command-p-alike" is great, for example)
It doesn't have a giant themes or plugin site, but it can open files as big as your available RAM while staying fast. I'll give up a nice TM theme for "always works and never crashes".
(Please make JavaScript for Automation the defacto over AS!)
but it can open files as big as your available RAM while staying fast
This is BBEdit's (and TextWrangler's) biggest asset to me. When other text editors on any platform on any machine choke on large files, BBEdit just doesn't care.
For really big files, I like glogg (https://glogg.bonnefon.org). It's just a viewer not an editor but it handles files larger than the available RAM with ease (multi-GB log files).
Older versions of BBEdit and TextWrangler used to be able to open enormous files (larger than entire system RAM) while remaining incredibly performant. I don't know how they did it, but it was magical and a killer feature.
Unfortunately, that stopped being the case since they refactored the text display UI somewhere around version 9.
Are you sure it was that good with large files? I used to be a TextWrangler evangelist until I noticed it was mangling large files. You'd change one character but the saved file differed by far more than one character. Medium-sized nowadays, hundreds of MB TSV files. About 10 years ago.
Yup. About 15 years ago, doing search/replace on multi-hundred-MB log files and SQL database dumps.
About 3-4 years ago it stopped being nearly as performant with large files (even a couple MB).
I’ve never had a problem with either BBEdit or Textwrangler mangling files. I can believe there may have been such a bug at one point, but I must have sidestepped it - perhaps it was caught and fixed quickly.
Been using first Text Wrangler for the last ~ten years. At some point as my main coding editor and later on as generic txt/md/csv editor. When they sunsetted Text Wrangler, ended up switching to BBEdit. Its trial version's free features are enough but recentely ended up buying the license just to show my support and appreciation. Awesome applications which can handle big files.
As a passing note: afaik Vim can edit files larger than (used) memory―thanks to the mechanism of 'swap files.' The same feature also allows it to restore the editing state after a power failure, even if the changes weren't saved to the original file (it possibly even restores the undo history, but I'm not sure about that).
I didn't think too much about this feature until I moved to Emacs looking for the sane scripting. Turns out, it's very nice to not need a hex editor to open a large file, and to have all editor features you're used to instead.
Yeah, Emacs doesn't have plugins as such. It's a Lisp system, and programs, packages, and modes can modify or extend that system. From what I could tell about vlf, it runs pretty seamlessly, aside from a prompt when you open a large enough file.
The secret is that lots of Emacs commands actually call Elisp code, not the internals of the editor―you can invoke help on a command and then navigate to the code of the function.
(I have to confess that this sometimes comes useful in adding customization to those commands.)
Emacs blew my Goddamned mind one day when I was using M-. to examine the Lisp implementations of various Emacs commands. One day I dug a little too far and tried to examine the source to what turned out to be an Emacs primitive -- but that didn't slow down M-., which happily jumped straight into the Emacs C source to show me the implementation of the primitive. (I had compiled this Emacs on my own, and apparently it remembered where it was compiled.)
AFAIK Smooth scrolling isn't available on BBEdit, and my eyes can't track the code as it scrolls. If you use Cocoa text views or basically anything from NEXTstep way back in 10.0 your view would be either automatically or trivially be upgraded to smooth scrolling over the years. BBEdit seems like a perfect example of what happens when you don't continuously adopt and rewrite to new/modern interfaces.
> It doesn't have a giant themes or plugin site, but it can open files as big as your available RAM while staying fast. I'll give up a nice TM theme for "always works and never crashes".
I don't know what the early versions were like (it was already version 2 when I started using it). But I've been using Sublime Text for the last 6 years and I don't think I've experienced a single crash with it either.
Apple script, then, makes me sad, because is some of those things that, when you build, you have a lot of hope on that and put a lot o effort for it to be nice and beautiful, and imagine how people will love and how successful it will be. The team developing it probably had dreams and believed they were doing something innovative or meaningful. Then the harsh reality is that all the effort and hope in beauty and niceness were useless because the thing you were building wasn't really necessary or useful to the world. The fact that it was a team in a big company makes it less sad, if it was an solo guy or "small family team" then its really sad. I like Automator and think the natural language style of its script is a brave idea, but I found it too complicated to put to use when I tried it years ago, when I was a completely level-zero non-technical, And I would propably find it too basic now that i can do some Ruby and C#. Just as a note, I didnt get, in the end, if its JS or Python you want for Automator, or both, in this last case, please add Ruby too :D
I hope this doesn't turn into a editor war but.... I used slickedit since 1993 Windows 3.1 for Networks and loved it, ... VSCode is the first time I've seriously considered switching because AFAIK it's the only editor that has eslint integration and that's proved invaluable. It's not just eslint linting JavaScript but the fact that their are library specific plugins for things like React, Vue, GraphQL, etc..
I have no idea how well it does for other languages. I assume it does well for C# and typescript.
It does feel (to me with my limited experience) that eslint's plugin architecture and uber configurable rule system are adding something I had not seen in other languages. Hoping that other languages will come up with something similar and maybe more editors will take up the integration.
I came from another platform and tried BBEdit, but never quite got the hang of it. I ended up using TextMate and that's what I've stuck with ever since, largely for similar reasons. Text editors have advanced a lot over time, somewhat surprisingly, but ultimately I need a text editor to operate via the principle of least surprise and be incredibly stable. I still mostly use `vim`, but I am really happy about the state of editors on OS X. It's far better than on my prior platform.
Some of us still do, it's open source now, still getting updates and feels like a modern Mac app, all shortcuts work as expected, find/replace dialogue is a separate window, file panels look and act like Mac file panels complete with blur, smooth scrolling and elastic overshoot act as expected.
it used to cost eye-watering $200 until relatively recently. Big price drop made it an interesting alternative for Mac people over more "modern" alternatives. I've been using it for years (although I'm mostly a Vim person), but its old-school, html-first, nature shows through a bit too much for me.
I liked BBEdit when I played around with it, but my core suite needs to work everywhere, and preferably be open source so I can rely on/contribute to it limping along after the primary authors abandon it.
For a lot of platforms, a company will produce a single piece of good software, and then milk it forever.
For the Macintosh, especially the small developers scene, there is a group of companies that consistently produce outstanding products. If they come out with a new program, you immediately give it weighty consideration because of the quality or utility of previous releases.
BBEdit, mentioned elsewhere in this discussion, is one of those. I'm also a big fan of Panic. I mention Panic because I spent the morning working with its terminal emulator Prompt on my iPad. I also use Transmit and Coda2 at work.
Can anyone recommend other companies worth keeping an eye on for new products?
Can anyone recommend other companies worth keeping an eye on for new products?
Anything coming from OmniGroup is generally great (if you need it). OmniGraffle has absolutely been a life-saver for me. When I have the time, I like doing slide diagrams in TikZ. But I've found that I can typically do in OmniGraffle in ten minutes what would take me hours in TikZ. So if time is a constraint, I will use OmniGraffle to create graphs.
I have also used OmniFocus for a while, which also worked great. (Though it was too strongly focused on GTD for me, so I switched to Things.)
I think that most great Mac apps are made by developers that have only a single app. There are only very few companies that manage the jump to multiple apps (I can only think of Panic and the Omni Group).
Oh, and there's also Rogue Amoeba, with their line of audio apps.
> For a lot of platforms, a company will produce a single piece of good software, and then support it forever.
Fixed that for you. And it's a very good thing of course - a lot nicer than the alternative of pointless "upgrades" that don't actually bring anything worthwhile, or branching out into all sorts of useless projects.
BBEdit was my first "real" text editor, maybe along about 93 or 94. When it came out, it was far, far ahead of any other similar tools on either platform. It introduced a lot of future programmers to regular expressions -- whether that was a blessing or a curse might be debatable.
I tried to make a purchase from Ambrosia last night and it appears that their payment and fulfillment systems are inoperative. I had heard that was the case but I was being optimistic. They may have gone defunct without warning at some point in 2018.
It’ll be a shame to lose gems like Escape Velocity. I know several people (myself included) have asked about acquiring the rights to the games but received no reply. It appears Ambrosia is indeed defunct.
Given how badly my effort to make Mac shareware went back in 2010, inspired in part by their catalog (and Marathon and a few others), I’m not surprised. I wasn’t expecting a grand success, but I only made around £2000 total, including the later iOS App Store stuff.
That reminds me, I need to delete those meta tags from my website…
It’s been twenty years since I last seriously used macOS, but I’ll always have a place in my heart for BBEdit. I still have the BBEdit T-shirt I got when I was in high school, and proudly wear it when I work out. I even have print-outs from back then (remember printing things to read them offline?).
It was an amazing text editor way back then, before I discovered Emacs & when my computer was too slow to run Alpha (and honestly, I don’t think that I really appreciated Alpha at the time). BBEdit was fast, flexible and did everything I could want.
I wonder if they still have my name in their customer database? Maybe my license is still good …
I started using BBEdit in the last few years, and mostly prefer it. I used emacs and vim for a couple of years each, so it's not because I haven't seen/used "better" editors. I think using only AppleScript as a scripting language really holds it back from a broader audience, and personally, I just don't script it, although I do use the option to run scripts on my text from menus, etc. (Any language, Python, perl, whatever.)
I love BBEdit to death because it is the exact opposite of what things like Atom and VSCode stand for. A lightweight, bomb proof text editor that can scroll through 100k+ line documents without a sweat.
Nice article indeed. Two amazing products missing, probably because they came with OSX OmniGraffle and OmniOutliner; both classics that keep innovating and nowadays also run on iOS: https://en.m.wikipedia.org/wiki/The_Omni_Group
”Innovating” ways to make you pay more when you buy Omnigraffle on iOS, and six months later find it doesn’t work any more, but there is a “new” version you can pay full price for all over again.
I understand people like BBEdit, and this article is more than just about the popular editor. FWIW, I tried it, but for me, BBEdit just can’t “defeat” vim, even on mac. Vim is now 27yrs, and actively maintained, and once learned, its power is unmatched imho.
As for graphics conversion, I’ve never used the app mentioned in the article, rather always turned to netpbm, which is available in homebrew on mac.
Still. Much respect for developers sticking to, and maintaining their well liked apps for the long haul.
Most of the BBEdit can fit, however some functionality will be lost.
Similarly, Fetch can fit. If Forklift, Cyberduck, Transmit and DaisyDisk can fit into the AppStore model with minimal losses, Fetch can too.
However there's always a distinct beauty to an application which is downloaded independently and can run on a platform without restrictions. BBEdit has a very distinct feeling to it. It's fast, compact and packed with lots and lots of features. It's fitting into the definition of well distilled and developed application.
I know BBEdit, GraphicConverter, and Fetch use some system hooks to integrate with Finder. I've never used PCalc and can't think of a reason it wouldn't work in a sandbox.
Like many, I really appreciate the role that BBEdit has played on the Mac. There's just one thing about it that really gets on my nerves, and that's the fact that auto-indent... doesn't.
Upvote for Launchbar. When I use it at work people look at me like I’m a wizard. All 3rd deliverable docs from that random project started 3 years ago? cmd + space + couple characters guessed from the title + 1 second, boom, its there.
> Little Snitch is a malware vector, pretty much like PC "antivirus" software.
Wait, what? I personally found it annoying and poorly designed to the point that I uninstalled it, but I'd like to see the receipts on "malware vector" please.
Transmission's native Windows port is relatively recent. There was technically an unofficial "qt" port before that one, but it was outdated and never felt great. Transmission was designed as a Mac-first program, and it really shows.
Transmission's Git repository only goes back to some time before 0.5 in 2005-10-26[0], but GTK support was added 2005-11-18[1], less than a month after the first commit.
Yes, the Linux port has been around for forever. It's just... I don't know, every aspect of the UI has always really felt like it was built around the macOS design ethos first and foremost, with Linux tagging along for the ride.
> Little Snitch is a malware vector, pretty much like PC "antivirus" software.
Is that because the Little Snitch network capture parser can be exploited by magic/malformed network packets to gain kernel privileges? Are there known exploits that were previously patched?
Do you recommend any alternative Mac firewall which doesn't have this problem? Can the native firewall perform outbound packet filtering?
It is a tremendous amount of work, far more than most people would imagine, just to keep up (i.e. zero features, just keeping the code base in sync with the platform). I ported the entire code base from System-6-style to Mac OS 8, complete with fancy Appearance support and a lot of different callback mechanisms and other OS features of the day. I ported networking code away from deprecated layers. I ported from 68K to PowerPC, to Intel 32-bit, and now 64-bit is required. I ported file management code multiple times to entirely different APIs. I added tons of Objective-C. I migrated compilers from MPW, to CodeWarrior, to GCC, to LLVM. I replaced, painstakingly, thousands of lines of Carbon-style code with entirely different Cocoa idioms. I redesigned interfaces that were once described by Rez input files, to use Interface Builder (multiple times, as IB kept changing). I added code-signing. I split a single-application architecture into sub-processes with OS services. And these are just things I can pick off the top of my head; I am sure there are many more. Again, this is just to keep the damn code working as a nice modern app, before you even add work to make it do whatever it’s supposed to do.
Also, in every single case, it is noteworthy that the OS features I worked so hard to adopt were eventually thrown out by Apple anyway. This means I fully expect 10 years from now that even today’s code isn’t going to “last”. Some of the changes were particularly insulting, I would add, since Apple at the time made bold statements about those APIs being “the future”, and such; for instance, after completely redesigning an application to use the Mac HIToolbox “properly” in every possible way, it really hurt when Apple just decided they didn’t give a damn about Carbon to the point where it wouldn’t even compile anymore a few releases back.
I am fine with this because this is the kind of thing I like to work on. I do wish though that more people would realize how much effort software maintenance really is. Unfortunately, a heck of a lot is hidden behind simple-looking UIs and most programs will be a lot more effort to build than they appear to be.