9 years of Apple text editor solo dev

A solo developer’s nine-year journey building a minimalist Mac/iOS text editor in Objective‑C prompts a broader look at the trade‑offs between native Apple development and web or cross‑platform stacks. Commenters dissect Swift vs Objective‑C, SwiftUI’s maturity, backwards compatibility, and dependency avoidance, while also highlighting how obsessive attention to UI details, pricing experiments, and direct in‑app support can make small, paid indie apps viable on Apple platforms. Overall, the thread contrasts the stability and craftsmanship possible in Apple’s native frameworks with the appeal of faster iteration and wider reach on the web.

Native vs Web and Platform Stability

  • Several commenters argue the web runtime is extremely stable and almost fully backward compatible; old JS apps typically keep working.
  • In contrast, native Apple platforms are seen as brittle: OS updates can break apps, Swift lacked ABI stability early on, and Apple does not backport many APIs.
  • Others note that framework churn is more of a problem on Windows and the web than on Apple, where AppKit/UIKit are relatively stable over time.

Objective‑C vs Swift and Tooling

  • Strong debate around the choice to stick with Objective‑C.
  • Pro‑ObjC points: old code still compiles, faster compile times, more predictable tooling/debugger, “low‑level and hackable,” good for low‑maintenance products.
  • Pro‑Swift points: Swift has matured, offers better safety and expressiveness, is now ABI‑stable, and Apple is increasingly writing new frameworks and even parts of Foundation in Swift.
  • Some describe a smooth gradual migration strategy (adding Swift modules/tests into an ObjC app); others dislike Swift’s slow compilation and poor error messages.
  • There’s disagreement about ObjC’s long‑term future: some see it as inevitably sidelined; others think it will remain deeply embedded in Apple OSes for a long time.

SwiftUI vs UIKit/AppKit

  • Experiences with SwiftUI are mixed to negative: complaints about frequent changes (e.g., Combine → Observation), poor navigation/state story, bugs in previews, and performance cliffs for large lists.
  • Some say SwiftUI is great if you stay within its “happy path,” and you can drop down to UIKit/AppKit for complex pieces, even embedding SwiftUI inside classic views.
  • Others feel SwiftUI still lags far behind UIKit/AppKit for serious apps.

UX Details & Caret Animation

  • The smooth caret animation is polarizing: some find it delightfully “buttery,” others find it distracting or imprecise compared to discrete jumps.
  • Many emphasize that subtle, discoverable touches (“fringes”) create attachment, trust, and a sense of craft, especially in text editors.

Business Model & Distribution

  • The early “Pro features” popup and notification permission prompt are widely seen as too aggressive; the developer plans to delay them.
  • Users appreciate the one‑time “lifetime” option and ask for a nag‑free basic mode.
  • A major thread covers corporate purchasing: in‑app purchases don’t work with MDM/Apple Business Manager, so companies need a paid, non‑IAP SKU.
  • After discussion, the developer creates a separate, unlisted, paid “for business” App Store version to support this.

Website, SEO, and Marketing

  • The long technical write‑up page is praised for design and clarity; it’s hand‑built with Tailwind and custom visuals.
  • The ultra‑thin custom scrollbar is widely criticized as unusable; the developer iteratively widens it and makes it expand on hover.
  • The site’s SEO‑oriented blog (listicles like “Best writing apps…”) turns some readers off; others note it’s a pragmatic way to acquire users. Suggestions are made to split “real” articles into a separate RSS feed.

Indie Economics, Platform Choice, and Dependencies

  • Many celebrate the app’s polish, performance, and zero‑third‑party‑dependency approach, crediting the depth of AppKit/UIKit.
  • Several argue Apple users remain relatively willing to pay for quality indie apps, unlike typical Windows/Linux users.
  • The app currently earns significantly less than a full‑time European salary, so it remains a side project, but revenue is growing.
  • Lock‑in vs reach is debated: some prefer focusing on one platform for higher quality and fewer headaches; others advocate cross‑platform stacks (Flutter, React Native, Qt, Delphi, etc.) to reach larger markets at the cost of “native feel” and features.