Application Performance and UX


tldr: get application entry points and screen rendering under or as close to 250ms, with a goal of 100ms rendering from user interaction.


We have a goal of the application feeling production ready by the end of Q2, so Status can support the go to market strategies of Keycard, Teller Network and the SNT Utilities.

The keyword here is feeling. We’re a consumer facing application and how a user feels, how you feel when interacting with the application, matters.

It’d be amazing if we can raise this in our collective consciousness and ensure this is continually a priority moving forward.

Timing is Everything

Status faces substantial issues in rendering screens and loading in information, below I present 4 real world examples that demonstrates some of the worst offenders from my personal experience.

When it comes to protocols and UX, Status should be delay-tolerant and ‘offline first’, decoupling the retrieval of new information from the display of information the client already is aware of, and what it knows is incoming.

When it comes to rendering screens and entering the application, latency between user input or interaction should be kept to a minimum, it seems humans are capable of identifying visual stimulus changes around 50ms, while cognitive processing for reaction to visual stimulus happens around 250ms.

While user’s upper threshold for waiting for new information is about 10 seconds.
Unfortunately we are a far cry away from any of these user expectations.

I strongly recommend everyone reads the links below, there’s plenty of recommendations. To keep things convenient for the reader here’s some quotes to demonstrate impact:

[Google found that] the page with 10 results took 0.4 seconds to generate. The page with 30 results took 0.9 seconds. Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.

In A/B tests, [Amazon] tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue.

The 100 ms threshold was established over 30 yrs ago. See:

Card, S. K., Robertson, G. G., and Mackinlay, J. D. (1991). The information visualizer: An information workspace. Proc. ACM CHI’91 Conf. (New Orleans, LA, 28 April-2 May), 181-188.

Miller, R. B. (1968). Response time in man-computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277.

Myers, B. A. (1985). The importance of percent-done progress indicators for computer-human interfaces. Proc. ACM CHI’85 Conf. (San Francisco, CA, 14-18 April), 11-17.

Real-world Examples

The below scenarios are a daily occurrence for me. This is my real-world experience, I made an attempt to preserve some privacy by blurring some UI elements, however it may not be the case that I covered it entirely and apologize in advance.

When it comes to feeling, when using Status I observe within myself strong emotions of frustration and find Status tedious to use, which is further compounded with message reliability issues and little meaningful feedback on message delivery. I probably wouldn’t use Status if I wasn’t working on it, nor do I expect others to.

Cold Boot & Initial Sync

First Impressions matter, opening Status is the most important entry point to get right, this is still quite slow (regression?), It takes 13 seconds from opening Status to rendering the initial chat list. The rest of the video is syncing and does not complete, this time the syncing took over 15 minutes with auto-mailserver selection.

App-Entry from Push Notifications

The next important entry point into the application is from push notifications.


It takes 13 seconds to render the wrong UI elements, an additional 7 seconds to provide an error (which has persisted for some months and doesn’t seem to impact the display of chat history, as I get this frequently). I left the application recording for 15 minutes without ever seeing the message.


40 mins apart from the previous recording I attempted to view a new push notification.

Here it takes 9 seconds to render the wrong UI elements, an additional 8 seconds to show offline state and error. 27 seconds to show the message, and not the chat history.

Here we should be displaying the chat history and a placeholder for the new incoming message.

Slow-Rendering of Chat History

From opening a chat from chat list, it takes about 2 seconds to render the most recent page of chat messages.

Application Switching

Not recorded, but when switching the application from background to foreground on Android there is a consistent syncing period and the application is slow, even when there is no meaningful change to application state.

Bonus Points

  • Notice the sync bar animation jitter, while I don’t know how it’s implemented, could this animation be offloaded to the UI thread somehow? Are there more instances of this?

  • Redraws. @roman already did some excellent work on this and proved that redraws matter, the list scrolling performance has improved substantially. There are still many red patches in the application and it would be nice to minimise this further if possible.

  • the 9+ icons are essentially meaningless to me

  • i often never receive push notifications for new messages

Accountability & Responsibilities

It would be great if UX, QA and Core swarms, in that order, took on the responsibility to be accountable for ensuring that these issues and others like it are permanently resolved before the end of Q2.

I strongly believe that improving this will make Status a much more enjoyable experience and help users be more forgiving in our other shortcomings.



Switching between chats on desktop (mac) and iOS has felt delayed compared with other messengers I have grown used to. On desktop clicking on to another room or conversation takes nearly 1 second from click to updated view.

