Earlier quoted context omitted.
[flagged]
> 0 mention of pricing until you actually download the product. This is false. The prices are listed in the App Store.
It’s also on the page too.
9 years of Apple text editor solo dev
91–100 of 405 posts
Re: 9 years of Apple text editor solo dev
#92Earlier 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.
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.
[deleted]
Re: 9 years of Apple text editor solo dev
#93> 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 categories to shorten long framework methods. The underscore at the end helps to avoid clashes with public or private methods that Apple might decide to add in the future.
I think you already know what will happen if Apple adds a method (public or private) called text to NSTextField or stringValue to UITextField in the future ;)
Re: 9 years of Apple text editor solo dev
#94> Swift has come a long way and my guess is Apple has either embedded it into their platforms or added some fancy tree shaking for the binary.
It went ABI around Swift 5 or so.
I took a huge leap of faith, in 2014, and started using Swift, exclusively. It's turned out OK.
I'm not quite as positive about SwiftUI, though. I think it will work out, but it has a huge amount of catching up to do, if it is to replace UIKit/AppKit.
I'd be quite interested in Rich Siegel's take (the guy behind BBEdit). He's been at it, a while, as well.
Re: 9 years of Apple text editor solo dev
#95Earlier quoted context omitted.
Chrome?
Yep, I'm also seeing a 2px scrollbar that does not expand.
Oh yes, sorry. This is a form-over-function detail that I added to the website to mimic the app.
I did not, however, invest the time to make it expandable. I thought that people anyway don't use the scroll bar that much, and for quick navigation there is the table of contents on the left.
I'll see if I can make it more accessible!
Re: 9 years of Apple text editor solo dev
#96Earlier 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.
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.
Re: 9 years of Apple text editor solo dev
#97[flagged]
I honestly thought that the scrollbar didn't work at all until I read this comment. If I put the site on my right monitor, I can grab the scrollbar by just going to the edge. But on my left monitor, where I typically have the browser, it's almost impossible.
I too find it very annoying, especially for such a long article.
Re: 9 years of Apple text editor solo dev
#98> 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
I'd hesitate to put it that way.
Shipping software is always full of compromise, and we often have to stay away from the "bleeding edge," when we want to actually ship full-featured products.
I suspect that almost all the AAA apps are still ObjC.
I still use UIKit/AppKit for my work. I simply can't get the results that I need from SwiftUI.
Re: 9 years of Apple text editor solo dev
#99Re: 9 years of Apple text editor solo dev
#100> 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…
Keeping my fingers crossed it will not happen. :D