16 ms·

9 years of Apple text editor solo dev

740 points by pimterry 3y ago

shoehorse 3y ago
Fantastic!
- papereditor 3y ago
  Thank you!
tobr 3y 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 3y 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.
  - internetter 3y 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
    - throwaway66201 3y ago
      That's because of the dynamic nature of JavaScript, you could do that in Swift too but that'd be a lot of dynamic dispatch for a static language...
- treve 3y ago
  In this OP compared the runtime, not frameworks. In my experience the web platform is extremely stable.
- throwaway66201 3y 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 3y ago
    That was a particularly crazy time for Windows UI development!
- matsemann 3y 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 3y ago
Smoothing the caret after character insertion is unbelievably pleasant. Now every other input feels glitchy, almost like continual paper cuts.
- kibwen 3y 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 3y 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 3y 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 3y ago
    Something like this: https://www.youtube.com/watch?v=FCUi_dRU0tY https://www.youtube.com/watch?v=FCUi_dRU0tY
    - SPBS 3y ago
      That looks incredibly unpleasant (to me), makes positioning the cursor like slipping over oil. I prefer the discrete jumps that the cursor makes :)
Alifatisk 3y 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?
- lapcat 3y 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/ https://www.swift.org/blog/abi-stability-and-more/
  - macintux 3y ago
    Related discussion from 3 weeks ago: https://news.ycombinator.com/item?id=38651690 https://news.ycombinator.com/item?id=38651690
- KMnO4 3y 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 3y 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.
    - jguimont 3y ago
ulf-77723 3y ago
Nice write up! Kudos to the author for being so humble about his journey - quite something achieved from my perspective.
- papereditor 3y ago
  Thank you!
deleted 3y ago
[deleted]
toxypol 3y ago
[flagged]
- Oras 3y ago
  That’s the magic of finding pain points.
  - coldtea 3y ago
    [flagged]
    - Aerbil313 3y ago
      [flagged]
- coldtea 3y ago
  And $10/month subscription? What should something like Photoshop with 10000x the features and development costs then charge? $1000/month? I understand "keeping it simple" but not "keeping it simple AND charging a crazy price for it" (there are essential, complex apps, that charge much less than that). I guess, if you can get away with it...
  - weego 3y ago
    Scale and niche don't have the same underlying pricing considerations
    - coldtea 3y ago
      As if the "minimalist editor" niche isn't already served with 1000 other apps? It's not exactly a niche the author uniquely identified and served. It's one of the most crowded markets when it comes to offerings.
      - metafunctor 3y ago
        It's a crowded market, but it IS a market. In fact, crowded markets are the ones that work the best. If people find their app, like what they see, and are willing to pay the price, what is your objection exactly?
lawgimenez 3y 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/UserExperience/Conceptual/AutolayoutPG/index.html https://developer.apple.com/library/archive/documentation/Us...
- papereditor 3y ago
  Thank you! Storyboards do support auto layout. I did not think it was worth mentioning.
  - ohwellhere 3y 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/UserExperience/Conceptual/AutolayoutPG/WorkingwithConstraintsinInterfaceBuidler.html https://developer.apple.com/library/archive/documentation/Us...
    - mattl 3y ago
      They said they do support Auto Layouts.
      - ohwellhere 3y ago
        I can't read. :)
tomovo 3y 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 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 3y ago
  Pro features on what's ostensibly a replacement for TextEdit.app? No thanks...
  - deleted 3y ago
    [deleted]
- deleted 3y ago
  [deleted]
- papereditor 3y 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 3y 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.
- deleted 3y ago
  [deleted]
- papereditor 3y ago
  Thank you!
koopuluri 3y ago
Great write-up from a great creator. I admire his attention to detail and craft. Beautiful. Inspiring.
- papereditor 3y ago
  Thank you!
  - lovelyviking 3y 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.
    - papereditor 3y ago
      Sure. If I can assist in some way - I will. DM me on Twitter.
