9 years of Apple text editor solo dev

by pimterry • 3 years ago

740 335 3 years ago

tobr• 3 years ago

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?

realusername• 3 years ago

JS, as bad as it might be is close to 100% backward compatible, your project will work forever on newer browsers, that can't be said for Apple.

internetter7• 3 years ago

Also goes in the other way. We can literally only support iOS 17 because we’re using SwiftUI and Apple refuses to backport anything, whereas in JavaScript you can generally use new APIs while either gracefully failing or triggering a fallback

treve• 3 years ago

In this OP compared the runtime, not frameworks. In my experience the web platform is extremely stable.

throwaway662012• 3 years ago

Just don't use frameworks, or use the stable ones.

I use React and it had exactly one significant major change (class components -> functions & hooks) since 10 years ago when I started out with the beta release.

Windows went through 4 different "recommended" GUI frameworks and many more major API changes during that time.

robertlagrant• 3 years ago

That was a particularly crazy time for Windows UI development!

matsemann• 3 years ago

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..

anonymouse008• 3 years ago

Smoothing the caret after character insertion is unbelievably pleasant. Now every other input feels glitchy, almost like continual paper cuts.

kibwen• 3 years ago

To each their own. Microsoft Office apps do this by default these days and I found it maddeningly distracting. Fortunately, it can be turned off.

iamatqh• 3 years ago

What do you mean by "smoothing the caret"? I just tried the app to see if I can make sense of it; do you mean that the caret does not blink if you continuosly insert characters?

buzzerbetrayed• 3 years ago

When you type a character, the cursor smoothly animates from its previous position to the new one. As opposed to most apps where the cursor instantly jumps one character width to the right.

alexitosrv• 3 years ago

Something like this: https://www.youtube.com/watch?v=FCUi_dRU0tY

Alifatisk• 3 years ago

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?

lapcat11• 3 years ago

No, it's because Swift was not ABI stable at the time, so it couldn't be added to the operating system.

https://www.swift.org/blog/abi-stability-and-more/

macintux• 3 years ago

Related discussion from 3 weeks ago:

https://news.ycombinator.com/item?id=38651690

KMnO4• 3 years ago

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.

neverartful• 3 years ago

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.

lapcat11• 3 years ago

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).

papereditor68• 3 years ago

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. :)

ziddoap• 3 years ago

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 easy, now, to say that it was a poor choice/premature optimization/unnecessary/whatever. But, presumably, the author is unable to tell the future. At the time when the decision was made, there were benefits that the author deemed necessary (smaller distributable among other benefits).

jmull• 3 years ago

not having any benefits

Actually, building on stable abstraction is a pretty nice benefit when your focus is on the product.

Swift is quite nice, IMO, but has also changed quite a bit since 2015 and using it would likely have lead to a bunch of work to keep up.

ChrisMarshallNY3• 3 years ago

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.

lovelyviking2• 3 years ago

May be you can point out a few particular features of swift that would bring real advantages for his project?

shermantanktop• 3 years ago

And yet here they are, with a great app, some amount of sustained revenue, and a front page post on HN. Is that an accident?

The word that comes to mind after reading that post is “intentionality.” Many deliberate decisions, including for hard tradeoffs like this one. To me, that speaks to the importance of vision and judgment over the apparent correctness of individual choices.

danenania• 3 years ago

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?

ulf-77723• 3 years ago

Nice write up! Kudos to the author for being so humble about his journey - quite something achieved from my perspective.

papereditor68• 3 years ago

Thank you!

lawgimenez• 3 years ago

Nice write-up, it's been a while since I started a project in Storyboard. I am not yet done reading but I'm curious why there is no mention of [0]AutoLayout.

[0]https://developer.apple.com/library/archive/documentation/Us...

papereditor68• 3 years ago

Thank you! Storyboards do support auto layout. I did not think it was worth mentioning.

ohwellhere2• 3 years ago

It's been a hot minute since I've done work in this ecosystem, but I am not sure it is accurate to say that Storyboards do not support Auto Layout. I used to build iOS apps with Storyboards and Auto Layout a few years ago.

https://developer.apple.com/library/archive/documentation/Us...

tomovo• 3 years ago

Looks nice and kudos for sticking with Objective-C. Still a nice language which compiles quickly (well, any language compiles quickly compared to Swift).

