ehrt74

Personally i don't read too much into the play store reviews of evernote. it looks like they've been written by a bot. No one seems to write more than 3 sentences. All comments are in perfectly formed sentences, etc. etc. The likelihood of this happening when random humans are spontaneously writing comments is about zero.

Login taking forever is odd. You might want to ask support about that. On the web browser I save my login for 30 days, so I don't have to enter password and 2FA key every time

There was a problem with images being saved with the wrong file type extension (a jpeg would be saved as image.png for example). You can try downloading the image and checking with whatever-software-is-available-for-your-operating-system-of-choice if this is the case here

The mobile apps use react native. As far as I know this uses the webview component. This is a part of the operating system which is updated over the play store. The same version is shared by 99.9% of Android devices. Whenever a bug is fixed in the webview component, a delta is quickly pushed to the play store. There is no need to wait for a monthly update or download 2 GB. This happens automatically in the background. Android updates are not like iOS updates. On iOS updates are monolithic updates of the whole operating system. Android is made of smaller parts which are updated over the play store. The core operating system is a lot smaller than iOS.

Evernote stores notes locally in the browser in the built in database (yes, browsers have a database nowadays ...). You could try deleting this and seeing what the web app does.

Does Evernote on Android do some sort of intelligent classification of notes? In chrome on my Chromebook, the default behavior of the web clipper is to try to guess the notebook you want the note to appear in. Maybe a similar thing is happening on Android.

I use OneNote at work and on the web it's ridiculously slow. Evernote is much faster. I've never tried the OneNote Android app, but it wouldn't surprise me if it's also a wrapper around the JavaScript base. The android app will get faster with time, if developers of the base technology and Evernote themselves carry on working on it. A note-taking app running in a framework on a device with 8 64 bit cores and 12 GB of ram isn't necessarily slow (of course JavaScript is not a compiled language, so the interpreter has to do a lot more work, but even so, every phone that has been made in the last ten years is a supercomputer). To some degree the art of writing performant code is becoming more specialized. Evernote's backend, for example, is immensely performant and I imagine they run large numbers of automated performance tests against new features and code changes. The UI, not so much. End-users tend to want features first and performance second. Also performance optimisation often comes at a cost, and that is specialisation and greatly increased maintenance costs. The way I see it, if the price of using Evernote on a mobile device in 2021 is to have a modern, powerful device, then I'm willing to pay it, provided Evernote in 2025 also runs fine on the powerful device from 2021. Hardware always gets faster. As long as the software doesn't get hungrier faster than the hardware gets faster, things will be ok.

Hello! A couple of points. The evernote back end does not run on the JVM, and none of the current clients do. I don't know what the legacy clients were written in (can someone add this information?) The legacy Android client was written in a langauge whose syntax and class structure closely resembles Java, but does not include JNDI, so it is also not affected. Log4j is a Java library. Unless the code is written in a language that runs on the JVM you don't need to worry. There is however a possibility that Evernote uses the JVM for some small services, and as you say, it would be nice to have clarity here.

To some degree you're right. However managed environments like google cloud include ways to filter outgoing as well as incoming traffic. As far as I know, this needs to be configured. The main Evernote service seems to have been written in C++. This means it is not vulnerable to the log4j problem. I'm not a fan of C++ as a programming technology, but the Evernote code has been around for a while so i imagine they've got a large number of bugs. C++ is a fairly low-level language (and no internet service needs to be low-level). Nowadays something like go would be a better choice (high-level language with the performance of a low-level language without the unneeded capabilities). However go does not play well with other languages so unless Evernote is gradually ripping their software apart into microservices a migration will be a lot of work. All of which means that log4j isn't a problem as far as i can see for Evernote. I've also had a look at Android. Android does not support JNDI (Google's security is enormously good, so i imagine they never entertained the possibility of supporting JNDI in Android), which means that it is not vulnerable.

