Suunto App Update

[DMytro]

@sartoric so others can suffer XD

[Dimitrios Kanellopoulos]

Hey guys. An issue is preventing us from releasing Android atm. Sorry about that.

[LitchiMonster]

@dimitrios-kanellopoulos No stress, thanks for the update. Hope it works out! Next week it is then

[Frederick Rochette]

@dimitrios-kanellopoulos So we will have the update for iOS before

[Łukasz Szmigiel]

@dimitrios-kanellopoulos the update is simply so good that you’ve managed to break the Android.

[A Former User]

@dimitrios-kanellopoulos said in Suunto App Update:

Hey guys. An issue is preventing us from releasing Android atm. Sorry about that.

Nothing to be sorry, better that way than releasing with known bugs Hope iOS get it sooner

[Tomas5]

@Dimitrios-Kanellopoulos just from curiosity, why Suunto doesn’t use flutter so it can release exact same app on iOS and Android and developing just one app. There wouldn’t be differences between released apps for different OS. And since less work (only one codebase), developers could focus more on new features and bug fixes.

I just know people using flutter, newer used it by myself so maybe there is good reason to not use it for this usecase.

[Dimitrios Kanellopoulos]

@tomas5 flutter is just a framework. Can’t do things like maps , Bluetooth etc.

Also flutter is new. Not ready for iOS (performance issues see it’s tons of debate on the net).

Flutter became popular 1 year pretty much ago.

We do use multiplatform libraries though. Backend iOS and Android share quite a ton of codebase.

To give you my personal view on anything nowadays that uses some kinda “common” framework: see electron apps. It’s not better in performance from native.

To cut a long story short , technically , we are not there for such a big app that needs Bluetooth, maps , charts etc. Those are not flutter things.

[Tomas5]

@dimitrios-kanellopoulos thanks for explaining, i was guessing something like that.

[Dimitrios Kanellopoulos]

@tomas5 we are moving towards a similar solution. That is also part of my work.

I work on kotlin multiplatform libraries for Suunto

So for example when we create an algo that simplifies routes better , it can be used in both platforms.

[DMytro]

@dimitrios-kanellopoulos will this algo include paths of T4 difficulty? Those are currently completely omitted by SA.

[Dimitrios Kanellopoulos]

@dmytro t4?

[DMytro]

@dimitrios-kanellopoulos it’s swiss hiking difficulty scale:
https://www.bergfreunde.eu/alpine-grades-calculator/

Basically every “very difficult”, exposed hiking path, easy scramble route and via ferrata.

Probably isn’t the best idea to default the routing through theese, but maybe if “difficult terrain” toggle is switched or something. Or at least if manually taped on, because right now it’s only possible with free drawing.

[Aleksander H]

@tomas5 about three years ago I worked on a react native app which primarily controlled settings on a BLE device. We spent a lot of time writing native code and then bridging code so we could call it from the javascript layer because very much of what we had to do was platform dependent. Sure, the GUI and the business logic was reusable across platforms, but the increased complexity just wasn’t worth it in my opinion. We also hit quite a few issues with third party libraries not playing nice with each other resulting in some very hard to understand stack traces. I know colleagues on other projects have had similar experiences. Such frameworks definitely have their uses, but their not always the right choice.

Things might have changed a lot in three years though, and I’ve never tried Flutter. I’ve been working Java EE backend since then, so not really up to speed on mobile dev anymore.

[Dimitrios Kanellopoulos]

@dmytro the simplification happens when there are a lot but a lot of points. I am not sure about t4 but I would assume it all comes with compromises. My point is that the algo is now better

[TheGuyFromTheSummit]

@dimitrios-kanellopoulos any news for us?