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

[hnand]

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

or https://streamable.com/arq45m

[davely]

Overall, nice. But it immediately hits a pet peeve of mine: requiring an in-app purchase to enable native features built into my device’s OS.

In this case, $6 US for dark mode.

[prepend]

I get annoyed by these things too based on some sort of perceived cost/value of the feature being available and implemented, but paygated.

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.

[spiderice]

It isn’t flipping a bit, it’s designing an entire free to play game, getting millions of users, designing a hat, then flipping a bit. And about a million other things not mentioned.

[jallen_dot_dev]

Not to mention pretty much anything these days can be reduced down to "flipping a bit." As a software developer I flip bits for my employer, and in exchange, they tell my bank to flip some bits in their DB.

[satvikpendem]

Indeed, the sort of reductionistic argument that the GP is making is simply too simplistic to be useful. It's like saying making a chair is just rearranging atoms and therefore it should be free as well.

[prepend]

The difference is that making a chair involves labor and atoms. Enabling a digital hat involves neither.

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.

[prepend]

That particular hat is flipping a bit. Designing the game is a separate cost.

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.

[kumarm]

>>donate $6 to help dev

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.

[satvikpendem]

Agreed, no one who sells chairs will make them for free then ask for a $X "donation." But somehow people think devs should make their own stuff free too and ask for donations. If you like the product at a given price, buy it, and if you don't like either, don't buy it, same as any other good.

And people will pay $60 for physical items but balk at $0.99 apps and digital goods, it's strange.

[prepend]

Id rather also pay for the software. My point is charging $6 for dark mode is still “begging.”

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.

[satvikpendem]

People who offer their labor as shareware will tend towards making 0 dollars. That's just the reality of it, if people don't have to pay, they won't. If you want to make money, you should...charge people money.

[prepend]

That’s not true at all. Check out id software. They made gobs of money through shareware.

And of course there’s lots of open source developers who are excellent and donate their time with only expecting $0.

[coin]

> that is just flipping a bit

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.

[hombre_fatal]

I don’t see the problem. The app is basically a generous demo lacking only creature comforts until you pay.

That’s better than every other pay scheme I can think of since you have the option to do without.

[tinus_hn]

I’m not complaining about a free/cheap app from a small developer but the guidelines say you’re not supposed to gate OS or hardware features behind in-app purchase, so it may lead to refusal at any time.

[hnand]

I'll think about a better approach of monetizing the app. I always struggle when trying to choose what should be behind an in-app purchase. In this case I just picked the least restrictive option of what the popular competitor apps do (you can still use the dark mode, but it gets switched back when the session ends). Judging from the feedback on these apps I assumed that people are fine with it.

[nikodunk]

I think you made a good call. The counter-suggestion is “make a donate option” which generally is ignored by most and I doubt will pay you for your time. At $6 for dark mode, this is essentially a donate option anyway. People like free stuff.

[leesalminen]

FWIW, I think the pricing scheme you’ve come up with is fine. People will complain about anything, even free stuff.

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.

[zamnos]

It's fine. Not all complaints deserve a response, some people just like complaining. The other thing is follow through is non-existent. Outside of a signed business contract, when an individual says "I'd pay if only X", assume they won't have the patience to wait for X to be implemented, and then find you again to pay you. It's far more likely they'll just deal with their problem a different way.

[rollcat]

Agree. Apps using AppKit support dark mode by default, with zero input from the developer. This isn't even a matter of preference, but basic accessibility.

If the author really wishes to put this feature behind a purchase, "follow system settings" should be the free default.

[tarentel]

It does not work by default and it does require input from the developer. The UIKit API allows you to detect that you have it enabled but it doesn't magically redefine all the colors for you.

[marcellus23]

Not quite. If you use the UIKit system colors, it requires no work from the developer. The colors are semantic and automatically adapt to light/dark mode and high contrast mode. It only requires manual work if you have custom colors, or you do your own drawing.

[livinglist]

At $6, you really are not paying to use the dark mode, you are paying to appreciate the value it brings to you, nobody is forcing you to use the app.

[iknowstuff]

You get a full app for free, no subscription, and still complain? man you are so cheap.

[davely]

I think I was clear in my criticism with regard to the app pricing, which has nothing to do with your points.

[wahnfrieden]

apple has a rule against charging for platform-default available features

[joshmanders]

Dark mode is not a platform-default available feature. It's a setting in the OS that tells apps that you may prefer a darker variant, but it's still up to the app to implement the work required to make that happen. That is a feature of the app and can be charged for, hence why he does it and the app is still in the app store approved.

