The old guard of Mac indy apps has thrived for more than 25 years
macworld.com
macworld.com
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.
The truth is probably somewhere in the middle, supporting things longer than Apple, and shorter than Microsoft.
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.
It's still in production.
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 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.”
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.
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.
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.
But you can’t run 68K Mac software or PPC software on a modern Mac. Should Apple still include 68K and PPC emulators in MacOS.
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.)
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.
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
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.
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.
VC++ is... interesting.
This would basically be a modification of the "least permissions" principle—only expose old APIs to programs old enough to need them.
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.
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.
Just a nit; Microsoft is currently $30 billion over Apple in market cap.
It goes back and forth here of course.
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.
Let Microsoft worry about how to keep Windows running and I'll worry about keeping my own applications running.
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.
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.
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.
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.
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.
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!)
I'm not a very old user, but after touring the usual suspects, I've returned to it and I'm very happy with it.
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.
Though, from the description it sounds like it's still rather awkward compared to Vim's transparent handling. But I'll have to try it and see.
(I have to confess that this sometimes comes useful in adding customization to those commands.)
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.
Unfortunately, that stopped being the case since they refactored the text display UI somewhere around version 9.
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.
I might be transitioning to Emacs + Evil for a more IDE-like experience.
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.
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.
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.
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?
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.
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.)
Also, Omni has a cool name logo that almost reminds me of AVID's.
Also known as: continuing to provide value.
Oh, and there's also Rogue Amoeba, with their line of audio apps.
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.
Captain Hector take the wheel!
That reminds me, I need to delete those meta tags from my website…
I really, really need a "failure" like that, this trimester. Or this semester. I would accept the failure without any problem : )
It’s a surprisingly common mistake though. I think I see Dartmouth University more often than Dartmouth College when reading non-Dartmouth materials.
Mainstream newspapers and magazines have 1/5 the editors they once had, and everything is underpaid and on a hectic schedule.
And people expect editors to be involved at anything beyond a fleeting level in online outlets?
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 …
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'm pretty sure that's not me, unless it's a "easter egg" trick that shows a registered user's name in there.
They did, however, add a feature I requested in BBEdit 7.0 (rectangular text selections) which I still find kind of astounding and use almost daily.
I don't remember exactly when I first bought BBEdit, but it was in the mid-late `90s so it's been more than 20 years I've been depending on it.
Honestly, BBEdit is the main reason I still use a Mac. I'd switch to Linux in a heartbeat if BBEDit made a version to run on it.
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.
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?
Edit: https://www.sentinelone.com/blog/shut-snitch-reverse-enginee... (2016)
pf can filter outbound packets but not by application.
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8661
[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2675
[0]: https://github.com/transmission/transmission/tree/a6aa884776... [1]: https://github.com/transmission/transmission/tree/aad7bf22cb...