[HN Gopher] 9 years of Apple text editor solo dev
___________________________________________________________________
9 years of Apple text editor solo dev
Author : pimterry
Score : 598 points
Date : 2024-01-04 12:30 UTC (1 days ago)
(HTM) web link (papereditor.app)
(TXT) w3m dump (papereditor.app)
| tobr wrote:
| > Closed-sourced native UI is a fragile place compared to the
| predictable JavaScript runtime of the browser.
|
| Huh, that sounds contrary to what people usually tout as a
| benefit of native. You always hear about framework churn and
| cross-platform problems when it comes to JavaScript. Maybe that's
| not so true anymore?
| realusername wrote:
| JS, as bad as it might be is close to 100% backward compatible,
| your project will work forever on newer browsers, that can't be
| said for Apple.
| internetter wrote:
| Also goes in the other way. We can literally only support iOS
| 17 because we're using SwiftUI and Apple refuses to backport
| anything, whereas in JavaScript you can generally use new
| APIs while either gracefully failing or triggering a fallback
| throwaway66201 wrote:
| That's because of the dynamic nature of JavaScript, you
| could do that in Swift too but that'd be a lot of dynamic
| dispatch for a static language...
| treve wrote:
| In this OP compared the runtime, not frameworks. In my
| experience the web platform is extremely stable.
| throwaway66201 wrote:
| Just don't use frameworks, or use the stable ones.
|
| I use React and it had exactly one significant major change
| (class components -> functions & hooks) since 10 years ago when
| I started out with the beta release.
|
| Windows went through 4 different "recommended" GUI frameworks
| and many more major API changes during that time.
| robertlagrant wrote:
| That was a particularly crazy time for Windows UI
| development!
| matsemann wrote:
| Native on other systems, perhaps. But for MacOS it's common
| that half your apps will break if you update as soon as the
| update is available. Got to give each developer time to fix
| their app first..
| anonymouse008 wrote:
| Smoothing the caret after character insertion is unbelievably
| pleasant. Now every other input feels glitchy, almost like
| continual paper cuts.
| kibwen wrote:
| To each their own. Microsoft Office apps do this by default
| these days and I found it maddeningly distracting. Fortunately,
| it can be turned off.
| iamatqh wrote:
| What do you mean by "smoothing the caret"? I just tried the app
| to see if I can make sense of it; do you mean that the caret
| does not blink if you continuosly insert characters?
| buzzerbetrayed wrote:
| When you type a character, the cursor smoothly animates from
| its previous position to the new one. As opposed to most apps
| where the cursor instantly jumps one character width to the
| right.
| alexitosrv wrote:
| Something like this:
| https://www.youtube.com/watch?v=FCUi_dRU0tY
| SPBS wrote:
| That looks incredibly unpleasant (to me), makes positioning
| the cursor like slipping over oil. I prefer the discrete
| jumps that the cursor makes :)
| Alifatisk wrote:
| > To my surprise, the Swift one had the full Swift runtime
| embedded into it -- about 5MB, while the Objective-C one was
| super light -- tens or maybe 100KB in total.
|
| That's a huge difference, but I believe it's because Swift is
| meant to be somewhat cross-platform, right?
| lapcat wrote:
| No, it's because Swift was not ABI stable at the time, so it
| couldn't be added to the operating system.
|
| https://www.swift.org/blog/abi-stability-and-more/
| macintux wrote:
| Related discussion from 3 weeks ago:
|
| https://news.ycombinator.com/item?id=38651690
| KMnO4 wrote:
| That experiment was done in 2015, when the Swift runtime had to
| be included. If you build an app now, it will link to the
| system runtime and be close to 100kb as well.
|
| This seems to be premature optimization. The author forced
| himself to learn archaic Objective C for a completely
| unnecessary reason, and now is stuck with that design choice
| despite not having any benefits.
| neverartful wrote:
| Have you ever developed anything substantial with Objective
| C? If not, I suggest that 'unfamiliar' might be more apt than
| 'archaic'. Anyone starting a non-trivial iOS project in 2015
| in Swift would still need to learn the basics of Objective C
| because so much of the documentation and examples were still
| in Objective C at that time. I don't think it's accurate to
| say that learning Objective C in 2015 had no benefits.
| jguimont wrote:
| 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.
| kjs3 wrote:
| Around here, anything that happened before 2017 or so is
| 'old', and therefore 'bad'. The echo chamber has spoken.
| lapcat wrote:
| > 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).
| KerrAvon wrote:
| 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.
| papereditor wrote:
| 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. :)
| jshier wrote:
| 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.
| papereditor wrote:
| Interesting!
|
| So all the NS_SWIFT_UNAVAILABLE APIs are still easily
| bypassable in Swift?
| jshier wrote:
| 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.
| KerrAvon wrote:
| Yes, it's very rare that something is actually
| unavailable. You can even use things like `sysctlbyname`
| in Swift without writing C.
| ziddoap wrote:
| > _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).
| jmull wrote:
| > 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.
| ChrisMarshallNY wrote:
| _> 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.
| lovelyviking wrote:
| May be you can point out a few particular features of swift
| that would bring real advantages for his project?
| shermantanktop wrote:
| 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.
| danenania wrote:
| 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?
| papereditor wrote:
| You are correct.
|
| Swift is lighter on the eyes, but it still uses the same
| APIs when paired with UIKit/AppKit.
|
| SwiftUI is a different thing though. It's like React for
| UIKit/AppKit and has a different API.
| ulf-77723 wrote:
| Nice write up! Kudos to the author for being so humble about his
| journey - quite something achieved from my perspective.
| papereditor wrote:
| Thank you!
| lawgimenez wrote:
| 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..
| .
| papereditor wrote:
| Thank you! Storyboards do support auto layout. I did not think
| it was worth mentioning.
| ohwellhere wrote:
| 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.
| ..
| mattl wrote:
| They said they do support Auto Layouts.
| ohwellhere wrote:
| I can't read. :)
| tomovo wrote:
| 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.
| joenot443 wrote:
| Pro features on what's ostensibly a replacement for
| TextEdit.app?
|
| No thanks...
| kingkongjaffa wrote:
| 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.
| papereditor wrote:
| Thank you!
| koopuluri wrote:
| Great write-up from a great creator. I admire his attention to
| detail and craft. Beautiful. Inspiring.
| papereditor wrote:
| Thank you!
| lovelyviking wrote:
| Hi, it's very beautiful app and very nice write-up. I am a
| solo developer too with attitude to the quality of apps very
| similar to yours and in my case it is a _file manager_ for
| Mac OS. The file manager is written in objective-c as well
| and was gradually developed for some years already. It is
| very lightweight and I am using it daily as working horse to
| test and monitor it's quality. It is at polishing stage now
| and when I am thinking about certain integration with text
| editor I believe it should be nothing less than something
| like you've made. Your attention to details and quality of
| user experience is facilitating and very resonate with with
| my approach to my app. I was not thinking about something
| particular at the moment but I thought may be there is an
| opportunity for us to cooperate in some form at some point
| and be generally in touch perhaps.
| papereditor wrote:
| Sure. If I can assist in some way - I will. DM me on
| Twitter.
| monkeynotes wrote:
| All the "fringes" stuff is where the magic is. The author
| suggests that no one notices some of the refinements, well this
| may be true on day one, but people discover these touches as they
| grow more familiar. Those subtle thoughtful additions are what
| makes the difference between an app I like using, and one I love
| using. They help me feel a couple of things:
|
| 1) A connection; I feel like I noticed something just for those
| who care 2) Assurance the product is well cared for 3) A feeling
| that the dev understands me
|
| This stuff is gold for a product. I am thinking of Procreate when
| I think of the king of this sort of thing. That app is just so
| ridiculously clever. I don't know how they managed to take the
| plethora of UI that other illustration apps have and squeeze it
| down into ~6 menu items. Somehow it works beautifully and there
| are so many subtle touches and hidden workflow gestures just
| waiting to be discovered. It's usable out of the box, and the
| more you use it the more you naturally learn how to use it more
| efficiently.
| gyomu wrote:
| I love many things about Procreate, but their palm rejection is
| terrible (ie inexistent) compared to every other drawing app
| which means the canvas often zooms/rotates wildly while I'm
| drawing (maybe cause I'm left handed?), making it super
| frustrating to use; they've ignored requests to address it with
| eg canvas lock for years ;_;
|
| https://folio.procreate.com/discussions/3/6/13198
|
| https://folio.procreate.com/discussions/3/6/13105
| seanw444 wrote:
| > 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...
| monkeynotes wrote:
| 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.
| gyomu wrote:
| I'm on a 12.9" iPad :)
| meandmycode wrote:
| 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.
| throwaway2037 wrote:
| 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.
| raincole wrote:
| 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.
| tl wrote:
| > 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.
| hbn wrote:
| 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.
| timestretch wrote:
| 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.
| fsckboy wrote:
| > _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"
| biehl wrote:
| Lovely writeup. Making that webpage must have taken quite some
| time also?
|
| A question out of curiosity. What are your thoughts on re-writing
| in Swift?
|
| If it were me, I am sure my tech-fingers would itch for a
| rewrite, but my business hands would slap those thoughts away.
| papereditor wrote:
| 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.
| matt_s wrote:
| Out of curiosity is that a hand crafted page? It is a nice
| flow with the animations and the graphic call-outs, etc. I'm
| personally not interested in the Obj-C code snippets but that
| overall layout of the page, the sidebar ToC, the minimalist
| design is just really stunning.
|
| Also - how did you do the visuals in the "Gnarly Bits"
| section that split the page/components out into verticals?
| That is such an amazing way to display the internals of a
| thing like a page.
|
| If these elements could be packaged into a blog theme for
| whatever blog hosting platforms are popular these days I bet
| you'd get a bunch of people to purchase. Nice work!
| papereditor wrote:
| It's hand-crafted with TailwindCSS, vanilla HTML, and JS.
| I've worked on it for 2 months part-time. I was hoping it
| would get people's attention, and so it did. :)
|
| The component split is done by hand in Figma with regular
| screenshots and cropping. I also used a plugin for skewing.
| lapcat wrote:
| One nitpick: I dislike the tiny custom scroller.
|
| IMO customizing scrollers is almost always a disservice
| to users.
| papereditor wrote:
| Agree!
|
| It's a single form-over-function thing that I could not
| resist not to add. :)
| toyg wrote:
| 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.
| jshier wrote:
| 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.
| sandyarmstrong wrote:
| 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.
| throwaway2037 wrote:
| > C# is a totally different story.
|
| Interesting. Can you share more details?
| sandyarmstrong wrote:
| 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.
| toyg wrote:
| 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.
| lapcat wrote:
| > Foundation is being rewritten entirely in Swift.
|
| 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).
|
| > All new code is in Swift.
|
| False.
|
| > All new frameworks are Swift-only.
|
| False.
| jshier wrote:
| > 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.
| lapcat wrote:
| > It continues to grow, and it's a rewrite, so it
| certainly proves your assertion wrong.
|
| 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
| jshier wrote:
| > Which assertion was wrong?
|
| Your original assertion that Apple wasn't rewriting
| anything.
| lapcat wrote:
| > 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"?
| jshier wrote:
| 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?
| lapcat wrote:
| > 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.
| mac-mc wrote:
| 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.
| lapcat wrote:
| 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?
| Eric_WVGG wrote:
| 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...
| jshier wrote:
| 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.
| rewgs wrote:
| > Swift is for the new rubes, bootcamp graduates and so on.
|
| That was a bit rude and unnecessary.
| throwaway2037 wrote:
| 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?
| jimbokun wrote:
| > The developer productivity in Swift must be 10x compared
| to Objective C.
|
| Why do you say that? Do you have experience backing up that
| estimate?
| mckn1ght wrote:
| 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.
| shoehorse wrote:
| Fantastic!
| papereditor wrote:
| Thank you!
| sgt wrote:
| Just downloaded this app. It's not often you see indie apps that
| are this well designed. It almost feels like you're using
| something that is hand coded in Assembly - so fast!
| papereditor wrote:
| Thank you!
| WillAdams wrote:
| The fact that this supports the Touch Bar alone is _Huge_.
|
| Would it be possible to have a basic mode where one makes a one-
| time payment and has the option to hid all nagging about "Pro"
| features?
| papereditor wrote:
| You can pay for the lifetime license, and it will do exactly
| that.
| Terretta wrote:
| This is a great writeup.
|
| Enjoyed even the transparency on pricing thinking, but one
| price that doesn't seem to have been experimented with is
| allowing a one time purchase that is _not_ an in-app
| purchase.
|
| In-app purchases make your app unavailable to company
| employees where the company manages the Apple device using
| MDM and purchases software using e.g. Apple Business Manager
| or the older volume purchasing. The $99 option should also
| exist as a standalone retail version so a company can buy the
| app for employees.
|
| For small app makers: you might be surprised that a company-
| managed Mac with a company managed AppleID cannot use in-app
| purchases. Apple has no way for a company to do IAP for an
| employee, and in fact the employee cannot do it themselves
| either. For such users, you must either (a) allow retail app
| purchase, or (b) have an out-of-band subscription purchase
| and management, like Microsoft M365 or Adobe Creative Suite.
|
| Whether you do it out of band or as a one time retail
| purchase, if you do track logins, you should support the
| simple "Login with" or "Continue with" buttons for Microsoft
| to hit the 85% of small businesses with identities on that
| platform, but also Apple and Google. These buttons are easier
| to add than devs might think. You don't need "SSO" to let
| most companies log in with company IDs.
| papereditor wrote:
| 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.
| wx196 wrote:
| It is not possible to use the scroll on that website (working
| well on Firefox though).
| papereditor wrote:
| Chrome?
| dmitrybrant wrote:
| Yep, I'm also seeing a 2px scrollbar that does not expand.
| papereditor wrote:
| Oh yes, sorry. This is a form-over-function detail that I
| added to the website to mimic the app.
|
| I did not, however, invest the time to make it expandable.
| I thought that people anyway don't use the scroll bar that
| much, and for quick navigation there is the table of
| contents on the left.
|
| I'll see if I can make it more accessible!
| Narishma wrote:
| > 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.
| kemayo wrote:
| You can't (unless there's a trick I don't know) change
| the width of the scrollbar when hovering over it.
| However... you _can_ keep the width constant and have the
| apparent-width of the scroll thumb be determined by
| transparent borders.
|
| This would give the appearance of your current 2px
| scrollbar, but it'd be usable, and would visually expand
| out to show its grabbable area on hover:
| html::-webkit-scrollbar { width: 8px; }
| html::-webkit-scrollbar-track { background-color:
| transparent } html::-webkit-scrollbar-thumb {
| background: #d73f00; background-clip: padding-box;
| border-left: 6px solid transparent; }
| html::-webkit-scrollbar-thumb:hover { border: 0;
| }
|
| (The key to it is the background-clip property, that lets
| you use the border to control where the background is
| drawn.)
|
| You could also do exactly-this but without the :hover
| state, and it'd effectively just increase the grabbable-
| area of the thumb without any visual change to your
| current style. I like changing the visible width as a
| form of feedback though. :D
| papereditor wrote:
| Makes sense. I'll give it a try. Thanks!
| hannes0 wrote:
| 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.
| another2another wrote:
| Fantastic writeup (read all the way to the end!), and especially
| impressed the author is brave enough to include a chat support
| tool. I'd be worried that somebody would lean on the Z key for
| 20GB and constantly spam my chat.
|
| I have a copy of IA Writer that I've somehow never used, so maybe
| I'll buy this to add to the pile.
| papereditor wrote:
| Thank you!
|
| There's occasional spam, but the barrier of having an Apple
| device to spam is enough to not make it a problem.
| saagarjha wrote:
| > Categories in Objective-C are a way to add new methods to any
| existing class, including framework classes (categories can also
| be used to replace methods, which is both powerful and scary ). I
| use them to harmonize the API. So if a method in UITextField is
| called text and in NSTextField it is called stringValue I can add
| a stringValue method to UITextField that calls text (or vice
| versa).
|
| > By the way, I also use categories to shorten long framework
| methods. The underscore at the end helps to avoid clashes with
| public or private methods that Apple might decide to add in the
| future.
|
| I think you already know what will happen if Apple adds a method
| (public or private) called text to NSTextField or stringValue to
| UITextField in the future ;)
| papereditor wrote:
| Keeping my fingers crossed it will not happen. :D
| lapcat wrote:
| One problem in the past was -[NSArray firstObject], which many
| developers used as a category method, with differing
| implementations. Apple added it to the Mac OS X 10.9 SDK but
| actually implemented the method silently in 10.6!
| saagarjha wrote:
| Interestingly it seems to be 10.6+ in the documentation. They
| backdeploy like that sometimes I guess.
| lapcat wrote:
| Read the _real_ documentation, the archive. ;-) https://dev
| eloper.apple.com/library/archive/releasenotes/Fou...
| jimbokun wrote:
| > I think you already know what will happen
|
| I don't know, what will happen?
| saagarjha wrote:
| One of the implementations will get used. If they differ this
| is likely to cause at least one caller to be very upset.
| jimbokun wrote:
| So..."undefined behavior"?
| ChrisMarshallNY wrote:
| _> Swift has come a long way and my guess is Apple has either
| embedded it into their platforms or added some fancy tree shaking
| for the binary._
|
| It went ABI around Swift 5 or so.
|
| I took a huge leap of faith, in 2014, and started using Swift,
| exclusively. It's turned out OK.
|
| I'm not quite as positive about SwiftUI, though. I think it will
| work out, but it has a _huge_ amount of catching up to do, if it
| is to replace UIKit /AppKit.
|
| I'd be quite interested in Rich Siegel's take (the guy behind
| BBEdit). He's been at it, a while, as well.
| mromanuk wrote:
| 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.
| imbnwa wrote:
| I follow the development of Swiftcord, A SwiftUI Discord
| client, on the developer's discord, and they almost constantly
| lambast how much is apparently missing or unstable between
| AppKit and the current version of SwiftUI, which has made it a
| struggle to get to feature parity with the official Discord
| client based on Electron cause lots of things you expect either
| have to be implemented by hand or just can't be done IIRC.
| meindnoch wrote:
| Why do they insist on making their life harder? Just use
| Cocoa...
| lapcat wrote:
| > 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.
| ChrisMarshallNY wrote:
| Not surprising.
|
| I've been using BBEdit for about thirty years. It's been
| through many changes. I suspect that he's pretty
| conservative.
| orenlindsey wrote:
| 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)
| jshier wrote:
| 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.
| bsaul wrote:
| 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 ?
| jshier wrote:
| 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.
| jimbokun wrote:
| > The big problem is navigation and state handling
|
| Those seem like very basic features that a UI framework needs
| to get right.
| jshier wrote:
| 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.
| interactivecode wrote:
| 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.
| jimbokun wrote:
| 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.
| jshier wrote:
| 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.
| interactivecode wrote:
| 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.
| mac-mc wrote:
| 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.
| lenkite wrote:
| 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.
| raydev wrote:
| The existing UIViewController and how it's implemented
| breaks the model-view-controller pattern, so there was
| nothing to stick to.
| luizsantana wrote:
| Well, migrating swift versions was not too fun
| vitorsr wrote:
| I always make it a point to buy small apps that are well-
| designed, well-engineered and well-architected in order to
| support the developers who make them.
|
| We need more apps like this in every category.
| 20after4 wrote:
| > In the end, building a polished, frictionless support chat was
| one of the best decisions that I have ever made for Paper.
|
| Many many years ago, I used to run a web hosting company. One of
| the first things I did was I built one of those little chat
| widgets that let me chat directly with visitors on my website.
| This was around the year 2000 and before I had ever heard of
| liveperson which was somewhat new at the time. That single
| feature did more for my business than anything I did. Because I
| could talk directly with customers (and potential customers), and
| because I was the sole decision maker for the business, I was
| able to say yes to ridiculously obscure requests for features
| that were easy to implement but very valuable to just one
| specific customer. My hosting business never grew into a large
| company but it did support me through college and for a while
| afterwards.
| Solvency wrote:
| Why didn't you offer a customer support number?
| runjake wrote:
| I imagine because the web chat was asynchronous. They didn't
| necessarily have to drop everything at that moment to answer
| the call.
| 20after4 wrote:
| I did have a phone number, however, when someone is about to
| click "buy" on a website but they have one hesitation, they
| aren't as likely to dial a phone to get an answer. When they
| can click a button and have instant response right there on
| the page.
|
| I was a really powerful sales and support tool.
| neontomo wrote:
| I've been using an app called Left for simple text editing, but I
| think I prefer this one.
| bilekas wrote:
| > I had little trust in my ability to pick the right dependencies
| from an ecosystem that I was not familiar with
|
| For me this is an invaluable lesson to learn. A pet peeve of mine
| are tutorials or guides which consist of a list of external
| packages and libraries to add before writing a line of code.
|
| This write up is excellent though, some of the gripes I have with
| the Apple eco system the OP has turned into a 'learning'
| experience in a positive way. Really nice.
| papereditor wrote:
| Thank you!
| PH95VuimJjqBqy wrote:
| > For me this is an invaluable lesson to learn. A pet peeve of
| mine are tutorials or guides which consist of a list of
| external packages and libraries to add before writing a line of
| code.
|
| likewise, 80% of the tutorial is preamble to prepare for the
| 20% you care about.
|
| just don't.
| gopher_space wrote:
| "Here is the compacted multi-line command I used to set up an
| environment a few years ago. I will not be explaining what it
| does or why you need these specific lib versions, but will
| assume that we all have a few of their dependencies
| installed."
|
| And it's still the most useful guide to setting up Qt because
| it's the only first-page result that mentions Berkeley.
| imbnwa wrote:
| I'd been thinking of getting into Apple platform dev, but there
| really seems to be this strong contradiction in people saying to
| go full bore Swift/SwiftUI but reading this and as well following
| the Swiftcord devs' discord, there's a lot of problems with
| Swift/SwiftUI as a replacement for Obj-C/UIKit/AppKit. There also
| seems to be more and better documentation/examples for the Obj-C
| APIs than Swift; yes Obj-C is old, but Apple has been ringing the
| bell that this is the future for years now. How do you pick one
| to know you can just get things done, no matter what the
| requirements?
| mthoms wrote:
| I'm in a similar position. Can you not use UIKit in Swift or do
| you have to use SwiftUI?
| jshier wrote:
| Not only can you use UIKit / AppKit in Swift (always have
| been), you can wrap them into SwiftUI as well. There's really
| no need to choose nowadays.
| dceddia wrote:
| I went through this decision a few years back (end of 2020-ish)
| and decided to go with Swift because it seemed SwiftUI wasn't
| really far enough along yet, and some experimentation with
| SwiftUI caused me to agree.
|
| I wanted to avoid Objective C, largely because I liked the
| safety of Swift (optionals, if let, guard let, etc) to make it
| less likely that I'd introduce crashes.
|
| The funny thing I found was that I ended up needing to know how
| to at least _read_ Objective C code anyway, because like you
| say, the docs use a lot of it. StackOverflow had a lot of it
| too. So I had to get good at translating between the two.
|
| Unlike the web dev world I was used to, there are way fewer
| Swift/ObjC devs out there, and the answers are fewer and less
| up-to-date.
| fuzztester wrote:
| This is one of the big issues with many tech stacks these days:
| the somewhat frequent churn of the libraries and APIs. Things
| change under your feet in a few months, or a year, if not
| weeks, forcing you change your code to adapt, and then test and
| release everything again, etc.
| fbn79 wrote:
| The web page scrollbar is unusable
| papereditor wrote:
| Sorry, I'll try to make it more accessible.
|
| It expands in the app as you hover over it. Probably needs a
| similar thing for the website.
|
| Or I just need to give up and revert it to the standard one. :)
| hannes0 wrote:
| > Or I just need to give up and revert it to the standard
| one. :)
|
| Yes please.
| sequoia wrote:
| yeah I can't get my mouse to focus on it. It's too small so the
| WM thinks I'm trying to resize the window.
| johnthuss wrote:
| Very interesting article! I was really interested in your pricing
| experiments!
| papereditor wrote:
| Thank you!
| articsputnik wrote:
| This is a beautiful blog, the same as the minimalistic app. Huge
| congrats. I'm seeing myself building this, as the joy it returns
| by using an app built by yourself. I have feelings similar to
| those expressed in the article using vim-motions or generally
| Neovim. It's so simple that even it works in a terminal. But once
| mastered (at least the basics), I feel like a surgeon when
| operating, as I edit text so fine-grained and exact.
| papereditor wrote:
| Thank you!
| jwells89 wrote:
| The ability to go low/no-dependencies, as mentioned in the blog
| post, is one of my favorite things about Apple platforms. It's
| not just possible but _practical_ to build a capable, highly
| polished app without bringing in anything third-party thanks to
| the richness and depth of AppKit /UIKit. Few frameworks can
| compete, with even other juggernauts like Qt coming up short in
| comparison.
| germandiago wrote:
| And you are now locked down to one environment.
| ryanwaggoner wrote:
| One man's downside is another's upside.
| jwells89 wrote:
| Indeed. Supporting a single platform means generally fewer
| bugs and headaches, as multi-platform is going to introduce
| new troubles regardless of how one goes about it.
| Approaches that try to be write-once-run-everywhere "silver
| bullets" will still see platform--specific bugs, as will
| per-platform codebases.
|
| It's not a coincidence that macOS/iOS has long had a
| disproportionally large quantity of high quality indieware.
| Capable framework + minimal headaches = polished apps that
| an individual or small group can sustainably support, even
| within less profitable niches and without VC funding.
| settsu wrote:
| And? There are plenty of companies which have fared just fine
| under such "limitations".
| Analemma_ wrote:
| 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.
| jwells89 wrote:
| 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.
| Analemma_ wrote:
| 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.
|
| There's no silver bullet here.
| jwells89 wrote:
| 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.
|
| [0]: https://mauikit.org
| rubymamis wrote:
| You can use Rust with QML[1].
|
| 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.
|
| [1] https://github.com/woboq/qmetaobject-rs
|
| [2] https://www.get-plume.com/
|
| [3] https://www.appflowy.io/
|
| [4] https://github.com/stdware/qwindowkit
| ogoffart wrote:
| 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
| pjmlp wrote:
| > The way Qt Widgets is for practical purposes usable
| only with C++ or Python is one such thorn
|
| What happened with using the best tool for the job?
|
| So what if C++ and Python are the only bindings.
| epcoa wrote:
| " 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.
| fauigerzigerk wrote:
| 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.
| allenu wrote:
| 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.
| mattgreenrocks wrote:
| Often worth it for superior UX.
|
| 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.
| FpUser wrote:
| You can write app that will work on Windows, Mac, Linux,
| iOS, Android using Delphi.
| skydhash wrote:
| Working is easy, working well isn't.
| detourdog wrote:
| 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.
| Vermyndax wrote:
| One environment with support on a vast plethora of devices
| and a long lifespan.
| rubymamis wrote:
| 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).
|
| [1] https://www.get-plume.com/
| hit8run wrote:
| Looks good indeed. Well done.
| fbnlsr wrote:
| 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).
| rubymamis wrote:
| Whoops. I'll look into that, thanks!
|
| EDIT: Fixed.
| pcammeraat wrote:
| 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.
| ninepoints wrote:
| I don't really understand this take. Appkit/Uikit _is_ the
| dependency.
| criddell wrote:
| It's not a third party dependency.
| mattgreenrocks wrote:
| 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.
| danielvaughn wrote:
| Every now and then, a post appears on HN at the exact perfect
| time. As it happens I'm considering embarking on a similar
| journey - building a text editor from scratch as a native desktop
| mac app.
|
| I agree with his approach - I remember writing Objective-C back
| in 2015/2016. At the time, Swift had just launched but it was
| nowhere near ready for production. So I had to learn
| Objective-C/UIKit/etc. As frustrating as it could be at time, I
| overall have pretty fond memories of it, and I got really good at
| it.
|
| I've lost the skills since then but hope that Swift has matured
| enough to be suitable.
| brantonb wrote:
| > 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.
| papereditor wrote:
| Thanks! Indeed, there is TipKit. I've just learned about it a
| few days ago.
|
| I think so far when Apple added new features to existing
| components, they've always made dual APIs. Only some completely
| new things are Swift-exclusive.
|
| That said, as the pile of those exclusive things gets bigger,
| it would be harder and harder to stay in Objective-C.
| jshier wrote:
| You know you don't have to choose one or the other, right?
| The languages interoperate and there's really no overhead to
| adopting Swift anymore. On newer OSes you're using tons of
| Swift under the hood anyway.
| papereditor wrote:
| I have not investigated it, to be honest. If it's as easy
| as switching the compiler to Swift, and everything remains
| working as is, but I also get to use all the Swift stuff in
| addition to Objective-C, then I am clearly missing out!
| brantonb wrote:
| At my last job, we slowly started adopting Swift in 2016
| by writing some unit tests with it. Once we felt
| comfortable and established some coding conventions, we
| started adding some production code. By the time I left
| in fall 2023, we were well over 50% Swift without any big
| rewrites of Obj-C code. Almost all the new code came in
| as Swift because developers enjoyed writing it over
| Obj-C.
|
| Sounds like you rely on Categories a lot. Check out
| Extensions in Swift. [1]
|
| There are some limitations (e.g., Swift enums lose a lot
| of their power if they're needed in Obj-C) but overall
| the interop is great. I don't remember anything in UIKit
| that couldn't be done with Swift. And if you're dealing
| with unicode text, doing things in Swift may make your
| life much easier.
|
| [1] https://docs.swift.org/swift-book/documentation/the-
| swift-pr...
| KerrAvon wrote:
| I'm also puzzled by your statement about popovers; UIKit has
| supported them for a long, long time.
| papereditor wrote:
| NSPopover and the popover presentation style of
| UIViewController are a bit different things.
|
| I think, technically, you could emulate NSPopover with the
| latter. I will need to test it.
|
| Feel free to clarify, if I've misunderstood your comment.
| bitwize wrote:
| One of the really nice things about the Apple platform is you can
| still build and sell apps for it. Windows and especially Linux
| are encrusted with freeloaders, but Apple users are willing to
| open their wallets for software with that extra bit of care put
| into it.
| papereditor wrote:
| True!
|
| It's remarkable that even today, with millions of apps, you can
| still find paying customers through the App Store even if you
| are a nobody.
| leecommamichael wrote:
| I tried to build a zero-dependency editor of the same ilk and
| found it an insurmountable task. I garnered an immense gratitude
| for modern font-rendering, though! As someone that loves Swift, I
| think sticking with ObjC for this project was a great move. The
| default level of abstraction in Swift lends itself nicely to
| writing apps, but begins to feel like a bit of a different
| language at a sufficiently low-level (raw pointers, byte-arrays.)
| C is as low-friction as it gets for these things (though cuts
| like a knife in return.)
| brantonb wrote:
| This post was great, so I added the RSS feed to my reader and I
| almost instantly removed it. I always knew those "7 Best Writing
| Apps for iPhone (2024)" posts were only there for SEO, but seeing
| a post from 2021 with that title is frustrating. This post
| appears to be the only non-SEO-related post in the feed.
|
| Not trying to take anything away from the author: the app and
| this post look great. But consider doing more writing like this
| and breaking them out into a dedicated, non-SEO feed. I'd
| subscribe to that in a heartbeat.
| mtillman wrote:
| There is no money in doing what you're suggesting. You're
| basically asking for a donation.
| brantonb wrote:
| Yes, I'm asking for a bit of work to be done so that I can
| read their future posts like this. I spend money on well-
| crafted indie software but typically only after following the
| author for a while. I'd like to remain engaged and was
| offering a suggestion on how the author could make that
| happen.
|
| The current RSS feed is not useful for humans. I'm not into
| SEO, so maybe RSS feeds are taken into account. You can
| publish multiple feeds, though.
| papereditor wrote:
| Thanks!
|
| I've indeed forgotten about the RSS feed. That post was created
| in 2021, but I keep stuff up to date even for SEO content, so
| the update time is 2024. That said, those posts are purely for
| keywords - they have no value other than to get occasional
| clicks from Google, and to spread the word about Paper.
|
| I'll think about separating the feeds.
| brantonb wrote:
| I totally understand that you have to play the game, even if
| I think the game makes search results worse. Appreciate your
| consideration and the post itself. (I'm an iOS dev that's
| made the jump from Obj-C to Swift and now from UIKit to
| SwiftUI.)
| gwbennett wrote:
| Having been developing iOS apps since 2009, hard to believe 15
| years, this is one of the finest writeups from a developer I've
| seen. Congrats on your hard work and the decisions you made
| developing your app. You made some great decisions, i.e.,
| sticking to native development, no 3rd party dependencies, and
| sticking with Obj-C.
|
| I made the move to Swift when it came out. However, there are
| many times I miss Obj-C and many of the advantages you mentioned.
| I often wonder what Obj-C would look like today if Apple had put
| the time and effort into it instead of Swift.
|
| I was not aware of your app. I just downloaded it on my Mac and
| iPhone. It is really nice! I like the little things you have
| done, like the hints on the menu bars for using the Option key,
| and the hint disappearing when you do. I am going to continue to
| use it.
|
| Thanks for sharing your experiences. Best of luck!
| papereditor wrote:
| Thank you for the high praise!
| jshier wrote:
| > I often wonder what Obj-C would look like today if Apple had
| put the time and effort into it instead of Swift.
|
| It would largely look like Swift, since the goals of Swift (and
| most modern languages), safety and expressiveness, are
| fundamentally incompatible with C languages. There's really no
| point to basing a language on Obj-C if you're not keeping 100%
| compatibility, so they didn't.
| mac-mc wrote:
| There are a bunch of design decisions in Swift that make it
| more C++ with the corresponding binary bloat + other issues
| than reference counted Java/Smalltalk with a C FFI that Obj-C
| is.
|
| You could've had Obj-C without the C for example, ADTs
| (enums), strong nullability enforcement and a nicer syntax
| while reusing most of the Obj-C core and retaining the
| compile speed, rock solid / fast debugging, function calls as
| data (selectors), easy mock creation and so on.
|
| The systems programming capabilities is lost on %99.9 actual
| usage of swift. The swift project should've been split into
| two different projects IMO, where they modernized Obj-C into
| a successor language without making the C++ choices they did
| and created SwiftRust where the %0.1 that want system
| programming and nondeterministic multithreading capabilities
| can go do so. Apple second system effect-ed themselves
| hardcore with the Swift project, and it shows everywhere.
|
| https://en.wikipedia.org/wiki/Second-system_effect
| pjmlp wrote:
| 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.
| araes wrote:
| I cannot have read that correct. For people on the Apple Dev
| ecosystem, do you really have no access to SDK code as a
| reference? Not even some high level abstraction version? I got to
| that assembly code part and just sat there and re-read it again
| and again. "You've got to go straight to assembly mode?" I cannot
| have read that correct.
| tl wrote:
| You might want to clarify your question:
|
| > do you really have no access to SDK code as a reference?
|
| You get headers but no source. While Darwin is in theory open
| source, UIKit, et. al. are not.
|
| > I got to that assembly code part and just sat there and re-
| read it again and again.
|
| If you're referring to the screenshot, Xcode dumps you into
| disassembly in cases where the stack is not in your code. 0
| -[MoTextView endFloatingCursor] is the author's code. The
| remainder is UIKit. Also, most of the line items are _prefixed
| which indicates a private method upon whose existence (much
| less implementation) is not reliable. As the author mentions,
| the stack on the left is usually enough to diagnose problems.
|
| It's also one more thing that makes me fight using Swift; all
| of the name-mangling and opaque to the Objective C runtime
| additions make this problem even harder.
| jasonjmcghee wrote:
| I recently have been building in Swift and indeed this seems to
| be the case. It's endlessly frustrating. Also privatizing
| variables seems to be quite aggressive in standard libraries
| and I often find myself wanting to use that internal stuff.
| meindnoch wrote:
| >I often find myself wanting to use that internal stuff
|
| And then curse Apple when the internals change and your app
| breaks?
| jasonjmcghee wrote:
| I would never
| papereditor wrote:
| It's a calculated risk. You can make unique experiences
| with private stuff.
|
| Apple ships betas, so there is plenty of time to see if
| stuff breaks with the latest OS.
| meerita wrote:
| I am still using IA/Writer in my Mac. I wrote 3 books with it.
| The only thing I dislike most in the the absurd pricing on the
| iOS app.
| freetonik wrote:
| iA Writer feels weirdly sluggish on my iMac 2017 5K, especially
| compared to Paper.
| ilrwbwrkhv wrote:
| First of all this is amazing. Amazing app, amazing dev, amazing
| story. Everything that the hacker culture stands for, is
| flourishing in your app. My question is do you make enough to
| live off apps like these? I really hope so, because these are
| some of the best tech products in the world and I would love to
| see more of these.
| papereditor wrote:
| Thank you!
|
| Sadly, not enough to live off it in Europe.
|
| But it's slowly growing, so maybe one day. :)
| eslaught wrote:
| Since the author seems to be in the comments, have you ever
| considered implementing a Typora-style live preview? (Typora, for
| those who don't know, hides the Markdown formatting as you type,
| and shows it again when you move the cursor back onto the text.)
|
| Paper appears to have a more traditional split between text mode
| and preview mode, and you can't properly edit the formatting in
| preview mode (e.g., you cannot turn a heading back into normal
| text from preview mode).
|
| I'm sure it's a pain to implement, but it's the one really killer
| feature of Typora that I can't live without.
| papereditor wrote:
| That would be a massive challenge and probably would lead to
| more bugs which is against my goal of having a low-maintenance
| product. The more dynamic is your text rendering, the harder it
| gets.
|
| You can format from the Preview mode, by the way. You need to
| use the shortcuts for that or click inside the Format menu. If
| you put your caret on the line of the heading, then press
| Command+1/2/3 depending on the level of the heading it will
| convert the line back to normal text.
| eslaught wrote:
| Fair enough. Thanks for the response!
| rubymamis wrote:
| As someone that implement this right now in my block editor[1]
| I must say it's a HUGE pain in the ass. Synchronizing the
| underlying plaintext/markdown with the rendered rich-text/HTML
| is a big undertaking. Especially so, since Qt's QML TextEdit
| conversion between its rendered HTML and Markdown is so
| inconsistent and broken. I've been thinking of ditching it, but
| I might persevere and continue to try.
|
| [1] https://www.get-plume.com/
| eslaught wrote:
| I totally get that.
|
| I'm just one person, but for me, this was _the_ feature that
| made me switch to a minimalist text editor for writing.
|
| Otherwise, why not stick with Emacs? Plain text with light
| syntax highlighting is something Emacs already does fine,
| it's relatively distraction free, it has keyboard shortcuts
| I've already memorized forward and backwards.... The biggest
| downside is that I have to pop over to another window to get
| proper syntax rendering and to be 100% sure it's parsing the
| way I expect.
|
| Anyway, just my two cents. I could totally understand it not
| being worth the effort to implement, but when it works, it's
| _really_ nice.
| holoduke wrote:
| Funny that my story also plus 10 years as a solo app dev is a
| little different. I shifted from native to full webapps 2 years
| ago. Never been more happy with that decision. Development speed
| is a lot higher and easier. I found the iOS SDK, but in
| particular the Android SDK a monstrosity to work with. Yes there
| is a very small performance penalty, but for simple list scroll
| apps not impacting user experience (proof comes from user
| reviews)
| w10-1 wrote:
| 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)
| arthurofbabylon wrote:
| Are you working in TextKit 2 or TextKit 1?
|
| What is your flow for accommodating new OS changes (some being
| quite dramatic)? Do you make list of broken things and new
| opportunities, then devise a complete solution? Or do you address
| them incrementally?
|
| Great write up. Thank you.
| papereditor wrote:
| Thanks!
|
| Still on TextKit 1. I am thinking of migrating to 2, but I
| still have downloads on older Macs, so I want to wait.
| Supporting both 1 and 2 in parallel would be a nightmare.
|
| To be honest, I have not experienced a lot of dramatic updates.
| Apple has a good track record of keeping things backward
| compatible. The issues that I find on the new betas, I fix
| before the OSes are released in the Fall.
| asciimo wrote:
| Cmd+f, "vim", Cmd+w
|
| Update: jokes aside, this is a great read. Adding vim keybindings
| would violate the principles of this project.
| twiss wrote:
| 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).
| papereditor wrote:
| 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. :)
| elwell wrote:
| Love the technical detail of this post
| papereditor wrote:
| Thank you!
| makk wrote:
| Had never heard of paper editor. Just using it now for the first
| time and WOW. This is amaaaaaazing. There's this thing I've
| wanted to write for a while now and could never quite get
| started. Something about this UI just pulls the writing out of
| me. Love it!
| papereditor wrote:
| Thank you!
| luizsantana wrote:
| This post is gold! Not only I love the app the post is so well
| written and well presented. The author care for details is crazy
| nice
| papereditor wrote:
| Thank you!
| wffurr wrote:
| That was an amazing read, thanks for sharing all those details.
| Partway through I was amazed to find a code snippet that I need
| for my iOS PDF editor: your map of language to system fallback
| font! I had figured out part of it but hadn't done the whole
| "type in every language and see what I get" step yet.
| papereditor wrote:
| Thank you!
| pappereditorrr wrote:
| Nice app but your marketing make me not want to use the app.
|
| 1. The blog is flooded with SEO oriented posts
| https://papereditor.app/blog This vs That, Top this, Top that
|
| 2. In the App Store a whole bunch of other text editors are
| mentioned in the app description text in order to be included in
| the results when people search for other text editors.
|
| I'ts just shady and unnecessary if you trully believe in your
| app.
| papereditor wrote:
| Thanks!
|
| 1. What's wrong with SEO? People discover the app from Google.
| Some of them even become paid customers. If people discover and
| purchase what they need - what's the harm?
|
| 2. That does not affect the App Store search results. If it
| would have - everyone would be doing it. App Store allows a lot
| of text in the description, so I thought I would fill it with
| something useful. I've also ordered the names from shorter ones
| to longer ones so it looks like a mountain. Aesthetic details
| everywhere. :)
| pappereditorrr wrote:
| 1. Nothing is wrong with SEO. But I expected a blog in a
| similar fashion as your .dev page but I was highly
| disappointed when all I saw where these "empty" click-bait
| esque posts.
|
| 2. I've seen plenty of apps doing the same trick in the App
| Store. But if it doesn't affect the search indexing why even
| bother putting up a long list of apps that could hurt your
| business.
|
| Nothing but respect for the work that you do and the app
| you've created.
| papereditor wrote:
| 1. Sorry for the disappointment! SEO articles and high-
| quality thought pieces can coexist on a website - they have
| different purposes. The /blog slug is indeed a bit
| misleading, but that's what I started using initially, many
| years ago, and it's not even advertised on the website, so
| people should not end up on it. My point is - there is
| nothing shady about SEO articles. But I will think about
| reorganizing the site to better separate the articles.
|
| 2. I don't see why it would hurt. If people read the
| description and see the familiar name of the app that they
| use or have used, they will associate Paper with that app.
| It's just a list of writing apps - Paper is a writing app.
| I am trying to make a connection in their heads.
|
| Thanks - I love a good discussion!
| deergomoo wrote:
| 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 NS _Whatever_ tended to return
| results for UI _Whatever_ , and there are far fewer StackOverflow
| threads due to a lot of this stuff being from the early 2000s.
|
| Apple's documentation for their newest stuff is infamously
| barebones, but I've also found it difficult for the very old
| stuff too -- much of it hasn't been updated for Swift, so I've
| been at the mercy of Xcode autocomplete to find the new names for
| various constants, etc. Good Mac development is starting to feel
| like a lost art.
| papereditor wrote:
| Thanks!
|
| Can't recommend anything specific, to be honest. I've been
| piecing together information from old Apple docs,
| StackOverflow, API header files, and a bunch of really weird
| blogs. A lot of trial and error as well.
|
| I think your best bet is ChatGPT. It has seen every possible
| use-case of Apple APIs from GitHub so it should know a lot.
| I've gotten some good tips from it for very specific things
| that did not exist on the web.
| deergomoo wrote:
| Thanks!
| zengid wrote:
| This is a really beautiful write-up!
|
| I have one small gripe in that on my browser (chrome-windows11)
| the scroll bar is imperceptibly small, so I can't easily scrub
| through by grabbing it with the mouse. Other than that this is
| awesome.
| papereditor wrote:
| Thanks!
|
| Sorry, I'll try to make it more accessible.
| zengid wrote:
| No worries, thank you!
| fritzo wrote:
| Page annoyingly has no scrollbar.
| divbzero wrote:
| The "rotate-to-undo" gesture is so cool. It reminds me of the
| main character in _Doctor Strange_ rotating his hand to turn time
| backward and forward.
| brcmthrowaway wrote:
| How much do you make a year from this app
| papereditor wrote:
| I don't want to be public with $, but I can say that it is many
| times smaller than my full-time European salary.
| ChuckMcM wrote:
| This is a fabulous app for just writing (I know really simple but
| that is good stuff). It makes me really wish there was a portrait
| keyboard case for the iPad. (nobody does those, not even
| reMarkable which makes me sad)
| papereditor wrote:
| Thank you!
___________________________________________________________________
(page generated 2024-01-05 23:00 UTC)