Show HN: I made an iOS HN app to navigate large threads without getting lost (apps.apple.com)
I was struggling with navigating HN discussions using existing solutions, so I decided to implement a completely different approach, think of it as depth-first reading vs breadth-first reading. Visually it looks like swipeable stacks of comments and it offers several advantages over traditional interfaces:
- Comment width doesn't get narrower no matter how deep in the comment tree you are
- You always see the parent of the comment you're currently reading
- Swiping allows you to move in and out of subtrees with animated transitions that you fully control
- You can easily skip subtrees that don't interest you by scrolling
As a result it's easier to maintain the context and to keep track of where you are in the discussion tree. The app is fully featured, it does all the things that you would expect it to do, and there's extra: custom boards, search, in-thread search, anchors, reading list, recent items.
Video preview: https://imgur.com/a/tzBdpXw
96 comments
[ 2.4 ms ] story [ 183 ms ] threadIn this case, $6 US for dark mode.
Id rather just have a “donate $6 to help dev” in app purchase as it seems more authentic.
However, maybe there are really people who think dark mode is worth $6. Kids raised on Roblox seem to have no ethical issue with paying $5 for a digital hat that is just flipping a bit.
If a wizard could magically duplicate chairs, I’d have the same argument. Why charge $5 for something that costs $0 to replicate.
The design of the hat and the system to run it costs something. The design of the chair and the workshop to build it costs something. Those are fixed costs. It’s the marginal cost that is very different.
I’m not even against charging people for digital hats (I paid $5 after all), I’d just rather companies be more straightforward. Id rather pay $60 for a game once and not be microtransactioned.
Id rather pay $6 (or not since I don’t like this app) once than pay to enable features that clearly cost nothing or very little to implement.
App makers can charge whatever they like. And potential customers can complain about how much it sucks trying to convince app makers to build in a way I think is better for society (ie, straightforward prices for things rather than income streams from payments). But I could be wrong.
I played many a game that cost $20 and had thousands of hats so there’s many successful business plans that don’t involve free to play and then charging $5 for flipping a bit to enable my character to have a hat.
No other profession probably degrades themselves as much as developers. If his app is worth it, people would pay or else they don't.
No developer need to beg for money if they are good at their craft.
And people will pay $60 for physical items but balk at $0.99 apps and digital goods, it's strange.
I like the shareware model where people pay what they can, or what they perceive the value to be. I don’t think this is begging.
Programming is kind of unique because the marginal cost of production is near zero. I think this is a feature, not a bug and why it’s possible to have single person dev companies that are quite lucrative.
And of course there’s lots of open source developers who are excellent and donate their time with only expecting $0.
The bit is flipped at runtime or compile time. In the old days you'd pay for an upgrade and get a new binary with the feature compiled in. Nowadays the feature is compiled in and gated at runtime. In the end it's the same.
If the author really wishes to put this feature behind a purchase, "follow system settings" should be the free default.
It’s clear you put some thought into pricing and have avoided the subscription route which is what most people will complain about.
I wouldn’t put much stock into the complaints here.
the reason they can charge for it is that apple review is uneven and unpredictable.
That’s better than every other pay scheme I can think of since you have the option to do without.
I feel you should be able to tap a comment to expand, rather than just swipe. Also it’d be neat if you just kept the new scroll position when expanding rather than scrolling back
The orange flashes when navigating back are distracting. Just use the default system behaviour here (grey)
If you tap the active tab (both in the heading and tab bar), it should scroll to the top
One frustration that I had with existing apps is collapsing a subtree by accident when tapping the upvote button. I feel like it would be even more frustrating with how my app works, it'd just expand/collapse if you miss the hitbox.
> Also it’d be neat if you just kept the new scroll position when expanding rather than scrolling back
The issue with that is that if you expand a subtree, scroll way way down and then collapse, your scroll position will be so far away from the initial node that you'd get lost.
> The orange flashes when navigating back are distracting. Just use the default system behaviour here (grey)
I'll add an ability yo choose the color in the Settings.
> If you tap the active tab (both in the heading and tab bar), it should scroll to the top
Nice idea, I'll add that.
I like the app, but there's too many features behind the paywall.
-iPad user
I'll agree that charging $6 for dark mode does come off as nickel-and-diming. Honestly, I'd have avoided a free version and just made the basic price at least $6, one-time, with options for larger donations to the dev if you really like it.
I would definitely get less heat, but the user would paradoxically end up in a worse position. I feel like there's always a disconnect between the user and developer when it comes to a freemium model. Developer thinks that it's a paid app that the user can actually try and make an informed decision before buying. User thinks that it's a free app with arbitrary annoying restrictions. And I understand the user perspective.
I think things would be better if refunding was less painful for the user and developer both. If there was a zero friction way of refunding things, we could just abandon freemium.
Not sure if you're a dev yourself, but I don't think yours is an uncommon feeling among developers reacting to pricing.
[TL;DR - I think our expectations are out of whack though]
Why do you think this is, though? As a developer, we know that all code has a carrying cost, and that when building on the sand that is the iOS SDK, that almost mandates at minimum a yearly compatibility update, and possibly occasional significant rewrites if some critical SDK feature is removed or broken. Also, this app is building against a third-party (HN) api as this one does, which could change at any time and require the developer to update the app to be compatible. Having a periodic subscription is the only way to align developer and user interests -- they need to keep earning your money a little at a time, and as long as there is a good audience, there is a matching revenue stream to justify continued maintenance on the app. A one-time unlock front-loads 100% of revenue, making all maintenance work have negative ROI unless the app experiences constant, consistent growth forever. And there's certainly a limit on how many people will ever regularly read HN. 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.
As humans though, especially analytical ones who are keenly aware that $1 a month for the next 10 years is $120, we hate to think of spending an 'absurd amount' like that on any apps unless they fit a certain mental model (it seems things like Spotify fit a profile that we understand comes with monthly bills attached). But I think it's odd that, while we would feel completely fine spending $6 about once a month for an ice cream cone, Starbucks, a package of cookies, etc. we balk at the prospect of paying even $1 a month for an app, even when it's an app we use daily, like a podcast client or, for some, a HN app.
I think I place the blame on the expectations accidentally set up in the 1990s, when software for most consumers was preinstalled (thus invisible in cost) and everything else was "one-time" because both the need and the ability to distribute updates regularly was so much less. I assume companies like Microsoft and Adobe who did need to maintain their software could count on the massive ongoing computer adoption in that era to make them profitable even when many end-users would decline paid updates once the apps reached a certain level of maturity -- which I think was the predominant practice among anyone except certain classes of "professional" users. While I agree some apps are out there that charge say, a $19 monthly subscription to crop images, just exploiting ignorance of customers or preying on children, I think we should normalize apps that receive maintenance having a subscription model.
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.
> 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”
So if you didn't do anything, why should you get paid?
> 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).
So if your updates aren't doing me any good, why should you get paid?
> 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.
Some things aren't meant to last forever. Some apps aren't meant to be ongoing business models. Apple isn't still producing the computers it sold in the 90s. Sunsetting a product and ending support for it is a natural part of a product's life cycle. This is how pretty much every company operates.
Part of running a successful company is handling change and continually innovating and evolving, not just expecting your customer base to subsidize your stagnancy.
> So yes, a developer doing your preferred model absolutely must have a half dozen apps ... The mature ones will be left to wither even if they are widely-used and popular, because there aren’t enough new buyers.
That's part of business. I can't think of any successful business with only one single product that it maintains for eternity. There might be one, but that's not how normal businesses operate.
> many modern apps have a server-side component which needs to be paid for forever.
I don't have a problem with paying for resources I'm actually using. I use a note-taking app that includes a cloud subscription for syncing across devices; I'm fine with paying for that, because I'm getting something in return that I actually want and use.
> 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”
What I said—and what you included in your quote—was "maybe I don't feel I need any updates". I want a choice. "Stupid feature we added just to justify demanding 10 bucks a month from you" is one thing. "This app works on the latest OS release" is another.
Copying-and-pasting from above: I'm fine with paying for that, because I'm getting something in return that I actually want and use.
Your basic logic here is that you just want to write one little app and then sit back and have that one little app support you for the rest of your life. That's not a reasonable business model. I'm sorry if this sounds blunt, but that's just you wanting money without having to work for it.
Essentially you're trying to take an unprofitable way of working and force it to be profitable by demanding money you don't deserve. I think that's wrong. A lot of us think that's wrong. And I'd go so far as to say that, judging by every tech forum I'm active on, most of us—with the exception of a handful of wealthy tech influencers and their dev friends—think that's wrong.
So yeah. As I said: Grubby.
Nobody's forcing you to pay for software subscriptions. If you don't see an ongoing benefit from using software under active development and maintenance, by all means, don't subscribe. Use abandoned software from 10 years ago forever on your Windows 7 machine, or write your own, or use awful ad-supported dreck. You'll get no objection from me, it's your choice.
But a lot of people have moved on from the one-time-only model. Developers know that you don't build the "final email client" or "final podcast app" or "final note taking app" and have it stay static for 30 years. Apps are either under development or they die.* If you don't think the users who derive value from the app every day, and need it to keep existing, should be the ones who pay for that app to keep existing, well, I don't know what to tell you. I for one expect all my core apps to just work on every new device I get, and when I install a new OS version I don't want to worry that apps were left behind. I want Office on my Android tablet today, and if I buy an iPad tomorrow I want it working there, and I have a PC and a Mac so I want it on both. I don't want to have to spend $350 for a new copy of Office just because I decided to buy a Mac.
There are other advantages for consumers too. For instance, you can pay like $20-30 for all Adobe's top-end apps for a month - to try them out or to do a one-off project now and then. That would have cost you $2000 20 years ago when the "buy" model was the only one. Likewise, it would be silly to pay $20 each for 5 competing apps to see which one you like best, but when they're $1 a month you can try them all serially to find your favorite, without any "trial" restrictions which can get in the way.
But it's clear you think that continuing to make sure software works forever, fielding support issues from customers, making updates for every new OS feature, is "sitting back" and doing nothing, and that it's realistic for you to update neither your OS nor your software, ever, just to avoid paying maybe $80 a year in software subscriptions, so, okay. You do you. I'll refrain from replying after this comment, because it appears you have no interest in anything but griping about paying for what you use.
* This was even true in the 1980s, but the timescales were much longer then. A Commodore 64 program was also pretty obsolete 12 years later when everyone had moved onto new and incompatible hardware, but today Apple can hardly keep the SDK stable for 12 months.
I'm not going to address most of your post, because there honestly is not a lot to reply to: you're just reiterating assertions and—more problematically—insisting I said things I didn't say. I don't think it's the best use of my time to indulge that.
> If you don't think the users who derive value from the app every day, and need it to keep existing, should be the ones who pay for that app to keep existing, well, I don't know what to tell you.
Show me where I said I don't think users should pay for the app to keep existing. I'm fine with paying for app releases. Once per release.
> There are other advantages for consumers too. For instance, you can pay like $20-30 for all Adobe's top-end apps for a month - to try them out or to do a one-off project now and then.
Cool! If it's such an advantage for consumers, I'm all for offering that. Just include a lifetime license as well. If rentware is so beneficial to consumers, then there wouldn't be any problem offering people a choice, correct? Let the market decide.
> But it's clear you think that continuing to make sure software works forever, fielding support issues from customers, making updates for every new OS feature, is "sitting back" and doing nothing
Again: Show me exactly where I said that. I'm getting tired of this; you saw that I said the exact opposite as far as updates. Regarding support, again, I have no problem charging for that. That's a service.
I'm disappointed by this last response of yours. You came off as reasonable initially, but the shift to deliberately misquoting me is not cool. I don't think you should do that; it implies a lot about how confident you are in your reasoning.
Anyway—I suspect the rentware fad will be over in a few years, since everyone hates it and subscription fatigue is still setting in. (Especially if a recession, which I think is coming, makes a lot of folks question why they're paying $50–$100 in subscriptions every month for software they would have owned a few years ago.) The market will settle down to either a hybrid—apps offered under both rentware and lifetime licensing—or simply back to charging a more reasonable one-time amount.
And devs will be fine; they'll just have to treat their businesses as actual businesses, not lifestyle passive-income streams. I'm good with that.
https://play.google.com/store/apps/details?id=com.simon.harm...
I see you get a lot of comments about the paywall, I suggest you try offering a 7-day trial instead of the nag. Or, better yet, limit it to X number of openings or something like that.
The OG is definitely email. What would really rock would be an IMAP gateway which you subscribe to with your favorite email client which then gives you threading, read/unread markers etc. It could abstract different front-page days as folders and each submission as the root of a thread. Then you could use whatever email client you like the most, with all their decades of polishing. It could even support replying to threads. And it could support different "backends", like HN, reddit, whatnot.
Anybody? That's something I'd pay for. Or do I need to keep dreaming?
This doesn't make sense. Email is a protocol, not a UI. It would be fairly easy to make a UI that displays email like Reddit threads (the hardest part is probably stripping quoted replies). Thunderbird can display the discussion tree, but doesn't inline the message content. GMail inlines message content but linearizes the thread. I am not aware of any clients that inline the discussion content in a tree view.
Run mkdir -p /path/to/some/directory/{cur,new,tmp}, then ./hn2mdir.bash /path/to/some/directory/, and it'll crawl Algolia's HN API to dump a bunch of emails, one for each post/comment. You can read it with mutt -f /path/to/some/directory. Syncing with IMAP left as an exercise to the reader (I'm using mbsync).
Note that it gets large, fast, and may break your IMAP server; I periodically run find ~/Mail/HN -type f -mtime +30 -delete to clear it out.
Edit: should clarify, this is read-only, I've never bothered to set up any kind of response functionality
I remember reading threads using a UI like this (not my screenshot but this is the client I used, MacSOUP): http://www.fen-net.de/mac/bilder/macsoup/Thread.gif There were also keyboard shortcuts to make navigating efficient.
Having a Usenet gateway seems like it would make a lot more sense from a technical standpoint than an email gateway
I made a bidirectional gateway to/from the https://en.wikipedia.org/wiki/LysKOM protocol (based on the design of https://en.wikipedia.org/wiki/KOM_(BBS)) back when Netscape included a decent Usenet client. It worked surprisingly well since Usenet has robust support for threading.
(Your Swedish-sounding username inspired me, everyone else: sorry.)
https://web.archive.org/web/20010427050014/http://community....
https://web.archive.org/web/20010427050050/http://community....
Direct link to the video https://user-images.githubusercontent.com/17564071/236939878...
I made a few prototypes, experimented with omni-directional scrolling (comments don't change their relative position to each other, but you kind of move the viewfinder and it sticks to the edges of subtrees), color coding in different patterns and nothing felt good. I gave up and a few months later when I was thinking about a different problem, I just had a light-bulb moment about this one, mind works in mysterious ways I guess. It was unnecessary complicated at first (like dragging the designated "borders" with the comment staying fixed in one place), but I simplified it in the process quite a bit.
It looks pretty straightforward now, but I think a lot of people would be surprised to see how many tricks are there for it to actually look and feel that way.
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.
> 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
Regarding the settings, you're right that many users would only go there once; however, it's likely they would go looking for settings once they're already in a comment thread (or at least I was!).
I agree that mis-tapping could lead to confusion if stacks could be opened that way, but closing requires a swipe. But since you can tap to go into an article, it seems natural to tap to go into a stack also.
Regardless, I'm really enjoying the app's interface. I also sent you a message via your website's Google form, with other ideas. Congrats on the concept and execution!