monkeynotes 3y 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.
- gyomu 3y 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/13198 https://folio.procreate.com/discussions/3/6/13105 https://folio.procreate.com/discussions/3/6/13105
  - seanw444 3y 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...
  - deleted 3y ago
    [deleted]
  - monkeynotes 3y 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.
biehl 3y 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.
- papereditor 3y 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 3y 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!
    - papereditor 3y ago
      It's hand-crafted with TailwindCSS, vanilla HTML, and JS. I've worked on it for 2 months part-time. I was hoping it would get people's attention, and so it did. :) The component split is done by hand in Figma with regular screenshots and cropping. I also used a plugin for skewing.
      - lapcat 3y ago
        One nitpick: I dislike the tiny custom scroller. IMO customizing scrollers is almost always a disservice to users.
sgt 3y 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!
- papereditor 3y ago
  Thank you!
  - deleted 3y ago
    [deleted]
ubermonkey 3y ago
[flagged]
- frereubu 3y ago
  You're clearly not the target market.
  - seanw444 3y ago
    I didn't know there was a target market for that.
    - internetter 3y ago
      The 400 paying users beg to differ
- david422 3y ago
  The author did say he experimented up and down with prices and what people would pay for. If people think they are getting more then 33 cents a day worth of productivity out of the app ... then it works for them. Does seem rather high to me as well.
- ioslipstream 3y ago
  The app is free. In fact you don't miss much by not paying the subscription. Pro features are $10/month, but are actually also "free" via an unlimited time trial. The $10/month price tag is to support the developer if you're so inclined, which includes some nice-to-have features.
- deleted 3y ago
  [deleted]
WillAdams 3y 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?
- papereditor 3y ago
  You can pay for the lifetime license, and it will do exactly that.
  - Terretta 3y 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.
    - papereditor 3y ago
      Thank you for the suggestion! I've always avoided non-App Store distribution to keep things simpler. It's a nightmare to manage many different licensing schemes. Now I don't have to have any backend. Everything is done via the built-in, robust App Store mechanism that just works. I hope Apple will figure something out in the future. And I think they will since they want to increase their "Services" revenue as hardware sales decline. Making stuff easier for business customers seems like a low-hanging fruit.
mattlondon 3y ago
[flagged]
- artomweb 3y ago
  It's used as an indicator not an input.
  - deleted 3y ago
    [deleted]
- leftnode 3y ago
  A little harsh, no? Damn dude.
- papereditor 3y ago
  It expands as you hover over it just like every other scroll bar on macOS. :)
- delian66 3y ago
  With all due respect, please do so too. You could have stated whatever you think is a problem, without adding insults. Just some feedback for you.
- jbperry 3y ago
  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.
  - papereditor 3y 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. :)
wx196 3y ago
It is not possible to use the scroll on that website (working well on Firefox though).
- papereditor 3y ago
  Chrome?
  - dmitrybrant 3y ago
    Yep, I'm also seeing a 2px scrollbar that does not expand.
    - papereditor 3y ago
      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!
      - Narishma 3y ago
        > I thought that people anyway don't use the scroll bar that much It's hard to do when every popular platform seems intent on making it unusable.
        papereditor 3y ago
        I made it expand on hover now.
      - kemayo 3y ago
        You can't (unless there's a trick I don't know) change the width of the scrollbar when hovering over it. However... you can keep the width constant and have the apparent-width of the scroll thumb be determined by transparent borders. This would give the appearance of your current 2px scrollbar, but it'd be usable, and would visually expand out to show its grabbable area on hover: html::-webkit-scrollbar { width: 8px; } html::-webkit-scrollbar-track { background-color: transparent } html::-webkit-scrollbar-thumb { background: #d73f00; background-clip: padding-box; border-left: 6px solid transparent; } html::-webkit-scrollbar-thumb:hover { border: 0; } (The key to it is the background-clip property, that lets you use the border to control where the background is drawn.) You could also do exactly-this but without the :hover state, and it'd effectively just increase the grabbable-area of the thumb without any visual change to your current style. I like changing the visible width as a form of feedback though. :D
another2another 3y 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.
- papereditor 3y 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.
saagarjha 3y 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 ;)
- papereditor 3y ago
  Keeping my fingers crossed it will not happen. :D
  - deleted 3y ago
    [deleted]
  - deleted 3y ago
    [deleted]