[_zzaw]

The fact that this isn't grubby subscription pricing immediately puts this app on my radar as something worth buying. I was steeling myself to write it off as soon as I saw the "in-app purchases" section.

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.

[hnand]

> I'd have avoided a free version and just made the basic price at least $6

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.

[causi]

As a user, I've found utility in apps that offer all features and customizations for free, but reset your preferences every time you start the app. It's like a demo except it never stops working and you can see the maximum amount of value the app can provide you.

[hnand]

That's how my app handles customizations - they just get resetted once in a while, but you can use them without paying, Premium just makes them permanent. I wonder if it's not obvious from the UI and people think that you can't use them at all.

[anonymouse008]

Curious if you have an example app for this? I have a stored records based app I work on occasionally and I wonder if an X day storage would fit this bill… but it feels weird to say, “if you want to store data permanently then it’s $y a month”

[causi]

My personal experience with it is game emulators that reset your customized control layouts and such but I imagine it could work for other sorts of apps.

[xp84]

> grubby subscription pricing

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.

[_zzaw]

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

[xp84]

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”

[_zzaw]

> That means judicious adding of things people really want, but also NOT adding crap just to add a bullet point on a box.

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.

[xp84]

First off, I'd really appreciate if you could reduce the angry, accusatory tone, I don't think it's productive. I have zero apps including subscription apps. I work for a B2B company for a paycheck. I am on the consumer side of the transactions at issue here. I don't know what you do for a living, because from your positions, it appears you might have no idea how the software business actually works in 2023.

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.

[hugatest]

This is quite cool, but I'm wondering why we need to re-invent the wheel for all those threaded discussion platforms.

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?

[kalleboo]

For me the OG for threaded discussions is Usenet.

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

[ciex]

Email has terrible thread navigation and I consider old.reddit.com with reddit enhancement suite the best in class.

[kevincox]

> Email has terrible thread navigation

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.

[hugatest]

Then you need a better mail client.

[salted-fry]

I've been using an incredibly stupid bash script to do this; you've finally given me the push to publish it here: https://github.com/krsiehl/hn2mdir

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

[hugatest]

Wow, this is brilliant!

[gnicholas]

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.

[hnand]

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

[gnicholas]

Great, thanks for the replies.

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!

[pindogu]

Somewhat related: "Harmonic" is a GREAT viewer for Android

https://play.google.com/store/apps/details?id=com.simon.harm...

[jacobp100]

Neat! A few things

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

[hnand]

> I feel you should be able to tap a comment to expand, rather than just swipe

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.

[tkgally]

Nice! My first impressions were quite positive—the app scratches several itches I’ve had with HN’s UI—and I like the full feature set, so I bought the paid version. I hope that gives me the right to make one request: a native iPad version.

[hnand]

Thanks! I want to perfect the experience on iPhones first, but iPad version is definitely in my backlog.

[jamies]

One feature request please: add an option to open links immediately in Safari (which has my preferred web extensions installed).

[hnand]

Good idea, will do.

[carlos-menezes]

Interesting. I just installed this yesterday after migrating to the 12 Mini.

I like the app, but there's too many features behind the paywall.

[web3-is-a-scam]

This is such a wonderful way to browse comment threads, I absolutely despise the “standard” way of just collapsing things and that’s it…this makes so much more sense and is a game changer for browsing this site. Well done! One of the easiest $8 to support a fellow solo dev I’ve ever spent.

[expensive_news]

I’ve been trying it out, and I like it a lot. But I wish that you could still tap a post to collapse it, like marking a comment chain as read.

[marbletiles]

My main challenge with navigating large threads is seeing what's new when I return to them. If there was a view that helped with that, I'd be sold

[hnand]

That's an interesting UX problem. Have you tried Anchors ("#" buttons)? Do you feel like it would be convenient if there was an option to mark all new posts as anchors? You could jump between them with "previous/next" buttons.

[germinalphrase]

Highlight “new comments since last thread visit” without altering thread structure?

[hnand]

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

[easeout]

Nice work :) Your on-page hierarchical navigation looks like something you could do with existing navigation view transitions, disclosure groups, or an outline view, though the sticky header solution is cool. What UI patterns did you consider and how did you settle on this one?

[asimpletune]

Very nice, this is definitely the best UX for reading comments. Just one question. Is there no way to implement account log-in that integrates well with keychain? Thanks for the nice app!