The visuals and attention to detail reminded me of Bvckup (https://bvckup2.com).

Downloaded the app to check the "smooth caret" somebody mentioned, started typing and got interrupted after 3 words by a popup telling me to check out PRO features. Oh well. Next, a OS popup about notifications... no thanks. I don't expect any notifications from a text editor. Or at least give me a minute to check it out on my own.

joenot443• 3 years ago

Pro features on what's ostensibly a replacement for TextEdit.app?

No thanks...

papereditor68• 3 years ago

Thank you!

I'll think about delaying that popup. :)

I should delay asking about notifications as well. It's for the support chat that I mentioned in the article. If I write back in that chat, I fire a local notification. Makes sense more sense to ask for that permission only when the user has written something to the chat.

kingkongjaffa• 3 years ago

I alway cringe when I see the whole “made with love heart emoji by companyname”.(not saying paper does this)

But in this case I feel that paper was crafted with a strong vision and care. So you could say that you can _tell_ this was made with love.

papereditor68• 3 years ago

Thank you!

koopuluri• 3 years ago

Great write-up from a great creator. I admire his attention to detail and craft. Beautiful. Inspiring.

papereditor68• 3 years ago

Thank you!

lovelyviking2• 3 years ago

Hi, it’s very beautiful app and very nice write-up. I am a solo developer too with attitude to the quality of apps very similar to yours and in my case it is a file manager for Mac OS. The file manager is written in objective-c as well and was gradually developed for some years already. It is very lightweight and I am using it daily as working horse to test and monitor it’s quality. It is at polishing stage now and when I am thinking about certain integration with text editor I believe it should be nothing less than something like you’ve made. Your attention to details and quality of user experience is facilitating and very resonate with with my approach to my app. I was not thinking about something particular at the moment but I thought may be there is an opportunity for us to cooperate in some form at some point and be generally in touch perhaps.

monkeynotes2• 3 years ago

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 those who care 2) Assurance the product is well cared for 3) A feeling that the dev understands me

This stuff is gold for a product. I am thinking of Procreate when I think of the king of this sort of thing. That app is just so ridiculously clever. I don't know how they managed to take the plethora of UI that other illustration apps have and squeeze it down into ~6 menu items. Somehow it works beautifully and there are so many subtle touches and hidden workflow gestures just waiting to be discovered. It's usable out of the box, and the more you use it the more you naturally learn how to use it more efficiently.

gyomu2• 3 years ago

I love many things about Procreate, but their palm rejection is terrible (ie inexistent) compared to every other drawing app which means the canvas often zooms/rotates wildly while I’m drawing (maybe cause I’m left handed?), making it super frustrating to use; they’ve ignored requests to address it with eg canvas lock for years ;_;

https://folio.procreate.com/discussions/3/6/13198

https://folio.procreate.com/discussions/3/6/13105

seanw444• 3 years ago

they’ve ignored requests to address it with eg canvas lock for years

Shouldn't that be pretty easy to implement, too? Just a button that prevents rotation...

monkeynotes2• 3 years ago

I have had no problems with this, but I use an iPad Mini for all my sketching and my palm is often off of the screen to the side as it's a small surface.

meandmycode• 3 years ago

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.

throwaway20376• 3 years ago

Not to steal your thunder about a MacOS-specific text editor, I would say that many Windows devs would say the same about Notepad++ and Sublime Text. While I am not a Windows fanboi, when I am forced to use that platform, I am always searching the Start Menu to run those text editors! I agree: The "TLC" (tender, loving, care) is well transmitted to users over the long run. The endless number of "hacker-friendly" features slowly builds a rabid fanbase.

throwaway20376• 3 years ago

I am confused. Why was this downvoted with no child comments?

raincole• 3 years ago

It depends on what kind of app you are making. Text editor is probably where the "craftsmanship" shines the most, cause there are just way too many text editors out there.

(Un)fortunately in many other cases it doesn't work like that. People use a certain app to book train tickets even its UI sucks hard and it asks 100 permissions unnecessarily, because the only alternative is get it over the counter in person.

tl2• 3 years ago

People use a certain app to book train tickets even its UI sucks hard and it asks 100 permissions unnecessarily

It's worth questioning why this is, as often as you can. We have a wallet app / payment system on most mobile devices that is card agnostic and gets better interfaces. Meanwhile, other services have to make do until a big player like Amazon or Ticketmaster comes along, consolidates the industry and starts charging high rents.

hbn• 3 years ago

Apple has a lot of niceties like this in their software. I've had so many times I thought "I wonder if I can do this?" and it just works because a designer thought of it before me.

Prime example I stumbled upon recently: In Apple Music, you can press+hold an album or song to pop open an action menu. I use this a lot for adding songs to the queue. There's an item to add it next in the queue, and another to add it last in queue. Usually if I want it somewhere specific in the queue, I'd just add it next and then move the song where I wanted it, but if I'm adding an album partway through the queue, that means you'll be dragging a bunch of tracks manually. So I thought, "it'd be nice if I could just drag things exactly where I want in the queue and drop it there." And then I figured I'd actually try it. If you press and hold a song/album and yank it from its place, it stays under your thumb. You can then either operate with another finger to open up the queue, or hold your thumb over it to pop it open, and then just drop it exactly where you want in the queue.

Not the first time I've come across something like this, but it's the kind of thing I only find on Apple platforms, particularly with their own apps. As much as I liked Google Play Music, you couldn't do it there, and I just checked Spotify and it doesn't let you do that either.

timestretch• 3 years ago

I'm surprised to see an example from Apple Music. That app is an perfect example of design neglect too. The ability to filter your song list for a specific track is now hidden in Apple Music.

To reveal the filter field, you must select the "View" menu, and "Show Filter Field". Worse each time you relaunch Music, this field is again hidden, and you have to select the menu item again.

fsckboy• 3 years ago

people discover these touches as they grow more familiar