It wouldn't surprise me if Evernote does say something about this vulnerability soon. Log4j is all over the news at the moment. Seeing as Evernote is now a SAAS product, fixing a vulnerability (provided the back end code is vulnerable) should be possible quite quickly. When a Java application is packaged for deployment all the jars get bundled together, so finding out if log4j is used shouldn't be that difficult (unless they're doing some crazy class-loading at runtime or whatever). However I don't think anyone knows what Evernote is written in. Job opportunities and Wikipedia both suggest it's written in C++.

I have no idea about the infrastructure, but the v10 clients do not use Java* and are therefore safe. * it's possible the Android client uses some Java wrapper code. I don't know how react native works.

Just tried this on my phone (for the first time!). it worked fine. You could ask for help from support? Btw, the first time you try to create an audio note, Evernote will request access to the microphone. Then you need to grant this access (either for just one time or whenever the app is open).

I've never had performance problems with Evernote v10 on Android. But many say they have had performance problems. I wonder what the difference is? I have about 1500 notes and only a couple of long notes.

i use 1password for the TOTP code for Evernote and it works fine. Sometimes the code expires before i can click on the enter button 😕 Each code is only valid for 30s and is generated from a hash of the current time (in Unix time). This should make it time zone independent (with the possible exception of when you're using Windows, which treats time zones differently from every other operating system i know of) --- btw TOTP codes are an open standard. see here, if you're interested: https://datatracker.ietf.org/doc/html/rfc6238. all apps for TOTP codes should be compatible

Evernote stays open in the background for a reasonable length of time on my phone (pixel 6 pro) and it starts very quickly. I would imagine there is a bug causing it to crash when it gets pushed to the foreground. In general i'm not a fan of the technology v10 is based on. fortunately this should improve over time. if evernote had started their rewrite today, i wonder if they'd have picked flutter or kotlin multiplatform? both now run on the web, android, iOS, windows, OS X and linux with wayland/X server and both do so with near native performance.

Evernote works quickly for me (fedora web client). But none of my notes are particularly long. Maybe this one note you're having problems with has some strange content. This could be of interest to support. v10 seems to be slow in some cases for all platforms. as far as i know, nobody has yet been able to put their finger on the exact cause. People with large amounts of notes seem to have this issue more often and very large notes tend to lag too.

There are two things going on here. Firstly the font needs to support the unicode character in question. This depends on the browser you use. Google open-sourced the no-tofu fonts about 5 years ago, so you could download them and set them as the fonts for your web browser to check that it's not a font problem. The second problem is that some emoji have now moved out of the range of characters which can be expressed in 4-bytes. Javascript itself started out using utf-16 for strings (because that's what the JVM uses). This quickly became too little (it only allows 65000 different characters) and now almost everybody uses a variable length encoding called UTF-8 (invented by Rob Pike - who later invented my favourite programming language). However to the best of my knowledge, javascript (like the JVM) uses extended characters to support 4-byte, not UTF-8. I'm not sure to what degree the browsers differ in being able to handle characters from the supplementary multilingual plane (also called "the astral plane"). These are unicode code points beyond the 4-byte limit. To check this you could try some astral plane characters. Here's a list on wikipedia: https://en.wikipedia.org/wiki/Plane_(Unicode)#Supplementary_Multilingual_Plane --- edit --- also of course the back end and the interface technologies need to support the characters as well, but if it works on one client then its a good sign that the back end supports it. as to the interface technology, if i remember correctly, evernote uses Thrift and that is totally agnostic with respect to string encodings.

Note that each web client counts towards the limit, so if you use the web client on a private computer and a work computer that would be two different devices.

I had a problem for a while with some images (i think i added them using the web client) having the wrong file ending. for example, the image file was called image001.jpg but was actually a png. I forget which client had problems with this, but it could have been the Android client. Can you download the image on a computer and check to see if the ending is correct?

Not that i'm saying that this was the case for Evernote, but I've known companies that have been unable to update programs because they'd lost the source code and only had the binaries available.

Xerox Park was doing this in the early 70s on a visual interface, and text interfaces had already had it for a decade.

Android itself has a large suite of compatibility tests. Very little ever gets removed and if it does, then with many years warning. I presume that the old Evernote app was using some deprecated APIs which eventually got removed.

Good job i speak German Flavour of the month, new-fangled capability? something like that in English

there are a lot of good open-source note-taking apps. Some are probably of excellent quality (open-source code is regularly rated as better than closed-source code for quality and safety). However, one of the main advantages of Evernote is synchronization between devices. This requires internet services that cost money to run and maintain. Some companies can afford to run these services at a loss (Microsoft, Google, Apple) just to get people to move to their platforms. I consider that to be a really bad thing. Running and managing a server online with the scale to support Evernote's data is very skilled work and undercutting this work by bankrolling OneNote or Google Notes or Apple Notes or similar is really bad for the market. So basically: if you're keeping notes locally, yes, you'll find good open-source alternatives. If however you want to store notes somewhere on line so you can sync them between devices, be prepared to spend some money and deal with some tricky configuration issues.

Apple already knows what is installed on your iPhone and your mac. there was a case recently where mac users couldn't start a single program because the OS phones home on every program start to check if the user has the rights to start it and the server at apple was overloaded. I very much hope that iOS does scan your phone to check for malware. Enough malware is distributed through the apple store. In one famous example many thousands of apps were compromised and then downloaded some 200 million times and apple did nothing (not even warning the users) for 2 weeks. I hope they've improved since then (it was a number of years ago).