[busymom0]

The entire parsing logic couldn't be separated from the app efficiently I think. It's doable but would be hard to do it efficiently. Right now, the parsing happens in Swift (and Kotlin for Android). I could maybe switch the parsing to javascript and then download the parsing code over the internet, then use javascript bridge to do the parsing. But javascript bridge is slower than swift.

The better way I am thinking is to fetch the XPath/CSS query selection strings remotely on each app launch. Since fixes for the website changes usually involve me only having to modify the XPath for each element in my app, I could just modify the XPath on my server and then have my app fetch them on app launch. The XPath is just a string in the app, so it can be done.

Whether this is doable obviously depends upon how big of a change the HN website HTML has. I will look into it.

[KMnO4]

> But javascript bridge is slower than swift

How much slower are we talking? 20ms vs 9ms? I feel like we developers prematurely optimize critical paths without taking the actual timeliness of the objective into account.

[busymom0]

The parsing plays a major role and is already the bottleneck in the app.

When using the app, the more the number of comments a post has, the longer it takes. On older devices (iPhone 6S or cheaper Android phones for example), it can take 10-15 seconds to parse 500 comment posts. My app already has to take this into account and therefore only displays 20 comments right away and then adds additional comments as it's finishing parsing the rest.

Since the app has a "go to next top level comment thread" button, this button has to stay hidden until all 500 comments have been parsed. So any slowness in the parsing can significantly ruin the experience.

[1_1xdev]

Your idea to fetch the x path/selector from your api is a good one.

If the logic needs to change more substantially yeah you’re gonna have to ship an app change.