9 ms·

Reviving a 16-year-old Mac App

235 points by tumultco 6y ago

dhosek 6y ago
I was thinking initially that it'd be an especially challenging thing bringing code from OS 9 into the modern era, then I realized that MacOS (formerly OS X) is almost twenty years old. I've got some old PHP code that dates back to the 90s and is still running although I had to make some changes when my web host EOL'd PHP5 (I'd note that some of the files have a .php4 suffix).
bluedino 6y ago
The old app really still looks quite nice. Even windows 98-era apps look pretty good in a way. One part of me doesn't like how much space is wasted by the new Mac UI trends shown in the second screenshot, mostly the left side panel. But I understand screens are different these days as well.
- deleted 6y ago
  [deleted]
- tumultco 6y ago
  Thanks! Apps back then also tried much more to adhere to the Mac HIG, and in doing so it was pretty easy to wind up with at least not an unattractive app. I assume you are referring to the inspector panel on your other left; the two main reasons it is wider are (1) that it shows HTML5 validation error text descriptions in the 3rd tab and (2) this is the same width we use in our other application Hype, so they now look like they belong together. I did have a moment of feeling that I was contributing to the "war on information density" with this change.
- endgame 6y ago
  One thing I really noticed when 98.css did the rounds the other day: Old UIs were _discoverable_ in a way that modern UIs are not. It's clear what's clickable, what's grouped together, where you can grab and drag.