people discover these touches in the breech, when they need to move on for some reason or other, and all that's familiar is lost. in the words of Joni Mitchell, "you don't know what you've got till it's gone"

biehl• 3 years ago

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.

papereditor68• 3 years ago

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.

mattbrewsbytes• 3 years ago

Out of curiosity is that a hand crafted page? It is a nice flow with the animations and the graphic call-outs, etc. I'm personally not interested in the Obj-C code snippets but that overall layout of the page, the sidebar ToC, the minimalist design is just really stunning.

Also - how did you do the visuals in the "Gnarly Bits" section that split the page/components out into verticals? That is such an amazing way to display the internals of a thing like a page.

If these elements could be packaged into a blog theme for whatever blog hosting platforms are popular these days I bet you'd get a bunch of people to purchase. Nice work!

toyg2• 3 years ago

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.

jshier16• 3 years ago

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.

rewgs• 3 years ago

Swift is for the new rubes, bootcamp graduates and so on.

That was a bit rude and unnecessary.

throwaway20376• 3 years ago

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, it is simply more "dev efficient" to write code in a managed (VM) langauge. Thoughts?

shoehorse• 3 years ago

Fantastic!

papereditor68• 3 years ago

Thank you!

sgt• 3 years ago

Just downloaded this app. It's not often you see indie apps that are this well designed. It almost feels like you're using something that is hand coded in Assembly - so fast!

papereditor68• 3 years ago

Thank you!

WillAdams• 3 years ago

The fact that this supports the Touch Bar alone is _Huge_.

Would it be possible to have a basic mode where one makes a one-time payment and has the option to hid all nagging about "Pro" features?

papereditor68• 3 years ago

You can pay for the lifetime license, and it will do exactly that.

Terretta3• 3 years ago

This is a great writeup.

Enjoyed even the transparency on pricing thinking, but one price that doesn't seem to have been experimented with is allowing a one time purchase that is not an in-app purchase.

In-app purchases make your app unavailable to company employees where the company manages the Apple device using MDM and purchases software using e.g. Apple Business Manager or the older volume purchasing. The $99 option should also exist as a standalone retail version so a company can buy the app for employees.

For small app makers: you might be surprised that a company-managed Mac with a company managed AppleID cannot use in-app purchases. Apple has no way for a company to do IAP for an employee, and in fact the employee cannot do it themselves either. For such users, you must either (a) allow retail app purchase, or (b) have an out-of-band subscription purchase and management, like Microsoft M365 or Adobe Creative Suite.

Whether you do it out of band or as a one time retail purchase, if you do track logins, you should support the simple "Login with" or "Continue with" buttons for Microsoft to hit the 85% of small businesses with identities on that platform, but also Apple and Google. These buttons are easier to add than devs might think. You don't need "SSO" to let most companies log in with company IDs.

wx196• 3 years ago

It is not possible to use the scroll on that website (working well on Firefox though).

papereditor68• 3 years ago

Chrome?

dmitrybrant• 3 years ago

Yep, I'm also seeing a 2px scrollbar that does not expand.

hannes02• 3 years ago

I came here to say this. Made me close the page after reading a few paragraphs. People need to stop fiddling with styling scroll bars.

papereditor68• 3 years ago

I made it expand on hover now.

another2another• 3 years ago

Fantastic writeup (read all the way to the end!), and especially impressed the author is brave enough to include a chat support tool. I'd be worried that somebody would lean on the Z key for 20GB and constantly spam my chat.

I have a copy of IA Writer that I've somehow never used, so maybe I'll buy this to add to the pile.

papereditor68• 3 years ago

Thank you!

There's occasional spam, but the barrier of having an Apple device to spam is enough to not make it a problem.

saagarjha5• 3 years ago

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 ;)

papereditor68• 3 years ago

Keeping my fingers crossed it will not happen. :D

lapcat11• 3 years ago

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!

saagarjha5• 3 years ago

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

jimbokun6• 3 years ago

I think you already know what will happen

I don't know, what will happen?

saagarjha5• 3 years ago

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

ChrisMarshallNY3• 3 years ago

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.

mromanuk• 3 years ago

I've released a SwiftUI app, but was a nightmarish experience. They are experimenting and changing stuff to better serve SwiftUI philosophy, like the change from Combine to Observation. There were plenty of bugs and some of them difficult to debug like previewing screens on Xcode, sometimes it keeps crashing. When it works it's marvelous. I hope they can stabilize it.

airstrike3• 3 years ago

You can still use Combine in Swift, but I agree Observation in general feels inferior for all but the most mundane cases.

It's like you go through a SwiftUI tutorial placing @Published and @ObservedObject everywhere, and then once you're writing the app you realize what you need is Combine except you haven't learned that yet

imbnwa2• 3 years ago

I follow the development of Swiftcord, A SwiftUI Discord client, on the developer's discord, and they almost constantly lambast how much is apparently missing or unstable between AppKit and the current version of SwiftUI, which has made it a struggle to get to feature parity with the official Discord client based on Electron cause lots of things you expect either have to be implemented by hand or just can't be done IIRC.

meindnoch2• 3 years ago

Why do they insist on making their life harder? Just use Cocoa...

