Mobile UI for desktop



Nice! Are chat commands usable too?


@julien, not yet. Thanks for mentioning them. Will add to list of issues.


Thanks for sharing this!


Problem with nested TouchableHighlight was solved, so now on desktop it is possible to open profiles from avatar in chat.
Also fixed lags in chat search box and removed context menu options and buttons that call actions specific for mobile, like “share”, “invite friends”, “scan qr code”
Context menu for chat messages now called by right mouse click.

Next step will be investigation of poor FlatList performance on desktop.


@volodymyr.kozieiev Thanks for this thread and the updates. Do you think we could create an issue in Github (possibly with multiple issues linked to it) that outlines the known steps to getting mobile UI into desktop? Any thoughts on rough timeline for doing this? With our without poor perf.

Wrike milestone:


@oskarth, I’ll create an issue. Mobile UI already works, so without FlatList optimization I’d say it is not more than week needed to check/merge it with some additional fixes. As for FlatList - can’t say for sure, I don’t know where is the source of a problem yet.



  • FlatList performance investigation is in progress, so far no solution found.
  • To merge big and long-lasting PR @oskarth suggested to put all changes related to new UI under the flag. So PR was changed. By default it shows old desktop UI, but if MOBILE_UI_FOR_DESKTOP=1 specified in .env file, app runs mobile UI for desktop.


FlatList performance update:

It is turned out that laggy behavior consist of at least two different issues.
First of them - long delays before dynamic loading next chunk of data. For this issue solution was found yesterday. There is discrepancy between mobile and desktop events flow. Desktop sends only one onScroll event per scroll and doesn’t trigger js implementation code as many times as it should.

Second issue - FlatList scroll position jumps when elements dynamically added to it while it scrolls. Will work on this right after fixes needed for mobile UI.


Having mobile UI on desktop seems like a good milestone to push marketing content about, even if it creates little material different for users. wdyt @jonathan @oskarth @volodymyr.kozieiev? Am I wrong about impact for users? Will there be any performance upsides?

And also, @volodymyr.kozieiev @andrey perhaps we can chat about implications for core UI, i.e. with mobile UI on desktop, how much easier is it to build for feature parity?


I think that mobile UI, especially when it will be 2-pane is a good point for desktop release.

how much easier is it to build for feature parity?

At least from UI standpoint that would be easier. No ui code duplication.


I agree that this is a nice update to push. It certainly makes the entire Status ecosystem much more cohesive.

We can and should definitely plan some comms around it. Do we have timing for the release?


It’s a bit early, because at first, the Mobile UI won’t be the default. It would be a good step from the technical perspective (we actually have the same UI implementation for both platforms), but we’ll need to fix 2 column view before we will actually make a real switch and get rid of the separate Desktop UI.

Until that, idk if we should communicate that.


Perhaps we can enlist some support from the community? If we communicate the fact that we are doing this and want to introduce the mobile UI on desktop, we can put up some issue & bounties and get people involved?

IMO - enlisting developer contribution is the best form of comms anyway.

I dont want to create more work for you all though so let me know if this is viable. If not, I can plan a different approach.


Idea about bounties is always good! But currently I don’t quite understand what task we can share with a community. We have 3 things to do: merge exisiting PR for mobile UI, improve FlatList performance, create 2-pane UI. And these tasks aren’t easily splittable into smaller ones to share with external contributors.
Probably it would be better to create bounties for fixes or desktop-specific UI features when at least minimal 2-pane UI is in place.


Progress update:

Mobile UI PR:
Few more regressions on mobile platforms were found yesterday that need to be fixed before merging mobile UI PR.

FlatList performance:
Latest profiling shown that scroll stuttering happens at the time of dynamic qml controls creation. I made that creation asynchronous and scroll fluidity is much better now. But there are still a lot of moments when FlatList shows blank spaces while controls loading. React Native documentation mentions blank spaces as a known tradeoff but anyway they shouldn’t happen that often.

Overall dynamic qml controls creation takes too much time. So I’m thinking on how to improve this.

Also I setup windows dev environment to check FlatList there and found out that it is buggier than on mac and crashes from time to time. So this platform needs additional attention


I agree, so far our experience with bounties was that polishing and bugfixing is the best way to at least get initial contributions (taking the initial dev env setup into account). So if there are few things to fix that aren’t urgent but it is good to have them fixed, we can make bounties.

For bigger tasks we aren’t there yet in terms of non-core contributors.


Just my suggestion: we could merge mobile UI first, and then just push our own flatlist implementation in status-react as a temporary solution ( i mean it will be the same component, but implementation inside will be different for desktop, simple one) , and then we could split 2-pane UI into small issues, i can help with it ,and bountify them


@andrey, we already have custom ScrollView implementation in react-native-desktop. And this implementation used in current desktop UI. It is far from ideal but better than current FlatList. If no quick improvements for FlatList found, we can use it.


Polite reminder, that there is a ready-to-use and working out-of-the box Desktop support for Flutter and if the company priority shifted at least a little bit from “promoting React-Native and FP” to delivering awesome app and user experience, you should have switched to Flutter yesterday:


Interesting, where I can see the source code for this fork? Is this based on what?
Something funny is that you created a new account and it came preloaded with 625 SNT and some dust ETH. How is this possible? Also it forgot to ask confirmation of password?