[hnand]

Thanks! Under the "Sign In" button you can tap "Alternative method", it opens a webview and you can auto-fill you credentials from the keychain. It's a few more taps, because you have to choose from the list of saved credentials, but otherwise that would be a security risk, Apple wouldn't allow that.

[nikodunk]

There isn’t - they’d need access to the news.yc domain to implement that. Otherwise any app could suggest you auto fill your bank login if domain linking weren’t implemented!

[RockyMcNuts]

LLMs might offer some creative ways around the trilemma of navigating threads chronologically, by topic/contextually, and by score.

[smusamashah]

This looks so good and should probably give some interesting ideas to @busymom0 the developer of android app HACK.

[causi]

Feature suggestion: a countdown so you know how many more times you and someone can reply to each other before you hit the limit and have to start repeatedly editing your last comment to carry on the conversation.

[hnand]

Do you have more info on the max comment depth by any chance? I did a quick search and, unless the info is outdated, it looks like there's some kind of anti-flamewar mechanism in place, but no set max depth https://news.ycombinator.com/item?id=11429230

[causi]

I couldn't tell you if it's a set depth or some kind of stochastic system. Many of HN's rules are subtle/invisible, to the point you can't even be sure whether they're being applied by an automatic system or by a moderator. For example, you can post a large number of highly-upvoted comments in a short timespan, but if their score is neutral or negative you'll get muted for an indeterminate amount of time; I've seen between ten minutes and a full 24 hours personally. You can also get muted for stepping on the wrong person's sacred cow; you can tell when that happens because you'll find yourself muted when your last day's comment history is, say, only three comments and all of them have positive scores and no flags. I've found it handy to keep a list of "things mods don't like opinions on".

[AHOHA]

To enable a dark mode you need to have a premium? No thanks! I’ve been using Hacki app so far and it’s awesome, need some improvements but generally speaking it’s been the best I tried, and it’s free.

[dbtonez]

i've been trying to be more active on the site, and i have just installed the app. initial impressions: great interface. excellent usability. i especially like the reading list feature. i tend to dump threads anywhere and everywhere on the browser and tend to forget about them. thanks for your hard work!

[lambdaba]

Honestly this is the best iOS HN app to date.

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.

[bdlowery]

HACK is better.

[jedi2610]

there is glider. https://github.com/Mosc/Glider. but not sure if it's available for ios although it is written in flutter

[livinglist]

It’s not but you can build it from the repo with no extra hacking.

[bdlowery]

Has no one heard of HACK? It’s like this app, but better.

[abhayhegde]

Seems interesting, but the video preview is not working.

[hnand]

Added another link. Video preview is the same as on the App Store page.

[bazmattaz]

Why can’t a user reply in any of these HN apps?

[web3-is-a-scam]

You can in this one you just need the full paid version.

[Jcowell]

i’m replying right now from the HACK HN app.

[dvngnt_]

this is exactly how RES and baconreader for reddit works. impossible to go back

[NaN1352]

Pet peeve : wish "iOS" term was banned and use "iPhone only" instead.

-iPad user

[easeout]

While iOS is an umbrella term, the App Store is pretty clear about which devices an app supports. The device range is explained right beneath the screenshots, and the Compatibility section goes into more detail. In this case iPad isn't mentioned, so are you looking for some clear "no iPad" signal? If it will run on iPad, just not as a full-frame iPad app—because a few really won't run at all, like if they require a hardware capability only a phone has—how could they make that clear? In the storefront signal-to-noise game, is it worth the attention?

[zuhsetaqi]

iOS is iPhone only. iPads are running iPadOS

[easeout]

It's still one iOS SDK. As a developer and power user audience, we remember when iPhone OS was first renamed to iOS on iPad's release because they were the same. It hasn't been renamed back. Regarding usage, the term iOS development within Apple dev shops still refers to both iPhone and iPad code and App Store distribution. We generally use iOS as an umbrella term, and reach for the new term iPadOS in reference to the iPad-exclusive parts of the user experience like its multitasking capabilities and Universal Control.

[david422]

Hmmm, never even knew that. Thought iOS covered both iphone and ipad.

[loloquwowndueo]

https://www.apple.com/ipados/ipados-16/

[web3-is-a-scam]

It used to but they separated them a few years ago.

[easeout]

It does except in recent marketing. iOS is still used as an umbrella term.

[jadtz]

It used to be like that until 2019 when iPadOS was introduced.