lapcat11• 3 years ago

I'd be quite interested in Rich Siegel's take (the guy behind BBEdit). He's been at it, a while, as well.

Looking inside the BBEdit app, I see some Swift in BBEdit.app/Contents/Frameworks/CandiedYams.framework, which appears to be a third-party framework (CFBundleIdentifier org.darkrainfall.candied-yams), but not much else.

ChrisMarshallNY3• 3 years ago

Not surprising.

I've been using BBEdit for about thirty years. It's been through many changes. I suspect that he's pretty conservative.

orenlindsey• 3 years ago

SwiftUI is pretty good, I've been using to build an app. The big problem is navigation and state handling, it's not intuitive (although I never used AppKit or UIKit so I can't say if it's better or worse)

jshier16• 3 years ago

Yeah, you really need to combine SwiftUI with a dedicated architecture like PointFree's Swift Composable Architecture. It solves your state and navigation problems while adding dependency and testing solutions as well.

Apple's stubborn and bizarrely proud insistence on not providing the full solution here is very annoying.

jimbokun6• 3 years ago

The big problem is navigation and state handling

Those seem like very basic features that a UI framework needs to get right.

interactivecode2• 3 years ago

You should give it an other go building on SwiftData and the new Observation API’s. They made leaps and bounds and it’s so much better now!

I’m having a lot of fun with it at the moment. If you stay within the bounds of how they encourage you to build the apps, you can just go go go and with very little work release a fast, stable, native app across all their platforms.

jimbokun6• 3 years ago

When I tried using SwiftUI, the performance for scrolling through lists past a certain size was very painful. I guess there were ways to mitigate this slowness, but they were very unintuitive and did not give me confidence in the developers commitment to keeping apps snappy and responsive.

The APIs for NSTableView and NSCollectionView, in contrast, were always very responsive and performant when used in the default way.

All of this greatly reduced my trust in SwiftUI. Seems like they did not have performance in mind in the core design decisions of the framework, and only tested it on small data sizes.

Maybe things have improved since then.

jshier16• 3 years ago

No, List still has some awful performance cliffs unless you go out of your way to model your infinite lists in a way it can handle. There are some nice UI / NSTableView / CollectionView wrappers nowadays though.

interactivecode2• 3 years ago

The great strength of SwiftUI is that until they have caught up with UIKit and AppKit you can just drop down to those frameworks. So you can use SwiftUI in 95% of your app and where you run into limitions you can use the lowerlevel NSCollectionView for example. Whats even cooler is that inside that NSCollectionView you can just use SwiftUI views again.

lenkite• 3 years ago

I wish Apple had stuck to Model-View-Controller instead of shoehorning React philosophy into their native UI framework. Personally, I find the "old-school" way of doing things far easier to follow and understand.

luizsantana2• 3 years ago

Well, migrating swift versions was not too fun

vitorsr• 3 years ago

I always make it a point to buy small apps that are well-designed, well-engineered and well-architected in order to support the developers who make them.

We need more apps like this in every category.

20after42• 3 years ago

In the end, building a polished, frictionless support chat was one of the best decisions that I have ever made for Paper.

Many many years ago, I used to run a web hosting company. One of the first things I did was I built one of those little chat widgets that let me chat directly with visitors on my website. This was around the year 2000 and before I had ever heard of liveperson which was somewhat new at the time. That single feature did more for my business than anything I did. Because I could talk directly with customers (and potential customers), and because I was the sole decision maker for the business, I was able to say yes to ridiculously obscure requests for features that were easy to implement but very valuable to just one specific customer. My hosting business never grew into a large company but it did support me through college and for a while afterwards.

Solvency• 3 years ago

Why didn't you offer a customer support number?

runjake• 3 years ago

I imagine because the web chat was asynchronous. They didn't necessarily have to drop everything at that moment to answer the call.

20after42• 3 years ago

I did have a phone number, however, when someone is about to click "buy" on a website but they have one hesitation, they aren't as likely to dial a phone to get an answer. When they can click a button and have instant response right there on the page.

I was a really powerful sales and support tool.

neontomo• 3 years ago

I've been using an app called Left for simple text editing, but I think I prefer this one.

bilekas• 3 years ago

I had little trust in my ability to pick the right dependencies from an ecosystem that I was not familiar with

For me this is an invaluable lesson to learn. A pet peeve of mine are tutorials or guides which consist of a list of external packages and libraries to add before writing a line of code.

This write up is excellent though, some of the gripes I have with the Apple eco system the OP has turned into a 'learning' experience in a positive way. Really nice.

papereditor68• 3 years ago

Thank you!

PH95VuimJjqBqy• 3 years ago

For me this is an invaluable lesson to learn. A pet peeve of mine are tutorials or guides which consist of a list of external packages and libraries to add before writing a line of code.

likewise, 80% of the tutorial is preamble to prepare for the 20% you care about.

just don't.

gopher_space• 3 years ago

"Here is the compacted multi-line command I used to set up an environment a few years ago. I will not be explaining what it does or why you need these specific lib versions, but will assume that we all have a few of their dependencies installed."

