There appear to be 2 different apps for Rocket Chat on iOS
https://itunes.apple.com/us/app/rocket-chat/id1028869439?mt=8
Is there a reason why there are 2 apps? Can the old one be yanked to save people from getting confused.
2 Likes
Yes, the old one (Rocket.Chat) is based on hybrid app Cordova technology, and it has served us well for the last couple of years. There are some in the community who depend on it currently. We have issued a deprecation notice for March 2018 when we will remove the Cordova apps from the stores.
The Rocket.Chat+ apps are native apps - written from scratch using Swift on iOS and Java on Android. They are still in extended beta and will become our “official mobile apps” once we remove the Cordova apps in March.
Thanks.
1 Like
Understood, minor warning though our team have been finding the Rocket.Chat+ app really problematic.
It regularly drops messages and has large missing content holes, formatting is way rougher than it is in the web app (missing rounded corners and such) and embeds just say “tap to open file”, when tapping them we get nothing. I feel like it does need a fair bit of polish.
Not asking you to reconsider a hybrid approach but maybe integrating a webview for sections of the app (message stream display) would heavily simplify dev there, cause as it is you are stuck re-implementing everything.
Yes I’m not sure if we need a new post to track this or if there’s a better place to report it, but in the Rocket.Chat+ app, I regularly find many messages missing. If I don’t use it for some time, I find it’ll only load the last few messages, leaving a giant gap in history if I scroll upwards.
The other day for example I used it at 8pm, and it had nothing between 7:30pm or so and 11am, when there was activity all day.
@sam @eviltrout was this iOS or Android? If you do get a specific reproducible case please open an issue:
iOS Repo - https://github.com/rocketchat/rocket.chat.ios
Android Repo - https://github.com/rocketchat/rocket.chat.android
Regarding polish. This is definitely known and being actively worked on. Even just the visual inconsistency between mobile and desktop. We’ll be bringing the new style introduced on the website to the mobile.
Also under the hood, being mobile they are working on making use of a bit more REST calls. Right now everything happens over a single websocket. Which depending on network connection can be a little flaky. So the network stack and reliability of sending / receiving is getting a lot of attention as well.
Thank you @sam! This is not at all the experience we have with it.
in facr we thought it may be stablized enough to be made primary.
i will ask our mobile team lead to follow up here. it is very valuable for us to get external feedback like this.
Hey guys, thank you very much for your feedback. Let me try to answer to your specific reports:
-
“tap to open file” not working: if this is related to iOS (I think it is), can you tell me what kind of file are you trying to open? When you tap to open, it’ll download the file to your device and open it using iOS native document “opener”, so it should work with most of file types;
-
Can you tell me what specific formatting issue are you having? AFAIK the only piece of format that is missing today is the code block formatting to a specific language. All the other markdown format should be available and working very similar to the web; If it’s not, can you please send us some screenshot?
-
Regarding the “missing” messages: can you tell us if this is Android or iOS (or both)? We always fetch the history from the API and fill the missing points, but maybe you guys found a bug on this case; Also, what version of the server are you guys using?
Thank you very much for your feedback. We truly believe that the native experience will be much better for our users in the short/medium term, having all the most used features and much more polished app, your feedback is very important for us.
1 Like
Looks like one link is to our Cordova application (for iOS) and the other one is the Electron app (for macOS)?
@sam Just wanted to introduce you to @rafaelks, our mobile team lead. 
1 Like
Hi @rafaelks, yes confirmed this is all the iOS version of Rocket Chat +, happy to open GitHub issues
There is actually no “file” to download, an example of an “expand to download” we would get is for
All I see in Rocket Chat + is “LowFreeDiskSpace @sjc1”, and click to download, clicking does nothing.
More around fit-and-finish, rounded corners on mentions, stuff like that. Also, since we heavily modified UI via CSS we lose all our changes.
For example stuff like this, which is not even done
I am not sure how solvable this is.
We are using the hosted service by you, not sure what version it is.
I noticed this on iOS, Rocket Chat +.
Does the app recover cleanly from dropped sockets?
Interesting! I see what’s going on, because of the properties of this message, we’re understanding that the link is a file to be downloaded. I’ll open an issue for that and making sure that it gets fixed to the next release. 
You’re right, we cannot handle custom CSS in the mobile apps right now, I think we’ll have more information about this in the future, custom layout/UI replicated to the native apps is something we’ll be working in the short future. Regarding the rounded-corners, this is already done and merged to the next release (1.8.0). And about the marker of “unread”, I also opened issues for that, for both iOS and Android.
Just confirmed that you guys are using 0.59.4. This is the latest stable version of the server, so this shouldn’t be a problem. The iOS app should receive the updates and always recover cleanly from dropped sockets, also when you close the app and open again. Is this happening always to you?
When I saw this restarting the app meant issue was still there.
Interesting, what is the protocol it uses for recovery? Can there be a timing issue where it updates its local db prior to copying the messages to local storage?
Yes, when you reconnect to the server we sync data that wasn’t synced yet by using the latest date you got some information from the server. It should work, but maybe you entered an edge case?
Can I send you our TestFlight build? If yes, just send me the emails you want to be invited. We’ll probably send a new build tomorrow with some of the fixes.
Thank you very much!
RocketChat+ has yet to work for my server either.
Not working at all is a completely separate issue.
I don’t want to derail conversation here. If with hosted of course hit up our support. But on-premises it always boils down to one of two things.
- Your reverse proxy is not properly handling upgrade of /websocket to a websocket. Websocket is needed by the Rocket.Chat+ app.
- Your ssl cert is not valid or you aren’t using one. SSL is required, especially for iOS.
Apache is typically the reverse proxy used when people tell me they have issues 
nginx for me. It works fine with the Electron, as well as the Cordova client, once that cute bug that renders the client useless on 0.60 is fixed…
By “not working” I mean I’m unable to complete oauth – I think I debugged this with @rafaelks while at the GSoC mentor summit back in October…but we never got far with it…and both of us forgot – or got wrapped up with the summit…which happens.
Oh gosh, I didn’t know it wasn’t fixed yet for you, I’m sorry! But what Aaron said makes a lot of sense. If you’re using your own cloud solution, you need to make sure that your server supports WebSocket. Web (Cordova and Electron is basically the same as Web, just a wrapper) will use HTTP protocol if WebSocket isn’t available in a transparent way for the final user. There are tons of issues related to that in our GitHub and people still face the same problem every time.
To make sure your server supports WebSocket, please run this simple curl command and make sure you’re running Nginx version 1.3 or greater.
curl -i -N -H "Connection: Upgrade" \
-H "Upgrade: websocket" \
-H "Host: yourhost.com" \
-H "Origin: yourhost.com" \
-H "Sec-WebSocket-Key: fVXESE8fjBMx8HheW0YlZQ==" \
-H "Sec-WebSocket-Version: 13" \
https://yourhost.com/websocket \
--verbose
Could you give it a try and see if that works for you?
Thank you!
rob at rob-laptop in ~
$ curl -i -N -H "Connection: Upgrade" \
-H "Upgrade: websocket" \
-H "Host: chat.librehealth.io" \
-H "Origin: chat.librehealth.io" \
-H "Sec-WebSocket-Key: fVXESE8fjBMx8HheW0YlZQ==" \
-H "Sec-WebSocket-Version: 13" \
https://chat.librehealth.io/websocket \
--verbose
* Trying 2001:4800:7818:103:be76:4eff:fe04:5979...
* Connected to chat.librehealth.io (2001:4800:7818:103:be76:4eff:fe04:5979) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 604 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: chat.librehealth.io (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: CN=chat.librehealth.io
* start date: Sat, 04 Nov 2017 18:11:47 GMT
* expire date: Fri, 02 Feb 2018 18:11:47 GMT
* issuer: C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
* compression: NULL
* ALPN, server accepted to use http/1.1
> GET /websocket HTTP/1.1
> Host: chat.librehealth.io
> User-Agent: curl/7.47.0
> Accept: */*
> Connection: Upgrade
> Upgrade: websocket
> Origin: chat.librehealth.io
> Sec-WebSocket-Key: fVXESE8fjBMx8HheW0YlZQ==
> Sec-WebSocket-Version: 13
>
< HTTP/1.1 101 Switching Protocols
HTTP/1.1 101 Switching Protocols
< Server: nginx/1.12.1
Server: nginx/1.12.1
< Date: Tue, 02 Jan 2018 11:29:50 GMT
Date: Tue, 02 Jan 2018 11:29:50 GMT
< Connection: upgrade
Connection: upgrade
< Upgrade: websocket
Upgrade: websocket
< Sec-WebSocket-Accept: dyU1fPKS9c9nPGo2mPsrQv40G9E=
Sec-WebSocket-Accept: dyU1fPKS9c9nPGo2mPsrQv40G9E=
ďż˝{"server_id":"0"}
Just confirmed that connecting to your server from our mobile apps are working just fine. But I could not create or login with any account. Did you made any customization in the login/signup code? I received an alert saying that my email was invalid (but wasn’t). Do you know what could be happening?
Yeah – I seem to have issues with everything but the Cordova client. I don’t think we did anything special…We just configured oauth…I’m not sure what’s up 