Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

9 years of Apple text editor solo dev

papereditor.app

Post reply on HN
Print view View original

301–310 of 405 posts

Re: 9 years of Apple text editor solo dev

#301

Post by gyomu »

monkeynotes wrote: post #273
gyomu wrote: post #49

Earlier quoted context omitted.

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/discussi…

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.

I’m on a 12.9” iPad :)

Re: 9 years of Apple text editor solo dev

#303

Post by papereditor »

pappereditorrr wrote: post #294
papereditor wrote: post #288

Earlier quoted context omitted.

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 short…

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 t…

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!

Re: 9 years of Apple text editor solo dev

#305

Post by KerrAvon »

papereditor wrote: post #185
brantonb wrote: post #178

> 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…

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.

I'm also puzzled by your statement about popovers; UIKit has supported them for a long, long time.

Re: 9 years of Apple text editor solo dev

#307

Post by papereditor »

KerrAvon wrote: post #305
papereditor wrote: post #185

Earlier quoted context omitted.

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.

I'm also puzzled by your statement about popovers; UIKit has supported them for a long, long time.

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.

Re: 9 years of Apple text editor solo dev

#308

Post by KerrAvon »

lapcat wrote: post #52
KMnO4 wrote: post #47

Earlier quoted context omitted.

That experiment was done in 2015, when the Swift runtime had to be included. If you build an app now, it will link to the system runtime and be close to 100kb as well. This seems to be premature optimization. The author forced himself to learn archaic Objective C for a completely unnecessary reason, and now is stuck with that design choice despite not having any benefits.

> The author forced himself to learn archaic Objective C for a completely unnecessary reason, and now is stuck with that design choice despite not having any benefits. Some benefits: 1) Most Swift code written in 2015 when the author was starting won't even compile today, because the language has changed in non-compatible ways. Whereas Objective-C code written in 2015, 2005, and possibly even 1995 will usually still…

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.

Re: 9 years of Apple text editor solo dev

#309

Post by KerrAvon »

jshier wrote: post #129
papereditor wrote: post #105

Earlier quoted context omitted.

Interesting! So all the NS_SWIFT_UNAVAILABLE APIs are still easily bypassable in Swift?

Depends what they are. Most of the time those are unavailable because they've been replaced with better Swift imports of the same API somewhere. Less commonly it's because they use one of the few C features that can't be imported into Swift or, even more rarely, because the API is fundamentally unsafe and they don't want it available in Swift. In all cases you can reexpose these APIs to Swift by writing your own C wr…

Yes, it's very rare that something is actually unavailable. You can even use things like `sysctlbyname` in Swift without writing C.

Re: 9 years of Apple text editor solo dev

#310

Post by brailsafe »

rubymamis wrote: post #177
jwells89 wrote: post #170

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.

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/

No BBedit in the comparison list?
Post reply on HN