When will the INaturalist app issue on Android be resolved?

Hello everyone. What’s going on with the INat app on Android? When are they planning on updating it? Today, I spent a lot of time just trying to get the app to upload photos properly. Without freezing. Without crashes. Without constant “INaturalist app not responding” messages.

I even disabled the internet connection on my phone, meaning the app wasn’t sending photos to the servers. But it still manages to eat up RAM. How is this even happening? What’s in the app that’s eating up my phone’s resources? It’s not really designed for anything other than taking photos and uploading observations. It’s not some kind of super app, really.

I really don’t understand this. There are countless indie developers who maintain their services, make updates, etc. Why can’t INaturalist do the same? INaturalist has one of the worst mobile apps I’ve ever seen. And yet, INaturalist promotes itself through its mobile app! This is absurd.

Did you try uninstalling and reinstalling the app? The Android app is working fine for me.

No, it doesn’t help.

Android version 14. App version 1.38.2.

How about we completely scrap the useless and annoying new app and go back to having a basic iNat app that works (like iNat Classic) and keep the Seek stuff as a separate app instead of trying to force them together.

I really hate the new app and always use iNat Classic instead is it works best. I know I’m not the only one, I see comments saying similar things here and posts on the iNat subreddit also saying this.

Moreover, the iPhone app doesn’t even have a function to revoke an ID.

We certainly need a iNat light app, no functions, other than recording, notes, one click ID (iconic taxa only), storage for large numbers of observations (important!) and a fast upload when bad local internet connections are available.

I had similar slow uploads when living in Haiti, 15/20 minutes per observation where not unusual. Now in a Western country the app is working fine for me.

I learned that deleting memory and cache helps to keep it functional.

I also have had to revert to the original app as iNat Next simply does not work fast enough for my needs. There isn’t time to wait around for actual minutes just trying to get the interface open to add a handful of observations. The absurd response I and others have received from staff thus far is “you should be making fewer observations as the new app isn’t built for volume”. Yes, great idea to tell people to stop using iNaturalist so much. It really makes me feel warm and fuzzy and definitely won’t cause me to warn people in real life not to bother with the new platform.

This is all I want, really (and is essentially what the original iNaturalist app is – in fact, I would be fine if the Projects browser and the News tab were cut out of that app as well). I find it hard to believe that the tradeoff suggested here is worthwhile. That is, that attempting (with apparently limited success) to harmonise all mobile functions into a single app, but having that app be a hundred times slower and with a dumbed-down default interface that discourages adding multiple photos or not AI-identifying and uploading records instantly, makes sense; or that there even needs to be a tradeoff in speed and reliability for the app to be the same experience across platforms. How is it possible that having a cross-platform app means it has to lag to the point where staff are advising “not uploading so much” as the official solution to the ongoing speed issues? I really like to think staff are trying to work through this, and my default assumption is that everyone is operating in good faith. However, the response received so far to each report of problems with the new app has been uniformly a disappointment.

The eagerness to throw resources and time behind implementing (and adjusting on the fly) harebrained schemes like the provisional name pilot (where the enormity of the likely resulting taxonomic problems, and the accessibility of the formatting outside the US, was not thought through) or the now-redirected Google AI effort (to which no backlash was expected, somehow) is beyond exasperating, but totally understandable in a mercenary sort of way given the sums of money being thrown at them. On the other hand, the lack of a similar level of attention or interest regarding core functions and performance of the platform – setting aside, for this thread, the woefully insufficient desktop notification system and other “features” – really makes the app seem more like an afterthought than the alleged flagship for how people should engage with iNaturalist in the first place.

Perhaps it’s like the recent homepage update, and geared toward being maximally shiny to attract new users, but subsequently retaining those users and keeping them satisfied with app performance is not a priority. Or perhaps it’s that the thought is that the new app is sufficient without checking, unless staff have tested alternative configurations and just not mentioned it or explained how it’s been fixed (power-user uploading of hundreds of observations; using a phone that’s not the latest and most powerful model; slower internet connections; trying to make observations at a rapid clip while on a long hike, instead of just leisurely recording with no time constraints). I will admit one failing on my end: I forgot to follow up in an earlier thread and specify that recent updates to the app have not fixed the overall speed of the workflow for me.