- jcfields 6y ago
  I think Mac apps have settled into a pleasant place for the most part, though I'm not a fan of the look of Apple's newer apps like the App Store and News. I'm glad that the brighter colors are more subdued now, annoying UI elements like drawers and palette windows have mostly been replaced by inspector panes, and brushed metal is long gone.
  - Nextgrid 6y ago
    Yep these new apps (including the "Marzipan" or "Catalyst" or whatever it's called) are pure garbage both in terms of design and usability.
lorenzfx 6y ago
> I don’t think it is an exaggeration to say the amount required to learn to distribute software exceeds the amount I needed to know to write the first beta of HyperEdit! I wonder if it would have gotten off the ground if I started today. This mirrors my feeling. It might be easier to learn to program say TypeScript or Go today than it was to learn php or C in the late 90s, but actually creating a complete program, distributing it, having it run or accessed by users is much harder than when I learned to program back then.
- kccqzy 6y ago
  Same story in cloud. It takes less effort to write the program than to properly set up CI/CD, permissions, auth, auto-scaling, backup, monitoring, and so many more.
  - searchableguy 6y ago
    I think that's doing it wrong because you don't need those features until you do... At which point you should invest in them. Otherwise, I don't see the benefit of having them. If all you end up with is one user.
    - kccqzy 6y ago
      > If all you end up with is one user. This isn't what I'm talking about. With just one user, even for desktop software the complexities of distributing the software are negligible.
    - mypalmike 6y ago
      A lot of developers, particularly at larger companies, do actually need these things before launching a service.
  - Nextgrid 6y ago
    To be fair, bare-metal dedicated servers are still a thing, end up cheaper than the equivalent cloud offering on bandwidth alone (as they usually come with unmetered bandwidth), and you can just SFTP your project in there and run it with nohup (not saying it's a good idea, but if you're just playing around then it's perfectly fine).
saagarjha 6y ago
> In 2020, distributing requires learning the intricacies of certificates, code signing, provisioning profiles, hardening, notarization, .dmg creation, gatekeeper, and paying a $99 per year fee. I had to manually create, sign, and notarize a Mac app the other day and it was total madness. It took multiple tabs of Apple documentation (new documentation, I might add, created this year because everyone complained last year about how the process was impenetrable) and back-and-forth with some seasoned Mac devs before I had something that would launch successfully on a fully updated, GateKeepered system.
- kick 6y ago
  This may be a question you get a lot, and I apologize in advance if it is, but: Why use Mac, if it makes so simple of things difficult?
  - filoleg 6y ago
    I think it is less about Mac development and more about submitting it to Mac App Store. You can still make an app for Mac without submitting it to the app store, without having to deal with majority of those issues. It's just sometimes there are good reasons for wanting to have it in the app store. No personal experience with either, but I would wager that you would encounter somewhat similar roadblocks if you try submitting things to Chrome App Store or Microsoft Store.
    - grishka 6y ago
      > You can still make an app for Mac without submitting it to the app store, without having to deal with majority of those issues. Not any more. Apple is so much of a control freak lately that non-app-store apps on Catalina are still required to go through them for "notarization" to be allowed to run on an unmodified OS — and yes that requires the $99 account. For me personally, that's the reason I'm staying on Mojave. That and 32-bit apps.
      - tumultco 6y ago
spongeb00b 6y ago
Maybe I was just the right age as a teenager back then and it does feel cliche to say, but there really was something special and magical about Mac software like this back in those days. I miss the pinstripes and aqua glossiness, but also the fact that software in other platforms just seemed so boring in comparison!
- tumultco 6y ago
  Removing color from toolbar/sidebar icons and fixing all line weights reduces the personality of software as well as increasing usability cognition. Even with years of use, I still have trouble quickly discerning the difference between many of Mail.app's toolbar buttons!
lemax 6y ago
This feels similar to Glitch, FKA HyperDev, Fog Creek's developer playground.
earthboundkid 6y ago
Every modern web framework has auto reload, so this is an app that’s only targeting people who know HTML well enough to hand write a page but don’t know about modern web development. Good luck, but I can’t imagine it’s a growing market.
- tumultco 6y ago
  I absolutely wondered the same thing when doing the update as the world isn't 2003 anymore. But I have found it useful even when doing modern web development as a quick playground to try snippets. "Live as you type" speed can change your iteration flow vs. an often slower rebuild+auto reload cycle. This was more of a passion/craft project than one I expect will make a gigantic impact. A side motive was to help move out some code of our Hype app to an "app shell" where I can more quickly make other applications with the same trial/licensing/windowing/etc. components.
- moolcool 6y ago
  Or developers who want to write basic HTML webpages without use of any of the bloated modern frameworks...
  - kalleboo 6y ago
    Right, sometimes you just want a web page, and not a web app.
- lang_agnostic 6y ago
  Education?
  - earthboundkid 6y ago
    Students cheapskates unless they're forced to buy something by the school.
- njhaveri 6y ago
  I build my website with Jekyll 4 and use livereload, but have actually found some use out of this tool for writing small snippets. Seeing your CSS come to life with every keystroke in real time (without having to press CMD+S in your IDE) is surprisingly useful. The main use-case where this tool has been useful, though, is when I'm working on my Mac app that uses WKWebView and Javascript pretty extensively. It's much faster to get little JS snippets right compared to the really slow build+run cycle in Xcode.
Razengan 6y ago
> In 2003, you could switch the config to Release, hit build, zip the app, and then put on a web server. You can still do that.
- userbinator 6y ago
  ...and that's how a lot of stuff is released on GitHub, but you can't get into Apple's walled garden that way.
  - Razengan 6y ago
    You can still distribute macOS apps on your own, just have to get users to trust you. Why do you want to publish on the Mac App Store? If you think there's an advantage, then the costs are justified.
    - cwizou 6y ago
      Sadly, this does not work for everything, as users can't always override the notarization requirement that was introduced in Catalina. I had the issue with Aerial, it's a screensaver which, technically, is a plugin and not an application. As such, the user will never get prompted for anything (and I'm putting aside the compounding effect/slight madness that screensavers are now a plugin to an appex to two different applications with different permissions set ! Oh Catalina...). The only solution was to sign/notarize it, and I have to admit it took me more than a few days to figure it out, as finding exactly what works for distributing a plugin was not documented. And this is just to distribute a usable plugin on GitHub !
stevoski 6y ago
I created a commercial Mac desktop app in 2008. I sold it off late last year (2019). It stopped being fun somewhere along the way. This was partly because I never knew what new requirement Apple was going to add with each new annual release of macOS. Would my app work? Would it not work? How many days, weeks, or more of work would I need to do to keep my app working while not actually making it better for my users?
ashishb 6y ago
The 99$ annual fee is ridiculous. Big companies don't talk about it because it is a regressive tax. It hurts hobbyist more than anyone else.
- dan1234 6y ago
  I don’t think Apple want hobbyist apps in the store. They want apps that will create revenue and the fee creates a filter of sorts. It would be good to be able to side load hobby apps, but that’s never happening. The fee does also get you 2 tech support requests, which should connect you with their engineers if you need help (never needed this, can’t say how extensive it is). Also, I did read somewhere that they waive the fee for some nonprofit/education institutions.
  - ashishb 6y ago
    Google Play store has a 25$ one-time fee. Much more affordable IMHO than 99$ annual fee. If I am being charged a 99$ fee, I simply can't share my creation without finding a way to make money off of my users. That isn't easy. Future hobbyists will be created on non-Apple platforms.
    - PeterisP 6y ago
      That's the whole point - making it not too affordable so that users browsing the App Store don't have to wade through too many nonserious hobbyist apps. Lowering the bar too much hurts users. I mean, all this is about mass distribution to unsophisticated consumers, not hobbyists - without that $99 you can work on your hobby projects and you can share them with other hobbyists; the only place where that $99 is a barrier is the distribution channel to non-hobbyist users. In essence, the message from Apple to hobbyist developers is to 'go big or go home' - if you're seriously developing something useful, then $99 is insignificant; and if the time effort you're putting in that app is not much, much more than $99 then it's reasonable to draw a line that they don't want such hobby projects on the app store. You can experiment with it and share it in small communities and when (if!) you think this project has become serious enough to go beyond hobbyists to the mass market, only then you need to pull out that symbolic $99 to demonstrate that you mean it.
dingo_bat 6y ago
A much shorter article, if it were to exist: Reviving a 16-year-old Windows App
crashity2 6y ago
The image in the default file is something like whisk-outline. Can't find that anywhere inside the app. Where is that coming from? It specifies a relative path, not an absolute one. Did a find for the image from the command line. Can't find it anywhere. Nothing in preferences for a source of files. Ran the app a second time--the default file is gone. Where did it go? Not in recent files. Dragged my own image in a new file. Got an outline box and the alt text, but no image. Put the image in "watched files" in the right pane, still no image. Where is the file root? Where is the image root? When I try a piece of software I instantly look for the thing I thing will be hardest. Your app displays all the HTML and styles great, no worries, but where's the root in the filesystem? Where's the image root path against which your relative paths are specified? Went through all the docs--nothing about images. Not in the video, not anywhere else I can find. I just don't understand where the HTML root is or how I insert resources in your app or where the relative paths point to or how to specify relative or absolute paths. Nothing seems to work. I read about sandboxing in the docs. Is this a sandboxing problem? No dialogs pop up as described in the docs. Checked settings--nothing there. All I want to do is write a couple of lines of HTML to specify an image and have it displayed. This simple task is not working and not addressed in your documentation. Honestly, this sort of thing makes me feel like I'm losing my mind. How is it that specification of path and resource roots is not one of the first and most prominent things in the docs? How is it not there anywhere? How does the developer and every user not go, "Wow, I wrote an img src= line and it doesn't display the image?"
rcarmo 6y ago
I still use Tumult's Hype 3 (Pro, I think) to do HTML5 animations - it's pretty great, even if moving to 4/Pro for the (very few) features I'd like to have seems a bit steep at $99. Whisk appeals to me because I _know_ it's going to be a polished, lightweight app, but with VS Code having quite usable previews I don't see the value of its current price point (to me).
- robenkleene 6y ago
  What do you use for a preview in VSCode? Do you mean this extension? https://marketplace.visualstudio.com/items?itemName=auchenberg.vscode-browser-preview https://marketplace.visualstudio.com/items?itemName=auchenbe... (Personally, I find the extensions I’ve tried clunky, so I’m curious if there’s a better way.)
- tumultco 6y ago
  Note that we do have upgrade discounts available, and if you purchased v3 after Oct 14, 2017 it is a free upgrade to the corresponding v4 edition. https://tumult.com/hype/support/upgrade-discounts/ https://tumult.com/hype/support/upgrade-discounts/
elsurudo 6y ago
Cool story. In a way I'm surprised one would try to adapt the old code after so much time has passed, rather than just starting fresh. It can definitely be interesting, just more... frustrating.
- schrijver 6y ago
  I imagine in the end not much old code was left, but if his initial code was well structured I can also see how it helps to not start from a blank slate. The structure you see in the names of files, classes etc. can make it easier to keep a mental model of the app that you’re building.
- soapdog 6y ago
  I guess Objective-C/Cocoa might have not changed much between the last HyperEdit version and now. If the developer organized his codebase well, replacing the old webview with the new stuff and so on should be less work than rewriting the whole app (IMHO). I haven't coded for the mac in more than a decade but what I remember from ObjC/Cocoa was that it was quite pleasant to use and very powerful. By powerful I mean that the ratio between LoC and smiles on my face was skewed towards smiling.
  - elsurudo 6y ago
    That's true. I maintain a couple of obj-C iOS apps (one of those ~10 years old) and apart from framework upgrades (iOS 6-7 was a big one) and dealing with a few deprecations, it's been surprisingly friction-free. macOS is probably even more stable. Swift, on the other hand... it's been a moving target for sure, and I'm glad I didn't just rewrite everything (like I did for one app).

235 points by tumultco 6y ago

I was thinking initially that it'd be an especially challenging thing bringing code from OS 9 into the modern era, then I realized that MacOS (formerly OS X) is almost twenty years old. I've got some old PHP code that dates back to the 90s and is still running although I had to make some changes when my web host EOL'd PHP5 (I'd note that some of the files have a .php4 suffix).

bluedino 6y ago

The old app really still looks quite nice. Even windows 98-era apps look pretty good in a way. One part of me doesn't like how much space is wasted by the new Mac UI trends shown in the second screenshot, mostly the left side panel. But I understand screens are different these days as well.

deleted 6y ago
[deleted]
tumultco 6y ago
Thanks! Apps back then also tried much more to adhere to the Mac HIG, and in doing so it was pretty easy to wind up with at least not an unattractive app. I assume you are referring to the inspector panel on your other left; the two main reasons it is wider are (1) that it shows HTML5 validation error text descriptions in the 3rd tab and (2) this is the same width we use in our other application Hype, so they now look like they belong together. I did have a moment of feeling that I was contributing to the "war on information density" with this change.
endgame 6y ago
One thing I really noticed when 98.css did the rounds the other day: Old UIs were _discoverable_ in a way that modern UIs are not. It's clear what's clickable, what's grouped together, where you can grab and drag.
jcfields 6y ago
I think Mac apps have settled into a pleasant place for the most part, though I'm not a fan of the look of Apple's newer apps like the App Store and News. I'm glad that the brighter colors are more subdued now, annoying UI elements like drawers and palette windows have mostly been replaced by inspector panes, and brushed metal is long gone.
- Nextgrid 6y ago
  Yep these new apps (including the "Marzipan" or "Catalyst" or whatever it's called) are pure garbage both in terms of design and usability.

lorenzfx 6y ago

> I don’t think it is an exaggeration to say the amount required to learn to distribute software exceeds the amount I needed to know to write the first beta of HyperEdit! I wonder if it would have gotten off the ground if I started today. This mirrors my feeling. It might be easier to learn to program say TypeScript or Go today than it was to learn php or C in the late 90s, but actually creating a complete program, distributing it, having it run or accessed by users is much harder than when I learned to program back then.

kccqzy 6y ago
Same story in cloud. It takes less effort to write the program than to properly set up CI/CD, permissions, auth, auto-scaling, backup, monitoring, and so many more.
- searchableguy 6y ago
  I think that's doing it wrong because you don't need those features until you do... At which point you should invest in them. Otherwise, I don't see the benefit of having them. If all you end up with is one user.
  - kccqzy 6y ago
    > If all you end up with is one user. This isn't what I'm talking about. With just one user, even for desktop software the complexities of distributing the software are negligible.
  - mypalmike 6y ago
    A lot of developers, particularly at larger companies, do actually need these things before launching a service.
- Nextgrid 6y ago
  To be fair, bare-metal dedicated servers are still a thing, end up cheaper than the equivalent cloud offering on bandwidth alone (as they usually come with unmetered bandwidth), and you can just SFTP your project in there and run it with nohup (not saying it's a good idea, but if you're just playing around then it's perfectly fine).

saagarjha 6y ago

> In 2020, distributing requires learning the intricacies of certificates, code signing, provisioning profiles, hardening, notarization, .dmg creation, gatekeeper, and paying a $99 per year fee. I had to manually create, sign, and notarize a Mac app the other day and it was total madness. It took multiple tabs of Apple documentation (new documentation, I might add, created this year because everyone complained last year about how the process was impenetrable) and back-and-forth with some seasoned Mac devs before I had something that would launch successfully on a fully updated, GateKeepered system.

kick 6y ago
This may be a question you get a lot, and I apologize in advance if it is, but: Why use Mac, if it makes so simple of things difficult?
- filoleg 6y ago
  I think it is less about Mac development and more about submitting it to Mac App Store. You can still make an app for Mac without submitting it to the app store, without having to deal with majority of those issues. It's just sometimes there are good reasons for wanting to have it in the app store. No personal experience with either, but I would wager that you would encounter somewhat similar roadblocks if you try submitting things to Chrome App Store or Microsoft Store.
  - grishka 6y ago
    > You can still make an app for Mac without submitting it to the app store, without having to deal with majority of those issues. Not any more. Apple is so much of a control freak lately that non-app-store apps on Catalina are still required to go through them for "notarization" to be allowed to run on an unmodified OS — and yes that requires the $99 account. For me personally, that's the reason I'm staying on Mojave. That and 32-bit apps.
    - tumultco 6y ago

spongeb00b 6y ago

Maybe I was just the right age as a teenager back then and it does feel cliche to say, but there really was something special and magical about Mac software like this back in those days. I miss the pinstripes and aqua glossiness, but also the fact that software in other platforms just seemed so boring in comparison!

tumultco 6y ago
Removing color from toolbar/sidebar icons and fixing all line weights reduces the personality of software as well as increasing usability cognition. Even with years of use, I still have trouble quickly discerning the difference between many of Mail.app's toolbar buttons!

lemax 6y ago

This feels similar to Glitch, FKA HyperDev, Fog Creek's developer playground.

earthboundkid 6y ago

Every modern web framework has auto reload, so this is an app that’s only targeting people who know HTML well enough to hand write a page but don’t know about modern web development. Good luck, but I can’t imagine it’s a growing market.

tumultco 6y ago
I absolutely wondered the same thing when doing the update as the world isn't 2003 anymore. But I have found it useful even when doing modern web development as a quick playground to try snippets. "Live as you type" speed can change your iteration flow vs. an often slower rebuild+auto reload cycle. This was more of a passion/craft project than one I expect will make a gigantic impact. A side motive was to help move out some code of our Hype app to an "app shell" where I can more quickly make other applications with the same trial/licensing/windowing/etc. components.
moolcool 6y ago
Or developers who want to write basic HTML webpages without use of any of the bloated modern frameworks...
- kalleboo 6y ago
  Right, sometimes you just want a web page, and not a web app.
lang_agnostic 6y ago
Education?
- earthboundkid 6y ago
  Students cheapskates unless they're forced to buy something by the school.
njhaveri 6y ago
I build my website with Jekyll 4 and use livereload, but have actually found some use out of this tool for writing small snippets. Seeing your CSS come to life with every keystroke in real time (without having to press CMD+S in your IDE) is surprisingly useful. The main use-case where this tool has been useful, though, is when I'm working on my Mac app that uses WKWebView and Javascript pretty extensively. It's much faster to get little JS snippets right compared to the really slow build+run cycle in Xcode.

Razengan 6y ago

> In 2003, you could switch the config to Release, hit build, zip the app, and then put on a web server. You can still do that.

userbinator 6y ago
...and that's how a lot of stuff is released on GitHub, but you can't get into Apple's walled garden that way.
- Razengan 6y ago
  You can still distribute macOS apps on your own, just have to get users to trust you. Why do you want to publish on the Mac App Store? If you think there's an advantage, then the costs are justified.
  - cwizou 6y ago
    Sadly, this does not work for everything, as users can't always override the notarization requirement that was introduced in Catalina. I had the issue with Aerial, it's a screensaver which, technically, is a plugin and not an application. As such, the user will never get prompted for anything (and I'm putting aside the compounding effect/slight madness that screensavers are now a plugin to an appex to two different applications with different permissions set ! Oh Catalina...). The only solution was to sign/notarize it, and I have to admit it took me more than a few days to figure it out, as finding exactly what works for distributing a plugin was not documented. And this is just to distribute a usable plugin on GitHub !

stevoski 6y ago

I created a commercial Mac desktop app in 2008. I sold it off late last year (2019). It stopped being fun somewhere along the way. This was partly because I never knew what new requirement Apple was going to add with each new annual release of macOS. Would my app work? Would it not work? How many days, weeks, or more of work would I need to do to keep my app working while not actually making it better for my users?

ashishb 6y ago

The 99$ annual fee is ridiculous. Big companies don't talk about it because it is a regressive tax. It hurts hobbyist more than anyone else.

dan1234 6y ago
I don’t think Apple want hobbyist apps in the store. They want apps that will create revenue and the fee creates a filter of sorts. It would be good to be able to side load hobby apps, but that’s never happening. The fee does also get you 2 tech support requests, which should connect you with their engineers if you need help (never needed this, can’t say how extensive it is). Also, I did read somewhere that they waive the fee for some nonprofit/education institutions.
- ashishb 6y ago
  Google Play store has a 25$ one-time fee. Much more affordable IMHO than 99$ annual fee. If I am being charged a 99$ fee, I simply can't share my creation without finding a way to make money off of my users. That isn't easy. Future hobbyists will be created on non-Apple platforms.
  - PeterisP 6y ago
    That's the whole point - making it not too affordable so that users browsing the App Store don't have to wade through too many nonserious hobbyist apps. Lowering the bar too much hurts users. I mean, all this is about mass distribution to unsophisticated consumers, not hobbyists - without that $99 you can work on your hobby projects and you can share them with other hobbyists; the only place where that $99 is a barrier is the distribution channel to non-hobbyist users. In essence, the message from Apple to hobbyist developers is to 'go big or go home' - if you're seriously developing something useful, then $99 is insignificant; and if the time effort you're putting in that app is not much, much more than $99 then it's reasonable to draw a line that they don't want such hobby projects on the app store. You can experiment with it and share it in small communities and when (if!) you think this project has become serious enough to go beyond hobbyists to the mass market, only then you need to pull out that symbolic $99 to demonstrate that you mean it.

dingo_bat 6y ago

A much shorter article, if it were to exist: Reviving a 16-year-old Windows App

crashity2 6y ago

The image in the default file is something like whisk-outline. Can't find that anywhere inside the app. Where is that coming from? It specifies a relative path, not an absolute one. Did a find for the image from the command line. Can't find it anywhere. Nothing in preferences for a source of files. Ran the app a second time--the default file is gone. Where did it go? Not in recent files. Dragged my own image in a new file. Got an outline box and the alt text, but no image. Put the image in "watched files" in the right pane, still no image. Where is the file root? Where is the image root? When I try a piece of software I instantly look for the thing I thing will be hardest. Your app displays all the HTML and styles great, no worries, but where's the root in the filesystem? Where's the image root path against which your relative paths are specified? Went through all the docs--nothing about images. Not in the video, not anywhere else I can find. I just don't understand where the HTML root is or how I insert resources in your app or where the relative paths point to or how to specify relative or absolute paths. Nothing seems to work. I read about sandboxing in the docs. Is this a sandboxing problem? No dialogs pop up as described in the docs. Checked settings--nothing there. All I want to do is write a couple of lines of HTML to specify an image and have it displayed. This simple task is not working and not addressed in your documentation. Honestly, this sort of thing makes me feel like I'm losing my mind. How is it that specification of path and resource roots is not one of the first and most prominent things in the docs? How is it not there anywhere? How does the developer and every user not go, "Wow, I wrote an img src= line and it doesn't display the image?"

rcarmo 6y ago

I still use Tumult's Hype 3 (Pro, I think) to do HTML5 animations - it's pretty great, even if moving to 4/Pro for the (very few) features I'd like to have seems a bit steep at $99. Whisk appeals to me because I _know_ it's going to be a polished, lightweight app, but with VS Code having quite usable previews I don't see the value of its current price point (to me).

robenkleene 6y ago
What do you use for a preview in VSCode? Do you mean this extension? https://marketplace.visualstudio.com/items?itemName=auchenberg.vscode-browser-preview https://marketplace.visualstudio.com/items?itemName=auchenbe... (Personally, I find the extensions I’ve tried clunky, so I’m curious if there’s a better way.)
tumultco 6y ago
Note that we do have upgrade discounts available, and if you purchased v3 after Oct 14, 2017 it is a free upgrade to the corresponding v4 edition. https://tumult.com/hype/support/upgrade-discounts/ https://tumult.com/hype/support/upgrade-discounts/

elsurudo 6y ago

Cool story. In a way I'm surprised one would try to adapt the old code after so much time has passed, rather than just starting fresh. It can definitely be interesting, just more... frustrating.

schrijver 6y ago
I imagine in the end not much old code was left, but if his initial code was well structured I can also see how it helps to not start from a blank slate. The structure you see in the names of files, classes etc. can make it easier to keep a mental model of the app that you’re building.
soapdog 6y ago
I guess Objective-C/Cocoa might have not changed much between the last HyperEdit version and now. If the developer organized his codebase well, replacing the old webview with the new stuff and so on should be less work than rewriting the whole app (IMHO). I haven't coded for the mac in more than a decade but what I remember from ObjC/Cocoa was that it was quite pleasant to use and very powerful. By powerful I mean that the ratio between LoC and smiles on my face was skewed towards smiling.
- elsurudo 6y ago
  That's true. I maintain a couple of obj-C iOS apps (one of those ~10 years old) and apart from framework upgrades (iOS 6-7 was a big one) and dealing with a few deprecations, it's been surprisingly friction-free. macOS is probably even more stable. Swift, on the other hand... it's been a moving target for sure, and I'm glad I didn't just rewrite everything (like I did for one app).