Live data from Hacker News

9 years of Apple text editor solo dev

papereditor.app

161–170 of 405 posts

Re: 9 years of Apple text editor solo dev

#161

> Categories in Objective-C are a way to add new methods to any existing class, including framework classes (categories can also be used to replace methods, which is both powerful and scary ). I use them to harmonize the API. So if a method in UITextField is called text and in NSTextField it is called stringValue I can add a stringValue method to UITextField that calls text (or vice versa). > By the way, I also use c…

> I think you already know what will happen

I don't know, what will happen?

Re: 9 years of Apple text editor solo dev

#162
post #85

Earlier quoted context omitted.

They're literally rewriting in Swift right now. Foundation is being rewritten entirely in Swift. All new code is in Swift. All new frameworks are Swift-only. They're using Swift from low level firmware on the Secure Enclave to apps. This is already real.

Yup, exactly. Swift was specifically designed to replace Objective-C and C++ throughout Apple codebases (see https://www.youtube.com/watch?v=ZQc9-seU-5k ). C# is a totally different story.

> C# is a totally different story.

Interesting. Can you share more details?

Re: 9 years of Apple text editor solo dev

#163
post #85

Earlier quoted context omitted.

They're literally rewriting in Swift right now. Foundation is being rewritten entirely in Swift. All new code is in Swift. All new frameworks are Swift-only. They're using Swift from low level firmware on the Secure Enclave to apps. This is already real.

This is turning into a silly argument… but anyway there's a blogger who has been tracking the number of binaries written in the various languages (and appkit vs catalyst vs swiftui etc.) for years. Sonoma is 13% Swift (up from 11% in Ventura), 53% Obj-C (down from 55% in Ventura). The priority actually appears to be eating away from the C/C++ parts of the codebase (currently 33%, down from 42% just two releases ago).…

At this point you can't separate Swift from the rest of the system so cleanly. Since it's now included with the OS directly and linked to from many system libraries, including parts of Foundation which have been directly rewritten in Swift while maintaining ABI compatibility with Obj-C callers, virtually everything on the system that uses Apple's frameworks uses Swift to some degree.

Re: 9 years of Apple text editor solo dev

#164
post #65

Earlier quoted context omitted.

Be real: Apple is not going to rewrite MacOs/iOs in Swift. Objective-C will always be there, offering faster and more robust features. Just look at the Microsoft equivalent: yes, C# is good and all, but the hardcore Windows apps are still using (lightly-skinned) VC++ APIs - after almost 25 years since they started flogging .NET. Swift is for the new rubes, bootcamp graduates and so on.

One of the most complex apps that Microsoft produces is Visual Studio. It is currently a hybrid of C++ and C#. I suppose that almost all new features are written in C# where possible. Why won't Apply follow the same path? The developer productivity in Swift must be 10x compared to Objective C. To be clear: I write this post as someone who has infinite love for optimization of native code. However, in many situtations…

> The developer productivity in Swift must be 10x compared to Objective C.

Why do you say that? Do you have experience backing up that estimate?

Re: 9 years of Apple text editor solo dev

#165
post #145
post #140

Earlier quoted context omitted.

> Which assertion was wrong? Your original assertion that Apple wasn't rewriting anything.

> Your original assertion that Apple wasn't rewriting anything. I have no idea what you're talking about. I made no such assertion. Perhaps you're confusing me and "toyg"?

Ah true. Not sure why you replied then. Your point about Foundation was meaningless and the others just nits. Do you have an actual point to make?

Re: 9 years of Apple text editor solo dev

#166
post #120

I'd been thinking of getting into Apple platform dev, but there really seems to be this strong contradiction in people saying to go full bore Swift/SwiftUI but reading this and as well following the Swiftcord devs' discord, there's a lot of problems with Swift/SwiftUI as a replacement for Obj-C/UIKit/AppKit. There also seems to be more and better documentation/examples for the Obj-C APIs than Swift; yes Obj-C is old,…

I went through this decision a few years back (end of 2020-ish) and decided to go with Swift because it seemed SwiftUI wasn't really far enough along yet, and some experimentation with SwiftUI caused me to agree.

I wanted to avoid Objective C, largely because I liked the safety of Swift (optionals, if let, guard let, etc) to make it less likely that I'd introduce crashes.

The funny thing I found was that I ended up needing to know how to at least read Objective C code anyway, because like you say, the docs use a lot of it. StackOverflow had a lot of it too. So I had to get good at translating between the two.

Unlike the web dev world I was used to, there are way fewer Swift/ObjC devs out there, and the answers are fewer and less up-to-date.

Re: 9 years of Apple text editor solo dev

#167
post #107

> Categories in Objective-C are a way to add new methods to any existing class, including framework classes (categories can also be used to replace methods, which is both powerful and scary ). I use them to harmonize the API. So if a method in UITextField is called text and in NSTextField it is called stringValue I can add a stringValue method to UITextField that calls text (or vice versa). > By the way, I also use c…

One problem in the past was -[NSArray firstObject], which many developers used as a category method, with differing implementations. Apple added it to the Mac OS X 10.9 SDK but actually implemented the method silently in 10.6!

Interestingly it seems to be 10.6+ in the documentation. They backdeploy like that sometimes I guess.

Re: 9 years of Apple text editor solo dev

#168

> Categories in Objective-C are a way to add new methods to any existing class, including framework classes (categories can also be used to replace methods, which is both powerful and scary ). I use them to harmonize the API. So if a method in UITextField is called text and in NSTextField it is called stringValue I can add a stringValue method to UITextField that calls text (or vice versa). > By the way, I also use c…

> I think you already know what will happen I don't know, what will happen?

One of the implementations will get used. If they differ this is likely to cause at least one caller to be very upset.

Re: 9 years of Apple text editor solo dev

#169
This is a beautiful blog, the same as the minimalistic app. Huge congrats. I'm seeing myself building this, as the joy it returns by using an app built by yourself. I have feelings similar to those expressed in the article using vim-motions or generally Neovim. It's so simple that even it works in a terminal. But once mastered (at least the basics), I feel like a surgeon when operating, as I edit text so fine-grained and exact.

Re: 9 years of Apple text editor solo dev

#170
The ability to go low/no-dependencies, as mentioned in the blog post, is one of my favorite things about Apple platforms. It’s not just possible but practical to build a capable, highly polished app without bringing in anything third-party thanks to the richness and depth of AppKit/UIKit. Few frameworks can compete, with even other juggernauts like Qt coming up short in comparison.
Post reply on HN