Is the request to “upload fewer observations” made out of desperation, or is that genuinely what staff think people should do? I’m not sure which is more off-putting. (I won’t mention any episode of users being singled out by staff for cross-examination questioning based on the specific observations they’ve posted, as at least that seems to have been deleted.)

Pardon the long post. This is something I feel very strongly about. No, I don’t want to stop uploading my usual and reasonable numbers of observations. No, I can’t constantly upload as I go, when I’m in areas or countries without cell service, or trying to avoid draining my entire battery. No, I can’t afford to buy a new fancier phone just for the sake of using iNaturalist. No, the rest of my mobile operating system isn’t lagging or breaking the way iNat Next does. And no, I don’t know if I will continue using iNat on mobile when, as planned, staff someday cut off support for uploading via “iNat Classic”.

What we’re talking about doesn’t actually require incredible effort or new technologies from developers. The app can be optimized. Where there’s a will, there’s a way. But they don’t have that will. So how can they invite someone to INaturalist if their app doesn’t work properly?

With this approach to the project, INaturalist won’t last long. If a viable alternative appears, I’ll happily switch to it and delete an app that hogs more resources than Instagram. Although, INaturalist’s functionality is far from Instagram’s.

If the original poster has an android phone, they are presumably not using iNat Next.

There is a beta version for Android on the Github repo.

I’m completely with you. As an identifier the dysfunctionality of the android app is even more exasperating; I get no access to the list of taxa I follow, the more I click on users’ observations and scroll down the list the more the app struggles and lags, after a while it starts going on loops and no longer allows me to suggest new IDs, and if I keep going it crashes entirely. For some reason they never got rid of endless scrolling despite the glaring lag issues.

Do know that people have been complaining about these problems for years and nothing has ever been addressed. iNat Next is on the way, but judging by general feedback it doesn’t seem to be much of an improvement.

In addition to what @zdanko said, the IOS iNat Next app is intended to be cross platform and was built in part to replicate the Android app which was further along in development due to be being easier to upload iterative platform changes via Google Store vs Apple Store.

As a result a lot of the problems with the Android app got imported into the IOS iNat Next app, and the additional problems with the IOS iNat Next have been filtering into the Android app.

Eventually the two will be identical as that’s the stated goal, and both platforms will share the entire suite of problems and likely none of the solutions.

@sbrobeson The things you mention are part of what led Ken-Ichi, one of the two founders of iNat and the initial designer of the software, to leave the iNat organization. Some of the points you mention are ones he also mentioned as influencing his decision.

Afaik, they are not planning to fix any major things for it aside from minor bugs and even if its classified as genuine bug report there is no developers time to fix them now (well all the issues mentioned in this thread already arent fixed as of today when those issues are long known on these classic apps) compared to investing that time in polishing new app as iNat already chose to :person_shrugging:

the newer inat next beta android app on github looks underwhelming to me when I tried but again its not public release and idk if its going to get better next. The decision to spend effort on newer apps was made to integrate developer effort for ios+android easily instead of maintaining two separate native apps.

wait till u see how much more resources the newer iNat next android is going to take (to my device it was 4x on the beta release of latter) :joy:

well the app was never designed for identifiers point from the start and there is no pushes to even do now, maybe there were some features added for IDers in app after this old comment, but mostly negligible compared to full web experience for IDers :upside_down_face: :

Nothing the original poster has written suggests that they are using iNat Next; I assume they are using the original Android app, which in my experience over the last several months has become particularly prone to the sort of bugs described in the original post.

Discussion of the problems of iNat Next are irrelevant if that is the case, as it is a completely different app (not based on the Android app) with a very different user interface and code.

Edit: I’m aware that it is possible to install iNat Next even if one is using Android; because doing this requires a deliberate effort, it is likely that someone using it on Android would have said that this is what they are using – and if they found that it was consistently causing issues, they would likely have simply gone back to using the original Android app. Given that neither of these things seem to be the case, it is reasonable to guess that they are not using iNat Next. Talking about iNat Classic (for iOS) being better/less buggy is not going to be useful for them if they are using the classic version (for Android).

