I guess in terms of the Sonos speakers, with you only having one at the moment, my question is what is the USP, must have feature that keeps Sonos top of the list?

I had never been 100% comfortable with the eggs in one basket, reliant on software out of my control when I started buying sonos again ~2020 so even as my system expanded back out to the whole house, I was keeping an eye on alternatives with a view to jumping ship. but it was a bit of a better the devil you know, while not finding a fully suitable alternative.

Unfortunately the May release just confirmed I was right not being comfortable with devices I had no real control over whether they would work as I expected or not.

In terms of the app speed I think there is more to it. I suspect the ground up rewrite was taken as an opportunity to get rid of the separate android and ios native code bases and move the whole app to a single Flutter code base. Sonos had already been starting to use Flutter for the wizards a couple of years back, which obviously meant having to integrate them with two separate code bases.

https://tech-blog.sonos.com/posts/renovating-setup-with-flutter/

Flutter like any cross platform framework has upsides and downsides though. Performance vs native apps is still a downside as far as I know, with Flutter apps being generally slower, while using more cpu and memory resource.

There are also differences in support for the underlying platform and how easy or hard it is to integrate 3rd party code. Some things are easier with Flutter, some things are harder.

I think the new ui is just a case of following current ui/ux patterns, it’s nothing unique in the current sea of apps. Although it seems to be a pattern that has been around for a few years now, so maybe the industry is about to change and Sonos will continue to lag behind and look dated 

It is a shame the interesting articles dried up on the tech blog, it now feels more like a “everyone else has one, we need a tech blog” given the way the articles slowed down.

From the initial articles around how they were changing the build/test/release lifecycle and tooling, automating some of the infra setup it looked like they were heading in the right direction.

Then you look at some of the bugs over the past few weeks and I wonder where it all went wrong getting the basics right. How did the bugs get missed by the build/test platform? Reasons I can think of don’t give me a warm fuzzy feeling of confidence about what is going on inside the engineering teams.

The poor handling of the release is easy to understand and explain. Between that and the follow up leadership responses and ama it’s the main reason I found an alternative. I still have a few speakers that weren’t worth selling which let me explore my technical curiosity about progress. Eventually the app will be mostly fixed, but I’m not going to get sucked back in again.

(1) For me it is the ability to provide clear separation between personal listening via headphones/earbuds (we use the Spotify app for this) and in-home listening on the speaker(s) where we use the Sonos/Sonophone app.  I have found that trying to use the Spotify app to control both streams very frustrating.  I had the same issue when I tried to use Apple Music to control both personal and on-speaker listening.  The Sonos paradigm seems to handle this properly, even if the current Sonos app is a car crash.

(2) I can see the attraction of a cross-application framework, but I thought Flutter was only used for the “Setup” parts of the system and that it was native frameworks all the way for the rest?  That’s what I remember from the AMA session anyway.  The lag in the volume control sounds to me like they went all-in on web based APIs for all control and the lag is probably due to network latency.  Not that it matters anyway.  The point is that there is bad lag all over the UI and the reason is irrelevant.  There is no excuse for lag anywhere in the UI.

1. While I don’t use headphones, I get that. I probably have a similar style of usage where sometimes when gaming I want music from Qobuz playing rather than the in-game background music, so use the Qobuz app on my PC, but for in-home listening use a different app (Rigelian on my tablet, so have completely separate play queues for the same AVR and music source.
   Similarly I will use the Qobuz app or browser streams on my tablet to ad-hoc airplay to a JBL Charge 5 Wifi speaker in the bathroom and bedroom speaker when getting ready and Rigelian or musiccast for normal usage, so keep separated views.
2. I reread the AMA notes and you are correct. It is still a mix of native and flutter.
   I agree there is no valid reason for lag within reason. On Apple devices it is easier, as it’s a closed hardware/software platform designed to behave in a particular way. Android becomes far harder as there are so many devices of different ages, some of which weren’t fit for purpose on release, nevermind when the user fills it with masses of apps 

Building an app which integrates with online APIs certainly requires a different, more defensive programming style to something that operates lan only and different thinking about how the ui should provide feedback when waiting for responses. Do you show a spinner until all requests complete or a timeout hits, do you progressively update the ui as different calls return for example? Both methods have their own downsides from a user perspective.

In my early days of working with online platforms it was often easy to spot developers who had previously worked primarily on lan based applications, rather than with internet integrated ones because their code would have less robust or zero checks around requests, data integrity. On a lan the chances of interruption to a request or server process was very low, but across an internet link… all bets were off 

Even now, I still often have to deal with code and systems that are only happy path tested.

Integation of realtime control across the internet has some very obvious challenges around latency. While things like websockets can help, they also bring their own set of headaches and gotchas, especially at scale. 

Even now I see products which we would have previous referred to as a product designed for the “silicon valley bubble” under the controlled and advanced setups in silicon valley they perform flawlessly… meanwhile out in the real world where the randomness of connectivity and devices is all over the place it would rapidly fall apart.

Most projects I’ve worked on have had strict requirements around things like client side timing, such as simultaneous events within milliseconds across all client devices, as “realtime” as possible blocking of access when crossing borders in certain countries.

Where I work and have worked, as the company building these things it is always our responsibility to ensure what we design, develop and release both front end and backend performs appropriately regardless of whether our users are on high speed fiber internet, low bandwith mobile/adsl networks or the device they are using. It keeps things interesting and is far more involved and challenging that the usual api integrations.