And it's still the most useful guide to setting up Qt because it's the only first-page result that mentions Berkeley.

imbnwa2• 3 years ago

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, but Apple has been ringing the bell that this is the future for years now. How do you pick one to know you can just get things done, no matter what the requirements?

mthoms• 3 years ago

I'm in a similar position. Can you not use UIKit in Swift or do you have to use SwiftUI?

jshier16• 3 years ago

Not only can you use UIKit / AppKit in Swift (always have been), you can wrap them into SwiftUI as well. There's really no need to choose nowadays.

dceddia• 3 years ago

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.

fuzztester• 3 years ago

This is one of the big issues with many tech stacks these days: the somewhat frequent churn of the libraries and APIs. Things change under your feet in a few months, or a year, if not weeks, forcing you change your code to adapt, and then test and release everything again, etc.

fbn79• 3 years ago

The web page scrollbar is unusable

papereditor68• 3 years ago

Sorry, I'll try to make it more accessible.

It expands in the app as you hover over it. Probably needs a similar thing for the website.

Or I just need to give up and revert it to the standard one. :)

hannes02• 3 years ago

Or I just need to give up and revert it to the standard one. :)

Yes please.

sequoia• 3 years ago

yeah I can't get my mouse to focus on it. It's too small so the WM thinks I'm trying to resize the window.

papereditor68• 3 years ago

I made it expand on hover now.

johnthuss• 3 years ago

Very interesting article! I was really interested in your pricing experiments!

papereditor68• 3 years ago

Thank you!

articsputnik• 3 years ago

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.

papereditor68• 3 years ago

Thank you!

jwells896• 3 years ago

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.

germandiago3• 3 years ago

And you are now locked down to one environment.

ryanwaggoner• 3 years ago

One man’s downside is another’s upside.

settsu• 3 years ago

And? There are plenty of companies which have fared just fine under such "limitations".

Analemma_2• 3 years ago

The insistence that every application/framework must be cross-platform, or its worthless, is so bizarre to me. What is even the point of having multiple operating systems if they can't have distinct features to gain competitive advantage by attracting application developers? If operating systems can't differentiate, we might as well all use Windows.

Cross-platform applications have their place, but sometimes I like having features that I can get in one place and nowhere else. Let them both exist and quit griping about it.

allenu2• 3 years ago

If you’re an indie dev, that can be a good thing. I find it much simpler to ship for iOS and Mac as a solo dev.

mattgreenrocks2• 3 years ago

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.

detourdog• 3 years ago

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.

Vermyndax• 3 years ago

One environment with support on a vast plethora of devices and a long lifespan.

satvikpendem3• 3 years ago

Indeed, Apple customers are quite a big market of course, but as an indie dev especially, there are more markets to bring your products and services to. That is why I use frameworks like Flutter which work everywhere, even if they are worse than Apple's developer platforms (and this is subjective even still). The upside is simply too great to lock myself to only one platform.

rubymamis12• 3 years ago

I've built my note-taking app[1] in Qt, and while I worked hard to make it look good, I'm very satisfied with the result.

Also, it turns out to be much faster than comparable native apps (performance benchmarks available on the website).

[1] https://www.get-plume.com/

hit8run• 3 years ago

Looks good indeed. Well done.

fbnlsr• 3 years ago

Looks really nice. Just a heads-up, I get a NS_BINDING_ABORTED error on the home page video, so I can't see it. (Firefox 121.0, Linux).

brailsafe3• 3 years ago

No BBedit in the comparison list?

Klonoar• 3 years ago

You have one of the few Qt-based apps that looks and feels like it belongs on macOS. Really well done.

markdoubleyou• 3 years ago

Looks great! Did you use QT Quick or the Widgets?

pcammeraat• 3 years ago

This is also my favourite thing about the Apple platform. My apps usually do not have any dependencies and when they have they are often my own. It keeps it simple.

ninepoints• 3 years ago

I don't really understand this take. Appkit/Uikit _is_ the dependency.

criddell• 3 years ago

It's not a third party dependency.

mattgreenrocks2• 3 years ago

Definitely. It can take awhile to get the hang of some of Apple's frameworks, but they're generally very high quality. The best sign of this is you can ship components with them, forget about the details that went into building said component over months, and then come back and evolve them mostly painlessly.

Contrast with a lot of the web frontend ecosystem, where stuff might go stale within a few months. And the overall pervasive feeling of jank that comes when you're building UIs. (Though, I presume this goes away once you internalize browser layout engines better.)

For my two Mac apps, I use very few third party deps. They're simply not needed! They serve small, discrete purposes and could be replaced by bespoke code at a moment's notice. This is how software should be built! We've just forgotten about this because the browser ships with so little in terms of UI components.

danielvaughn• 3 years ago

Every now and then, a post appears on HN at the exact perfect time. As it happens I'm considering embarking on a similar journey - building a text editor from scratch as a native desktop mac app.

I agree with his approach - I remember writing Objective-C back in 2015/2016. At the time, Swift had just launched but it was nowhere near ready for production. So I had to learn Objective-C/UIKit/etc. As frustrating as it could be at time, I overall have pretty fond memories of it, and I got really good at it.

