Show HN: I made an iOS HN app to navigate large threads without getting lost

Love this! I regularly hit the minus button on the top comment to see what the next top-level comment is. Your interface shows me the most popular top-level comments so I can choose from among them. That's great!

A couple thoughts:

• I can't tell what the hashtag button is for

• The numbers in the lower right corner of each stack seem like they refer to the number of sub-comments, but in my brief experience this doesn't seem to be the case. Is this a bug, of have I misunderstood what these numbers refer to?

• I'd prefer to be able to tap a comment stack and have it open up. I get that swiping isn't that hard, but I typically one-hand and would prefer if mere tapping did the same thing as swiping (and I can't think of what else a tap would mean, so it shouldn't cause a conflict to have this as an option, right?)

• There's no way to reach the settings from the discussion view. The presence of a ... icon makes this confusing, because that's where I'd expect to be able to change settings and such. I would suggest adding Settings to this menu, as an alternate way of reaching it.

I know some people are upset about the freemium model, but I think you threaded the needle just about right here. You don't actually disable the night mode functionality in free mode — you just make it not a permanent setting. It would be slightly better if you were more explicit about when the temporary setting will expire, but I really don't see how someone can complain about how you've done this. You let people access every single functionality so they can try it out. Unless you're making this a pure hobby (in which case there would be less upkeep, support, and ongoing development), you can't rely on a tip jar.

Thanks!

> I can't tell what the hashtag button is for

It's demonstrated in the guide [1]

I have to think about how to explain the feature in the app without overwhelming the user. Always open to suggestions!

> The numbers in the lower right corner of each stack seem like they refer to the number of sub-comments, but in my brief experience this doesn't seem to be the case. Is this a bug, of have I misunderstood what these numbers refer to?

It's the total number of comments in the subtree (including all the child subtrees and their subtrees and so on).

> I'd prefer to be able to tap a comment stack and have it open up. I get that swiping isn't that hard, but I typically one-hand and would prefer if mere tapping did the same thing as swiping (and I can't think of what else a tap would mean, so it shouldn't cause a conflict to have this as an option, right?)

I think it could be a frustrating experience when you mistap upvote or any other button, expanding/collapsing the stack instead. I will try it to see how it feels, it just might be one of those things that look good only on paper, and once implemented it'll be just an extra option that everybody ignores. There's also a good argument for that - accessibility [2], but there are alternatives for the tap gesture.

> I would suggest adding Settings to this menu, as an alternate way of reaching it.

I figured that on average users go to settings only a few times, mostly when they initially set up the app. Adding an entry point on the thread screen would increase the complexity, support and testing efforts, but further down the road when other things are ironed out it can be a good improvement.

[1] https://github.com/devandsev/HackerNews-Support/wiki/Guide#a...

[2] https://github.com/devandsev/HackerNews-Support/issues/1

> they need to keep earning your money a little at a time

So release new products or paid updates, the way everyone did before subs.

> A one-time unlock front-loads 100% of revenue

Also known as "buying", which is a thing

> making all maintenance work have negative ROI unless the app experiences constant, consistent growth forever

Unless you release paid updates, which is what a number of developers do.

> Eventually that ceiling will be hit, and the app's revenue could drop to effectively zero, even if a million users count on it daily.

So don't put all your eggs in one basket. Have different products. Explore different things. You're essentially asking to be rewarded for stagnation here.

Subscriptions are about (1) being paid for work you didn't do, since you get paid whether you did anything or not; (2) disrespecting my choice as a consumer, since maybe I don't feel I need any updates and I don't want to pay for them, and (3) encouraging bloat, since there's more pressure to pack in needless features just so you can justify demanding payment every month.

You're basically saying "I need regular handouts because I couldn't make money otherwise." That's a problem with your business plan, and it doesn't justify demanding money for work you didn't do, or requiring me to pay for things I don't need.

I'll agree with you on one thing: years of free or artificially cheap software have conditioned people to not want to pay a lot for software. I always thought $0.99 per app was ridiculously low. I don't have a problem paying tens or even hundreds of dollars for good, powerful software, but I want to own it. If I'm going back through old files a decade or two from now, as a lot of us do, I want to be able to open them. And I don't want to have every one of my apps draining my bank account bit by bit.

If you want to offer a subscription for people who want every update you release, fine. At least they're getting something. But the fairer model is what a number of developers are doing: more money upfront, which includes a lifetime license and one year of updates (which is nice, but I would understand if they didn't include it).

There's a reason why so many people despise subscriptions, and why I doubt that model—while it seems to be the fad now—will ever be normalized. Most of us can't afford it, it denies us long-term access to our own content, and we know on a basic level that it's wrong.

Thread structure won't be altered, new comments will be marked like here https://github.com/devandsev/HackerNews-Support/wiki/Guide#a... and you'll be able to iterate over them.

Direct link to the video https://user-images.githubusercontent.com/17564071/236939878...

I am surprised to see your comment about bloat. If anything, the fact that you only ever got paid again for a major update, and an update HAD to have whiz-bang features to sell, that was what contributed to so much bloat. Think of how many home users needed anything that was added to Word from 1990-2000. By contrast, to keep subscribers happy you don’t need new features, you need to continually keep the experience great. That means judicious adding of things people really want, but also NOT adding crap just to add a bullet point on a box. And NOT “ruining” the app by screwing up what people like about it.

> Unless you release paid updates, which is what a number of developers do.

This just introduces two more user complaints: those paid updates are very likely to either be not consequential enough to justify paying, or to add bloat. Presumably, when you bought the app, you were satisfied with the functionality it already had (and indeed if they make big changes it often gets hate just for the disruptiveness). But my point is software costs money (time) to support, forever. And once a product (especially a specialized one) has already found most of its buyers, that means the developer has every incentive to abandon the app because maintaining or updating it is never going to justify the cost. So yes, a developer doing your preferred model absolutely must have a half dozen apps, which will be at various stages in their life cycles, but only the apps that are new, and have a chance of growing their user base further, are going to get any maintenance, attention, and updates. The mature ones will be left to wither even if they are widely-used and popular, because there aren’t enough new buyers.

The other part of this is that besides just maintenance, many modern apps have a server-side component which needs to be paid for forever. It’s basically a pyramid scheme if your only source of revenue is new users and they subsidize the lifetime access of the earlier buyers. It will collapse eventually.

As for “files” — that’s really not the primary type of application I am talking about here. If you are making an application that authors proprietary documents, I think it’s perfectly reasonable to expect a free reader to exist whether you have an active subscription or not. However I think that’s maybe 2% of the consumer software market today. I think the only files that I can think of on my computer that aren’t standards-based formats are Pixelmator files and TurboTax files (though I stopped using that and use a web-based replacement).

> since maybe I don't feel I need any updates and I don't want to pay for them,

The updates I’m talking about, which you “don’t want to pay for,” include “making the app continue to run on a current OS”