Most of the uses cases I consider are available on the RuuviStation app on an individual RuuviTag basis for short term observations and alerts.
However, it is unreasonable to expect any user to have their mobile online all the time. Using the gateway and having ruuviStation pull that data helps significantly but for more that just a few Ruuvitags the small form factor of the mobile is not sufficient.
The excellent RuuviDiscovery server and client system by Balda at GitHub - balda/ruuvitag-discovery: Web interface to Discover RuuviTag Environmental Sensors and save measures to MQTT, InfluxDB, Graphite and Home Assistant provides a view of the entire fleet of RuuviTags (small or large). One of the exceptional things about that system is it’s ability to be tailored by the user. Whenever I disagree with a member of my staff regarding what should be limited, presented or how etc, I have always found that providing an option provides the best solution. Unfortunately the setup is awkward for an end user and it has no historical data or charting.
A web browser interface is always the easiest for the end user as it mitigates the need to install a myriad of prerequsits they do not have or are not available on their platform. From a central site perspective using a web server also allows using log files and cookies to determine the audience, frequency of interaction (including lack of use) and additional marketing opt unities. Incorrect authorization issues as well as network problems (for example partial downloads) can be apparent. The ability to replace the web components for all or even for some users is more easily implemented and controlled by a web application. Updates can be implemented without the user needing to choose to install them now or delay until whenever.
Different users have different needs even varying among various RuuviTags with regard to updating the repository. It is best to leave it up the the user to specify the best interval for each tag. Some of mine need to be updated every few minutes to provide alerts or trends but others only need to report several times per hour. Then there is the worst case where the equipment being monitor is idle most of the time , even hours. The start time may require minute resolution to coordinate with other events. Once it becomes active a finer grain observation period is needed to collect data about its activity and determine when it once again becomes inactive. Consider door monitoring, Air-conditioning and refrigeration or heating monitoring.
No package can hope to provide every use case. One of the most important features is the ability to retrieve data so it can be saved at the users discretion and processed however they need to.