- lapcat 3y 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!
  - saagarjha 3y ago
    Interestingly it seems to be 10.6+ in the documentation. They backdeploy like that sometimes I guess.
    - lapcat 3y ago
      Read the real documentation, the archive. ;-) https://developer.apple.com/library/archive/releasenotes/Foundation/RN-Foundation-older-but-post-10.8/index.html#//apple_ref/doc/uid/TP40016592 https://developer.apple.com/library/archive/releasenotes/Fou...
ChrisMarshallNY 3y 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 3y 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.
  - airstrike 3y 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
- imbnwa 3y 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.
  - meindnoch 3y ago
    Why do they insist on making their life harder? Just use Cocoa...
vitorsr 3y 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.
20after4 3y 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 3y ago
  Why didn't you offer a customer support number?
  - runjake 3y ago
    I imagine because the web chat was asynchronous. They didn't necessarily have to drop everything at that moment to answer the call.
  - 20after4 3y 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.
- deleted 3y ago
  [deleted]
neontomo 3y ago
I've been using an app called Left for simple text editing, but I think I prefer this one.
bilekas 3y 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.
- papereditor 3y ago
  Thank you!
- PH95VuimJjqBqy 3y 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 3y 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.
imbnwa 3y 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 3y ago
  I'm in a similar position. Can you not use UIKit in Swift or do you have to use SwiftUI?
  - jshier 3y 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 3y 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 3y 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 3y ago
The web page scrollbar is unusable
- papereditor 3y 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. :)
  - hannes0 3y ago
    > Or I just need to give up and revert it to the standard one. :) Yes please.
    - papereditor 3y ago
      I made it expand on hover now.
- sequoia 3y 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.
  - papereditor 3y ago
    I made it expand on hover now.
johnthuss 3y ago
Very interesting article! I was really interested in your pricing experiments!
- papereditor 3y ago
  Thank you!
articsputnik 3y 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.
- papereditor 3y ago
  Thank you!
jwells89 3y 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.
- germandiago 3y ago
  And you are now locked down to one environment.
  - ryanwaggoner 3y ago
    One man’s downside is another’s upside.
    - jwells89 3y ago
      Indeed. Supporting a single platform means generally fewer bugs and headaches, as multi-platform is going to introduce new troubles regardless of how one goes about it. Approaches that try to be write-once-run-everywhere “silver bullets” will still see platform—specific bugs, as will per-platform codebases. It’s not a coincidence that macOS/iOS has long had a disproportionally large quantity of high quality indieware. Capable framework + minimal headaches = polished apps that an individual or small group can sustainably support, even within less profitable niches and without VC funding.
  - settsu 3y ago
    And? There are plenty of companies which have fared just fine under such "limitations".
  - Analemma_ 3y 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.
