That was an amazing read, thanks for sharing all those details. Partway through I was amazed to find a code snippet that I need for my iOS PDF editor: your map of language to system fallback font! I had figured out part of it but hadn't done the whole "type in every language and see what I get" step yet.
9 years of Apple text editor solo dev
261–270 of 405 posts
Re: 9 years of Apple text editor solo dev
#262Earlier quoted context omitted.
It does happen though - Qt tries very hard to do that. I don't know about literally everything, but the majority of platform-specific features/optimizations can be exposed through Qt with enough work. And what is the result? Everyone complains that Qt is too hard to use, and so it has utterly lost the cross-platform war to Electron, and meanwhile the devs who want the platform-native functionality (like the OP of the…
Qt is probably closest among cross platform frameworks, but comes with some thorns that can be difficult to ignore and contribute to that “hard to use” sentiment. The way Qt Widgets is for practical purposes usable only with C++ or Python is one such thorn, as is its use of custom types like QString. Both increase friction significantly as many devs aren’t able to use their preferred language and can’t use the langua…
You can use Rust with QML[1].
QML is actually pretty amazing. I've been building my block editor[2] view entirely in QML while the model is in C++. This separation of logic and presentation works great. And yes, there are some crashes sometimes (that I find quite easy to debug thanks to the built-in debugger), but take for example a similar app that's built with Rust and Dart[3], in my testing there were still memory leaks that caused my computer to hang. It's better to know you have a bug than for it to be hidden from you.
I agree with parent commenter, saying these cross-platform frameworks will end up supporting the least common denominator set of features. But I found with external open source libraries, the community is catching up very fast. For example, you want the awesome translucency macOS apps have for your Qt app? Here you go[4]. Many such cases. It's also pretty straightforward to add your own custom OS-dependent code, especially so, if someone already open sourced his approach. I recently wanted to move the traffic light buttons on macOS for my app, but couldn't figure the Objective-C code for that. I ended up looking at either Tauri or Electron source code and found my answer.
[1] https://github.com/woboq/qmetaobject-rs
Re: 9 years of Apple text editor solo dev
#263Earlier 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.
It's been a long time since I did anything in macos/ios land, but in my experience most of the learning curve wasn't in Objective C, which is a fairly straightforward C-like language, but in all the platform APIs. Has Swift changed things much in this regard?
You are correct.
Swift is lighter on the eyes, but it still uses the same APIs when paired with UIKit/AppKit.
SwiftUI is a different thing though. It's like React for UIKit/AppKit and has a different API.
Re: 9 years of Apple text editor solo dev
#264Earlier quoted context omitted.
It does happen though - Qt tries very hard to do that. I don't know about literally everything, but the majority of platform-specific features/optimizations can be exposed through Qt with enough work. And what is the result? Everyone complains that Qt is too hard to use, and so it has utterly lost the cross-platform war to Electron, and meanwhile the devs who want the platform-native functionality (like the OP of the…
Qt is probably closest among cross platform frameworks, but comes with some thorns that can be difficult to ignore and contribute to that “hard to use” sentiment. The way Qt Widgets is for practical purposes usable only with C++ or Python is one such thorn, as is its use of custom types like QString. Both increase friction significantly as many devs aren’t able to use their preferred language and can’t use the langua…
I'd like to take the opportunity to mention Slint: a new toolkit in the scene, is inspired by the spirit of Qt while aiming to address its shortcomings
https://slint.dev
Re: 9 years of Apple text editor solo dev
#265Nice app but your marketing make me not want to use the app.
1. The blog is flooded with SEO oriented posts https://papereditor.app/blog This vs That, Top this, Top that
2. In the App Store a whole bunch of other text editors are mentioned in the app description text in order to be included in the results when people search for other text editors.
I'ts just shady and unnecessary if you trully believe in your app.
Re: 9 years of Apple text editor solo dev
#266The 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.
And you are now locked down to one environment.
I'm not sure one is locked down. One can write the model and the controller in the style one likes and then they just bind to appkit/uikit for the Apple versions.
This could be done despite nobody I know working this way. This used to be normal when x-windows was thriving.
Re: 9 years of Apple text editor solo dev
#267Great read! A question for the author (as I see they're in this thread and hopefully still around!) -- do you have any good resources and recommendations for learning AppKit and Mac development in general?
I've been (very slowly) dabbling around writing a Game Boy emulator in Swift and, surprisingly, some of the biggest difficulties I've had have been actually getting stuff on-screen, rather than the emulation itself. Turning an array of bytes into pixels on-screen, timers accurate enough to run my main loop at 59.97Hz, window behaviour etc.
I know all this stuff exists and isn't even that hard, but actually finding what I need has proven quite difficult. I found that Google searches for NSWhatever tended to return results for UIWhatever, and there are far fewer StackOverflow threads due to a lot of this stuff being from the early 2000s.
Apple's documentation for their newest stuff is infamously barebones, but I've also found it difficult for the very old stuff too -- much of it hasn't been updated for Swift, so I've been at the mercy of Xcode autocomplete to find the new names for various constants, etc. Good Mac development is starting to feel like a lost art.
Re: 9 years of Apple text editor solo dev
#268Earlier quoted context omitted.
And you are now locked down to one environment.
Often worth it for superior UX. The promise of fantastic cross-platform apps still hasn't borne out. We've been promised this since Java, yet converged on shipping Chrome with a webapp.
You can write app that will work on Windows, Mac, Linux, iOS, Android using Delphi.
Re: 9 years of Apple text editor solo dev
#269Having been developing iOS apps since 2009, hard to believe 15 years, this is one of the finest writeups from a developer I've seen. Congrats on your hard work and the decisions you made developing your app. You made some great decisions, i.e., sticking to native development, no 3rd party dependencies, and sticking with Obj-C. I made the move to Swift when it came out. However, there are many times I miss Obj-C and m…
> I often wonder what Obj-C would look like today if Apple had put the time and effort into it instead of Swift. It would largely look like Swift, since the goals of Swift (and most modern languages), safety and expressiveness, are fundamentally incompatible with C languages. There's really no point to basing a language on Obj-C if you're not keeping 100% compatibility, so they didn't.
There are a bunch of design decisions in Swift that make it more C++ with the corresponding binary bloat + other issues than reference counted Java/Smalltalk with a C FFI that Obj-C is.
You could've had Obj-C without the C for example, ADTs (enums), strong nullability enforcement and a nicer syntax while reusing most of the Obj-C core and retaining the compile speed, rock solid / fast debugging, function calls as data (selectors), easy mock creation and so on.
The systems programming capabilities is lost on %99.9 actual usage of swift. The swift project should've been split into two different projects IMO, where they modernized Obj-C into a successor language without making the C++ choices they did and created SwiftRust where the %0.1 that want system programming and nondeterministic multithreading capabilities can go do so. Apple second system effect-ed themselves hardcore with the Swift project, and it shows everywhere.
Re: 9 years of Apple text editor solo dev
#270This is a really beautiful write-up!
I have one small gripe in that on my browser (chrome-windows11) the scroll bar is imperceptibly small, so I can't easily scrub through by grabbing it with the mouse. Other than that this is awesome.