On iOS it’s also nearly 1 second before the conversation is visible. I noticed on something like whats app the conversation is already rendered when the animation is sliding in, while on Status the window is blank during the animation. Practically one can’t really read much while it’s sliding in, but it does make it seem faster if the conversation is rendered in the window sliding in. I also think the slide in animation speed on Status is slower than on messengers like whats app.

I think it was a smart move by whats app to make the slide in animation slightly faster than the iOS default messages app because it makes it feel like whats app is faster than the default messages app.


This is some painful stuff to watch. For reference here, some factors I think we should investigate:


  • Network and connectivity management (fetching of information, time outs, etc.)
  • Memory management
    (I put my beloved Fairphone to rest as I kept struggling with memory issues and could no longer even get past the loading screen)
  • GUI performance (optimizing framerates)
  • Input responsiveness (Are we optimally using React Native touchables)


  • GUI performance (loading states, empty states, user controlled fetching)
  • Input responsiveness (specifying component states of all tap and touch events)

I’ll set up a kick-off call on how each of these factors and others might impact the issues @jarradhope described and have been reported elsewhere.

Meanwhile, I’m in the dark when it comes to the engineering side, not my area of expertise. If anyone has strong suspicions on where we can improve. Please ping me.

Can’t find a recent reference, but am pretty sure system performance has a proven effect on human performance, comfort and satisfaction through heart rate increase. So agreed, this is a big deal.


With regards to

I ran across these in and noticed this in another PR in progress

This has been in the back of my mind recently, and I do not exactly know how to improve it yet, but leaving this here as a side note.


This is fairly shocking. I’m having much better load times on iOS, though if I haven’t synced in some time it’s much slower. But when I open a conversation, for instance, it takes less than 1 second.

I do have issues with chats syncing out of order, which is disorienting when switching devices.

the 9+ icons are essentially meaningless to me

The issue with 9+ icons for unread messages is on the front-end Core UI backlog and meant to be tackled in Q2 as part of the mark all as read feature, which would allow users to pick up where they left off in a public channel and then jump to bottom. The problematic behaviour for me there is that the 9+ badges do not clear properly once a conversation has been viewed. Is that also what you’re referring to @jarradhope?


Thanks for the detailed report, use cases and numbers. Thought I’d quickly partially replicate it as another data point:


Phone: iPhone XS Max 10 / Honor 8 / Samsung Galaxy S8
Version: Recent (iPhone) / latest stable (Android)

Parameters: Phone / Chats / Last sync / Test case

Method: Ad hoc, counting seconds

Cold Boot & Initial Sync

iPhone XS Max (~50 chats; last sync: few minutes ago)

Cold boot: 3s to initial chat list
Initial sync: ~3.5s sec (just synced a few seconds ago)

Huawei Honor 8 (3 popular public chats with no history; first sync)

Cold boot: 6s

Initial sync: 30s+ (network bound? I could interact with chat earlier though)

App-Entry from Push Notifications

Didn’t test

Slow-Rendering of Chat History

iPhone XS Max (~50 chats; last sync: few minutes ago)
<0.5s (need to measure precisely for better granularity)

Huawei Honor 8 (3 popular public chats with 24h history; synced)


Application Switching

iPhone XS Max (~50 chats; last sync: few minutes ago)

Essentially instant

Huawei Honor 8 (3 popular public chats with 24h history; synced)

Almost instant

Caveats and improvements

Things I didn’t do that it’d be great to see more data points on:

  • Android phone didn’t recover old account with lots of state
  • Didn’t test push notification flow
  • Didn’t test with other Android device (i.e. Samsung Galaxy S8) or older iPhone (i.e. 6)
  • Ad hoc measurement, so to get finer touch need to measure either with stopwatch/frame/profiling tool.


Essentially replicated on old Android device, cold boot time especially is ridiculous. General sluggishness on Android. More data points from e.g. QA cc would be useful.

Would love to see a plan from Core on how we plan to attack these more in detail, starting with low hanging fruits and biggest problems.


so the device I run these examples is a Huawei M5 8inch Tablet (yes I know tablets aren’t supported its just an android phone with a larger screen calm yo self)