danielvaughn 3y 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.
brantonb 3y 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 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.
- papereditor 3y 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.
  - jshier 3y 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.
    - papereditor 3y ago
      I have not investigated it, to be honest. If it's as easy as switching the compiler to Swift, and everything remains working as is, but I also get to use all the Swift stuff in addition to Objective-C, then I am clearly missing out!
      - brantonb 3y ago
        At my last job, we slowly started adopting Swift in 2016 by writing some unit tests with it. Once we felt comfortable and established some coding conventions, we started adding some production code. By the time I left in fall 2023, we were well over 50% Swift without any big rewrites of Obj-C code. Almost all the new code came in as Swift because developers enjoyed writing it over Obj-C. Sounds like you rely on Categories a lot. Check out Extensions in Swift. [1] There are some limitations (e.g., Swift enums lose a lot of their power if they're needed in Obj-C) but overall the interop is great. I don't remember anything in UIKit that couldn't be done with Swift. And if you're dealing with unicode text, doing things in Swift may make your life much easier. [1] https://docs.swift.org/swift-book/documentation/the-swift-programming-language/extensions/ https://docs.swift.org/swift-book/documentation/the-swift-pr...
bitwize 3y 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.
- papereditor 3y 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 3y 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.)
brantonb 3y 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 3y ago
  There is no money in doing what you're suggesting. You're basically asking for a donation.
  - brantonb 3y 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.
- papereditor 3y 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.
  - brantonb 3y 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 3y 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!
- papereditor 3y ago
  Thank you for the high praise!
- jshier 3y 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-mc 3y 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 https://en.wikipedia.org/wiki/Second-system_effect
araes 3y 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.
- tl 3y 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.
- jasonjmcghee 3y 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.
  - meindnoch 3y ago
    >I often find myself wanting to use that internal stuff And then curse Apple when the internals change and your app breaks?
    - jasonjmcghee 3y ago
      I would never
meerita 3y 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 3y ago
  iA Writer feels weirdly sluggish on my iMac 2017 5K, especially compared to Paper.
  - meerita 3y ago
    I am using it in a M1 Pro and it's fast.
ilrwbwrkhv 3y 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.
- papereditor 3y ago
  Thank you! Sadly, not enough to live off it in Europe. But it's slowly growing, so maybe one day. :)
eslaught 3y 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.
- papereditor 3y 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.
  - eslaught 3y ago
    Fair enough. Thanks for the response!
- rubymamis 3y 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/ https://www.get-plume.com/
  - eslaught 3y 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 3y 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 3y 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)
- deleted 3y ago
  [deleted]
arthurofbabylon 3y 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.
- papereditor 3y 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 3y ago
Cmd+f, "vim", Cmd+w Update: jokes aside, this is a great read. Adding vim keybindings would violate the principles of this project.
twiss 3y 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 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).
- papereditor 3y 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. :)
  - twiss 3y ago
    Fair enough :)
elwell 3y ago
Love the technical detail of this post
- papereditor 3y ago
  Thank you!
makk 3y 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!
- papereditor 3y ago
  Thank you!
luizsantana 3y 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
- papereditor 3y ago
  Thank you!
wffurr 3y 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.
- papereditor 3y ago
  Thank you!
pappereditorrr 3y 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 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.
- papereditor 3y 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. :)
  - pappereditorrr 3y 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.
    - papereditor 3y ago
      1. Sorry for the disappointment! SEO articles and high-quality thought pieces can coexist on a website - they have different purposes. The /blog slug is indeed a bit misleading, but that's what I started using initially, many years ago, and it's not even advertised on the website, so people should not end up on it. My point is - there is nothing shady about SEO articles. But I will think about reorganizing the site to better separate the articles. 2. I don't see why it would hurt. If people read the description and see the familiar name of the app that they use or have used, they will associate Paper with that app. It's just a list of writing apps - Paper is a writing app. I am trying to make a connection in their heads. Thanks - I love a good discussion!
deergomoo 3y 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.
- papereditor 3y 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.
  - deergomoo 3y ago
    Thanks!
  - tigeroil 3y 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.
zengid 3y 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.
- papereditor 3y ago
  Thanks! Sorry, I'll try to make it more accessible.
  - zengid 3y ago
    No worries, thank you!
    - papereditor 3y ago
      I made it expand on hover now.
- deleted 3y ago
  [deleted]
fritzo 3y ago
Page annoyingly has no scrollbar.
- papereditor 3y ago
  I made it expand on hover now.
  - fritzo 3y ago
    Wow, thanks!
