I have been out today, but just saw this. While it looks like this has already died down a bit, I’d just give me two cents as well. No hard feelings about anything though.

First off, like was stated before, the current TestFlight release is - and was admitted to be - a major rewrite or a major portion of the app. In fact, it was performance itself that was a determining factor in the rewrite. As you probably know if you are a dev yourself, things like that don’t come cost-free. As a single person working on that aspect of things, it took a lot of work to tear out things and make them right. And - obviously as we can see here - they are not right. In fact, they are not even complete.

The reason that these builds get pushed to TF is that - again only being myself, Sean, and a few other contributors - it would be impossible to meaningfully conduct QA on the entire app and find these issues. There are issues that I am still unable to reproduce myself that I see people having. This is just part of development, and is something that will always be a part of development. A larger team would have a QA team that builds go through, which we do not have. And even in those cases where big QA teams find all the issues, how often do we see bugs still creeping through the holes? Often!

Now I think the reason that the comment might have been taken offensively was the mention of (and I can see you did end up crossing part of it out) “non-native, hacky, pragmatic solutions”. This is one of those things that we all know lots of people take seriously. In fact, it seems you possible that you are one of those people. I’ve fallen into the trap before too, so I get it. We can definitely get defensive over our work and the tools that we choose to use for that work.

Now, yes, you are right. The issue here might have been that when you changed accounts, things were not reloaded. This is something that must happen because there is zero correlation between post ID 4003 on lemmy.world and post ID 4003 on infosec.pub. And that is something that very well might be broken in the latest TF release (in fact, we know it is broken). And if I were a more dedicated and efficient person, I would have fixed it immediately after finding out and have pushed an update Sunday morning whenever I realized it. However, I am neither of those things and took the day off for myself. But we do know about it, and it will be fixed.

The statement that this is likely to be an issue with the tech stack is just not correct though. Additionally, the claims made here about battery life, memory usage, and “background behavior” are actually irrelevant. I’ll admit there might be higher battery usage with a RN app given the necessity of a bit more work going on, but not substantial on today’s devices. Memory usage is something that I have personally checked, and the app rarely uses over 120MB of memory (usually far less) and this is mainly due to images (I do believe that CPU might be one thing that is higher on RN in most cases, but memory seems to actually be about the same if not less).

A majority of the issues that people have (rightfully) had with RN over the past are the lack of native navigation (which is no longer the case in React Navigation 6), non-native animations (no longer an issue especially with Reanimated 3.x) and the native bridge requirement (this is being resolved now with the new architecture and the rolling out of Fabric). And while I do not admit to being the most knowledgeable RN dev (we are definitely learning with the process), I am certain that none of these performance issues are directly linked to React Native but rather something that we ourselves are doing.

And the claim that the stack itself is the reason for those issues is simply fascinating given the fact that not only other Lemmy apps I see being developed with Swift have performance issues in some places but most big-name apps I see these days have those same issues is telling of something. Not that the stack itself is causing issues, but that performance issues are something that happen and are dealt with. No one can blame any of the devs of any apps for these issues and I have seen all of them continually improve on them. I have been nothing but impressed by the Mlem team who’s app on the first day I downloaded it was - to be frank - pretty hard to use. Now, it has grown into quite something indeed and performance is quickly being addressed.

Lastly, perhaps you were unaware but the intention originally was to make an app that worked on both platforms. However, once it was seen that a number of fine apps were coming to the platform, we decided it would be best to focus on iOS. It is what we use, and what we care about the most.

Regardless, I am not offended by anything here and I am in fact someone who almost certainly not going to be learning Swift anytime soon. That is not because I have anything against Swift (I don’t have the same belief about the vast degree of superiority that it might have) but because I actually believe React Native to be a wonderful framework and I am intent on learning more about that itself. And while it certainly is not my reason for doing so (I do have quite a lot more experience with Javascript than either Swift or Java/Kotlin and that is the main reason), I am pretty sure that the continued growth, development, and real world use of React Native speaks for itself in terms of whether or not it is a viable solution for mobile app development.

Just my two cents. No hard feelings here.