It has a HiSilicon Kirin 960 processor, 4GB memory and a Mali-G71 MP8 GPU, state of the art in 2016. I`m not sure how useful the old/new distinction is considering our ui complexity, processor should be fine for decryption) and every other app performs wonderfully on it.

I have ~120 chats, and 10 dapps. and 100mbps download speed.


I think we will start with the cold startup and mostly focus on Android, looking at the numbers.

Also this slowness of syncing looks very suspicious, but it might be mitigated by switching protocol parsing to status-go (but that needs to be confirmed).

And I guess we will start with replicating the conditions, making a test account with around ~120 chats and similar specs like Huawei M5. I think we have a bot that can make a decent history for these chatrooms.



Here is a quick investigation

As you can see on the picture, we have one js thread and when a user presses a button, we:

  1. register re-frame event in a queue
  2. run all events in a queue
  3. calculate ALL active subscription functions (currently ~100!!)
  4. calculate all active render functions
  5. parse hiccup convert to js

Low hanging fruits

  • inspect all subs on performance
  • make more efficient subscriptions tree
  • find out why we calculate not visible render functions and subscriptions (i believe it’s because of react-navigation)
  • inspect events, optimize or split

Hight hanging

  • move events and subs in separate js thread, because of re-frame arch it should be doable, so in main thread will be only user action events
  • find out how realm impacts performance, because we need to convert message data many times, and save it encrypted in realm, i believe it would be much more efficient if we could store messages with status-go

Currently, we react on any change in app-db, and there maybe subscriptions with calculations, so we need to improve our subscriptions graph,
first node must be map only with keys which impact subscriptions, next, one subscription for each key in this map, and next subscriptions related to these keys

re-frame has a solution for events. it suggests to split calculations in small functions, and we used this before, but for some reason, we decided to use our own solution with fx/merge where we merge all small event functions in a big one, and this may lead to performance issues, for example, if you’ve received a lot of messages you need to filter them, sort etc, save in realm, all in one function, maybe we could find a compromise here and split it for example for such events like messages

Screens rendering
Currently, we calculate all screens even if they are not displayed, maybe we could find a way when we could keep them in react but don’t calculate subscriptions and render functions for them

PS: 5 steps above happen for each event, for example when you type a text in the input field, for each char we calculate all subscriptions and views renderers


I am not sure about this, subscriptions that take other subscriptions as input should only render if those subscriptions have changed afaik

that would be a nice effort, similar to events, I would be in favor of putting all subscriptions to first level keys in app-db in one file and use them as input for other more complex subscriptions.
such an effort would also include diagnosing poor design of app-db with top level keys that should rather be nested to reduce amount of recomputations

I disagree with splitting events, more on this in response to your other paragraph.

while I agree with this, the simplest and more efficient solution might actually end up being the current effort to move chat protocols to status-go. if status-go stores messages and returns them per chat and in order with a comprehensive API we could avoid the most expensive computations on status-react side.

already commented above, I think we are thinking roughly about the same thing

strongly disagree with that statement, fx/merge is about

  • composability
  • transactional events which cancels out if an error occurs instead of partially changing app state as it would happen with a small chain of events, they also avoid unnecessary recomputation of subscriptions.
  • the fx/merge actually often do little work and are mostly about returning a map of effects, which are going to do the actual work. for instance saving in realm is done outside of the event.

Keep in mind that there is overhead to dispatching events, events dispatch within another event only run next tick, but those dispatched at the same time all render during the same tick. After events are computed there is a check to app-db. fx/merged is saving a lot of time by merging changes to realm as well.

Now sorting and filtering the messages especially in big chats is a big deal and not really related to fx/merge, it will take 99% of the computation time regardless of how much fx/defn are merged within the event. So the actual effort should rather be put into finding a solution to that problem, either by offloading this work to another thread (but it has its own complications), using status-go for that, or putting more effort into alternative datastructures such as the ordered persistent hashmap which could be leveraged for more caching and less sorting.

(parenthesis re-frisk really doesn’t like custom datastructures and my repl is often wrecked by millions of lines of exceptions such as

                       java.util.concurrent.ThreadPoolExecutor$  624
                        java.util.concurrent.ThreadPoolExecutor.runWorker 1149
                 clojure.core.async.impl.channels.ManyToManyChannel/fn/fn             channels.clj:   95
                                         clojure.core.async/do-alts/fn/fn                async.clj:  252
                                          clojure.core.async/ioc-alts!/fn                async.clj:  383
             clojure.core.async.impl.ioc-macros/run-state-machine-wrapped           ioc_macros.clj:  977
                     clojure.core.async.impl.ioc-macros/run-state-machine           ioc_macros.clj:  973
              taoensso.sente/-start-chsk-router!/fn/state-machine--auto--               sente.cljc: 1529
           taoensso.sente/-start-chsk-router!/fn/state-machine--auto--/fn               sente.cljc: 1529
                                    taoensso.sente/-start-chsk-router!/fn               sente.cljc: 1527
taoensso.sente/-start-chsk-router!/fn/state-machine--auto--/fn/inst-17988               sente.cljc: 1541
                                  re-frisk-sidecar.core/event-msg-handler                 core.clj:   70
                                       re-frisk-sidecar.core/eval18744/fn                 core.clj:  111
                                                       clojure.core/swap!                 core.clj: 2345
                                                          delta.cljc:   94
                                                      delta.cljc:   84
                                              delta.cljc:   80
                                                      clojure.core/reduce                 core.clj: 6748
                                              clojure.core.protocols/fn/G            protocols.clj:   13
                                                clojure.core.protocols/fn            protocols.clj:   75
                                       clojure.core.protocols/iter-reduce            protocols.clj:   49
                                           delta.cljc:   80
                                                   clojure.core/update-in                 core.clj: 6092
                                                   clojure.core/update-in                 core.clj: 6106
                                                clojure.core/update-in/up                 core.clj: 6105
                                                       clojure.core/apply                 core.clj:  659
                                        delta.cljc:   80
                                                          delta.cljc:   94
                                                      delta.cljc:   84
                                              delta.cljc:   80
                                                      clojure.core/reduce                 core.clj: 6748
                                              clojure.core.protocols/fn/G            protocols.clj:   13
                                                clojure.core.protocols/fn            protocols.clj:   75
                                       clojure.core.protocols/iter-reduce            protocols.clj:   49
                                           delta.cljc:   80
                                                   clojure.core/update-in                 core.clj: 6092
                                                   clojure.core/update-in                 core.clj: 6106
                                                clojure.core/update-in/up                 core.clj: 6105
                                                       clojure.core/apply                 core.clj:  659
                                        delta.cljc:   80
                                                          delta.cljc:   94
                                                      delta.cljc:   84
                                              delta.cljc:   80
                                                      clojure.core/reduce                 core.clj: 6748
                                              clojure.core.protocols/fn/G            protocols.clj:   13
                                                clojure.core.protocols/fn            protocols.clj:   75
                                       clojure.core.protocols/iter-reduce            protocols.clj:   49
                                           delta.cljc:   80
                                                   clojure.core/update-in                 core.clj: 6092
                                                   clojure.core/update-in                 core.clj: 6106
                                                clojure.core/update-in/up                 core.clj: 6105
                                                       clojure.core/apply                 core.clj:  659
                                        delta.cljc:   80
                                                          delta.cljc:   94
                                                      delta.cljc:   85
                                                       clojure.core/merge                 core.clj: 3033
                                                       clojure.core/merge                 core.clj: 3040
                                                     clojure.core/reduce1                 core.clj:  926
                                                     clojure.core/reduce1                 core.clj:  936
                                                    clojure.core/merge/fn                 core.clj: 3041
                                                        clojure.core/conj                 core.clj:   85
java.lang.IllegalArgumentException: Don't know how to create ISeq from: com.cognitect.transit.impl.TaggedValueImpl

I think relying more on local state especially for input fields would already save us a lot of subscriptions and events, we can pass a validation function for those fields that require some validation, it doesn’t have to be done through an event

Overall I would be very much in favor of having only one subscription per screen, which is composed of subscriptions with a focus on minimizing recomputations


thanks Eric for your answer

yes, i wrote it not exactly how i meant, but anyway i tested it with 10x, and it’s from ~60 to ~100 subscriptions by one event are run when many screens are active, because of react-navigation when you leave the screen, subscriptions remain active for it

that’s true, but maybe we could find a way how to run them in a separate tick, just as a low hanging temporary solution, for example split them and dispatch-later

i’ll try to find a time once again to look at that

that would be great!


We went through the excruciatingly difficult decision to ditch React Native and move to Swift and Kotlin code bases.

I cannot tell you how much I despise React Native. You cannot even construct a performant table view with 100 cells.

I wish you all the best as you try to speed up Status.


Are they actually computed or just active? Also just like events some subs are fairly quick to compute. For instance if you just patch together a bunch of other subs it’s just going to be a few assoc


I’m wondering if this is more an issue in how react-native is being used?

As someone who has mostly used react-dom, I know this can be an issue where rendering cells for all available data will lead to poor performance over just rendering the cells that come into view. There are solutions to deal with this issue like

Have you tried optimizing react’s rendering before migrating away?