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.
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.
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.
Interesting!
So all the NS_SWIFT_UNAVAILABLE APIs are still easily bypassable in Swift?
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.
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.
Around here, anything that happened before 2017 or so is 'old', and therefore 'bad'. The echo chamber has spoken.
And for what it is worth, the times I had to use Objective-C, it is a nice superset of C language that reads cleanly and is easy to grasp.
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).
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.
May be you can point out a few particular features of swift that would bring real advantages for his project?
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).
not having any benefits
Actually, building on stable abstraction is a pretty nice benefit when your focus is on the product.
Swift is quite nice, IMO, but has also changed quite a bit since 2015 and using it would likely have lead to a bunch of work to keep up.
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?
> 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.
No, it's because Swift was not ABI stable at the time, so it couldn't be added to the operating system.
Related discussion from 3 weeks 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.
And you are now locked down to one environment.
One man’s downside is another’s upside.
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.
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.
And? There are plenty of companies which have fared just fine under such "limitations".
If you’re an indie dev, that can be a good thing. I find it much simpler to ship for iOS and Mac as a solo dev.
I've built my note-taking app[1] in Qt, and while I worked hard to make it look good, I'm very satisfied with the result.
Also, it turns out to be much faster than comparable native apps (performance benchmarks available on the website).
Looks really nice. Just a heads-up, I get a NS_BINDING_ABORTED error on the home page video, so I can't see it. (Firefox 121.0, Linux).
Whoops. I'll look into that, thanks!
EDIT: Fixed.
Looks good indeed. Well done.
I don't really understand this take. Appkit/Uikit _is_ the dependency.
It's not a third party dependency.
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.
> 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.
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.
The big problem is navigation and state handling
Those seem like very basic features that a UI framework needs to get right.
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.
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.
When I tried using SwiftUI, the performance for scrolling through lists past a certain size was very painful. I guess there were ways to mitigate this slowness, but they were very unintuitive and did not give me confidence in the developers commitment to keeping apps snappy and responsive.
The APIs for NSTableView and NSCollectionView, in contrast, were always very responsive and performant when used in the default way.
All of this greatly reduced my trust in SwiftUI. Seems like they did not have performance in mind in the core design decisions of the framework, and only tested it on small data sizes.
Maybe things have improved since then.
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.
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.
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.
Not surprising.
I've been using BBEdit for about thirty years. It's been through many changes. I suspect that he's pretty conservative.
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.
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.
It is not possible to use the scroll on that website (working well on Firefox though).
Chrome?
Yep, I'm also seeing a 2px scrollbar that does not expand.
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!
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;
}
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
Makes sense. I'll give it a try. Thanks!
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.
I came here to say this. Made me close the page after reading a few paragraphs. People need to stop fiddling with styling scroll bars.
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?
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.
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
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...
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.
That was a particularly crazy time for Windows UI development!
In this OP compared the runtime, not frameworks. In my experience the web platform is extremely stable.
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..
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!
Interestingly it seems to be 10.6+ in the documentation. They backdeploy like that sometimes I guess.
Read the real documentation, the archive. ;-) https://developer.apple.com/library/archive/releasenotes/Fou...
I think you already know what will happen
I don't know, what will happen?
One of the implementations will get used. If they differ this is likely to cause at least one caller to be very upset.
So..."undefined behavior"?
Keeping my fingers crossed it will not happen. :D
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.
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.
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 ;_;
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...
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.
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.
Nice write-up, it's been a while since I started a project in Storyboard. I am not yet done reading but I'm curious why there is no mention of [0]AutoLayout.
[0]https://developer.apple.com/library/archive/documentation/Us...
Thank you! Storyboards do support auto layout. I did not think it was worth mentioning.
It's been a hot minute since I've done work in this ecosystem, but I am not sure it is accurate to say that Storyboards do not support Auto Layout. I used to build iOS apps with Storyboards and Auto Layout a few years ago.
https://developer.apple.com/library/archive/documentation/Us...
They said they do support Auto Layouts.
I can't read. :)
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.
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.
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.)
There is no money in doing what you're suggesting. You're basically asking for a donation.
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.
Smoothing the caret after character insertion is unbelievably pleasant. Now every other input feels glitchy, almost like continual paper cuts.
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.
Something like this: https://www.youtube.com/watch?v=FCUi_dRU0tY
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.
Great write-up from a great creator. I admire his attention to detail and craft. Beautiful. Inspiring.
Thank you!
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.
Sure. If I can assist in some way - I will. DM me on Twitter.
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'm in a similar position. Can you not use UIKit in Swift or do you have to use SwiftUI?
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.
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.
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?
You can pay for the lifetime license, and it will do exactly that.
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.
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.
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!
Thank you for the high praise!
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.
The web page scrollbar is unusable
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. :)
Or I just need to give up and revert it to the standard one. :)
Yes please.
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.
Fair enough. Thanks for the response!
For instance, the NSPopover is a good candidate for bubbles that hint at stuff in the Mac app. An iOS counterpart sadly does not exist, so no bubbles in the iOS app.
Ignoring popover presentations in UIKit, there’s also a new TipKit framework in iOS 17, but it’s Swift-only.
https://developer.apple.com/documentation/TipKit
The author has done a great job while remaining in Obj-C. I’m really curious how long they can avoid Swift, keep the native experience, and offer new features in the platforms.
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 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.
Thank you!
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.
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.
Why didn't you offer a customer support number?
I imagine because the web chat was asynchronous. They didn't necessarily have to drop everything at that moment to answer the call.
Nice write up! Kudos to the author for being so humble about his journey - quite something achieved from my perspective.
Thank you!
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.
Pro features on what's ostensibly a replacement for TextEdit.app?
No thanks...
Fantastic!
Thank you!
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!
Thank you!
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.
iA Writer feels weirdly sluggish on my iMac 2017 5K, especially compared to Paper.
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.
Thank you!
Very interesting article! I was really interested in your pricing experiments!
Thank you!
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.
Thank you!
Sadly, not enough to live off it in Europe.
But it's slowly growing, so maybe one day. :)
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.
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.
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.
Thank you!
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.
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.
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.
Thank you!
There's occasional spam, but the barrier of having an Apple device to spam is enough to not make it a problem.
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)
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.
I've been using an app called Left for simple text editing, but I think I prefer this one.
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.)
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)
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.
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).
False.
False.
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.
Which assertion was wrong? I was paraphrasing from the project page itself:
"It is in its early stages with many features still to be implemented." https://github.com/apple/swift-foundation
Your original assertion that Apple wasn't rewriting anything.
I have no idea what you're talking about. I made no such assertion.
Perhaps you're confusing me and "toyg"?
Ah true. Not sure why you replied then. 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.
Yup, exactly. Swift was specifically designed to replace Objective-C and C++ throughout Apple codebases (see https://www.youtube.com/watch?v=ZQc9-seU-5k).
C# is a totally different story.
Interesting. Can you share more details?
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.
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).
https://blog.timac.org/2023/1128-state-of-appkit-catalyst-sw...
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.
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?
Why do you say that? Do you have experience backing up that estimate?
That was a bit rude and unnecessary.
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.
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.
One nitpick: I dislike the tiny custom scroller.
IMO customizing scrollers is almost always a disservice to users.
Agree!
It's a single form-over-function thing that I could not resist not to add. :)