It makes sense when the editor is a core feature of your paid product. I understand the sentiment.
But is not it strange that I would need 8 months & a "development is ongoing" mindset just to render Markdown (which is very secondary to the main app features, and mostly just a user convenience people expect in 2026) with a custom low-level solution, effectively playing hardcore engineer instead of building what I actually want to build?
Anyhow, my point is not that "it is impossible". My point in the article is that I understand why people choose web technologies over native for such things. They want to build products, not fight the system’s limitations.
But I think my opinionated point from the article still stands: if you need rich text & good typography without fighting the platform, then web technologies quickly become the pragmatic choice.
For my app, I will probably continue with WebKit. It is the most reasonable middle ground for now. But in this situation, it is tempting to jump to something with a stronger rendering engine, like Chromium instead of WebKit, and start using the huge ecosystem of tools that already work. For example, https://diffs.com is one of the most tempting parts for me. The awkward thing is that embedding WebKit & calling it a day does not feel like a clean native solution either. You lose many of the native things you get when rendering through SwiftUI primitives, but you also do not get the full power & ecosystem of a proper web stack. And that makes it much easier to understand why so many companies (good & bad) choose Electron.
From an engineering perspective, even the fact that you can avoid this controversial middle ground entirely & build the app around web technologies from the start makes sense. It is not just laziness or ignorance of native platforms. Sometimes it is simply the more consistent & logical architecture.
Skill issue, I guess. I even tried your SSTextView (which is a very nice piece of software, by the way), though it does fit here, but I tried to understand how wrong my TextKit2 implementation is. In my tests, the SSTextView performed a bit worse with p95 on the static markdown scroll test (70.20 ms vs 16.7 ms for per frame rendering). But it is clear from the traces that SSTextView just does too many things I do not need. At least, I had my confirmation that I am not completely wrong about TextKit.
Do not know about "forever", at the moment it works okay, I guess. But for a long long time most of the iOS apps were using this https://github.com/TTTAttributedLabel/TTTAttributedLabel to have proper support for links & other basic attributes.
I tried Textual earlier today with some not-so-good results:
- Static completed Markdown scrolling fails the new focused probe. Result: p95 18.86 ms vs 16.7 ms budget, max 232.49 ms.
- Long live Markdown/code update path also fails. Result: p95 59.33 ms vs 16.7 ms, max 75.94 ms. This is a separate but related stress case around large rich text surfaces during updates.
- Long-history scaling technically passes, but the numbers are not smooth-frame healthy:
- 120 turns: total p95 21.35 ms
- 500 turns: total p95 23.11 ms
- 1000 turns: total p95 36.77 ms
Technically, it is not bad. However, it is a bit slower than my own solution & has similar performance gaps, mostly related to SwiftUI rather than the Textual implementation.
Yeah, this is actually my current in-progress solution: render the final Markdown & the streaming through WebKit.
And yes, I agree: on macOS, WebKit is a native OS framework. In that sense, it is "native". But I think it also supports the broader point I was making: if you want to work with rich text, Markdown, selection, typography, and long-form formatted content properly, web technologies quickly become the only viable option. I am not saying that using WebKit for a Markdown view is wrong. Quite the opposite, it is probably the most reasonable option available. The problem is that the "native" solution here is still effectively a web-rendering solution. There is a cost. Each `WKWebView` brings a WebKit engine with its own performance & memory overhead. So you cannot just sprinkle `WKWebView` everywhere & pretend it is free native macOS component as any other. My frustration is mostly that this is the answer. For this kind of UI, SwiftUI / AppKit / TextKit still do not give you a clean, modern, composable path that feels better than "just use WebKit".
`NSTextView` is good. My point is not that `NSTextView` itself is bad. The problem is that once you are working with all the "modern" Apple stack (Swift, SwiftUI, and the direction Apple is clearly pushing developers towards) `NSTextView` does not fit as naturally anymore. Some newer APIs are not even available for AppKit now, so you quickly end up in an awkward middle ground.
By "streaming" text, I mean a formatted text stream that has to be parsed, formatted, and appended on the fly - basically how every model/AI chat works now. And this is where `NSTextView` becomes tricky. It forces an interesting architectural choice: either go deeper into AppKit with `NSCollectionView`, custom cells, manual layout, etc., or fight the whole SwiftUI model by embedding something like `NSTextView` inside `LazyVStack` / SwiftUI views & then dealing with all the integration problems.
So I am not saying Cocoa / AppKit was always bad, or that `NSTextView` is useless. I am saying that for modern chat-style UI with incrementally rendered formatted text, it does not compose well with the rest of the modern Apple stack.
This is my pet project, a desktop app for working with xAI models & capabilities, so by "performance" I mostly mean "pleasant to use" (as it goes, simple & opinionated). Technically speaking, something like: stable FPS, no visible lags, and the ability to scroll smoothly while the model is streaming.
Regarding the parent comment: yes, memory is important, and I absolutely get the point. There should be a red line, for sure. But I will not sacrifice UX, productivity, and simple pleasure from using software just to save a few hundred megabytes of RAM (or even a few gigabytes) especially for an app I spend hours with behind the screen.
Memory consumption can & should be optimised with proper engineering for sure. As lags & inadequate performance in basic SDK-level primitives are much harder (impossible?) to fix from the outside.
This is me. I use Safari’s Reading Mode for almost everything, and for sites like Medium and similar platforms, it is enabled by default. There is something pleasant and calming about a consistent reading experience when consuming text content. Plus, Reading Mode supports basic customisations and follows the Light/Dark theme system, which some websites struggle with. It is not perfect, but it is familiar and easy to use. Recently, the Safari team improved it with an automatic Table of Contents, it preserves font, zoom, and theme selections across devices (works well for both macOS and iOS). The sepia theme is good enough to please my eyes. This is a fair assumption.
Many people I know use https://astro.build/ to create impressive landing pages for products or validation. It is fully static by default which is impressive.
Thanks for the app! I am curious about some of the design decisions on the iOS side. In your blog, you mention that “We truly believe a native Android & iOS experience stands out compared to non-native approaches, and we want to highlight that with HN,” but I noticed a few things:
- The app does not support Dynamic Type and instead uses steppers for font adjustments, which seem to stop at arbitrary values.
- It uses a custom web view for link previews.
- In many instances, it ignores safe areas.
When you say “native,” do you mean it is written in Swift, or is there more to it?
I am glad that they are trying to improve the security aspect of the tool. The tool is pretty good, but it is still uncomfortable that they use Adjust and Appsflyer to track almost everything[0] and require Full Keyboard Access on iOS.
As a mobile engineer with 20 years of experience and some knowledge about web development, I would say that web dev is more mature, flexible and (what is the essential part) keep up with new trends much faster.
Things like declarative UI syntax is still something new in the mobile world (SwiftUI, Compose, etc.), dependency management is a dark area (Android is a bit better, but a total mess on iOS/macOS development side), debugging experience for the web is miles ahead.
I usually ask myself the same question but in reverse – why mobile/desktop app development has not evolved to be like web dev?
Bumble | Google Cloud Platform Engineer | Full-time | Moscow, Russia (on-site, remote or mixed) | https://bumble.com
Bumble Inc. is the parent company of Badoo and Bumble, two of the world’s highest-grossing dating apps with millions of users worldwide. The Bumble platform enables people to connect and build equitable and healthy relationships. Founded by CEO Whitney Wolfe Herd in 2014, the Bumble app was one of the first dating apps built with women at the center, and the Badoo app, which was founded in 2006, was one of the pioneers of web and mobile dating products. Bumble currently employs over 700 people in offices in Austin, Barcelona, London, and Moscow.
Bumble is looking for a talented Google Cloud Platform engineer to own and drive technical projects from specification to delivery and beyond.
Experience We Are Looking For
- Experience building maintainable and testable code bases, including API design and testing techniques
- Experience with Google Cloud Platform
- Experience with Go or PHP or Java/Kotlin languages
- Experience developing APIs and integrating third-party services
- Experience in relational databases and SQL
- Excellent problem-solving skill and a desire to work on diverse projects involving interesting technical challenges
- Understanding of analytics, remote reporting, measurements, experiments and AB test systems
I use Things[0]. My journey looks like Emacs Org Mode -> Omnifocus -> Journaling mode (Notion, Craft) -> Things, and I am happy with the current setup. Things supports Someday/Anytime flows for easy reviews, recently they implemented markdown support for notes within tasks (including subtasks), and I like the concept of Deadlines.
- Inbox is a regular trash bin for all the incoming things (I review them once in 2-3 days)
- Today list of tasks I have to accomplish today with strict deadlines. When I finish with the Today list, I scan the Upcoming view for something I can work on in advance and then switch to the Anytime list (I use tags as a context switcher, like @: Work, Personal, Hobby) to pick up the next one
- Areas are a helpful feature too where I store work or personal related projects. It is worth mentioning that Things hides Someday (postponed) tasks and projects from the overview by default, and it helps to stay focused.
- For example, I have a "Hobbies" area with projects like "Blogging", "Watching List", or "FFXIV".
In the morning, I plan my day. Validate the tasks assigned for Today, scan the active projects for open tasks and check the agenda. When I have the scope for today, I try to break down large tasks into smaller ones (for two reasons, it is easier to overcome all the distractions during the day with smaller tasks and to think about the scope once again).
It depends on the job, but priorities never work for me. They can change in an eye blink and sometimes give you a false feeling of control (you marked something as a high priority a month ago, and it bothers you. But the circumstances have changed, and now you have a dilemma: convince yourself that it is not necessary anymore and you made a mistake or blindly follow the priority tag. Both options are bad, by the way). If I need prioritisation, I am overwhelmed with projects and try to solve this problem first. Sometimes, I have many parallel projects that require prioritisation, that's true, but even in such cases, I prioritise weekly (usually, Monday's evening when it is more or less clear how the week goes).
Ah, and yes, the UX of the application is excellent. I can do everything with keyboard shortcuts; they use the "modal editing" paradigm, which allows features like "type to search" (you can start typing anywhere, and it instantly brings the search interface); etc.
Had to move from central London to a suburb to afford a house with a dedicated cabinet. One of the best decisions I made at the beginning of the pandemic. I am sure my mental health has improved a lot with the option to "close" the cabinet at 6 PM and disconnect from my work till morning.
> Do you have a special desk?
A basic standing desk I bought on Amazon. It is okay. But now I am thinking to buy a new solid one. Standing desks tend to be wobble, and it can be not very pleasant.
> What monitors do you have?
iMac M1 24". I have LG 5k 24" as well on the table. But I turn it on only to connect to the iPad or when I have to present something online.
> Keyboard?
Ultimate Hacking Keyboard[0] 60 v1 with a palm rest. One of the best purchases at the beginning of the work from home/isolation trends.
> Mouse?
Apple Magic Trackpad. Do not like mouses.
> Do you work from a laptop?
Used to. But with the shift to the work from home situation, I switched to iMac—a more prominent display, quiet, better ergonomic.
> Do you move around the house?
Yes, but only for meetings. I usually make calls (Zoom, Google Meet) from my iPhone to move around. The second reason I do so, by the way, is the terrible Bluetooth stack on the current Apple Silicon machines and the inability of Google Sevices to work reliable anywhere except Google Chrome in the latest version.
> What other equipment?
- iFi ZEN DAC[1] for music
- BenQ WiT e-Reading Desk Lamp[2]
- Apple AirPods Max + AirPods Pro
> Microphone?
Nope. I am using the one in my headphone or iMac's ones.
Thanks for the answer! It does make sense. With a few caveats, however. From my experience, this is a way to go if you:
- Identified your market fit as users who appreciate and accept calls (not the case for many. GenZ, for example, does not fit)
- These calls are the main motto for the app (but in this case, I do not understand why you hide all the other features from potential users like me. I do not need personal calls, but I could change my mind after a few trial weeks with proper motivation)
Anyway, do not get me wrong. These are just my two cents. Otherwise, good luck with the project!
The project looks interesting, and I like the approach. But the "Claim your habit plan" paywall after a few onboarding screens with no option to try the application does not look right and feels like another "dark pattern" we are familiar with (force to waste some time and then block the results with a paywall).
But is not it strange that I would need 8 months & a "development is ongoing" mindset just to render Markdown (which is very secondary to the main app features, and mostly just a user convenience people expect in 2026) with a custom low-level solution, effectively playing hardcore engineer instead of building what I actually want to build?
Anyhow, my point is not that "it is impossible". My point in the article is that I understand why people choose web technologies over native for such things. They want to build products, not fight the system’s limitations.