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:<p>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<p>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.
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.<p>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.<p>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.<p>Thanks for sharing your experiences. Best of luck!
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 <i>practical</i> 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.
<i>> 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.</i><p>It went ABI around Swift 5 or so.<p>I took a huge leap of faith, in 2014, and started using Swift, exclusively. It's turned out OK.<p>I'm not quite as positive about SwiftUI, though. I think it will work out, but it has a <i>huge</i> amount of catching up to do, if it is to replace UIKit/AppKit.<p>I'd be quite interested in Rich Siegel's take (the guy behind BBEdit). He's been at it, a while, as well.
> I had little trust in my ability to pick the right dependencies from an ecosystem that I was not familiar with<p>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.<p>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.
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.
> Closed-sourced native UI is a fragile place compared to the predictable JavaScript runtime of the browser.<p>Is that really the case with Apple dev? I'm genuinely curious.<p>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 <i>the</i> best UI framework that I've used), GTK, and QT were significantly less frustrating - dare I say enjoyable.
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.
Lovely writeup. Making that webpage must have taken quite some time also?<p>A question out of curiosity. What are your thoughts on re-writing in Swift?<p>If it were me, I am sure my tech-fingers would itch for a rewrite, but my business hands would slap those thoughts away.
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.<p>We need more apps like this in every category.
> 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.<p>That's a huge difference, but I believe it's because Swift is meant to be somewhat cross-platform, right?
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?<p>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.<p>I know all this stuff exists and isn't even that hard, but actually <i>finding</i> what I need has proven quite difficult. I found that Google searches for NS<i>Whatever</i> tended to return results for UI<i>Whatever</i>, and there are far fewer StackOverflow threads due to a lot of this stuff being from the early 2000s.<p>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.
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!
The “rotate-to-undo” gesture is so cool. It reminds me of the main character in <i>Doctor Strange</i> rotating his hand to turn time backward and forward.
> 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).<p>> 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.<p>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 ;)
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.<p>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.<p>I've lost the skills since then but hope that Swift has matured enough to be suitable.
> 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.<p>Ignoring popover presentations in UIKit,
there’s also a new TipKit framework in iOS 17, but it’s Swift-only.<p><a href="https://developer.apple.com/documentation/TipKit" rel="nofollow">https://developer.apple.com/documentation/TipKit</a><p>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.
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)
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.
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?
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.)<p>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).<p>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.
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](<a href="https://en.wikipedia.org/wiki/Alfred_Nobel" rel="nofollow">https://en.wikipedia.org/wiki/Alfred_Nobel</a>) 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).
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.)
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.<p>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.
Nice app but your marketing make me not want to use the app.<p>1. The blog is flooded with SEO oriented posts <a href="https://papereditor.app/blog" rel="nofollow">https://papereditor.app/blog</a>
This vs That, Top this, Top that<p>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.<p>I'ts just shady and unnecessary if you trully believe in your app.
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.<p>[0]<a href="https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/AutolayoutPG/index.html" rel="nofollow">https://developer.apple.com/library/archive/documentation/Us...</a>
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.
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.<p>I have a copy of IA Writer that I've somehow never used, so maybe I'll buy this to add to the pile.
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!
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.
Are you working in TextKit 2 or TextKit 1?<p>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?<p>Great write up. Thank you.
This is a really beautiful write-up!<p>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.
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)
The fact that this supports the Touch Bar alone is _Huge_.<p>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?
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.
> Closed-sourced native UI is a fragile place compared to the predictable JavaScript runtime of the browser.<p>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?
Looks nice and kudos for sticking with Objective-C. Still a nice language which compiles quickly (well, any language compiles quickly compared to Swift).<p>The visuals and attention to detail reminded me of Bvckup (<a href="https://bvckup2.com" rel="nofollow">https://bvckup2.com</a>).<p>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.
> In the end, building a polished, frictionless support chat was one of the best decisions that I have ever made for Paper.<p>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.
I alway cringe when I see the whole “made with love heart emoji by companyname”.(not saying paper does this)<p>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.
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.<p>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.<p>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.<p>So as a solo dev, amplify this advantage, and ask: what do people really want, that they can't get from the herd?<p>(Esp. in an age thundering with AI mash-up's)