divbzero 3y 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.
brcmthrowaway 3y ago
How much do you make a year from this app
- papereditor 3y 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.
  - brcmthrowaway 3y ago
    So its a side hustle
    - papereditor 3y ago
      Yep.
- internetter 3y 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
  - papereditor 3y 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 3y 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)
- papereditor 3y ago
  Thank you!
zamalek 3y 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-_- 3y 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.
- papereditor 3y ago
  Thank you!
xer0x 3y ago
Amazing story!
- papereditor 3y ago
  Thank you!
eaxrdi 3y ago
nice write-up
- papereditor 3y ago
  Thank you!

740 points by pimterry 3y ago

shoehorse 3y ago

Fantastic!

papereditor 3y ago
Thank you!

tobr 3y 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 3y 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.
- internetter 3y 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
  - throwaway66201 3y ago
    That's because of the dynamic nature of JavaScript, you could do that in Swift too but that'd be a lot of dynamic dispatch for a static language...
treve 3y ago
In this OP compared the runtime, not frameworks. In my experience the web platform is extremely stable.
throwaway66201 3y 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 3y ago
  That was a particularly crazy time for Windows UI development!
matsemann 3y 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 3y ago

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

kibwen 3y 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 3y 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 3y 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 3y ago
  Something like this: https://www.youtube.com/watch?v=FCUi_dRU0tY https://www.youtube.com/watch?v=FCUi_dRU0tY
  - SPBS 3y ago
    That looks incredibly unpleasant (to me), makes positioning the cursor like slipping over oil. I prefer the discrete jumps that the cursor makes :)

Alifatisk 3y 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?

lapcat 3y 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/ https://www.swift.org/blog/abi-stability-and-more/
- macintux 3y ago
  Related discussion from 3 weeks ago: https://news.ycombinator.com/item?id=38651690 https://news.ycombinator.com/item?id=38651690
KMnO4 3y 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 3y 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.
  - jguimont 3y ago

ulf-77723 3y ago

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

papereditor 3y ago
Thank you!

deleted 3y ago

[deleted]

toxypol 3y ago

[flagged]

Oras 3y ago
That’s the magic of finding pain points.
- coldtea 3y ago
  [flagged]
  - Aerbil313 3y ago
    [flagged]
coldtea 3y ago
And $10/month subscription? What should something like Photoshop with 10000x the features and development costs then charge? $1000/month? I understand "keeping it simple" but not "keeping it simple AND charging a crazy price for it" (there are essential, complex apps, that charge much less than that). I guess, if you can get away with it...
- weego 3y ago
  Scale and niche don't have the same underlying pricing considerations
  - coldtea 3y ago
    As if the "minimalist editor" niche isn't already served with 1000 other apps? It's not exactly a niche the author uniquely identified and served. It's one of the most crowded markets when it comes to offerings.
    - metafunctor 3y ago
      It's a crowded market, but it IS a market. In fact, crowded markets are the ones that work the best. If people find their app, like what they see, and are willing to pay the price, what is your objection exactly?

lawgimenez 3y 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/UserExperience/Conceptual/AutolayoutPG/index.html https://developer.apple.com/library/archive/documentation/Us...

papereditor 3y ago
Thank you! Storyboards do support auto layout. I did not think it was worth mentioning.
- ohwellhere 3y 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/UserExperience/Conceptual/AutolayoutPG/WorkingwithConstraintsinInterfaceBuidler.html https://developer.apple.com/library/archive/documentation/Us...
  - mattl 3y ago
    They said they do support Auto Layouts.
    - ohwellhere 3y ago
      I can't read. :)

tomovo 3y 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 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 3y ago
Pro features on what's ostensibly a replacement for TextEdit.app? No thanks...
- deleted 3y ago
  [deleted]
deleted 3y ago
[deleted]
papereditor 3y 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 3y 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.

deleted 3y ago
[deleted]
papereditor 3y ago
Thank you!

koopuluri 3y ago

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