For the amount of logs that the app writes, they should get rid of TinyLog and use a real logger like SLF4J + logback-android.

That should solve half of the problems.

Yes, I believe this is the case. Oddly, despite the totally different code base, the original Android iNaturalist app and iNaturalist Next on iPhone have that very similar problem of getting more and more buggy while scrolling down and loading additional results. However, it tends to result in the Android app behaving strangely and breaking/crashing, while the iNaturalist Next situation is more one of slowing down and ultimately freezing on screens that won’t load fully. Most of the crashes in iNaturalist Next I’ve experienced are related to trying to post identifications, unlike in the Android app. Still, they both become unusable pretty quickly in superficially similar ways during simple regular use such as the. native-in-app infinite scrolling. It is not encouraging that the app intended as a replacement (right away on iOS and in the near future on Android) replicates so much of what made the existing/older Android app such a frustration to use.

Yes, I read his blogged explanation when it was posted. It’s understandable, but his departure obviously had little or no impact on the platform he departed from. That these are points brought up by even someone who was until recently a staff member shows that they are obvious to anyone involved and concerned, but deeply rooted or at least not addressable in total by the people who chose to stay.

I’m most distressed by the responses that boil down to or explicitly state that user behavior is seen as the real problem, not the bug-causing aspects of site architecture and features. Being told not to upload so much, or to have staff publicly single out a user for the specific organisms they uploaded it (before deleting it, I suppose having realized the issue), indicates that the goal is not to maintain a platform that works best for users within the rules, but to train users to work best for the platform. “iNat is not designed for recording like this” or “Unfortunately, the app isn’t built to handle this” or “You might consider making fewer observations” or insisting that users frequently delete and reinstall the app rather than providing a way to clear the cache (as there is in the old iNaturalist iPhone app) all go beyond hinting into unambiguously stating that all performance issues are considered to be user errors and the platform will go on working (or not) as it has, until people get used to its problems. Once new members are attracted by a shiny redesigned interface, they should just deal with bugs themselves. However, the preexistence of a lightweight iNaturalist uploading app on at least one operating system suggests that none of the present issues are intrinsic to app development — they are just the ones that staff developers, in the specific way they test functionality, either overlook or choose to accept.

Of course, maybe staff are working on these behind the scenes! However, examples like the ability to directly edit taxon entry names show that the developers can’t be bothered to post (where an ordinary member of the public would better see it) a simple “Yes, we’re working on it.” In that case, a long-running feature request received followup questions from forum users for many years, which were all ignored without response, until one day staff abruptly announced that the feature had been added. We don’t need constant insider updates by any means, but for a normal user, it would help to know what staff are planning, at least without tracking the iNaturalist Github for the handful of specific features that are being worked on there.

I’m going to set this topic to close in an hour, as @daisan didn’t provide any specific information in their original post or any later posts, and the topic veered off into complaints about an entirely different app, and various other complaints.

We don’t plan on updating the current Android app aside from bug fixes, but without specific bug reports that we can try and replicate and investigate, there isn’t anything we can do. If something is not working, please try and write as many details as possible about exactly when you come across the issue, and provide screenshots and screen recordings, and file a new bug report and we’ll take a look.

Regarding the new iPhone app (I wouldn’t recommend trying it for Android at this point, it’s not ready for beta testing), I know it’s incredibly frustrating that it’s still very laggy and buggy. And app should not be like that. I personally have rarely encountered those issues, even when making 50 plus draft observations and uploading them on mobile data, so it’s hard for me to make detailed bug reports for it. In my experience the app works well for making many observations in the field, and is much more efficient if your workflow involves importing photos taken on a hike, which in my experience is the easiest way to make a lot of observations. But a significant number of users are encountering these lags and crashes, and I’m sorry you’re experiencing them. Others on our team have recently been able to replicate some of the issues and we think we have some leads for fixes, but I cant make any promises yet.