I've lost the skills since then but hope that Swift has matured enough to be suitable.

brantonb5• 3 years ago

For instance, the NSPopover is a good candidate for bubbles that hint at stuff in the Mac app. An iOS counterpart sadly does not exist, so no bubbles in the iOS app.

Ignoring popover presentations in UIKit, there’s also a new TipKit framework in iOS 17, but it’s Swift-only.

https://developer.apple.com/documentation/TipKit

The author has done a great job while remaining in Obj-C. I’m really curious how long they can avoid Swift, keep the native experience, and offer new features in the platforms.

papereditor68• 3 years ago

Thanks! Indeed, there is TipKit. I've just learned about it a few days ago.

I think so far when Apple added new features to existing components, they've always made dual APIs. Only some completely new things are Swift-exclusive.

That said, as the pile of those exclusive things gets bigger, it would be harder and harder to stay in Objective-C.

jshier16• 3 years ago

You know you don't have to choose one or the other, right? The languages interoperate and there's really no overhead to adopting Swift anymore. On newer OSes you're using tons of Swift under the hood anyway.

KerrAvon3• 3 years ago

I'm also puzzled by your statement about popovers; UIKit has supported them for a long, long time.

bitwize• 3 years ago

One of the really nice things about the Apple platform is you can still build and sell apps for it. Windows and especially Linux are encrusted with freeloaders, but Apple users are willing to open their wallets for software with that extra bit of care put into it.

papereditor68• 3 years ago

True!

It's remarkable that even today, with millions of apps, you can still find paying customers through the App Store even if you are a nobody.

leecommamichael• 3 years ago

I tried to build a zero-dependency editor of the same ilk and found it an insurmountable task. I garnered an immense gratitude for modern font-rendering, though! As someone that loves Swift, I think sticking with ObjC for this project was a great move. The default level of abstraction in Swift lends itself nicely to writing apps, but begins to feel like a bit of a different language at a sufficiently low-level (raw pointers, byte-arrays.) C is as low-friction as it gets for these things (though cuts like a knife in return.)

brantonb5• 3 years ago

This post was great, so I added the RSS feed to my reader and I almost instantly removed it. I always knew those "7 Best Writing Apps for iPhone (2024)" posts were only there for SEO, but seeing a post from 2021 with that title is frustrating. This post appears to be the only non-SEO-related post in the feed.

Not trying to take anything away from the author: the app and this post look great. But consider doing more writing like this and breaking them out into a dedicated, non-SEO feed. I'd subscribe to that in a heartbeat.

mtillman• 3 years ago

There is no money in doing what you're suggesting. You're basically asking for a donation.

brantonb5• 3 years ago

Yes, I'm asking for a bit of work to be done so that I can read their future posts like this. I spend money on well-crafted indie software but typically only after following the author for a while. I'd like to remain engaged and was offering a suggestion on how the author could make that happen.

The current RSS feed is not useful for humans. I'm not into SEO, so maybe RSS feeds are taken into account. You can publish multiple feeds, though.

papereditor68• 3 years ago

Thanks!

I've indeed forgotten about the RSS feed. That post was created in 2021, but I keep stuff up to date even for SEO content, so the update time is 2024. That said, those posts are purely for keywords - they have no value other than to get occasional clicks from Google, and to spread the word about Paper.

I'll think about separating the feeds.

brantonb5• 3 years ago

I totally understand that you have to play the game, even if I think the game makes search results worse. Appreciate your consideration and the post itself. (I'm an iOS dev that's made the jump from Obj-C to Swift and now from UIKit to SwiftUI.)

gwbennett• 3 years ago

Having 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 many of the advantages you mentioned. I often wonder what Obj-C would look like today if Apple had put the time and effort into it instead of Swift.

I was not aware of your app. I just downloaded it on my Mac and iPhone. It is really nice! I like the little things you have done, like the hints on the menu bars for using the Option key, and the hint disappearing when you do. I am going to continue to use it.

Thanks for sharing your experiences. Best of luck!

papereditor68• 3 years ago

Thank you for the high praise!

jshier16• 3 years ago

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.

mac-mc3• 3 years ago

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.

https://en.wikipedia.org/wiki/Second-system_effect

araes• 3 years ago

I cannot have read that correct. For people on the Apple Dev ecosystem, do you really have no access to SDK code as a reference? Not even some high level abstraction version? I got to that assembly code part and just sat there and re-read it again and again. "You've got to go straight to assembly mode?" I cannot have read that correct.

tl2• 3 years ago

You might want to clarify your question:

do you really have no access to SDK code as a reference?

You get headers but no source. While Darwin is in theory open source, UIKit, et. al. are not.

I got to that assembly code part and just sat there and re-read it again and again.

If you're referring to the screenshot, Xcode dumps you into disassembly in cases where the stack is not in your code. 0 -[MoTextView endFloatingCursor] is the author's code. The remainder is UIKit. Also, most of the line items are _prefixed which indicates a private method upon whose existence (much less implementation) is not reliable. As the author mentions, the stack on the left is usually enough to diagnose problems.

It's also one more thing that makes me fight using Swift; all of the name-mangling and opaque to the Objective C runtime additions make this problem even harder.