papereditor 3y ago
Thank you!
- lovelyviking 3y 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.
  - papereditor 3y ago
    Sure. If I can assist in some way - I will. DM me on Twitter.

monkeynotes 3y 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.

gyomu 3y 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/13198 https://folio.procreate.com/discussions/3/6/13105 https://folio.procreate.com/discussions/3/6/13105
- seanw444 3y 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...
- deleted 3y ago
  [deleted]
- monkeynotes 3y 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.

biehl 3y 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.

papereditor 3y 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 3y 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!
  - papereditor 3y ago
    It's hand-crafted with TailwindCSS, vanilla HTML, and JS. I've worked on it for 2 months part-time. I was hoping it would get people's attention, and so it did. :) The component split is done by hand in Figma with regular screenshots and cropping. I also used a plugin for skewing.
    - lapcat 3y ago
      One nitpick: I dislike the tiny custom scroller. IMO customizing scrollers is almost always a disservice to users.

sgt 3y 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!

papereditor 3y ago
Thank you!
- deleted 3y ago
  [deleted]

ubermonkey 3y ago

[flagged]

frereubu 3y ago
You're clearly not the target market.
- seanw444 3y ago
  I didn't know there was a target market for that.
  - internetter 3y ago
    The 400 paying users beg to differ
david422 3y ago
The author did say he experimented up and down with prices and what people would pay for. If people think they are getting more then 33 cents a day worth of productivity out of the app ... then it works for them. Does seem rather high to me as well.
ioslipstream 3y ago
The app is free. In fact you don't miss much by not paying the subscription. Pro features are $10/month, but are actually also "free" via an unlimited time trial. The $10/month price tag is to support the developer if you're so inclined, which includes some nice-to-have features.
deleted 3y ago
[deleted]

WillAdams 3y 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?

papereditor 3y ago
You can pay for the lifetime license, and it will do exactly that.
- Terretta 3y 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.
  - papereditor 3y ago
    Thank you for the suggestion! I've always avoided non-App Store distribution to keep things simpler. It's a nightmare to manage many different licensing schemes. Now I don't have to have any backend. Everything is done via the built-in, robust App Store mechanism that just works. I hope Apple will figure something out in the future. And I think they will since they want to increase their "Services" revenue as hardware sales decline. Making stuff easier for business customers seems like a low-hanging fruit.

mattlondon 3y ago

[flagged]

artomweb 3y ago
It's used as an indicator not an input.
- deleted 3y ago
  [deleted]
leftnode 3y ago
A little harsh, no? Damn dude.
papereditor 3y ago
It expands as you hover over it just like every other scroll bar on macOS. :)
delian66 3y ago
With all due respect, please do so too. You could have stated whatever you think is a problem, without adding insults. Just some feedback for you.
jbperry 3y ago
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.
- papereditor 3y 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. :)

wx196 3y ago

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

papereditor 3y ago
Chrome?
- dmitrybrant 3y ago
  Yep, I'm also seeing a 2px scrollbar that does not expand.
  - papereditor 3y ago
    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!
    - Narishma 3y ago
      > I thought that people anyway don't use the scroll bar that much It's hard to do when every popular platform seems intent on making it unusable.
      - papereditor 3y ago
        I made it expand on hover now.
    - kemayo 3y ago
      You can't (unless there's a trick I don't know) change the width of the scrollbar when hovering over it. However... you can keep the width constant and have the apparent-width of the scroll thumb be determined by transparent borders. This would give the appearance of your current 2px scrollbar, but it'd be usable, and would visually expand out to show its grabbable area on hover: html::-webkit-scrollbar { width: 8px; } html::-webkit-scrollbar-track { background-color: transparent } html::-webkit-scrollbar-thumb { background: #d73f00; background-clip: padding-box; border-left: 6px solid transparent; } html::-webkit-scrollbar-thumb:hover { border: 0; } (The key to it is the background-clip property, that lets you use the border to control where the background is drawn.) You could also do exactly-this but without the :hover state, and it'd effectively just increase the grabbable-area of the thumb without any visual change to your current style. I like changing the visible width as a form of feedback though. :D

another2another 3y 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.

papereditor 3y 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.

saagarjha 3y 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 ;)

