I put this in the same category that the mini-player hasn’t been updated to make it work better when overlayed over video, and that now - at least for me - it only works correctly over Firefox - no longer Chrome or Safari.
AI FTP detection is nice, but doesn’t really make any difference to me. But what would would be a modern Workout Creator that allows you to create workouts that automatically switch between ERG / Slope, and a better mini-player optimized to be overlayed over full screen video.
Sure they do In both cases, you want to look for the “kind” column. I’m on an Intel Mac. The newer M1 Macs mostly likely have “Apple Silicon” listed for M1 native apps.
You worked for ARM?!? How cool is that! What did you do there?
There are a few separate problems when you use cross-platform development tools, and not all of them are performance-related.
Cross-platform APIs almost always imply that you develop for the lowest common denominator and discourages from using platform-specific features. E. g. an obvious API TrainerRoad should have adopted eons ago is Apple Health. It could automatically update your weight (if you log it with Apple Health or have something like a Withings scale that does that for you). It could ingest other health-related metrics like sleep, resting heart rate, activity in zone. E. g. it could detect that you went on a hike the day before and adapt your workouts.
Cross-platform APIs lead to UIs that feel non-native on the platform. Some companies sell that as an advantage, because your app works the same independently of the platform you are using. Although I feel most of the time they think of design as how it looks rather than how it works.
Electron specifically has a performance overhead, although all cross-platform frameworks do to some degree. With Electron you are quite literally running your app’s UI in a browser. This doesn’t just yield an overhead, but also has a cost in responsiveness. Especially touch-based interfaces feel broken if the delay is too large. The performance overhead can manifest itself in ways that common users notice, e. g. reduced battery life or bad responsiveness of buttons.
Cross-platform apps are much larger and have much larger updates. That is because you need to ship all cross-platform libraries with your app. Even updates, which on iOS can only ship the deltas, are quite large because e. g. your cross-platform framework has been updated and you need to ship the whole thing.
Cross-platform frameworks take time to adopt platform-specific features, they are at least 1 year/generation behind. For example, iOS and macOS allow the display’s refresh rate to adapt to the situation. This is to save battery life.
But the massive benefit is cost reduction. Sometimes massive cost reduction.
As a company you hire developers who can work on electron… Otherwise you need full groups dedicated to each individual app.
You mention apple health. Well… I think Google and Samsung have their own platforms for health too… Maybe I want TR to use it (i don’t). But this is even more money .
Small companies like TR survive early on with cost cutting measure. They can’t make everything we want. Nate has mentioned in the past, and it was a gigantic thread a while ago, how he would like to charge more so he can hire more people and do even more things. Base on all the feedback this was not taken well by a huge amount of people…
I would love to have a native app… And leverage all the tools available for me on my devices. But you know, i rather have all the new things they have done in the last 24 months… Like ai ftp, train now (will use it today), training levels (also using to help me pick a proper Wo), adaptive training, and thing that will be added later like showing training data of runs and swims… This are things that probably 90% of users want and also will actually notice and use.
There will be many users who will notice and use native apps and integration to apple, window or Android specific health apps. But that’s is much smaller group.
I don’t think the request is unreasonable, but OP actitud is not the best. I would invite him to the swim/run thread that has been active since 2018. People get mad and keep asking for it. But they don’t call all the other features added useless (like OP did with AI ftp). We don’t get into arguments when someone tell us there are other, and bigger fish to fry. And finally we are getting what we been asking for. It only took 4 years of people asking…
Maybe when TR joins Z we will get native gaming graphics that use more battery… Imagine a 3d rendered blue graphics with background that changes as time goes we are show motivational graphics on hard intervals…
Currently, TR has at least two code bases (desktop and mobile).
And I am not sure whether the cost reduction is as big as people think it is on paper. Or that they factor in all the costs. It is certainly doable for a small software company to write several different versions based on distinct code bases.
I give you that cross-platform tools Electron are an easier sell and the path of less resistance.
I wouldn’t compare Apple to Google and Samsung here. For one, Apple has the Watch. And even if you have non-Apple gear, most integrate with Apple Health. Apple not only has a functioning ecosystem around this already, it also has (in terms of money) the most valuable customers.
Thing is, I know of counter examples. One is Algoriddim’s DJay. The core devs are acquaintances of mine. They make a pro level DJ app. To give you an idea, they won an Apple Design Award and were presenting on stage at Apple events. But they are a small team, about 10 people when I met them last. (I’m just saying that they aren’t just some random tiny software company.)
Initially, they were Mac-only, but they brought iOS apps to market. Then Windows and Android. I can’t speak for what they did to transition to Windows, but the Mac app and iOS app had separate code for a good portion of the app (since they have completely different UIs). Like TR they also support a host of hardware devices. A lot of the under-the-hood stuff was surely shared.
Like I said, I don’t know what they did for the Windows and Android versions, so perhaps they have some shared cross-platform code. Although I sorta doubt it, audio code is super sensitive to latency and has to be written low-level. They also have a bunch of ML-based features that I don’t think are feasible with cross-platform code.
So it is definitely possible. However, you have to keep in mind that these people are high-level software geeks with excellent knowledge in audio and practical DJ experience, whereas TR probably attracts a different crowd (cycling geeks).
And this is a good point. However, I wouldn’t underestimate the added friction and limitations you have during development since you are cross-platform.
Currently, I’d settle for getting the features back that I had in the previous version of the mobile app (reviewing my intervals and adding annotations) and a functional calendar.
Is this true? Apple has always been stingy when it come to let other integrate with their products. I know Google health just suck in everything from everywhere similar to Garmin and Strava… So maybe that’s what apple does? Not super familiar with that since I don’t use is. And i suspect the Vern diagram of apple health and TR users is rather small… Maybe because there is no integration but also probably because there is no real interest… I have seen a request to support this (maybe there is I just really don’t know)
Sure. The dj app is a very single purpose app… It’s an app that relies 100% on the front end and what it does. TR is not comparable. They have backend , which one could argue is the most important part, and the other is the front end which one could argue is the least important part. They are probably more concerned about making sure backend stuff is great while the front end get the minimum to keep it going. They have probably very little interested in the front end… Since that not what they are trying to do…
TR and z are the best way to see it… TR care about the data… Z cares about the looks… Z probably have teams working on individual clients for all supported platforms… Because that’s what they care about… Same as your friends company. Their engineers work and put money on what is important for them… Front end.
I think you are very wrong on this point. My bet would be that the venn diagram of TR users and Apple Health users is probably pretty high % of the TR iOS user base. Even though TR doesn’t support Apple Health, TrainingPeaks does, so I use Apple Health as a gateway to get info into TrainingPeaks. TR is either going to have to write integrations itself, or better integrate into a hub, if it wants to progress from an analytics perspective. Right now, the only thing I can track in TR is cycling workouts, and even with that, it doesn’t have any tools that allow you to draw even the most basic conclusions - e.g., how many hours have I done in the last month / quarter / year; how many workouts have I successfully completed; how many workouts have I completed (success or not); etc. Let alone allowing me to track all of the workouts - e.g., run, walk, strength, swim, etc. - that impact me.
Keep in mind… It’s been more than 4 years since users ask just to get swims and runs in… Yet we are still waiting… And that’s core users right there…
My point if TR users and apple health users was related to people actually actively asking for integration not people who would use it if it was available to them…
There is a difference.
In any case… My point doesn’t change…
TR is not interested right now in investing in doing natives apps. Yes it can be done. Integration with other things can be better. The apps could use more tlc. The workout creater ffs. That’s a hot garbage.
But right all, most of their eggs are on the analysis side of things and most of their efforts and money are for that… It’s a fact and there is not much we can do… We all can ask and fight and argue about semantics and shit that doesn’t really matter… At the end… It is what it is. You either use the tools they give us and enjoy the analysis of things or we whine and bitch and at the end nothing will change…
I actually think the inability of TR to important swim / run / etc. and parse the FIT files speaks to inflexible architecture decisions made early on. At a minimum, TR should be able to easily import any activity type, parse the FIT file, and display it on the calendar. Given that doing this seems to be a big lift, implies that a lot of TR was built assuming the only workouts would be cycling, and fixing this means rebuilding / designing some core TR functionality.
A perfect example of this is Nate’s explanation of amount of recoding that was need to change from a binary gender (the original code was basically male true / false) to a more inclusive. And that this recoding was in multiple places, that all had to be hunted down and fixed.
Given the number / length of requests, if they have the data, but they can’t display it to end-users, more confirmation of my point: there’s a bunch of hard-coded bits in the way that the calendar works.
Absolutely.
They made choices early on, as most programs do, and now they have to deal with the changing market…
This is not a TR only problem. It’s a very common industry problem. They create the solution for their problem and now they are trying to apply the same solution to different problems and they are probably having issues adapting…
No, Apple’s Health is used ubiquitously by other companies. My Withings scale integrates into Health, Myfitnesspal (which my wife uses) does, too. Wahoo and Strava upload data to Apple’s Health, too, as does Strong, a workout app. I reckon Garmin does, too. You can grant read and write access separately and for separate data fields if you want to preserve your privacy. It really works well. The nice thing is that it acts as a central repository with information that is not obtainable from each of the apps separately. E. g. my Withings scale would not have to integrate into TR, Wahoo, Strava, etc. separately, just once.
DJay does integrate with cloud services like e. g. Spotify and it does have a ML/AI component. As an app, it is much more complicated, because it relies on a lot of time-sensitive operations that need to be optimized for each platform.
You are right that TR needs to develop a sophisticated backend, too, and I mentioned that already. There is a tendency I noticed among many companies (think Netflix) that think their competitive advantage is what is on their servers, and that is true. Another, even worse example are business apps, where usually nobody cares about the end user. But user satisfaction is still in large part determined by the face of TR, which are the apps.
How many e. g. video apps do you love? Do you love the Youtube app? Or the Netflix app? I use both a lot, but I hate both even though I like the services.
You have a point but IMHO make a big mistake: good design is not how it looks, but how it works. I can list a ton of issues that have nothing to do with how TR does something, but basic functionality that is simply missing on the mobile apps. I cannot do a lot of the calendaring. Yes, I can schedule and delete workouts. But I don’t think you can drag and drop workouts around or long-press to get to a menu. I can no longer check whether I hit my power numbers or add annotations.
And I think the most important limitation is the lack of proper performance analytics. I. e. how do you display changes in performance in a way that is relevant and understandable to TR’s athletes? A lot of TR’s future problems are related to how it presents the data obtained from AT to its users.
I think we agree that TR front end is hit great and a lot can be done…the disagreement might be on how strong we feel for the need for change. I don’t have strong feeling because I don’t use many of the front end features.
I am aware that this is not a battle I’ll win. Using TR’s app often frustrates me to no end, because I have to go back and forth between the website and the app.
For example, choosing an alternate workout is much easier in the app than on the website. But scheduling additional workouts and moving workouts around is much easier on the website.
You don’t use the calendar, for instance?
One important distinction, though: @Nate_Pearson has mentioned multiple times on the podcast that they would like to integrate HRV data, sleep data and other activities when adjusting workouts that are part of a plan. Just last week, @Jonathan gave an example: suppose you spend Sunday hiking for 12 hours, then you might want to drop your workout intensity back to Achievable for the next one or two workouts. If you want to do these features, I think you really need Health integration.
You can’t even do research on these features using methods from ML if you don’t have this data in the first place. So at least in this instance, I am talking about a feature that TR actually really seems to want to implement.
Yeah, technical debt is a big issue, and there is a tendency to put layers of patches on the problem rather than write something new from the ground up. I wouldn’t be surprised if the calendar has these issues, which make the implementation of new features like Adaptive Training hard. E. g. it is currently not clear which workouts are adaptable and which are not.
Just stay on the same schedule as those apps since it’s a similar binary. Problem solved.
In both cases, you want to look for the “kind” column. I’m on an Intel Mac. The newer M1 Macs mostly likely have “Apple Silicon” listed for M1 native apps.
