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.
Apple has a lot of niceties like this in their software. I've had so many times I thought "I wonder if I can do this?" and it just works because a designer thought of it before me.
Prime example I stumbled upon recently: In Apple Music, you can press+hold an album or song to pop open an action menu. I use this a lot for adding songs to the queue. There's an item to add it next in the queue, and another to add it last in queue. Usually if I want it somewhere specific in the queue, I'd just add it next and then move the song where I wanted it, but if I'm adding an album partway through the queue, that means you'll be dragging a bunch of tracks manually. So I thought, "it'd be nice if I could just drag things exactly where I want in the queue and drop it there." And then I figured I'd actually try it. If you press and hold a song/album and yank it from its place, it stays under your thumb. You can then either operate with another finger to open up the queue, or hold your thumb over it to pop it open, and then just drop it exactly where you want in the queue.
Not the first time I've come across something like this, but it's the kind of thing I only find on Apple platforms, particularly with their own apps. As much as I liked Google Play Music, you couldn't do it there, and I just checked Spotify and it doesn't let you do that either.
I'm surprised to see an example from Apple Music. That app is an perfect example of design neglect too. The ability to filter your song list for a specific track is now hidden in Apple Music.
To reveal the filter field, you must select the "View" menu, and "Show Filter Field". Worse each time you relaunch Music, this field is again hidden, and you have to select the menu item again.
It's much worse for apple music classical. It's great for classical music, but the way the library works with works and recordings is unintuitive and they decided to remove the ability to download (!?) and the ability to share playlists in the classical app and those as main-app only.
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 ;_;
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.
> people discover these touches as they grow more familiar
people discover these touches in the breech, when they need to move on for some reason or other, and all that's familiar is lost. in the words of Joni Mitchell, "you don't know what you've got till it's gone"
It depends on what kind of app you are making. Text editor is probably where the "craftsmanship" shines the most, cause there are just way too many text editors out there.
(Un)fortunately in many other cases it doesn't work like that. People use a certain app to book train tickets even its UI sucks hard and it asks 100 permissions unnecessarily, because the only alternative is get it over the counter in person.
> People use a certain app to book train tickets even its UI sucks hard and it asks 100 permissions unnecessarily
It's worth questioning why this is, as often as you can. We have a wallet app / payment system on most mobile devices that is card agnostic and gets better interfaces. Meanwhile, other services have to make do until a big player like Amazon or Ticketmaster comes along, consolidates the industry and starts charging high rents.
This is very true, and with regard to product success, the opposite effect here is a sad story - a tool full on lots of small annoyances is death by a thousand cut because each is hard to describe it doesn't seem worth explaining and so you get no telemetry for why nobody uses your product.
Not to steal your thunder about a MacOS-specific text editor, I would say that many Windows devs would say the same about Notepad++ and Sublime Text. While I am not a Windows fanboi, when I am forced to use that platform, I am always searching the Start Menu to run those text editors! I agree: The "TLC" (tender, loving, care) is well transmitted to users over the long run. The endless number of "hacker-friendly" features slowly builds a rabid fanbase.
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!
> I often wonder what Obj-C would look like today if Apple had put the time and effort into it instead of Swift.
It would largely look like Swift, since the goals of Swift (and most modern languages), safety and expressiveness, are fundamentally incompatible with C languages. There's really no point to basing a language on Obj-C if you're not keeping 100% compatibility, so they didn't.
There are a bunch of design decisions in Swift that make it more C++ with the corresponding binary bloat + other issues than reference counted Java/Smalltalk with a C FFI that Obj-C is.
You could've had Obj-C without the C for example, ADTs (enums), strong nullability enforcement and a nicer syntax while reusing most of the Obj-C core and retaining the compile speed, rock solid / fast debugging, function calls as data (selectors), easy mock creation and so on.
The systems programming capabilities is lost on %99.9 actual usage of swift. The swift project should've been split into two different projects IMO, where they modernized Obj-C into a successor language without making the C++ choices they did and created SwiftRust where the %0.1 that want system programming and nondeterministic multithreading capabilities can go do so. Apple second system effect-ed themselves hardcore with the Swift project, and it shows everywhere.
Sounds like you want Mojo, Lattner's statically typed language built on Python. In any case, the language you describe wouldn't be compatible with Obj-C except through an import layer like Swift. "Obj-C without the C" is meaningfully impossible.
And it's funny you mention systems programming, since Swift is still relatively bad at that compared to C++ or Rust, and most of its improvements in that area are recent and ongoing. It'll be another release or two before the memory movement features are fully in place and the language allows full control over ownership (without unsafe heroics at least).
Chris Lattner is on record that isn't something that Apple really cared about, and all Objective-C improvements starting with Objective-C 2.0 were already steps into improving the interoperability with what be later known as Swift.
Safe system programming is one of the key design goals from Swift.
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.
Definitely. It can take awhile to get the hang of some of Apple's frameworks, but they're generally very high quality. The best sign of this is you can ship components with them, forget about the details that went into building said component over months, and then come back and evolve them mostly painlessly.
Contrast with a lot of the web frontend ecosystem, where stuff might go stale within a few months. And the overall pervasive feeling of jank that comes when you're building UIs. (Though, I presume this goes away once you internalize browser layout engines better.)
For my two Mac apps, I use very few third party deps. They're simply not needed! They serve small, discrete purposes and could be replaced by bespoke code at a moment's notice. This is how software should be built! We've just forgotten about this because the browser ships with so little in terms of UI components.
I do see you have block editing in the qualifying statement for your speed comparison list, but Kanban seems to only be in your upcoming features list? I use bear regularly, but none of the features you mention are why I use bear; it's just a nice markdown editing experience and I'm rarely, if ever, dragging and dropping blocks within a document. I suppose if there are enough people who do find that crucial, you might want to emphasise it a little more, I don't think I spotted any mention of it.
I didn't mention it since I'm yet to implement it. I think I'll release Plume's beta in around two months, so I've got plenty of time to work on those. And yes, the Kanban is work in progress, but I'm nearly done[1].
Hmm, maybe that does look kind of interesting, thanks for the pic. Have you thought of any alternative ways to represent the todo checkbox in those Kanban tiles? Maybe aligning to the top instead of vertical center?
I haven't thought about that. In the regular editor, the checkbox is aligned to the top of the text. I'll experiment and see how it goes. Thanks for the suggestion.
I did use Qt Quick and I've been having such a great experience (as someone that used to program GUI imperatively via Qt C++ or using other framework like React/React Native) in my opinion, Qt C++ and Qt Quick is the best combo for a GUI framework. You get the performance of C++ and the simplicity, fluid animations, reactivity of QML, etc... My block editor is build in such a way that the models are in C++ and the views are in QML. This separation of logic and presentation works really well. I'll probably wrote a blog post about it.
Must be Widgets since using QML at work makes me regularly wanna rip my hair out. Its one of the worst frameworks Ive used once you go beyond simple hello world programs.
This is also my favourite thing about the Apple platform. My apps usually do not have any dependencies and when they have they are often my own. It keeps it simple.
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.
This could be at least partially solved if cross platform frameworks filled in feature gaps between platforms, making their feature set a union of features on all supported operating systems, but this rarely happens. Instead they typically take a least common denominator approach, limiting apps written with them to only the most common basic features.
“ feature gaps between platforms, making their feature set a union of features”
This fundamentally doesn’t work for UI/UX. You have to pick a paradigm and implementation details at some point and the high level UX design of Windows UI dejure and Mac are just different, in ways that cannot be factored out of a framework without leaky abstractions.
Your choices are: the Qt/Tk/Swing approach write once, a solid if dated UX that is themeable but not truly native anywhere, the web app (or its QML/Flutter/FX equiv), wxwidgets etal which sort of tried to be native everywhere last century and looks and works that way, or at least two parallel independent native UI implementations which is a gargantuan more effort.
Or go whole hog with FLTK or your own custom thing. a11y? WTF is that?
“ Instead they typically take a least common denominator approach, limiting apps written with them to only the most common basic features.”
I wouldn’t call wxwidgets basic, but it is a mess. It can’t be any other way. If it could someone would have made it in the last 30 years.
Just because you use Cocoa/AppKit rather than drawing on a canvas does not magically make your app feel like a Mac app.
Literally 100s of side projects have started down this path. People eventually learn you can’t abstract everything away, at least not the labor intensive part.
It does happen though - Qt tries very hard to do that. I don't know about literally everything, but the majority of platform-specific features/optimizations can be exposed through Qt with enough work.
And what is the result? Everyone complains that Qt is too hard to use, and so it has utterly lost the cross-platform war to Electron, and meanwhile the devs who want the platform-native functionality (like the OP of the article) use the OS-native toolchains instead.
Qt is probably closest among cross platform frameworks, but comes with some thorns that can be difficult to ignore and contribute to that “hard to use” sentiment.
The way Qt Widgets is for practical purposes usable only with C++ or Python is one such thorn, as is its use of custom types like QString. Both increase friction significantly as many devs aren’t able to use their preferred language and can’t use the language primitives they’re familiar with. Qt Widgets apps also require a good deal extra elbowgrease to make feel good on all supported platforms due to oddities in widget layout and drawing, and to my knowledge use of newer features (like blurred “vibrant” (macOS) or “mica” (Windows) window backgrounds requires dropping down to native code.
For QML, devs are stuck with JavaScript (which while functional, isn’t everybody’s cup of tea) and face some of the same issues that web/electron devs do with needing to pull in third party frameworks (like MauiKit[0]) to have a usable widget set.
Distribution is a problem across the board in Qt with tooling being a less than great state. It’s a very common issue to see crashes in Qt apps as a result of some incantation being missing.
In short Qt has the right idea, but I believe it’s held back by many of its technical and design decisions. I’d like to see a project that’s like it, but built in a modern language with good C interop so high quality efficient bindings can be easily generated, and has a bigger focus on good DX.
QML is actually pretty amazing. I've been building my block editor[2] view entirely in QML while the model is in C++. This separation of logic and presentation works great. And yes, there are some crashes sometimes (that I find quite easy to debug thanks to the built-in debugger), but take for example a similar app that's built with Rust and Dart[3], in my testing there were still memory leaks that caused my computer to hang. It's better to know you have a bug than for it to be hidden from you.
I agree with parent commenter, saying these cross-platform frameworks will end up supporting the least common denominator set of features. But I found with external open source libraries, the community is catching up very fast. For example, you want the awesome translucency macOS apps have for your Qt app? Here you go[4]. Many such cases. It's also pretty straightforward to add your own custom OS-dependent code, especially so, if someone already open sourced his approach. I recently wanted to move the traffic light buttons on macOS for my app, but couldn't figure the Objective-C code for that. I ended up looking at either Tauri or Electron source code and found my answer.
You talk as if Qt was really bad. Do you know of any toolkit that is better? I mean: Electron is a memory hog by default, Flutter or React I do not see they are available in those many languages you demand from Qt.
Which is that platonic toolkit I do not know of that is easy to distribute, productive, fast and available in any language?
For cross platform, from a technical standpoint Qt is one of best and that’s the problem. The best isn’t good enough, not for the masses that instead chose Electron and certainly not for the sorts of devs making polished Apple platform apps.
Developer experience is extremely important but it’s consistently something that’s swept under the rug with Qt, much to its detriment. Devs at large would rather be limited to a single platform or make huge tradeoffs in efficiency than live with bad DX.
The Telegram Desktop app is written with Qt, and I think they've done a pretty good job. I think there's a certain bias here. Most of the popular Qt apps are either open source or Enterprise software, both don't care much about UX and aesthetics. What I'm trying to get at, is that with some effort Qt apps can be on the same level (or very close) to native apps. That's what I aspire with my Qt apps as well.
I'd like to take the opportunity to mention Slint: a new toolkit in the scene, is inspired by the spirit of Qt while aiming to address its shortcomings
https://slint.dev
I've spent (what I thought was) quite a bit of time researching so many of these alternatives posted on this thread and this is the first I hear of slint, so thank you for sharing. It may be just what I was looking for
What I find bizarre is that this is often discussed without considering the specifics of the app.
I agree that not every app must be cross-platform. Text editors are a good example. The economics may or may not be more difficult. Yes the audience is smaller but the cost may be lower as well and you may have a competitive edge over cross-platform apps.
The problem with starting a single platform app is that you have to decide very early on that you're not going to need any collaboration/sharing features (unless the app is built on top of some cross-platform protocol or file format) and that you're not going to serve multi-platform users any time soon. This is a big decision with far reaching consequences.
I think there's a risk for developers (and tech bloggers) to become so enamoured with the fine details of their platform of choice that they lose touch with the priorities of the user community.
> The problem with starting a single platform app is that you have to decide very early on that you're not going to need any collaboration/sharing features
I beg to differ. Many industries (Graphic design, many engineering disciplines and game development) have a defacto platform for this exact reason
Yes, initially it is easier, but it is more difficult to scale to other platforms later on. It's all dependent on how much work you want to do upfront versus in the future.
As an indie dev, I feel like the greater risk is that you aren't able to release an MVP and find PMF at all, so I'd always err on getting something working on fewer platforms first so you can move quickly. Having the option to go multi-platform later is a good problem to have, but isn't guaranteed, so don't tackle it early on.
Trying to build for multiple platforms is a lot of overhead, not to mention UI paradigms don't always map one-to-one. Even building for both Mac and iOS (versus just iOS, for instance), for me, can be challenging since there are enough to differences between the two platforms in terms of UX that I have to take extra care to nail both experiences faithfully.
Yep that's true, but it's still another reason I'd use Flutter or React Native simply because they make building for even one platform much easier than Swift, in my experience. Then you can build up afterwards because they also make building for other platforms easier too. It's just one reason why Electron for example is well used in companies.
I think it depends on what you are building and who are your competitors.
Many B2B apps are built as plain web apps that run in the web browser and connect to a backend (CRUD apps). That's because business customers care less about the presentation, and more about the value that the software might deliver. If it saves them time or money - they will buy it no matter what the UX is. And many of them even prefer a tab in the browser, since they do their work in the browser anyway.
With B2C users often expect a more polished experience. More often than not they pay for a nicer, more polished thing, rather than for something that solves a particular pain point. Of course, the app should be useful, but that's table stakes. The deciding factor often becomes the UX. Thus in B2C, the client technology plays a bigger role. Depending on how many competitors offer a native UX, the users might not even consider you if they see that the app is not lightning-fast or has some weird, custom UI that looks off.
React Native has some native UI elements, but then many other things such as the navigation stack are reimplemented from scratch which results in a UX that appears to be similar, yet may work in weird ways that differ from native behavior. Plus React Native is pretty slow in my experience, and like any cross-platform thing has a ton of other weird edge cases and annoyances.
I have not used Flutter, but from my understanding, they have reimplemented the whole UI stack from scratch, and draw everything on a low-level graphical canvas. This means that it is even less native than React Native. They emulate/copy the native UI, but it is not the same. Not to mention that they have to do a ton of work to keep up with the latest changes in Android and iOS. Feel free to correct me.
For B2B, React Native, Flutter, or even Web/Electron are perfectly fine. For some less competitive B2C categories as well. For super competitive ones native is almost always a requirement.
“Easier” depends a lot on the project in my experience. For example if you need a tableview/datagrid as performant and feature rich as NSTableView on Swift/AppKit, you’re probably going to have to build it yourself with React (of any flavor) and especially Flutter (which has a heavy mobile bent to it) or at minimum settle for a community library that’s got big holes in its functionality.
There’s also the whole third party dependency mess referenced in an earlier post, which is unavoidable with both — anything more involved than “hello world” is going to have a mile long list due to how barebones the frameworks themselves are.
Indeed, Apple customers are quite a big market of course, but as an indie dev especially, there are more markets to bring your products and services to. That is why I use frameworks like Flutter which work everywhere, even if they are worse than Apple's developer platforms (and this is subjective even still). The upside is simply too great to lock myself to only one platform.
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.
I'm not sure one is locked down. One can write the model and the controller in the style one likes and then they just bind to appkit/uikit for the Apple versions.
This could be done despite nobody I know working this way. This used to be normal when x-windows was thriving.
The promise of fantastic cross-platform apps still hasn't borne out. We've been promised this since Java, yet converged on shipping Chrome with a webapp.
I brought it just as an example of what is possible. I do not give rat's ass whether it "inspires one's confidence" and who wants to be locked into what.
Freepascal is only tool I have found that creates same look and feel across platforms. After so many years of promise and intentions the cross platform issue only solved by Delphi/fpc to a professional level as far as I can tell. It's a metaphor for our industry chasing bling over productivity and generations seeking g rip and replace rather than understanding the constraints the prev gen worked with. Im only 60 but have worked with assembler, Algol, COBOL, Delphi, pascal, Awk, c#, various BASICs from apple II to VB.net. Python and JavaScript for 2 decades. Now most excited about Mojo.
> 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.
When I tried using SwiftUI, the performance for scrolling through lists past a certain size was very painful. I guess there were ways to mitigate this slowness, but they were very unintuitive and did not give me confidence in the developers commitment to keeping apps snappy and responsive.
The APIs for NSTableView and NSCollectionView, in contrast, were always very responsive and performant when used in the default way.
All of this greatly reduced my trust in SwiftUI. Seems like they did not have performance in mind in the core design decisions of the framework, and only tested it on small data sizes.
The great strength of SwiftUI is that until they have caught up with UIKit and AppKit you can just drop down to those frameworks. So you can use SwiftUI in 95% of your app and where you run into limitions you can use the lowerlevel NSCollectionView for example. Whats even cooler is that inside that NSCollectionView you can just use SwiftUI views again.
That has some unique edge cases as we have been discovering when you interleave UIKit and SwiftUI together.
I kind of wish that SwiftUI was a clean break in some ways and did not depend on UIKit and avoid all the abstraction leak issues that have been arising as a result. I know that would never happen in practicality although.
I wish Apple had stuck to Model-View-Controller instead of shoehorning React philosophy into their native UI framework. Personally, I find the "old-school" way of doing things far easier to follow and understand.
React is popular for a reason. Declarative UI is a million times easier to implement and maintain. If a total newbie had to learn UIKit and SwiftUI then pick one, they'd pick SwiftUI 100% of the time.
No, List still has some awful performance cliffs unless you go out of your way to model your infinite lists in a way it can handle. There are some nice UI / NSTableView / CollectionView wrappers nowadays though.
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.
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
> I'd be quite interested in Rich Siegel's take (the guy behind BBEdit). He's been at it, a while, as well.
Looking inside the BBEdit app, I see some Swift in BBEdit.app/Contents/Frameworks/CandiedYams.framework, which appears to be a third-party framework (CFBundleIdentifier org.darkrainfall.candied-yams), but not much else.
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.
SwiftUI is pretty good, I've been using to build an app. The big problem is navigation and state handling, it's not intuitive (although I never used AppKit or UIKit so I can't say if it's better or worse)
Yeah, you really need to combine SwiftUI with a dedicated architecture like PointFree's Swift Composable Architecture. It solves your state and navigation problems while adding dependency and testing solutions as well.
Apple's stubborn and bizarrely proud insistence on not providing the full solution here is very annoying.
just had a look at Composable Architecture, and it looks like swiftUI being the equivalent of react, they faced the same problem and someone developed a redux in swift. Am i correct ?
Kind of, but without the reactive UI bits, since SwiftUI already provides that (they provide a way to publish state into the older frameworks as well). It's heavily inspired by Elm and React but doesn't match 1:1 with either.
You should give it an other go building on SwiftData and the new Observation API’s. They made leaps and bounds and it’s so much better now!
I’m having a lot of fun with it at the moment. If you stay within the bounds of how they encourage you to build the apps, you can just go go go and with very little work release a fast, stable, native app across all their platforms.
Apple seems to think the UI frameworks should only focus on UI, and so overall arch is an afterthought. You can, of course, navigate and store state using the tools provided, but it's a pain to do so beyond local screens, where you have to manually pass things around, and you lose most testability.
> 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.
> 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.
"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.
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.
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.
> 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.
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.
> 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.
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.
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!
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.
I think it's still annoying. When reading, I often look at where the scrollbar is to get an idea of how much reading is left. Right now, the scrollbar is so thin that I have to waste time looking for it. On a 34" monitor, it's very annoying.
Be real: Apple is not going to rewrite MacOs/iOs in Swift. Objective-C will always be there, offering faster and more robust features.
Just look at the Microsoft equivalent: yes, C# is good and all, but the hardcore Windows apps are still using (lightly-skinned) VC++ APIs - after almost 25 years since they started flogging .NET.
Swift is for the new rubes, bootcamp graduates and so on.
They're literally rewriting in Swift right now. Foundation is being rewritten entirely in Swift. All new code is in Swift. All new frameworks are Swift-only. They're using Swift from low level firmware on the Secure Enclave to apps. This is already real.
> That's a mult-year project in its very early stages, yet we're already almost 10 years into Swift (more than 10 years of Swift internally to Apple).
It has already shipped, replacing parts of Foundation in the 2023 OS versions. It continues to grow, and it's a rewrite, so it certainly proves your assertion wrong.
My other points were a bit hyperbolic. Feel free the replace "all" with "the vast majority of". Apple obviously still writes Obj-C in their existing Obj-C frameworks, and doesn't arbitrarily rewrite into Swift, but their internal barriers to use Swift are now almost entirely gone. And I can't think of an entirely new framework that wasn't Swift-only recently.
> Your point about Foundation was meaningless and the others just nits. Do you have an actual point to make?
My point, as always, is the truth. You said two false things, which you subsequently admitted were hyperbole. Truth is valuable in itself, and more important than "points", i.e., arguments or motives.
If I were to make a point, though, it's that Objective-C still has a very long life ahead of it, and its complete replacement, if that ever occurs, will be an arduous process, given the amount of extant Objective-C code in the operating systems and first-party apps (not to mention third-party apps). It's not just Objective-C either: C++ is also used quite a bit in the OS. Think of WebKit, for example.
You're not going to be able to hire many people with Objective-C experience nowadays. Engineers with 7 years of experience just writing iOS apps will very likely will have only used Swift in their work experience. I work with 2 of them now.
The article author is a solo indie dev. I'm a solo indie dev. We don't need to hire.
By the way, we could be hired, for the right compensation. Nonetheless, companies almost never try to recruit me, but they still whine about how "hard" it is to find ObjC developers. They're not even looking.
Besides, experienced engineers can learn a new programming language. Do you think that every engineer Apple hired before 2014 had Objective-C experience?
This is turning into a silly argument… but anyway there's a blogger who has been tracking the number of binaries written in the various languages (and appkit vs catalyst vs swiftui etc.) for years.
Sonoma is 13% Swift (up from 11% in Ventura), 53% Obj-C (down from 55% in Ventura). The priority actually appears to be eating away from the C/C++ parts of the codebase (currently 33%, down from 42% just two releases ago).
At this point you can't separate Swift from the rest of the system so cleanly. Since it's now included with the OS directly and linked to from many system libraries, including parts of Foundation which have been directly rewritten in Swift while maintaining ABI compatibility with Obj-C callers, virtually everything on the system that uses Apple's frameworks uses Swift to some degree.
Disclaimer: I work for Microsoft, though I wasn't there during the early days of .NET or Windows Longhorn.
C# was created as a Java competitor. Although it had great C interoperability, the underlying .NET Framework was still a VM-based runtime with a garbage collector and all the disadvantages that brings. You can probably find various articles (https://longhorn.ms/the-reset/ is one) discussing attempts to adopt C#/.NET code for Windows Longhorn, which ultimately had to be walked back completely. .NET wasn't purpose-built for writing OS components or working deep inside existing Windows code.
Apple learned from this and other examples. The Swift team actively works with teams at Apple deep in native code to make sure they can handle their use cases without performance penalties, and with minimal ergonomic issues.
The difference is really about what the stated goals of the language were/are.
Thank you to share. My guess: In the year 2000, it was impossible with current desktop computing power to use C# for OS internals. In 2024, it is a different story.
That's what MS said as well, when they were pushing C#. All Windows will be using safe code! Still waiting... Another example is Mozilla and Rust - hell, I wouldn't be surprised if there was still Netscape code somewhere in the bowels of FF/TB!
Sure, Apple cares less about backward compatibility, but still, it's unlikely Objective-C is going anywhere, under the hood.
One of the most complex apps that Microsoft produces is Visual Studio. It is currently a hybrid of C++ and C#. I suppose that almost all new features are written in C# where possible. Why won't Apply follow the same path? The developer productivity in Swift must be 10x compared to Objective C. To be clear: I write this post as someone who has infinite love for optimization of native code. However, in many situtations, it is simply more "dev efficient" to write code in a managed (VM) langauge. Thoughts?
Apple does use Swift in their IDE, Xcode. Several years ago they rewrote the text editor component in Swift. It’s taken them a while to get all the features back that the old one had, and has had a fair amount of bugs as well. I often wonder why they didn’t just leave it in ObjC and add the new features they wanted to add, like the minimap or sticky declaration heaters.
I definitely wouldn’t call Swift a 10x improvement in efficiency, and I like coding in Swift. I do advent of code in it each year, but spend a fair amount of time just fighting with the compiler–after all these years, it still emits strange or just flat out incorrect diagnostics.
I concur. I'm 10k LOC deep into a SwiftUI app (Absolutely no clue how much that works out to be in Objective C + UIKit equivalent code), and one of the most frustrating things (after all the stuff you can't do without a PhD in apple internals) is how piss poor Swift errors are. I've changed a line of code in one file, and then another, completely unrelated one stopped compiling. Most frequently, it's something about how checking the file took too long and it should be broken up (which you will learn, really means you have a small error somewhere in said file and swift isn't in a sharing mood)
When I switch between C or C++ and a (non-deterministic) VM-based language like Java or C#, it feels like 10x. The IDEs are way more advanced, including (for me) the #1 all-important: debugging. For me (a mere mortal, average programmer), the fact that null pointer exceptions are clear in Java/C# is a huge gain compared "core dump" in C or C++. Going further, I am sure many would say the same kind of productivity speed-up for C or C++ to Python or Ruby.
I have a bit of code I use for ARM Cortex devices where I can trap bus errors. Most of the time I can recover the program counter where that happened. And use addr2line to get the file and line number. I've heard game developers talk about doing that sort of thing as well.
I would think if the C/C++ developers didn't have their head up their **[1] that could be a standard out of the box feature. There isn't any reason a program couldn't spit to stderr, 'seg_fault: file boots.c, line 1043'
In C++ I'm dubious you couldn't throw an exception instead of dumping.
[1] Got rid of frame pointers because they were sure that would make their dog slow C++ compilers run faster. Voice over. But it didn't make them faster. It made programs impossible to profile.
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.
> To my surprise, the Swift one had the full Swift runtime embedded into it — about 5MB, while the Objective-C one was super light — tens or maybe 100KB in total.
That's a huge difference, but I believe it's because Swift is meant to be somewhat cross-platform, right?
That experiment was done in 2015, when the Swift runtime had to be included. If you build an app now, it will link to the system runtime and be close to 100kb as well.
This seems to be premature optimization. The author forced himself to learn archaic Objective C for a completely unnecessary reason, and now is stuck with that design choice despite not having any benefits.
> The author forced himself to learn archaic Objective C for a completely unnecessary reason, and now is stuck with that design choice despite not having any benefits.
Some benefits:
1) Most Swift code written in 2015 when the author was starting won't even compile today, because the language has changed in non-compatible ways. Whereas Objective-C code written in 2015, 2005, and possibly even 1995 will usually still compile and run. The author mentioned low maintenance costs as a goal.
2) Swift compile times are still vastly slower than Objective-C.
3) The Swift tooling is still buggy, including the compiler, and especially the debugger (the author wrote an entire section about debugging).
Yup; 2015 was not the right time to move to Swift for most people.
If I started a new app today, I'd use Swift -- it's mature enough. But in 2015 and for a long time after, it wasn't really a good option unless you wanted to be on the bleeding edge (and you were willing to bleed).
Compile times will always be slower than Objective-C, but the compiled code _can_ be faster, with effort. And maybe someone will eventually break down and write a Swift-centric debugger.
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.
>The author forced himself to learn archaic Objective C for a completely unnecessary reason, and now is stuck with that design choice despite not having any benefits.
It's easy, now, to say that it was a poor choice/premature optimization/unnecessary/whatever. But, presumably, the author is unable to tell the future. At the time when the decision was made, there were benefits that the author deemed necessary (smaller distributable among other benefits).
I think even today Objective-C has some unique benefits for me. It's more low-level and more hackable. And I think some older APIs are not even available in Swift.
Of course, the pressure to rewrite would grow with every year as Apple continues deprioritizing Objective-C, but that's a problem for future me. :)
Aside from inline assembly, Swift can operate at just a low level, it just requires more work, since those operations are unsafe. All of Apple's public frameworks are importable into Swift. At this point there are more frameworks unavailable in Obj-C.
Depends what they are. Most of the time those are unavailable because they've been replaced with better Swift imports of the same API somewhere. Less commonly it's because they use one of the few C features that can't be imported into Swift or, even more rarely, because the API is fundamentally unsafe and they don't want it available in Swift. In all cases you can reexpose these APIs to Swift by writing your own C wrapper.
> The author forced himself to learn archaic Objective C for a completely unnecessary reason
I'd hesitate to put it that way.
Shipping software is always full of compromise, and we often have to stay away from the "bleeding edge," when we want to actually ship full-featured products.
I suspect that almost all the AAA apps are still ObjC.
I still use UIKit/AppKit for my work. I simply can't get the results that I need from SwiftUI.
And yet here they are, with a great app, some amount of sustained revenue, and a front page post on HN. Is that an accident?
The word that comes to mind after reading that post is “intentionality.” Many deliberate decisions, including for hard tradeoffs like this one. To me, that speaks to the importance of vision and judgment over the apparent correctness of individual choices.
It's been a long time since I did anything in macos/ios land, but in my experience most of the learning curve wasn't in Objective C, which is a fairly straightforward C-like language, but in all the platform APIs. Has Swift changed things much in this regard?
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.
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.
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.
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!
> 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 ;)
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!
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.
> 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.
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.
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.
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.
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!
They are separate compilers. Obj-C is compiled by clang, Swift by the Swift compiler. You enable bridging in Xcode and then get access to your Obj-C code in Swift through the use of a bridging header, and Swift in Obj-C through the use of the *-Swift.h generated header. You can write classes in Swift that are visible to Obj-C and vice versa. You can't expose everything from Swift to Obj-C since Obj-C is missing most of Swift capabilities, but it's easy to call back and forth.
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.
Funny that my story also plus 10 years as a solo app dev is a little different. I shifted from native to full webapps 2 years ago. Never been more happy with that decision. Development speed is a lot higher and easier. I found the iOS SDK, but in particular the Android SDK a monstrosity to work with. Yes there is a very small performance penalty, but for simple list scroll apps not impacting user experience (proof comes from user reviews)
That was an amazing read, thanks for sharing all those details. Partway through I was amazed to find a code snippet that I need for my iOS PDF editor: your map of language to system fallback font! I had figured out part of it but hadn't done the whole "type in every language and see what I get" step yet.
I'd been thinking of getting into Apple platform dev, but there really seems to be this strong contradiction in people saying to go full bore Swift/SwiftUI but reading this and as well following the Swiftcord devs' discord, there's a lot of problems with Swift/SwiftUI as a replacement for Obj-C/UIKit/AppKit. There also seems to be more and better documentation/examples for the Obj-C APIs than Swift; yes Obj-C is old, but Apple has been ringing the bell that this is the future for years now. How do you pick one to know you can just get things done, no matter what the requirements?
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.
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.
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.
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.
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.
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.
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.
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:
(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
Only very tangentially related, but I think the generated Markdown shown in the last screenshot under "Gnarly bits" is not correct? It contains `[**Alfred Nobel](https://en.wikipedia.org/wiki/Alfred_Nobel) for this prize.**`, with the bold starting inside and ending outside the link; I don't think that's possible. It should either start outside, or have two sections of bold text (inside and outside the link).
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. :)
I tried to build a zero-dependency editor of the same ilk and found it an insurmountable task. I garnered an immense gratitude for modern font-rendering, though! As someone that loves Swift, I think sticking with ObjC for this project was a great move. The default level of abstraction in Swift lends itself nicely to writing apps, but begins to feel like a bit of a different language at a sufficiently low-level (raw pointers, byte-arrays.) C is as low-friction as it gets for these things (though cuts like a knife in return.)
This post was great, so I added the RSS feed to my reader and I almost instantly removed it. I always knew those "7 Best Writing Apps for iPhone (2024)" posts were only there for SEO, but seeing a post from 2021 with that title is frustrating. This post appears to be the only non-SEO-related post in the feed.
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.
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 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.)
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.
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.
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. :)
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.
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.
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.
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.
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?
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.
First of all this is amazing. Amazing app, amazing dev, amazing story. Everything that the hacker culture stands for, is flourishing in your app. My question is do you make enough to live off apps like these? I really hope so, because these are some of the best tech products in the world and I would love to see more of these.
Fantastic writeup (read all the way to the end!), and especially impressed the author is brave enough to include a chat support tool. I'd be worried that somebody would lean on the Z key for 20GB and constantly spam my chat.
I have a copy of IA Writer that I've somehow never used, so maybe I'll buy this to add to the pile.
Had never heard of paper editor. Just using it now for the first time and WOW. This is amaaaaaazing. There's this thing I've wanted to write for a while now and could never quite get started. Something about this UI just pulls the writing out of me. Love it!
One of the really nice things about the Apple platform is you can still build and sell apps for it. Windows and especially Linux are encrusted with freeloaders, but Apple users are willing to open their wallets for software with that extra bit of care put into it.
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?
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.
I have one small gripe in that on my browser (chrome-windows11) the scroll bar is imperceptibly small, so I can't easily scrub through by grabbing it with the mouse. Other than that this is awesome.
This is a fabulous app for just writing (I know really simple but that is good stuff). It makes me really wish there was a portrait keyboard case for the iPad. (nobody does those, not even reMarkable which makes me sad)
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.
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.
It's not confusing. They show up next to each other when you search. One is "free" showing "GET" and offering usually ad supported + IAP. The other is paid, with a special logo, saying life time purchase, no ads, or etc. You can link to each other and talk about the other.
I'm not at work so I can't readily pull up a list of the apps we can and do buy employees thanks to having a paid version available, but there are quite a few, and they win out over more popular apps that have only IAP.
I think the regular, unsophisticated user might still be confused. I already envision questions like: "Should I buy a lifetime license in the free version or the paid pro app?". There are also additional hurdles like, for example, reviews being divided between 2 separate apps. I don't know, maybe it's worth it, but I am hesitant. I want to keep the whole experience of Paper simple, and this just adds complexity. I would prefer to wait for Apple to solve this at some point in the future.
I just downloaded this app and somehow just the experience of writing in it feels so good. Kudos for simplicity and clarity of thought to prioritize experience over effort.
> Closed-sourced native UI is a fragile place compared to the predictable JavaScript runtime of the browser.
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?
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.
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..
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
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
Looks nice and kudos for sticking with Objective-C. Still a nice language which compiles quickly (well, any language compiles quickly compared to Swift).
The visuals and attention to detail reminded me of Bvckup (https://bvckup2.com).
Downloaded the app to check the "smooth caret" somebody mentioned, started typing and got interrupted after 3 words by a popup telling me to check out PRO features. Oh well. Next, a OS popup about notifications... no thanks. I don't expect any notifications from a text editor. Or at least give me a minute to check it out on my own.
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.
> 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.
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 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?
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.
Have you checked the App? It's a very specific experience, nothing like you'll see on other apps. Someone put a lot of thought on it and polished it thoroughly. The app feels like a design piece, where someone had opinions on how things should be done and made it.
If you like and want that, you pay. If you don't you ignore.
Personally, I like it very much. I always enjoy seeing something well thought that would not necessarily fit everyones needs. Did I bought it? Not now because I don't see myself writing lots of text but if I had been writing I would definitely consider id because I want it despite not needing it ATM.
Let's put it like this: you want a nice drawer to store clothes. It has one purpose and one purpose only. You can either go to Ikea and get a 50 EUR drawer that will do the job, or you can pay 500 EUR to a local artisan for a nice cabinet with solid wood, an elegant design, a nice finish and even good wood for the back part. Literally depends on who you are, but I don't see how this is any different.
And before "software is cheap and wood is not", yes, but paint is also cheap and you don't judge an art piece by the price of the materials used.
Is software cheap? Even a small project can a few weeks to hack things together, and if you try to price it based on your hourly salary, the cost can climb in the thousands really fast.
The other week I just purchased a Hacker News app on iOS from a solo dev, for support. As an iOS developer myself it is vital that we support each other. I am not even rich.
Plenty of people, it turns out. I spend ~7 hours a day using a text editor, I don’t mind paying for a good one if it makes that a bit more pleasant or enjoyable. I think my barrier for impulse buying software like this is around €100.
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).
You're making a common pricing mistake: the price of a product has absolutely nothing to do with the cost of building it. Nothing. Price only depends on what people are willing to pay for it, i.e. on the perceived value.
Just because you aren't the target audience for such a product doesn't mean that audience doesn't exist. The world is large.
Personally I see a great business in premium tools for the elites in any domain. A professional writer probably wouldn't mind shelling out an extra $1000 a year or more for a premium tool that's better than anything else out there. Smaller audience, but it likely exists.
This goes both ways: if people aren't willing to pay even the price it takes to make the product, you go out of business. This happens often as well.
If photoshop saw an opportunity to increase the price to generate greater revenue, of course they'll try to do so. These changes in pricing and priorities often lead to opportunities for new products & companies.
Why should the author care whether their price scales to Photoshop level?
Price should scale with demand. A company like Adobe might want to maximise revenue, so they price it optimally to make the most money out of their product.
A single developer might not want to support half a billion users at $5. If selling at $60 means a lower number of users and a manageable number of support requests per month, it is a much better idea, even if it means less revenue. And in general, at higher prices you get better quality customers.
Pricing is hard, because it is not intuitive. And more importantly, the value of something is often subjective. People tend to forget that.
No one is getting scammed here, even if it cost 1000x as much. Why are you saying buyers don't know what they are charged?
> stupid personal buying decisions
Why does it affect you so much what other people are doing with their money? Spoiler alert: it is none of your business, and you are taking it way too personal.
>No one is getting scammed here, even if it cost 1000x as much. Why are you saying buyers don't know what they are charged?
I'm obviously not saying they are blindly charged an amount that they don't know.
I'm saying that they are buying stuff influenced by the minimalist fashion/emotion/etc and they don't know they're overpaying for no good reason.
>Why does it affect you so much what other people are doing with their money?
Because I live in a society, not in the wilderness. What people do with their money affects everybody, and people making better decisions is good for society in general.
>Spoiler alert: it is none of your business, and you are taking it way too personal.
While answering to me is "your business"? And getting into direct personal comments (as opposed to making a general remark)?
Long ago I paid somewhere between $25 and $100 for a calculator construction kit on Mac classic. Purely a purchase of love because it seemed like cool software and I love RPN calculators.
I resent the modern attitude that paying for software is an undue burden.
>Historical note: Photoshop cost $895 in 1990, which is more than $2,100 today.
I know. I've used it for decades.
But $2100 for Photoshop - a professional working tool - even today, is way more justified than $100 for a "minimalist text editor" (or $120/year subscription for same). Not to mention you can get Photoshop+Lightroom+1TB storage for the same exact yearly subscription price.
If it wasn't a piece of software but something like a barebones plastic spatula sold for $100, people would just laugh it off. But because it's software and intangible we can mystify the end product and pretend like there aren't some much more realistic prices one would expect it to be sold at, and it's "all about demand". In other words, we bring in some of the mystification from the fashion industry, where the same t-shirt (materials, labour, design, etc wise) costs $10 in some outlet and $200 in another because it has a different brand name attached to it.
I created an account on this site (after years of lurking) just to upvote you here.
Just because other people are willing to spend this kind of money on a text editor doesn't mean we can't think they are ridiculous for doing so. I definitely judge people who spend $10 on a text editor.
>If people find their app, like what they see, and are willing to pay the price, what is your objection exactly?
My more general objection to your question is that I don't consider individual preference, or individual choice, or individual action beyond criticism, just because the individual is "fine with it".
People can "find a product, like what they see, and be willing to pay the price", and the purchase could still be stupid and deserved to be called as such, and the price could still be highway robbery and be deserved to be called as such, and the product could still be subpar/average/bad and be deserved to be called as such.
Do you think you know better than the companies developing these products and the consumers buying them? Do you believe you understand what the right products and fair prices should be? This seems to justify your use of terms like 'highway robbery' and calling people 'stupid'.
I would have words for such viewpoints, but for the sake of a civilized conversation, I won't express them here.
Why don't you let the actual target audience decide whether the niche is served or not? Everyone has a different definition of "minimalist" and niche markets may have more specific requirements, so if someone can sell their specialized tool then what's the problem with that? Nothing of what you wrote is a reason against the existence of more choices.
I wish more software companies would take the approach of not bloating up everything and constantly updating everything. Its like the keeping up with the Joneses mentality but for software.
The website barely gets any traffic. Almost everyone downloads directly from the App Store. The prices are visible there. Plus they fluctuate per country, so showing only the US prices is also misleading.
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.
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.