Live data from Hacker News

9 years of Apple text editor solo dev

papereditor.app

51–60 of 405 posts

Re: 9 years of Apple text editor solo dev

#51
Lovely writeup. Making that webpage must have taken quite some time also?

A question out of curiosity. What are your thoughts on re-writing in Swift?

If it were me, I am sure my tech-fingers would itch for a rewrite, but my business hands would slap those thoughts away.

Re: 9 years of Apple text editor solo dev

#52
post #47

> To my surprise, the Swift one had the full Swift runtime embedded into it — about 5MB, while the Objective-C one was super light — tens or maybe 100KB in total. That's a huge difference, but I believe it's because Swift is meant to be somewhat cross-platform, right?

That experiment was done in 2015, when the Swift runtime had to be included. If you build an app now, it will link to the system runtime and be close to 100kb as well. This seems to be premature optimization. The author forced himself to learn archaic Objective C for a completely unnecessary reason, and now is stuck with that design choice despite not having any benefits.

> The author forced himself to learn archaic Objective C for a completely unnecessary reason, and now is stuck with that design choice despite not having any benefits.

Some benefits:

1) Most Swift code written in 2015 when the author was starting won't even compile today, because the language has changed in non-compatible ways. Whereas Objective-C code written in 2015, 2005, and possibly even 1995 will usually still compile and run. The author mentioned low maintenance costs as a goal.

2) Swift compile times are still vastly slower than Objective-C.

3) The Swift tooling is still buggy, including the compiler, and especially the debugger (the author wrote an entire section about debugging).

Re: 9 years of Apple text editor solo dev

#53

All the "fringes" stuff is where the magic is. The author suggests that no one notices some of the refinements, well this may be true on day one, but people discover these touches as they grow more familiar. Those subtle thoughtful additions are what makes the difference between an app I like using, and one I love using. They help me feel a couple of things: 1) A connection; I feel like I noticed something just for t…

This is very true, and with regard to product success, the opposite effect here is a sad story - a tool full on lots of small annoyances is death by a thousand cut because each is hard to describe it doesn't seem worth explaining and so you get no telemetry for why nobody uses your product.

Re: 9 years of Apple text editor solo dev

#55
post #47

Earlier quoted context omitted.

That experiment was done in 2015, when the Swift runtime had to be included. If you build an app now, it will link to the system runtime and be close to 100kb as well. This seems to be premature optimization. The author forced himself to learn archaic Objective C for a completely unnecessary reason, and now is stuck with that design choice despite not having any benefits.

Have you ever developed anything substantial with Objective C? If not, I suggest that 'unfamiliar' might be more apt than 'archaic'. Anyone starting a non-trivial iOS project in 2015 in Swift would still need to learn the basics of Objective C because so much of the documentation and examples were still in Objective C at that time. I don't think it's accurate to say that learning Objective C in 2015 had no benefits.

And for what it is worth, the times I had to use Objective-C, it is a nice superset of C language that reads cleanly and is easy to grasp.

Re: 9 years of Apple text editor solo dev

#56
post #51

Lovely writeup. Making that webpage must have taken quite some time also? A question out of curiosity. What are your thoughts on re-writing in Swift? If it were me, I am sure my tech-fingers would itch for a rewrite, but my business hands would slap those thoughts away.

Thank you!

I probably would have to do it at some point if Apple decides to completely deprioritize it.

For now, Objective-C even has some benefits. It's more low-level and more hackable. And I think some older APIs are not even available in Swift.

Re: 9 years of Apple text editor solo dev

#58
post #2

> Closed-sourced native UI is a fragile place compared to the predictable JavaScript runtime of the browser. Huh, that sounds contrary to what people usually tout as a benefit of native. You always hear about framework churn and cross-platform problems when it comes to JavaScript. Maybe that’s not so true anymore?

Native on other systems, perhaps. But for MacOS it's common that half your apps will break if you update as soon as the update is available. Got to give each developer time to fix their app first..

Re: 9 years of Apple text editor solo dev

#60
post #47

> To my surprise, the Swift one had the full Swift runtime embedded into it — about 5MB, while the Objective-C one was super light — tens or maybe 100KB in total. That's a huge difference, but I believe it's because Swift is meant to be somewhat cross-platform, right?

That experiment was done in 2015, when the Swift runtime had to be included. If you build an app now, it will link to the system runtime and be close to 100kb as well. This seems to be premature optimization. The author forced himself to learn archaic Objective C for a completely unnecessary reason, and now is stuck with that design choice despite not having any benefits.

I think even today Objective-C has some unique benefits for me. It's more low-level and more hackable. And I think some older APIs are not even available in Swift.

Of course, the pressure to rewrite would grow with every year as Apple continues deprioritizing Objective-C, but that's a problem for future me. :)

Post reply on HN