I think we got to the point that we can (and need) to deprecate our Cordova apps from App Store and Google Play. The apps are confusing everyone and we’ve daily downloads of the app, and AFAIK most of the time the app doesn’t work.
My suggestion: let’s rename the app for now in both store to Rocket.Chat Cordova Legacy and see what happens. In the meantime, let’s update the application with Fabric, Google Analytics (or some other analytics tool) to allow us to know how many users are actually using this app daily.
After we have the numbers of usage, we may decide in removing the apps from the stores or keep it.
This is really important for us in order to avoid confusion with our users.
We have already notified all those Cordova App community users who are in touch with us. Our written notice went out last November (2017) - letting them know that Cordova app will be deprecated as of February of 2018.
The response has been incredibly understanding and supportive.
Having said that, we do believe that there exists a sizable community footprint that:
use Cordova Legacy for its constant feature parity
do not have app store keys to publish their own fork of the Cordova clients
do not contact us unless there is problem - several of them surfaced, for example, when Cordova was routinely displaying a blank page on startup
To ascertain this, I think @rafaelks 's suggestion is spot-on; and is something that we should action immediately:
In the meantime, let’s update the application with Fabric, Google Analytics (or some other analytics tool) to allow us to know how many users are actually using this app daily.
Agreed! I think this is good. Those that still want or need Cordova can keep using it… but it will help guide others to the native Rocket.Chat applications. I think this will help a ton on reducing the confusion.
What about existing users? Do we want to some how at least alert them of the new app? Maybe something as simple as:
Support for the Rocket.Chat Cordova application is now deprecated. It will not be receiving updates. Please try our native applications: Link
generally I agree with you, that this is a good move. Some remarks from my side:
I assume this is an internal document?
Can you elaborate on that? Is this also current practice with current (non legacy) and the future apps? I’d appreciate any information on what is being tracked (and what data is sent where) and how often this is done. Maybe this would be a good starting point for a public document that elaborates on which service/application sends off analytics. For example I haven’t been aware of the server sending data for analytics purposes to you. I think it should get a custom to write those things down so the people know what happens.
I think this is a good idea, too. Only thing would be to clarify how this is done. Onetime? Every X app launches (which is probably rather annoying)?
Right! Sorry about that, just fixed the link to be access as a public link. Thanks for letting me know.
Sure. This is a very important topic for me, I want to put our users privacy first always. Right now we do have a “tracking” from Fabric (before it was Crashlytics) that monitors all the crashes into the application and send us reports on how users usage. No private information is tracked (email, server, messages, profile information). The framework will track only the usage of the user (new sessions only, we don’t have any “event tracking” inside of the app) and if some crash happens we’ll have the stacktrace (again, with no information included). On latest iOS build, we started adding the user’s server and user’s name when some crash happens, this way we would be able to ask this user if we needed to in order to investigate how that crash happened. This feature was added in the application and we do plan to add a “toggle” so user will be able to remove this kind of tracking if he wants to for next release. Do you have any other idea on how could we do that? In the ideal world, we would have an internal analytics instead of using third-party services, but we don’t have the resources to develop it right now, that’s why we’re using a third-party one.
I totally agree with old app renaming, But why not rename only to Rocket.Chat Legacy? Cordova does not mean much to the end users.
Let’s do it as soon as possible and try to implement the tracking later.
@rafael.kellermann let me know what do you need from me to make it happen.
I don’t know how we could track the cordova usage, the Fabric integration didn’t work and JS analytics will not work cuz the app loads the JS from the server where it is connecting, we could inject the Google Analytics JS but it could override some existent one, so the tracking needs to be at the native side of the application, as Fabric does. Maybe @rafael.kellermann could try to install the Fabric in the project, @diegolmello tried and me too, but many errors involving the native compilation happened and I don’t know how to solve them.
I believe adding “Cordova” is important because it means something to people who care about Cordova. Those who doesn’t care will find the name weird and they won’t try it. Rocket.Chat Legacy is an interesting name that may cause some new user to try (and get frustrated with the experience).
In order to update the app name, the only thing we need is to ship an update to the app.
Can someone share the errors with me and then maybe I’ll be able to help? Otherwise we may end up looking into other solutions: 1) Other services (Flurry may be a good option for now, just for Cordova); 2) Create an endpoint for us that will hit on new sessions only, that would give us an idea of how many sessions we have daily on the app.
Spent 3 hours already trying to integrate Fabric/Crashlytics/Flurry with no success. The reason is because our Cordova version is super old and needs to be updated in order to support this libraries. I tried very old libraries for Fabric/Cordova as well but no success.
My suggestion: let’s track in our hosting service how many requests are being made via Cordova by looking into the User-Agent of the request and the IP address of the connection.
I investigated how the Cordova apps are sending the User-Agent on iOS and Android on my devices:
iOS
Mozilla/5.0 (iPhone; CPU iPhone OS 11_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E217 (140685359511584)
Android
Mozilla/5.0 (Linux; Android 6.0; F3311 Build/37.0.A.2.248; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/65.0.3325.109 Mobile Safari/537.36
@geekgonecrazy Do you think that’s a viable solution? Something we could do is to find the strings and see if have something useful?