papereditor 3y ago
Keeping my fingers crossed it will not happen. :D
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]
lapcat 3y 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!
- saagarjha 3y ago
  Interestingly it seems to be 10.6+ in the documentation. They backdeploy like that sometimes I guess.
  - lapcat 3y ago
    Read the real documentation, the archive. ;-) https://developer.apple.com/library/archive/releasenotes/Foundation/RN-Foundation-older-but-post-10.8/index.html#//apple_ref/doc/uid/TP40016592 https://developer.apple.com/library/archive/releasenotes/Fou...

ChrisMarshallNY 3y 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 3y 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.
- airstrike 3y 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
imbnwa 3y 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.
- meindnoch 3y ago
  Why do they insist on making their life harder? Just use Cocoa...

vitorsr 3y 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.

20after4 3y 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 3y ago
Why didn't you offer a customer support number?
- runjake 3y ago
  I imagine because the web chat was asynchronous. They didn't necessarily have to drop everything at that moment to answer the call.
- 20after4 3y 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.
deleted 3y ago
[deleted]

neontomo 3y ago

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

bilekas 3y 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.

papereditor 3y ago
Thank you!
PH95VuimJjqBqy 3y 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 3y 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.

imbnwa 3y 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 3y ago
I'm in a similar position. Can you not use UIKit in Swift or do you have to use SwiftUI?
- jshier 3y 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 3y 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 3y 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 3y ago

The web page scrollbar is unusable

papereditor 3y 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. :)
- hannes0 3y ago
  > Or I just need to give up and revert it to the standard one. :) Yes please.
  - papereditor 3y ago
    I made it expand on hover now.
sequoia 3y 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.
- papereditor 3y ago
  I made it expand on hover now.

johnthuss 3y ago

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

papereditor 3y ago
Thank you!

articsputnik 3y 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.

papereditor 3y ago
Thank you!

jwells89 3y 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.

germandiago 3y ago
And you are now locked down to one environment.
- ryanwaggoner 3y ago
  One man’s downside is another’s upside.
  - jwells89 3y ago
    Indeed. Supporting a single platform means generally fewer bugs and headaches, as multi-platform is going to introduce new troubles regardless of how one goes about it. Approaches that try to be write-once-run-everywhere “silver bullets” will still see platform—specific bugs, as will per-platform codebases. It’s not a coincidence that macOS/iOS has long had a disproportionally large quantity of high quality indieware. Capable framework + minimal headaches = polished apps that an individual or small group can sustainably support, even within less profitable niches and without VC funding.
- settsu 3y ago
  And? There are plenty of companies which have fared just fine under such "limitations".
- Analemma_ 3y 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.

danielvaughn 3y 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.

brantonb 3y 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 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.

papereditor 3y 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.
- jshier 3y 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.
  - papereditor 3y ago
    I have not investigated it, to be honest. If it's as easy as switching the compiler to Swift, and everything remains working as is, but I also get to use all the Swift stuff in addition to Objective-C, then I am clearly missing out!
    - brantonb 3y ago
      At my last job, we slowly started adopting Swift in 2016 by writing some unit tests with it. Once we felt comfortable and established some coding conventions, we started adding some production code. By the time I left in fall 2023, we were well over 50% Swift without any big rewrites of Obj-C code. Almost all the new code came in as Swift because developers enjoyed writing it over Obj-C. Sounds like you rely on Categories a lot. Check out Extensions in Swift. [1] There are some limitations (e.g., Swift enums lose a lot of their power if they're needed in Obj-C) but overall the interop is great. I don't remember anything in UIKit that couldn't be done with Swift. And if you're dealing with unicode text, doing things in Swift may make your life much easier. [1] https://docs.swift.org/swift-book/documentation/the-swift-programming-language/extensions/ https://docs.swift.org/swift-book/documentation/the-swift-pr...

bitwize 3y 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.

papereditor 3y 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 3y 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.)