jasonjmcghee2• 3 years ago

I recently have been building in Swift and indeed this seems to be the case. It's endlessly frustrating. Also privatizing variables seems to be quite aggressive in standard libraries and I often find myself wanting to use that internal stuff.

meindnoch2• 3 years ago

I often find myself wanting to use that internal stuff

And then curse Apple when the internals change and your app breaks?

meerita2• 3 years ago

I am still using IA/Writer in my Mac. I wrote 3 books with it. The only thing I dislike most in the the absurd pricing on the iOS app.

freetonik• 3 years ago

iA Writer feels weirdly sluggish on my iMac 2017 5K, especially compared to Paper.

meerita2• 3 years ago

I am using it in a M1 Pro and it's fast.

ilrwbwrkhv• 3 years ago

First of all this is amazing. Amazing app, amazing dev, amazing story. Everything that the hacker culture stands for, is flourishing in your app. My question is do you make enough to live off apps like these? I really hope so, because these are some of the best tech products in the world and I would love to see more of these.

papereditor68• 3 years ago

Thank you!

Sadly, not enough to live off it in Europe.

But it's slowly growing, so maybe one day. :)

eslaught3• 3 years ago

Since the author seems to be in the comments, have you ever considered implementing a Typora-style live preview? (Typora, for those who don't know, hides the Markdown formatting as you type, and shows it again when you move the cursor back onto the text.)

Paper appears to have a more traditional split between text mode and preview mode, and you can't properly edit the formatting in preview mode (e.g., you cannot turn a heading back into normal text from preview mode).

I'm sure it's a pain to implement, but it's the one really killer feature of Typora that I can't live without.

papereditor68• 3 years ago

That would be a massive challenge and probably would lead to more bugs which is against my goal of having a low-maintenance product. The more dynamic is your text rendering, the harder it gets.

You can format from the Preview mode, by the way. You need to use the shortcuts for that or click inside the Format menu. If you put your caret on the line of the heading, then press Command+1/2/3 depending on the level of the heading it will convert the line back to normal text.

eslaught3• 3 years ago

Fair enough. Thanks for the response!

rubymamis12• 3 years ago

As someone that implement this right now in my block editor[1] I must say it's a HUGE pain in the ass. Synchronizing the underlying plaintext/markdown with the rendered rich-text/HTML is a big undertaking. Especially so, since Qt's QML TextEdit conversion between its rendered HTML and Markdown is so inconsistent and broken. I've been thinking of ditching it, but I might persevere and continue to try.

[1] https://www.get-plume.com/

eslaught3• 3 years ago

I totally get that.

I'm just one person, but for me, this was the feature that made me switch to a minimalist text editor for writing.

Otherwise, why not stick with Emacs? Plain text with light syntax highlighting is something Emacs already does fine, it's relatively distraction free, it has keyboard shortcuts I've already memorized forward and backwards.... The biggest downside is that I have to pop over to another window to get proper syntax rendering and to be 100% sure it's parsing the way I expect.

Anyway, just my two cents. I could totally understand it not being worth the effort to implement, but when it works, it's really nice.

holoduke• 3 years ago

Funny that my story also plus 10 years as a solo app dev is a little different. I shifted from native to full webapps 2 years ago. Never been more happy with that decision. Development speed is a lot higher and easier. I found the iOS SDK, but in particular the Android SDK a monstrosity to work with. Yes there is a very small performance penalty, but for simple list scroll apps not impacting user experience (proof comes from user reviews)

w10-1• 3 years ago

I appreciate the technical details, but the only thing that really mattered was the completely arbitrary design decision to make it look like paper, i.e., to adopt a minimalist approach.

This has been the distinguishing feature, as against all the other feature-full applications. Its success has spawned copy-cat's in this and other domains.

The solo dev can avoid following the herd. Developer groups, esp. groups with investors, require mutually-acceptable justifications that reduce to, well, joining the herd.

So as a solo dev, amplify this advantage, and ask: what do people really want, that they can't get from the herd?

(Esp. in an age thundering with AI mash-up's)

arthurofbabylon• 3 years ago

Are you working in TextKit 2 or TextKit 1?

What is your flow for accommodating new OS changes (some being quite dramatic)? Do you make list of broken things and new opportunities, then devise a complete solution? Or do you address them incrementally?

Great write up. Thank you.

papereditor68• 3 years ago

Thanks!

Still on TextKit 1. I am thinking of migrating to 2, but I still have downloads on older Macs, so I want to wait. Supporting both 1 and 2 in parallel would be a nightmare.

To be honest, I have not experienced a lot of dramatic updates. Apple has a good track record of keeping things backward compatible. The issues that I find on the new betas, I fix before the OSes are released in the Fall.

asciimo• 3 years ago

Cmd+f, "vim", Cmd+w

Update: jokes aside, this is a great read. Adding vim keybindings would violate the principles of this project.

twiss2• 3 years ago

Only very tangentially related, but I think the generated Markdown shown in the last screenshot under "Gnarly bits" is not correct? It contains `[**Alfred Nobel](https://en.wikipedia.org/wiki/Alfred_Nobel) for this prize.**`, with the bold starting inside and ending outside the link; I don't think that's possible. It should either start outside, or have two sections of bold text (inside and outside the link).

papereditor68• 3 years ago

The Markdown engine is bespoke. I don't follow any specs. Paper might be looser in what it allows than other Markdown editors. Practically no one had issues with that over the years. :)

twiss2• 3 years ago

Fair enough :)

elwell• 3 years ago

Love the technical detail of this post

papereditor68• 3 years ago

Thank you!

makk• 3 years ago

Had never heard of paper editor. Just using it now for the first time and WOW. This is amaaaaaazing. There's this thing I've wanted to write for a while now and could never quite get started. Something about this UI just pulls the writing out of me. Love it!

papereditor68• 3 years ago

Thank you!

luizsantana2• 3 years ago

This post is gold! Not only I love the app the post is so well written and well presented. The author care for details is crazy nice

papereditor68• 3 years ago

Thank you!

wffurr• 3 years ago

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.

papereditor68• 3 years ago

Thank you!

pappereditorrr2• 3 years ago

Nice 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.

papereditor68• 3 years ago

Thanks!

1. What's wrong with SEO? People discover the app from Google. Some of them even become paid customers. If people discover and purchase what they need - what's the harm?

2. That does not affect the App Store search results. If it would have - everyone would be doing it. App Store allows a lot of text in the description, so I thought I would fill it with something useful. I've also ordered the names from shorter ones to longer ones so it looks like a mountain. Aesthetic details everywhere. :)

pappereditorrr2• 3 years ago

1. Nothing is wrong with SEO. But I expected a blog in a similar fashion as your .dev page but I was highly disappointed when all I saw where these "empty" click-bait esque posts.

2. I've seen plenty of apps doing the same trick in the App Store. But if it doesn't affect the search indexing why even bother putting up a long list of apps that could hurt your business.

Nothing but respect for the work that you do and the app you've created.

deergomoo2• 3 years ago

Great 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.

papereditor68• 3 years ago

Thanks!

Can't recommend anything specific, to be honest. I've been piecing together information from old Apple docs, StackOverflow, API header files, and a bunch of really weird blogs. A lot of trial and error as well.

I think your best bet is ChatGPT. It has seen every possible use-case of Apple APIs from GitHub so it should know a lot. I've gotten some good tips from it for very specific things that did not exist on the web.

deergomoo2• 3 years ago

Thanks!

tigeroil• 3 years ago

I'd second ChatGPT for development in general.

Whilst I'm just a web developer, I've had times, even using third party libraries that aren't particularly well documented, where ChatGPT seems to have a shockingly good grasp of the library and seems to understand it better than the documentation does.

It's a lifesaver honestly.

zengid2• 3 years ago

This 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.

papereditor68• 3 years ago

Thanks!

Sorry, I'll try to make it more accessible.

zengid2• 3 years ago

No worries, thank you!

fritzo2• 3 years ago

Page annoyingly has no scrollbar.

papereditor68• 3 years ago

I made it expand on hover now.

fritzo2• 3 years ago

Wow, thanks!

divbzero• 3 years ago

The “rotate-to-undo” gesture is so cool. It reminds me of the main character in Doctor Strange rotating his hand to turn time backward and forward.

brcmthrowaway2• 3 years ago

How much do you make a year from this app

papereditor68• 3 years ago

I don't want to be public with $, but I can say that it is many times smaller than my full-time European salary.

brcmthrowaway2• 3 years ago

So its a side hustle

internetter7• 3 years ago

The attached video in the article says there are 367 subscribers, and there is some discrepancy (they say subs are 100$ a year but app says 50$). Apple is likely taking 15% (indie developer program), so between 15-30k

papereditor68• 3 years ago

The numbers in that video are fake, but close enough. :)