brantonb 3y 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 3y ago
There is no money in doing what you're suggesting. You're basically asking for a donation.
- brantonb 3y 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.
papereditor 3y 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.
- brantonb 3y 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 3y 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!

papereditor 3y ago
Thank you for the high praise!
jshier 3y 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-mc 3y 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 https://en.wikipedia.org/wiki/Second-system_effect

araes 3y 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.

tl 3y 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.
jasonjmcghee 3y 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.
- meindnoch 3y ago
  >I often find myself wanting to use that internal stuff And then curse Apple when the internals change and your app breaks?
  - jasonjmcghee 3y ago
    I would never

meerita 3y 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 3y ago
iA Writer feels weirdly sluggish on my iMac 2017 5K, especially compared to Paper.
- meerita 3y ago
  I am using it in a M1 Pro and it's fast.

ilrwbwrkhv 3y 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.

papereditor 3y ago
Thank you! Sadly, not enough to live off it in Europe. But it's slowly growing, so maybe one day. :)

eslaught 3y 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.

papereditor 3y 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.
- eslaught 3y ago
  Fair enough. Thanks for the response!
rubymamis 3y 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/ https://www.get-plume.com/
- eslaught 3y 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 3y 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 3y 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)

deleted 3y ago
[deleted]

arthurofbabylon 3y 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.

papereditor 3y 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 3y ago

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

twiss 3y 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 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).

papereditor 3y 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. :)
- twiss 3y ago
  Fair enough :)

elwell 3y ago

Love the technical detail of this post

papereditor 3y ago
Thank you!

makk 3y 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!

papereditor 3y ago
Thank you!

luizsantana 3y 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

papereditor 3y ago
Thank you!

wffurr 3y 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.

papereditor 3y ago
Thank you!

pappereditorrr 3y 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 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.

papereditor 3y 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. :)
- pappereditorrr 3y 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.
  - papereditor 3y ago
    1. Sorry for the disappointment! SEO articles and high-quality thought pieces can coexist on a website - they have different purposes. The /blog slug is indeed a bit misleading, but that's what I started using initially, many years ago, and it's not even advertised on the website, so people should not end up on it. My point is - there is nothing shady about SEO articles. But I will think about reorganizing the site to better separate the articles. 2. I don't see why it would hurt. If people read the description and see the familiar name of the app that they use or have used, they will associate Paper with that app. It's just a list of writing apps - Paper is a writing app. I am trying to make a connection in their heads. Thanks - I love a good discussion!

deergomoo 3y 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.

papereditor 3y 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.
- deergomoo 3y ago
  Thanks!
- tigeroil 3y 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.

zengid 3y 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.

papereditor 3y ago
Thanks! Sorry, I'll try to make it more accessible.
- zengid 3y ago
  No worries, thank you!
  - papereditor 3y ago
    I made it expand on hover now.
deleted 3y ago
[deleted]

fritzo 3y ago

Page annoyingly has no scrollbar.

papereditor 3y ago
I made it expand on hover now.
- fritzo 3y ago
  Wow, thanks!

divbzero 3y 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.

brcmthrowaway 3y ago

How much do you make a year from this app

papereditor 3y 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.
- brcmthrowaway 3y ago
  So its a side hustle
  - papereditor 3y ago
    Yep.
internetter 3y 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
- papereditor 3y 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 3y 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)

papereditor 3y ago
Thank you!

zamalek 3y 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-_- 3y 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.

papereditor 3y ago
Thank you!

xer0x 3y ago

Amazing story!

papereditor 3y ago
Thank you!

eaxrdi 3y ago

nice write-up

papereditor 3y ago
Thank you!