Yearly subs are 50$. Lifetime is 100$. That video shows the number of Pro users, not subscribers.

ChuckMcM• 3 years ago

This is a fabulous app for just writing (I know really simple but that is good stuff). It makes me really wish there was a portrait keyboard case for the iPad. (nobody does those, not even reMarkable which makes me sad)

papereditor68• 3 years ago

Thank you!

zamalek• 3 years ago

Closed-sourced native UI is a fragile place compared to the predictable JavaScript runtime of the browser.

Is that really the case with Apple dev? I'm genuinely curious.

I wound up extremely tired of the continuous moving target of web dev - especially in terms of x-browser compat, and very intentionally avoided it as much as possible professionally. The likes of WinForms, WPF (the Silverlight subset is still the best UI framework that I've used), GTK, and QT were significantly less frustrating - dare I say enjoyable.

thumbsup-_-• 3 years ago

I just downloaded this app and somehow just the experience of writing in it feels so good. Kudos for simplicity and clarity of thought to prioritize experience over effort.

papereditor68• 3 years ago

Thank you!

xer0x• 3 years ago

Amazing story!

papereditor68• 3 years ago

Thank you!

eaxrdi• 3 years ago

nice write-up

papereditor68• 3 years ago

Thank you!

9 years of Apple text editor solo dev

Related Stories