Liftosaur: Weight Lifting Tracking App - Blog

How to start weightlifting

2021-01-17T00:00:00Z

Super short and simple starting guide for the folks who want to start weightlifting.

To get stronger and look better, you essentially need 3 things:

Lift heavy weights
Eat well
Sleep enough

To get started:

Go to thefitness.wiki, read articles about muscle gain in general and about diet.

Then, if you have access to gym with a barbell and a power rack (recommended!)

Read about Fitness Basic Beginner Routine.
Google for videos how to make the exercises from there with a proper form. Like "How to bench press with proper form".
Go to Liftosaur, select "Basic Beginner Routine" program, and start training.

If you don't have access to gym with barbell, but at least have dumbbells of various weight and some sort of bench:

Read about Dumbbell PPL program.
Google for videos how to make the exercises from there with a proper form. Like "How to dumbbell chest press proper form".
Go to Liftosaur, select "Dumbbell PPL" program, and start training.

That's it. It's that simple. Whole initial reading and videos watching would probably take like 1 hour. And then you'll spend around 40-60 minutes in gym about 3 times a week.

How I came to weightlifting

2021-01-30T00:00:00Z

Photo by Victor Freitas on Unsplash

The idea of starting to workout was in my head for a while. Everybody says - once you hit your 30s mark, it's better to start taking care of your body. Otherwise, you may not get to the moment when you could finally enjoy your 401k.

I also wanted to look better, more fit (and who wouldn't?). It's common knowledge that the best way to achieve that is, well, gym!

The problem was - how to start? Gym seemed intimidating - there're various machines, there're dumbbells, kettlebells, barbells - how do I know which to use, how do I know I use them properly?

Bodyweight

So, I put aside the gym idea and decided to start with bodyweight exercises. I really liked the idea of bodyweight exercises. There was something in the approach you only use your own body to get stronger. Elegance and simplicity of it attracted me.

I googled a bit and found the book of Mark Lauren - "You Are Your Own Gym". It had good reviews on Amazon, and there was a nice phone app that would tell you how to do exercises and what they should be. There were 10-week programs, it all looked fun, so I started working out three times a week, using the phone app that accompanies the book.

In about a month, my motivation started to go down. I began to skip workouts, and in about one more month I finally quit. I only went til the 8th week.

The workouts in that app were pretty challenging for me, but the biggest issue was - I wasn't feeling I was getting stronger. Bodyweight exercises are pretty hard to progress on. The idea is that you progress by switching to more challenging versions of exercises (like you start with incline push-ups, then horizontal push-ups, then decline push-ups, then one-arm push-ups, etc.), but the difficulty bump when you go from one version to another is so big, it's hard to actually make it.

At the end of the 8th week, I was pretty disappointed - the workouts didn't get any easier, I was exhausted after each workout, and I didn't feel I got stronger. My motivation finally died, and I quit.

Now I realize two months are not really enough to see any progress, but back then, I was expecting magical transformations in my body, and when I didn't see them, I got quite frustrated.

I thought I'd look at least like this after 2 months

Weightlifting

One year passed. I write software for a living, and I was reading Michael Snoyman's blog - he mostly writes about the programming language Haskell, but he also had a set of blog posts about lifting and health.

I find those kinds of articles very trustworthy - fitness is not what he sells, it's just his hobby, and he's also a software engineer, so I find his experience very relatable. After reading those articles, I was very pumped and decided to start weight lifting as well. He recommended Stronglifts 5x5 as a simple weightlifting program to begin with, and I decided to give it a try!

I read the site, read the exercise descriptions. It all made sense, and it was quite simple! The idea is that you do the so-called 5 "compound" exercises (they work a wide range of muscles of your body) three times a week, increasing weights each day. The exercise descriptions were veeeeery long and very repetitive though, he was repeating the same things and the same principles over and over and over again - no wonder there're like 20 thousand words per each exercise. But if you google something like "How to do deadlifts" you'll get some good videos at the top of search results explaining how to do those with proper form within 3-5 minutes.

Then, I had to choose a gym. I had Anytime Fitness, LA Fitness, and Planet Fitness in 15-minute drive distance around my house, and Planet Fitness was an obvious winner because it was cheap as peanuts - $10 per month! I was going to visit it first, and if it doesn't work for some reason - visit Anytime Fitness and LA Fitness.

Planet Fitness surprised me quite a lot. The gym itself was huge, it got all those fancy machines, but there was no single barbell! No power racks, no squat racks. Even no dumbbells. But rows and rows of empty treadmills, I think five smith machines, some other weird-looking equipment... Stronglifts program required a power rack and a barbell, so I had to pass on it.

Seriously, why so many treadmills?!

LA Fitness was even bigger. It was a massive 2-story building with a pool, basketball court, tens of treadmills again, and two power racks with barbells, with a line of 3 people for each... The chance of staying in line for bench presses like it was in 2010 for iPhone 4 was not super exciting, so that was a pass too.

Anytime Fitness was a cozy small gym with not-so-cozy pricing. There was one squat rack and one power rack though, two barbells, a rich set of dumbbells. And the main thing - there were no people. I was alone. The whole gym was empty. At 5pm. On Tuesday. That means it's empty pretty much all the time. That was a big deal for me - to ensure I won't lose any time staying in line and waiting while somebody is hard working on their curls staying in a rack. I got my wallet and subscribed for a year.

I started to visit the gym three times a week, strictly following the Stronglifts program. It was definitely way more fun than "You are your own gym". It was maybe too easy first (since you literally start with an empty barbell), but that would give me time to adjust, get into the habit of visiting the gym, work on proper form. But the most fun part was that I felt progress. At first - every day, then maybe every week, or even every couple of weeks, but my numbers went up and up. I saw that upwards graph in the Stronglifts phone app. Each time the weight I lift goes up, it feels like a little win, and it gives me that endorphin shot. This is addictive. I find it very hard to keep myself motivated for long-term goals - like I will look great if I keep doing this for the next 2 years regularly. I mean - yes, probably, but if not - I'll have hundreds of hours spent on nothing. And that suspicion eats you. But here - you successfully completed your 5x5 of bench press - done, you got your weight bump for the next workout - you feel a win. And it's awesome.

In about three months, I hit my first deload (when you have to reduce the weight on a barbell because you couldn't accomplish 5 sets of 5 reps for an exercise). But still, I was able to progress. In about three months more, I hit a plateau and just kept deloading and getting to the same level, not being able to increase weight anymore.

At that time, I was at:

185lb squat 5x5
150lb bench press 5x5
105lb overhead press 5x5
130lb barbell row 5x5
260lb deadlift 1x5

By that time, I was already reading a lot of articles related to weightlifting, was hanging out on /r/fitness, and found probably the best introduction into weightlifting - thefitness.wiki. I really like how short and to-the-point is all the material there. On Reddit, people mostly criticized Stronglifts 5x5 for being strongly skewed towards squats, and at the same time - praised 5/3/1 programs by Jim Wendler for being a balanced program. thefitness.wiki recommends 5/3/1 for Beginners as a starter, so I picked it up.

It worked great! I liked that the pace is slower, but you steadily keep increasing weights every three weeks instead. I got used to Stronglifts 5x5 app though, it was simple yet very convenient - it increased or decreased the weights when appropriate, had all the necessary functionality. But it was designed specifically for Stronglifts 5x5, and you can't adjust it to any other program.

Liftosaur

I wanted to find an app I could use for a long time, even if I change programs. I wanted to be able to tweak programs if necessary and couldn't find anything like that. Other apps were either designed for one specific routine (GZCLP, 5/3/1, etc.) or had a pack of popular routines, but none gave full flexibility in program editing. And it makes sense - to make it possible, you have to have full-grown, Turing-complete programming language built-in. I could do that. I'm a software engineer, so I can write an app with a built-in specialized programming language that allows you to express any possible weightlifting program. It will be shipped with popular weightlifting programs and will provide UI to make simple modifications in the routines. But, if you want to create something entirely new and nothing like before, you can always get to the lowest level and use the scripting language - Liftoscript!

After about six months of building it during my spare time, it resulted in Liftosaur! I use it for tracking my lifts since April 2020, and it goes great (though I'm obviously biased). It also motivates me to keep working out since I could think of some feature, then implement it in the app, and then try it out during my own workouts.

I now have a way better picture of what it takes to start weightlifting, and if I started today, I'd probably start with the Basic Beginner Routine and would follow the thefitness.wiki advice to switch to 5/3/1 for Beginners or GZCLP after three months (I wrote about it in my last blogpost)

Lifting weights is super fun. You feel powerful when you lift heavy weights, and you get your little wins pretty often. It's fun to chase numbers (the weight you lift, the reps you could do, etc.). There're many health benefits too, but it's hard to quantify them, and they look more like long-term goals, which I have a hard time to really care about. And you're looking better and better in the process (though that transformation is very slow, it takes years to really see the difference, so again - more like a long-term thing. If you see somebody sells you a three weeks program promising you'll look better at the end - it's a scam, you won't).

So, here I am, 1.5 years in for now, and hopefully, it's just a start.

Quirks of building a PWA app

2021-02-05T00:00:00Z

I wanted to build a weightlifting tracker app that would be like Stronglifts 5x5, but flexible, so you could build any program in there or modify any program for your needs. And it'd still be a user-friendly, pleasant to use app. And it'd have all the features you expect from that kind of app - progress view, graphs, rest timer, plates calculator, etc.

I write web apps for a living. I'm not a mobile developer. I knew that you could write web apps for mobile phones (they're called PWA - Progressive Web Apps), and then you can install them without App Store or Google Play, and theoretically, they'll be exactly like native apps.

There's also something cool, from idealistic point of view, in writing web apps and running them on phones (vs native apps). Web a is free and decentralized platform, I don't need to rely on Apple Store or Google Play rules, web apps exist kinda in parallel with the Apple/Google gate-keeped stores, and don't have to play by its rules. Also, the update cycles are way faster - I can just push the new version out, and it will be immediately delivered to users' devices, I don't need to wait for a week until my new app version is reviewed by Apple or Google. It's not like the main reason why I wrote PWA, though - the main reason is that I'm just very comfortable with building web apps, I know how to do it. I'm way less comfortable with building native apps.

But I also heard that you would never reach the same user experience as with native apps, though I wasn't sure why. What exactly would prevent that? I was curious to know, I thought - I'm going to write this app as a PWA specifically targeted for mobile devices and experience the development process, see what road bumps I could hit, and how far I could go before I hit a wall.

And here I am, nine months later, with a working PWA app, which is already pretty feature-rich, and I think at this point I can reflect on the development process and share my thoughts about PWAs and what it takes to develop them.

What the heck is PWA?

Liftosaur is a PWA. What that really means is that it has a manifest file and a script, that runs as a Service Worker - special JavaScript code, that is run by a browser separately from a web page, in a background. We add a link to our manifest file in index.html like this:

<link rel="manifest" href="/manifest.webmanifest" />

and then we load that service worker script like this:

navigator.serviceWorker.register("/webpushr-sw.js");

and voila! Our web page just became a Progressive Web App!

The manifest file describes how your app will look like mostly on phones - what icons would be used, whether it's full screen or with a URL bar, title/description, what splash screen looks like, etc.

The service worker script currently mostly solves two problems:

Caches all the scripts, styles, and some API calls so that the app would work offline.
Sets up Web Push mechanism, so you'd get pushes when the timer is triggered, and it's time to start another exercise set.

And that's mostly it! After that, you can add that web page to your phone home screen, and it'll like a native web app.

This is what it looks like on the home screen (last icon)
This is what PWA app looks like on iOS

But there are various problems associated with PWAs, related mainly to iOS Safari quirks and users' knowledge about PWAs.

Pain points

Mostly, my experience with building PWA - you can build decent PWA apps, though Mobile Safari definitely will try to make your life harder. I didn't really have any problems with Google Chrome on Android; the app works smoothly even on a cheap Android device. The major pain points were:

Cookies are weird on iOS when you add your app to the home screen

I initially set the app so that index.html and all other assets were loaded from www.liftosaur.com and served via Cloudflare CDN. API lived in Cloudflare workers on a separate domain, which used to be liftosaur.workers.dev. Some API expects the user to be logged in, so I had liftosaur.workers.dev/api/signin/google, which sets up a JWT auth cookie on the liftosaur.workers.dev domain. I don't need those cookies for the primary domain www.liftosaur.com (they're HttpOnly anyway, and I use them for API calls only). I thought it'd be fine - the cookies would live only on liftosaur.workers.dev, the browser would send them to all API endpoints (since they're also on liftosaur.workers.dev), and everything would just work. And it worked, almost everywhere - it worked in Mobile Safari browser, it worked in Chrome on Android. But if you add the app to the home screen on iOS, then for some reason, those cookies wouldn't be stored. Like, at all. I finally found a workaround - I stored the cookies with the .liftosaur.com domain and moved the API from liftosaur.workers.dev to api.liftosaur.com, so they'd share the same cookies with www.liftosaur.com. But it took me quite a while to figure that out.

No web push notifications for iOS

There's a feature in the app - after you've finished a set, you press a button, and it starts a timer. Once timer hits some threshold, it sends a push notification to your phone, so you know it's time to start another set. Apparently, there's no way to do that on iOS. I couldn't find a way to send a push notification in iOS, at all. It seems like a possible solution would be to install a "helper" native app that would proxy the push notification, but that seems excessive - I really doubt any user would want to do that!

You can trigger a sound only on user action

When the timer mentioned above hits a threshold, it plays a sound, so you know - it's time to start another set. I couldn't figure out how to do that on iOS. Safari on iOS only allows you to play a sound in e.g. an event click handler. If you try to play it on some random event happening (like for me, it was a Redux action triggering it), Safari complains about audio autoplay being forbidden. There're some solutions on the Internet/Stack Overflow, but none of them works. Apparently, if a user is done with the set and hits a button, you can start setTimeout and try to play the audio inside that setTimeout. It works, but only for small enough timeouts (like several seconds). Anything over a minute - and you get that audio autoplay forbidden error again.

I couldn't figure out that too for iOS. Liftosaur on iOS doesn't send push notifications when timers hit a threshold, and also it doesn't make a sound when it happens :(

iOS could be pretty aggressive unloading from memory the opened PWA apps that are added to the home screen

Imagine you just finished a set, and you switch to Twitter to read some stuff there while resting. A couple of minutes later, you switch back to Liftosaur - and iOS already unloaded it from memory, so Liftosaur loads again. So you need to make sure your app launches fast, and also you store as much internal state as possible in IndexedDB. Otherwise, users may have a horrible experience losing all their progress.

To be fair, it got better after iOS 13, and it's not as aggressive with unloading PWAs from memory anymore, but it still happens sometimes.

Missing some default gestures

There're some gestures built-in into any native app. Like swipe left to right across the screen gets you back to the previous page. Obviously you don't get them for PWAs, since it's just a web page.

It's not that big of a deal to implement those, but you have to implement those, and on a native app, you get them for free.

I personally don't use gestures much on my phone apps, but I can see how it could be a UX issue for some users.

Choose your app icon wisely because it will stay forever

If you add a PWA app to your home screen, whatever the app icon was, it will be there forever. Even if you update the manifest with the new icon, the icon won't change on the home screen. Not that big of a deal, but it definitely was an unpleasant surprise.

Users have no idea what the heck PWA is

And here's our winner!!! The major pain point of PWA is the users' knowledge. They don't know that a web page they're on is a web app they can install to their home screen. They don't know how to do that (and frankly, iOS Safari doesn't even try to make it obvious). They often even never heard of PWAs at all. They don't know PWAs exist and they can add a web app to their home screen.

To add to home screen on iOS, you need to Share (!) first
And there find the option "Add to Home Screen"

So, you need to deliver the installation instructions to your users somehow. Since there's a good chance they've never installed a PWA previously in their life, there're high chances that this PWA will be their first one, and they are going to figure out how to do that.

It is already hard to convince somebody to install an app. Convince somebody to install a web app is ten times harder if they never did that, and they don't know it's possible.

To be fair, if you use a web app several times on Android Chrome, and it's a PWA, Chrome will suggest adding it to the home screen once it notices you use the app often. iOS Safari will not.

In my opinion, this is the worst pain point of PWA. Technology-wise, and especially on Android - you can make very decent phone apps, and get the user experience very close to native apps. But the people aspect - educating users about PWAs and how to install them - is way harder.

Here's a bright side, though - Google Play allows you to publish your PWAs right in the store. It's called TWA (Trusted Web Activity), and that makes the PWA installation process look exactly like a native app - you can find it in the Play Store, click Install, and it will get installed, just like a regular app. Obviously - nothing like that exists on iOS.

PWA in Google Play Store

To build TWA, you'll need to ensure you get maximum PWA points in Lighthouse, and then you can use PWABuilder, that will generate Android APK, which you can upload to Google Play Store.

Conclusion

You definitely can build quality PWAs. You usually won't have any problems on Android, and you'll need to jump through some hoops for iOS. Some things are impossible to do on iOS at all. And be prepared that users don't know anything about PWAs, so you'd need to educate them about it somehow - that means your marketing will be harder.

Offline mode in Liftosaur

2021-03-04T00:00:00Z

One of the most significant benefits of PWA apps is enabling offline mode for your apps. You can set up caching in a service worker, and then if there's no Internet, the service worker returns the bundles and maybe even API responses from the cache. There're tons of tutorials on how to set it up, but caching is just the tip of an iceberg. You have to structure your whole app around offline mode if you really want to get a seamless experience without the Internet. That's hard.

Here I'd like to share how I did offline mode for Liftosaur. It's not perfect, and it still has its flaws. But it mostly works fine, only occasionally maybe possibly breaking user experience.

What do we need to do to make it work offline

Basically two things.

We need to cache bundles (HTML, CSS, and JS), so if there's no Internet, we could fetch them from the cache.
We need to sync our in-memory part of the state we want to preserve to some local storage and optionally sync it to the cloud when the Internet is available.

That's about it. But there're caveats.

Caching bundles

We can use a service worker for caching bundles, intercept all the network calls from there, and cache the bundles and maybe the API calls we care about. There're a million tutorials on the Internet on how to do that. It's probably the most popular usage of service workers.

For initial load, Liftosaur loads its bundles from the Internet and caches them. They are:

index.html - the main page, where we render our whole app.
main.js/css - the main bundle with all the logic included and styles for it.
vendor.js/css - all third-party libraries: CodeMirror, Preact, io-ts, etc.

Those are the files that are absolutely necessary for the working app. There're also others - Webpushr for push notifications, images of muscles and exercises, Rollbar for error collecting, and so on. If they don't load - the app works without them with some degraded functionality, some of them we cache anyway, but they're not that important.

It's a good idea to versionize your bundles, so you could cache them forever, and not be afraid of accidentally serving stale versions of bundles. I.e. you load the bundles from your index.html like:

<link href="main.css?version=123" rel="stylesheet" type="text/css" />
<script src="main.js?version=123"></script>

If we store our bundles on Amazon S3, it ignores the querystring params when returning the stored objects, so ?version=123 is ignored. But it's not ignored by CDN, browser cache, and the service worker cache. When we bump the version to 124, it misses the cache both on CDN, browser, and the service worker and returns the actual version of the bundle.

For a version value we simply use a Git commit hash. In Liftosaur we do that via Webpack's DefinePlugin:

// webpack.config.js
const { DefinePlugin } = require("webpack");
const commitHash = require("child_process").
    execSync("git rev-parse --short HEAD").toString().trim();

module.exports = {
  // ... various webpack settings
  plugins: [
    new DefinePlugin({
      __COMMIT_HASH__: JSON.stringify(commitHash)
    }),
    new CopyPlugin([
      {
        from: `src/index.html`,
        to: `index.html`,
        transform: (content) => content.toString().
          replace(/\?version=xxxxxxxx/g, `?version=${commitHash}`),
      }
  ]
}

So, this way, we'll add the __COMMIT_HASH__ variable to the bundle. When we copy index.html to the dist directory, we also replace ?version=xxxxxxxx with proper git commit hash.

In index.html, we import the bundles accordingly:

<link href="main.css?version=xxxxxxxx" rel="stylesheet" type="text/css" />
<script src="main.js?version=xxxxxxxx"></script>

In the service worker, we need to set up fetching the bundles, index.html, and handle caching. The logic for caching the bundles and index.html is different:

For bundles, since they're versioned, we can cache them forever. I'll just need to remove the old versions from the cache from time to time
For index.html, we don't need to return the cached version of it. We need to ensure the user gets the freshest version of it all the time. Unless the user is offline. In that case - return the cached version of index.html.

So, the service worker looks like this:

// sw.ts

// __COMMIT_HASH__ will be filled in by a webpack bundler
declare let __COMMIT_HASH__: string;

const cacheName = `liftosaur-sw-${__COMMIT_HASH__}`;

const urlsToCache = [
  `/main.css?version=${__COMMIT_HASH__}`,
  `/main.js?version=${__COMMIT_HASH__}`,
  `/vendors.css?vendor=${__COMMIT_HASH__}`,
  `/vendors.js?vendor=${__COMMIT_HASH__}`,
  "/index.html",
  "/",
];

async function cacheRequestAndResponse(request: Request, response: Response): Promise<void> {
  const cache = await caches.open(cacheName);
  await cache.put(request, response.clone());
}

async function requestAndCacheAllUrls(): Promise<void> {
  const cache = await caches.open(cacheName);
  await cache.addAll(urlsToCache);
}

// Fetches all the time, caches it, but never returns
// the cached version if user is online
async function handleFetchingIndexHtml(request: Request): Promise<Response> {
  const cachedResponse = await caches.match(request);
  try {
    const response = await fetch(request);
    await cacheRequestAndResponse(request, response);
    return response;
  } catch (err) {
    if (cachedResponse != null) {
      console.error(err);
      return cachedResponse;
    } else {
      throw err;
    }
  }
}

// Checks cache first, if there's no cached response -
// fetches the request and caches it
async function handleFetchingEverythingElse(request: Request): Promise<Response> {
  const cachedResponse = await caches.match(request);
  if (cachedResponse) {
    return cachedResponse;
  } else {
    const response = await fetch(request);
    // If the url is one of the urls to cache -
    // cache request and response
    const isCacheableRequest = urlsToCache.some((url) => {
      const url = new URL(request.url);
      return `${url.pathname}${url.search}` === url;
    });
    if (request.method === "GET" && isCacheableRequest) {
      await cacheRequestAndResponse(request, response);
    }
    return response;
  }
}

// When the browser installs the service worker for the
// first time, we'll request all the bundles and cache them
service.addEventListener("install", (event) => {
  event.waitUntil(requestAndCacheAllUrls());
});

// We intercept all fetch requests from a browser,
// and apply our logic to handling those
service.addEventListener("fetch", (e) => {
  const url = new URL(e.request.url);
  const isIndexHtml = url.pathname === "/" || url.pathname === "index.html";
  if (e.request.method === "GET" && isIndexHtml) {
    e.respondWith(handleFetchingIndexHtml(e.request));
  } else {
    e.respondWith(handleFetchingEverythingElse(e.request));
  }
});

// Every times service workers activates -
// check for old caches and remove them
self.addEventListener("activate", async (event) => {
  const allKeys = await caches.keys();
  const keysToRemove = allKeys.filter((k) => k !== cacheName);
  for (const key of keys) {
    await caches.delete(key);
  }
});

That is a rather long code listing, but it basically implements the logic we described above for bundles and for index.html.

Then we need to make sure to set proper Cache-Control headers. Since the versioned bundles are immutable, we can safely set the expiration time to a year. So, all the versioned bundles (main.js, main.css, vendors.js, etc) are served with Cache-Control: public, max-age=31536000, immutable. For index.html though, we need to ensure it's always fresh, so we set Cache-Control: max-age=0 for it.

This covers the part when we serve the app's code, even when the user is offline. But we also need to handle the local state part.

Adding local state

When a user interacts with the app (for example, progresses through the workout day), we update the global state in memory and sync the changes to the server. When the user refreshes the page, we fetch the state from the server. This way, the user's data won't be lost.

In case there's no Internet, there's a chance user could lose the data because we can't sync it to the server. It makes sense to sync it to some local storage too, so that if there's no Internet, the user won't lose the data. It also helps with data privacy - if the user is not logged in, no data is stored in the cloud, everything lives just on their device.

But now we have two problems:

The code may change, and it's expectations of the state shape also may change. That can lead to runtime exceptions when we try to load local or cloud data.
Local storage data and cloud storage data may change independently. For example, user may use the app on the phone without the Internet. Then they come home, open the app on the laptop, and use it there, then open the app on the phone again. At that moment, we'll load the data from the server, and if we blindly rewrite the local storage with cloud storage, the user may lose data. We practically have distributed system here now and should figure out how to resolve merge conflicts.

Database migrations

Let's talk about the solution to the first problem - changing code expectations of the state shape.

The codebase and the state are not synced. We can often get an older local state with the newer codebase. For example when there's a new feature released, the codebase may start to expect a different state shape. Like, we used to specify weight as a regular number. Then we added a new feature for switching between kilograms and pounds, so now we store the weight as {value: number, units: 'kg' | 'lb'}. But the local state and the cloud state of our users still have the weights stored as numbers! The user gets a new bundle, it expects the weight to be stored as an object, and that mismatch causes an exception. That easily can crash our app during the boot time, causing a white screen, a completely broken app, and frustrated users.

Humanity figured a solution for this problem - the database migrations.

I learned it when I was working with Ruby on Rails, and it's an excellent concept. Sometimes when you make modifications in the codebase, the expectations of the data store changes. Like, in some database table, you had a field name, which was a string, but then you decide that you should have first_name and last_name stored separately instead and updated the codebase for that. After that, you create a migration that has a version and the executable code to convert your table to the new state (with two separate name fields), and also you define how to rollback (i.e., switch back from two separate name fields to one). It could look like this:

{
  "version": 1,
  "migration": [
    "ALTER TABLE users ADD first_name varchar(255)",
    "ALTER TABLE users ADD last_name varchar(255)",
    "UPDATE users SET first_name = name",
    "ALTER TABLE users DROP COLUMN name",
  ],
  "rollback": [
    "ALTER TABLE users ADD name varchar(255)",
    "UPDATE users SET name = first_name",
    "ALTER TABLE users DROP COLUMN first_name",
    "ALTER TABLE users DROP COLUMN last_name",
  ]
}

Version is a monotonically increasing number.

The database stores its current version. When you try to run migrations, it will run them in the order defined by its versions. For example, the current version is 2, and you defined new migrations with versions 3 and 4. So, when you run migrations, it applies migrations 3 and 4.

You can also rollback the migrations and run rollbacks in reverse order. Usually, it's necessary when you published code that broke some functionality, and you want to revert changes. Then, you deploy the previous version of the code and run rollbacks in reverse order - first 4, then 3.

In a Ruby on Rails app, the process is usually the following:

You change the codebase
If the codebase's state shape expectations changed, you add migrations
You deploy the app
You run migrations

Local state migrations

In our case, things are somewhat more complicated. We do have continuous access to the databases, but we don't have access to the user's local storage state. So, we can't run migrations on the user's local storage state at an arbitrary point in time.

As a solution, we can move the migrations to the client code - to the JS bundles. And then, when a user opens an app, we will:

Get the local storage state, and run migrations on it.
Fetch the storage state from the cloud, and run migrations on it.
Merge the cloud state into the local storage state.
Upload the updated, merged state back to the cloud and to local storage.

For the server-side generated pages (for example, the shared workout results or the public profile page), the algorithm would be:

Fetch the data from the database
Apply migrations
Render the page, and for hydration - send the migrated data to the client inlined as JSON in the HTML.

I like to handle the local storage as a main source of truth and don't try to migrate the data in the database before I try to run migrations on the local storage. The reason - in case something goes wrong during running migrations on the local storage state or during merge, and it throws an exception - I want a chance to fix it. If I separately apply the same migration in the database, and it goes well there, but it fails locally - reverting the database migration could be hard.

I don't have rollbacks in my migrations (yet?), but they could be implemented. Though it's way harder than with the regular database migrations. When running migrations, they may fail in different places for different users since users maybe have different versions of the states.

For now, if some user has issues with the migrations, I just try to fix it asap by adjusting migrations or creating new ones - i.e., always going forward.

Implementation details

So, this is how it looks like in code. Liftosaur has a global state in memory, and the part of the state we want to store locally and in the cloud lives in the state.storage field.

There's the state.storage.version field, that stores the current version of the state. For simplicity, for a version, we use the current datetime in yyyymmddhhmmss format, like 20200929231430.

For the local storage we use IndexedDB, which has horrible API, but it's asynchronous and not limited by 5MB like window.localStorage.

Initially, we check if the local state is presented - by querying IndexedDB. If it's there, we fetch it and pass state.storage field into our migration function. That looks like:

interface IStorage {
  version: number;
  // ... other fields
}

// List of all migrations
const migrations = {
  // Each migration key is version and some descriptive name.
  "20200929231430_split_name_into_first_and_last_name": async (storage: any): Promise<IStorage> => {
    storage.firstName = storage.name;
    storage.lastName = "";
    delete storage.name;
    return storage;
  },
  // ...
};

async function runMigrations(storage: IStorage): Promise<IStorage> {
  // Ordering migrations by version
  const keys = Object.keys(migrations);
  keys.sort((a, b) => parseInt(a, 10) - parseInt(b, 10));

  // Figuring out what versions we should run for
  const newVersions = keys.filter((versionStr) => {
    const version = parseInt(versionStr, 10);
    return version > storage.version;
  });

  // Run the migrations
  let result = storage;
  for (const version of newVersions) {
    const storageCopy = JSON.parse(JSON.stringify(result));
    result = await migrations[version](storageCopy);
  }

  // Storing the last version as the new storage version
  result.version = parseInt(keys[keys.length - 1], 10);
  return result;
}

As I said above, it only can run forward; it doesn't support rollbacks.

Then, we fetch the storage from the cloud and also run it through migrations. Now we have local storage and cloud storage with the same version. We can merge them now.

For merging local and cloud states, it's tricky to do automatically. The logic is different, in some places it makes more sense to combine two arrays; in other cases - prefer one or another.

For example, it makes sense to combine workouts made both on the cloud and locally. But if, for example, user changed the available plates both locally and in the cloud, it doesn't make sense to combine both. We may end up having duplicate plates.

Ideally, it could be solved with special data structures called CRDT, where log changes separately on cloud and locally, and then replay them for merging. But that would complicate things significantly.

We're assuming that most of the time, users will use Liftosaur locally while offline, so usually, the local state is newer and more actual than the cloud state. With this assumption, we can combine workouts and some other parts, and for other stuff prefer local state as a source of truth.

So, like this:

function mergeStates(localStorage: IStorage, cloudStorage: IStorage): IStorage {
  return {
    version: localStorage.version,
    settings: localStorage.settings,
    // Concatenates two arrays, using date as unique key.
    // I.e. if both oldStorage.history and newStorage.history
    // has record with date == '2020-08-03', then the newStorage's
    // record with that date won't be added
    workoutsHistory: CollectionUtils.concatBy(
      oldStorage.history,
      newStorage.history,
      (record) => record.date)
    ),
    // ... etc
  };
}

Obviously, there're cases where this approach will work poorly, and users may lose some changes they did, for example, on the laptop while the phone was offline. For Liftosaur (since it's mostly a phone app), this should be pretty rare, so we sacrifice correctness in favor of simplicity here.

After the states are merged, we save the merged state in IndexedDB, and send the new state to the cloud. And from now on, we keep syncing the state into IndexedDB and cloud on each state.storage change.

Conclusion

That's about it! Implementing offline mode made me scratch my head a bit while doing all those migrations and configuring service workers. But once all the groundwork is done, I don't really have to think about it anymore while adding new features to Liftosaur. I just add new migrations from time to time and update the merging function.

Tailwind CSS colors in Chrome Devtools

2021-03-06T00:00:00Z

I like to prototype designs or experiment with UI right in the browser. For Liftosaur, I use Tailwind CSS to style the app. What I was really missing is the ability to specify the colors from my Tailwind CSS theme in devtools.

Apparently, it's pretty easy to add them though. You probably have a tailwind.config.js file in your project directory (if not, just create it with module.exports = {};). Then, you could use a script like this:

const resolveConfig = require("tailwindcss/resolveConfig");
const tailwindConfig = require("./tailwind.config.js");

const fullConfig = resolveConfig(tailwindConfig);

let output = ":root {\n";
for (const key of Object.keys(fullConfig.theme.colors)) {
  const value = fullConfig.theme.colors[key];
  if (typeof value === "string") {
    output += `  --${key}: ${value};\n`;
  } else {
    for (const colorKey of Object.keys(value)) {
      const colorValue = value[colorKey];
      output += `  --${key}-${colorKey}: ${colorValue};\n`;
    }
  }
}
output += "}\n";

console.log(output);

And run it like:

$ node tw.js > colors.css

It will generate a file with a bunch of CSS variables with colors from your theme. Copy the contents of colors.css to your app's CSS file. And you'll be able to use those in devtools:

How I moved Liftosaur from Cloudflare Workers to AWS Lambda

2021-06-22T00:00:00Z

TLDR; - I moved Liftosaur from Cloudflare Workers to AWS Lambda + Dynamo. It wasn't easy, especially it was bad because of poor local development environment. I built a skeleton to simplify that process for other folks who'd need to start a project in AWS - https://github.com/astashov/aws-cdk-lambda-typescript-starter.

Everything started with Cloudflare Workers

When I initially was choosing a hosting for server-side part of Liftosaur, I decided to go with Cloudflare Workers. I liked the idea - you write a service worker, and then run it in a cloud. And there was a bunch of other benefits too:

There's a KV (key-value) store as a database, which should be good enough for start
It integrates well with Cloudflare CDN
It has a way to store secrets (like API tokens, keys, etc)
There's a local dev server, that emulates the production environment
And it's $5 per month flat, which seems quite affordable
Built-in cache mechanisms, which you can access via Service Worker's Cache API
Separate production and development environments

But once I began to use Cloudflare Workers for realz, and deploy stuff into production, I quickly started to hit roadblocks:

That KV store is very limiting. It is what it is - a key-value store. So, no secondary indexes, no range queries. No easy way to even get all records in a collection - you can get collect all the keys, and then fetch values by each key one by one, but that's very slow.
Because there're no secondary indexes, you have to create separate collections in KV store that works as indexes, and manually maintain the consistency between those manual indexes and the source of truth. It quickly becomes very complicated and hard to maintain.
There're no good ways to do backups for the KV store. I tried to create a cron task in Cloudflare Dashboard, that'd call a specific endpoint each day, which would try to fetch all the records from the KV stores and save them on S3, but that quickly became incredibly slow.
Since the app is essentially a Service Worker running in a cloud, you cannot use any Node libraries. That was a big blocker. For example, I needed to create dynamically generated images with workout results when you share your workout in social media. I couldn't find a non-Node image manipulation library for that. I eventually created an AWS Lambda that does just that, using a Node library jimp, then exposed it via public REST API, and called that API from a Cloudflare Worker.
There's a limit of 1MB for the script you can run in a Cloudflare Worker. There's a built-in CLI, that bundles all your code with dependencies into one bundle and uploads it to the Cloudflare Worker. At the time when I migrated to AWS, my Cloudflare Workers bundle was 900kb, and it was starting to concern me - I could hit the limit very soon.
Local dev server is pretty nice, but it crashes constantly! You have to restart it all the time. It's pretty annoying.
You have almost no monitoring, and logging is weird - you can only tail logs, but cannot really access old logs. That makes debugging pretty challenging.
It enforces Webpack for bundling, it uses it internally. It's maybe not a big deal, but I wanted to switch to esbuild to make my builds faster, and couldn't do it for the server code.

Eventually, all that became unbearable. I was planning a big new feature (add Friends, Likes and Comments), and building all of that on such limited KV store was pretty difficult. Also, backups worked poorly, and that was super concerning - I definitely didn't want to lose users' data and not be able to restore.

Moving to AWS

I began to think where I could migrate Liftosaur to, and still pay no more than $5 a month. Would be nice to have a richer set of features, and especially decent database, backups, logging and monitoring. I already had some parts in AWS (e.g. lambdas for the image generators for social media), so decided to check if AWS would address some of the aforementioned issues.

To stay under $5 a month, in AWS I had to use on-demand payment policies, since Liftosaur traffic is pretty small. Any relational database costs way more than that, but e.g. document database DynamoDB could be within that price range. Moreover, it supports queries, secondary indexes, backups each second (sic!), there's built-in monitoring and logging. To run the server code, EC2 instances were a bit too expensive, but on-demand Lambdas are pretty cheap. Another benefit is that they're pretty similar to Cloudflare Workers (except they're regular Node apps, not Service Workers apps) - you don't have to manage the actual instances. Also, they come with logging/monitoring via Cloudwatch out-of-the-box.

AWS Lambdas has a concept of layers (something similar to Docker ones, I guess?), so you can move all the node_modules into a layer, and the actual size of your server code would be significantly smaller. And for caches, I could just use S3 for now.

So the setup I ended up with is something like this:

Still use Netlify for serving statics (CSS and JS bundles). Though that's probably me being lazy, there's nothing preventing me to just move it to S3.
All API is moved to AWS Lambda, and all data is stored in AWS Dynamo, and various caches are in S3

I use AWS CDK to describe all the infrastructure I have in AWS. That was the first time I learned about CDK, and wow, it's really amazing! It is somewhat similar to old AWS Cloudformation. But if you ever tried to write Cloudformation YAML files, you're unlikely had very good time. Likely, it was very BAD time. Those are multi kloc YAML files, that are very verbose and very hard to write. It becomes even worse when you have to describe business logic in those YAML files, so you write variables and if/else branches in YAML - it's just as bad as it sounds.

That new CDK tool still generates those YAML files, but allows you to describe the infrastructure in TypeScript instead. So, you'll get autocompletion, typechecking, easier API discovery and all the good stuff that a typesystem gives us. Also, using an actual programming language for describing business logic is way nicer. I highly recommend to give it a try, there's a pretty cool workshop to get some taste of it.

One thing that Lambdas do poorly though is a local development environment. There's a product in AWS called SAM (Serverless Application Model). It has CLI to run the lambdas locally, sam local start-api. So, you can generate a Cloudformation YAML from the CDK file. Then, that command - sam local start-api - will read the YAML file, and based on it will start a local server, that will run your Lambdas in a container. You'll be able to make API calls to it, and it will execute them inside a container.

The biggest caveat is that the SAM local dev server is slow. No, this is not enough. It's SLOOOOOOOOWWWWW. It seems like it restarts a container on every request, and then does I-dont-know-what, but for any call that really should be like 300ms, you end up with 10 seconds request time.

Also, there're other issues - e.g. you cannot use "nameless" Dynamo tables, because if you omit the Dynamo table name in the CDK template, then the local lambda and the lambda in AWS assume different names for some reason. Also, by some reason the binary outputs don't work (e.g. if I want to return image/png from a lambda call). It ignores isBase64Encoded flag by some reason, and local lambda just returns Base64 output, instead of binary.

Luckily, you don't really need to run everything locally via sam local start-api. Lambdas have their own format of requests and responses, but it's pretty easy to simulate it and just convert e.g. regular requests/responses of built-in Node http module into Lambdas' specific ones. That's what I did - wrote a simple Node server and that request/response transformer, and it works perfectly - it's fast, it reloads on any code changes. And it's very simple, so easy to add or modify it if necessary. And it solves the SAM local lambda's issues, like unability to use nameless DynamoDB tables, or returning binary responses.

I created 2 environments via CDK - prod and dev, each with their own lambda, dynamo tables, S3 buckets, etc. Dev environment also has its own subdomain. When you run the server locally, it connects to the dynamo tables/S3 buckets from Dev environment, so when developing locally you interact with those, and don't mess with production databases.

Another nice thing that I'm paying only ~$2.5/month for all of this now, so seems like a pretty good deal.

Starter skeleton for TypeScript/React projects on AWS Lambda

Migration to AWS wasn't that easy. I had some experience in AWS before, but mostly around EC2s, not Lambdas. It took me a while to figure out how to properly setup the infrastructure, how to describe it all in CDK, how to make it as cheap as possible for a low-traffic site like Liftosaur, how to set up local development environment properly, and multi-environment development in general.

To help other folks with that, and provide some template for cheap hosting on AWS Lambdas, I created a starter skeleton for the TypeScript/React projects on AWS Lambda and Dynamo. Here it is:

https://github.com/astashov/aws-cdk-lambda-typescript-starter

There, you can find:

Minimal CDK template for the AWS infrastructure, optimized for simplest and cheapest (but still very performant) setup for low traffic websites.
Fast and reliable local development environment - a server that restarts automatically and instantly on code changes. It regular Node's built-in http server for handling requests, and uses esbuild to blazingly fast compile/recompile the project - in less than a second.
When you run the CDK script, it also deploys the app itself, and uploads CSS/JS bundles to S3 and CDN.
It's a skeleton for NodeJS + TypeScript + React + server-side rendering support (SSR)
Has multiple environments - so you can test the changes in development environment first, before deploying it fully to production. Development and production have separate S3 buckets, lambdas, databases, a separate domain, etc.
Super easy to attach a public domain purchased via AWS Route53
Super easy to attach a certificate created via AWS Certificate Manager.
Serve the CSS, JS bundles and HTML from the same domain, to not worry about cross-domain issues. But still serve CSS and JS from CDN, to not sacrifice app performance.

IMHO it's pretty convenient for various small-traffic websites, pet projects, etc - you can start from it, and modify the CDK template if necessary to add more services if necessary (like email services, queues, etc).

So, try it out, hopefully you'll find it useful!

Workout planner inspired by the software development tools

2023-07-09T00:00:00Z

I recently finished a bunch of books on weightlifting programming, such as Art of Lifting and Science of Lifting by Greg Nuckols, and The Muscle and Strength Training Pyramid by Eric Helms, Andy Morgan, and Andrea Valdez. These are excellent books that introduced me to the world of weightlifting programming. They delve into the details of how to approach creating your own weightlifting programs, tailoring them to your needs and goals.

However, building a program is a complex task. You need to balance numerous variables, such as:

Ensuring you have enough sets per muscle group.
Ideally spreading out work on muscle groups throughout the week.
Ensuring you have enough volume, but not too much volume (based on your training age).
If you're building an intermediate or advanced program, you probably want to include week over week periodization, undulating volume and intensity, and splitting the block into mesocycles, etc.
Things would be different if you're training for strength or for hypertrophy.
And there are a lot of other parameters to keep in mind as well.

If you're just starting to get into weightlifting programming, it's a lot to keep in mind. Surprisingly, I couldn't find any tool or app to assist with this (although I could be bad at googling).

It's not an easy problem to solve though. Need to think through UI and UX of such tool, so that it'd be easy to use, and you'd have all the information in front of you, and you could easily tweak it. Would be also cool to be able store the programs you build too, and adjust them when you progress or when your goals change.

Getting inspiration from software development tools

The software development industry has decades of experience in developing tools for writing programs. A weighlifting program shares some similarities with a software program. For example, we have pretty formalized hierarchy - a weightlifting program consists of weeks, a week consists of workouts, a workout consists of exercises. Each exercise consists of:

Sets x reps (or reps range)
RPE (Rate of Perceived Exertion) value - basically how close you should be to failure
Weight (although it may not be necessary in program planning, and could be replaced by RPE)
Rest time
Additional properties (like tempo, if it's a superset, etc)

We can come up with formalized syntax to describe a workout. For example, each line would be an exercise in a workout, and various properties (sets x reps, RPE, etc) would be separated by slashes. For example:

Bench Press / 3x5 / @9 / 180s
Shoulder Press / 8+ @9 180s, 3x5 @7 60s
Bicep Curl / 3x8-12 / @8 / 90s
... etc

So, we start with the exercise, then after slash we have sets and reps. We can group them together like 3x8, or we can list them separately by comma, like 2x8, 6, 4. AMRAP sets would be suffixed by +. We can add RPE (via @ symbol) and rest time (by suffixing a number with s) - either to each set, or globally apply to the whole exercise if we add them to separate section separated by slashes /.

The order of sections within exercise doesn't really matter, could be 3x5 / @9 / 180s or @9 / 3x5 / 180s or any other order.

Having the whole workout as a plain text has a lot of benefits - we can freely copy/paste it, quickly change it in any text editor, it's easy to read and it's condensed and brief.

In software development, there're a lot of tools that help with writing code - code editors that would colorize the syntax so it's easier to read it, auto-format the code, show various hints and information when you place a cursor on specific words. I think we could get inspired from those tools, and build something similar for weightlifting programming.

Designing a tool for weightlifting programming

So, I opened Figma, and tried to come up with a design for such tool. I think it could look something like this:

And this is description of various sections:

So, the main part is the workout text field. We type the exercises, sets x reps, RPE, etc there, according to the syntax described above. The editor highlights different sections/parts in different colors to simplify reading.

When you type there, it'll show up the autocompletion with the exercises. You can autocomplete by exercise name, but also by target/synergetic muscles and muscle groups.

At the top, we can switch between different weeks, name a week and name each workout. It shows approximate time the workout would take (based on rest times, number of sets x reps, if there're any supersets), and also the approximate number of calories it'll burn.

On the right of the workout text field it shows the Week stats. There, you could see the total number of sets, and also distribution between strength and hypertrophy sets (based on number of reps). Also, you see the number of sets per muscle group, and the distribution between push, pull, upper and lower exercises.

In the set distributions, the format is: 4 (2s, 2h), 2 days, meaning it's 4 sets total, 2 sets are strength, 2 sets are hypertrophy. 2 days is frequency - meaning how many times per week you train that muscle group. Muscle groups are clickable, so you can add exercises targeting specific muscle groups to the workout by clicking on them.

While scrolling all the workouts of the week, the week stats are sticky, so you can always see them.

The set numbers are colored in red, yellow or green, based on whether you're in the recommended range. You can define the range in Settings, with some presets, like 10-12 sets per muscle group for novice, 13-15 for intermediate, etc, and that will define the color of the set numbers.

The Settings are accessible by clicking on the cog icon. There, you can define whether you train for strength or hypertrophy (defining percentage of strenght or hypertrophy sets), the recommended set ranges per muscle group, recommended frequency per muscle group, default Rest timer, and also define the custom exercises.

When you click on the workout text field, and place an input cursor to some line with some exercise, 2 new sections appear.

First is Workout stats, it shows up between the Week stats and the text field for the workout. It has the same data as the Week stats except the frequency.

Second is the Exercise stats, that will be displayed under the workout text field, showing the details for that exercise. There you'd see the muscles and muscle groups this exercise targets, and the number of sets this week.

The main purpose of Exercise stats though is to show the week over week change of sets x reps, as well as the week over week graphs of volume and intensity. This is especially useful for planning mesocycles and periodization for intermediate/advanced programs, where you could define the "accumulation" blocks, "intensification" blocks, etc. The graphs would provide a visual clue of how the volume and intensity changes in those blocks.

Progressive overload

The workout planner wouldn't help with the progressive overload though. Its purpose is to define exercises, sets and reps for the workouts for all the weeks. Then, you would convert it into the Liftosaur's program, and open in the Liftosaur's Web Editor (Program Buidler).

There, you'd add some kind of progressive overload to the exercises, and do final tweaks for your program. E.g. linear progression for novice program, or just adding weight at the end of mesocycle/macrocycle for intermediate/advanced program, adding double progression for isolates, tweaking warmups, etc.

Then, you generate the link for the program, import it into Liftosaur app - and voila! You can now follow your program in the Liftosaur app!

Each program in the workout planner has a unique URL (same as in Liftosaur programs), so you can bookmark it, and then open it later on again. This way, you can get back to your program, tweak it, maybe increase/decrease volume, maybe change exercises. You can also share it with other people if you want.

Conclusion

This IMHO could be a really useful tool to build your own weightlifting programs. What do you think?

Launched Workout planner!

2023-09-13T00:00:00Z

A couple months ago I wrote about the idea of building a workout planner, that would help you design weightlifting programs. I've been working on it since then, and now it's ready!

You can check it out here: https://liftosaur.com/planner

I believe it's an amazing tool for building weightlifting programs. It's a great way to visualize your programs, and see if you have enough volume per muscle group, and if you're hitting them with enough frequency. Hopefully it'll become a starting point for people to build their programs, especially for those who don't want to mess with coding.

It allows you to plan programs, make sure you have enough weekly volume per muscle group, and can balance it with workout time. You can build multiweek programs, and it'll show weekly undulating of volume and intensity per exercise on a graph. And you can export the program to the Liftosaur app, making it a way faster way to build Liftosaur programs.

It's not as flexible as the Liftosaur's built-in program editor, but it's a lot faster to build programs with it, and it probably be enough for like 80% of use cases. And you can always do the final tweaks in Liftosaur if needed.

If you would prefer to watch the video instead, here's how I use Planner to build a program

How to use it

It's inspired by rich text editors called IDEs (Interactive Development Environment), that are pretty popular in the software engineering world. Those are the text editors that will autocomplete your code, suggest what you should write, check the code you wrote for errors, and generally allow you to write code faster and more efficiently.

The workout planner is similar - it will autocomplete the exercises, equipment, show available progressive overloads, colorize the syntax, etc. It uses a special syntax, so there's some learning curve, but it's very similar to how people generally describe their workout programs, and once you learn it - you can build programs really fast.

Each exercise should go on a separate line. It consists of sections separated by a slash (/). The simplest exercise is written like this:

Bench Press / 3x8

You can do rep ranges too:

Bench Press / 3x8-12

You can list multiple sets, separated by commas, like this:

Bench Press / 5, 3, 1, 5x5

That would be 8 sets total - first 5 reps, then 3 reps, 1 rep, and then 5 sets of 5 reps.

If you don't specify the weight, it'll use the weight calculated from RPE tables, like this one. By default it'll assume you want to do exercises til failure (@10 RPE), so e.g. if you write:

Bench Press / 3x12

It'll check in the RPE table that for if you want to do 12 reps til failure (@10 RPE), you probably should use 65% of 1RM, so it'll set the weight to 65% of 1RM under the hood. If you don't want to go to full failure, you can specify desired RPE:

Bench Press / 3x12 @8

Then the weight would be lower - 60%. You can specify the weight explicitly, as a percentage of 1RM, like this:

Bench Press / 3x12 80%

Or you can specify the weight in kg/lb, like this:

Bench Press / 3x12 60kg

If you specify the weight in kgs though, it'd be static, and not tied to the state.weight state variable when you convert it into Liftosaur program.

RPE, percentage and weight can be specified for each set or range of sets individually, so you can mix and match:

Bench Press / 5 @8, 3 @9, 1 @10, 5x5 50%

You can specify the rest time. E.g. this is how you could do myo-reps - i.e. doing heavy 12, and then doing 5x5 with short rest times and same weight:

Bench Press / 12 20s 60%, 5x5 20s 60%

You can also specify the rest time, weight, 1RM percentage and RPE also, for all sets, so you don't have to repeat yourself. Do it in a separate section like this:

Bench Press / 12, 5x5 / 20s 60%

So, an example workout may look something like this:

Bench Press / 3x5 80% Incline Bench Press / 3x8-12 @8 / 90s Skullcrusher / 3x15 @8 Lateral Raise / 3x15 @8

By default, it'll use default equipment - e.g. for Bench Press it'll use Barbell. If you want to specify different equipment, add it after the exercise name, like this:

Bench Press, dumbbell / 3x5

How to read stats

The planner shows you daily and weekly number of sets per muscle group, per movement type and split between "strength" and "hypertrophy" sets. As an example, this is Workout Planner for the GZCLP program. Let's take a look at the Week Stats section. It looks like this:

Shoulders: 15↓ (7.5s, 7.5h), 3d

That describes the volume (number of sets) you have weekly per muscle group. E.g. in the example above, we have 15 sets for shoulders. If you hover your mouse over the number '15', you'll see what exercises contribute to that number:

Bent Over Row - 3 (0s, 3h)

Overhead Press - 5 (5s, 0h)

Bench Press - 4 (2.5s, 1.5h)

Lat Pulldown - 3 (0s, 3h)

You can see that Bent Over Row and Overhead Press are black (meaning they have target muscles in the Shoulder muscle group), and Bench Press and Lat Pulldown are gray (meaning they have synergist muscles in the Shoulder muscle group).

The number of sets is colored in red, yellow or green, based on whether you're in the recommended range. You can define the range in Settings, with some presets, like 10-12 sets per muscle group for novice, 13-15 for intermediate, etc, and that will define the color of the set numbers. Red - you're completely outside of the range, yellow - you're close to the range, green - you're in the range. The arrow ↓ means you need to decrease the number of sets to get into the range.

(2.5s, 1.5h) means it has 2.5 sets in strength rep range (1-8 reps) and 1.5 sets of hypertrophy (8+ reps). We count synergist muscles by default as a half set, hence there's .5 - i.e. the number is not round.

3d is frequency - means we hit this muscle group 3 days per week.

There're also Day Stats, that show up if you click on the workout text field. Muscle groups are links there, so you can click it and it'll filter the Exercises to only show ones that have that muscle group.

Specifying progressive overload

You can specify the progressive overload for each exercise. It won't affect the weekly volume stats, but it'll be added when you export a program to Liftosaur. For now, there're 3 types of progressive overload:

Linear Progression (lp) - increase or decrease the weight by a fixed amount or percentage after N attempts.
Double Progression (dp) - increase the reps within a range, then reset the reps and increase the weight.
Reps Sum (sum) - increase the weight if the total sum of reps of all sets more than the threshold.

You can add a progression like this:

Bench Press / 3x8 / progress: lp(5lb, 3)

That will increase the weight by 5lb after 3 successful attempts. Or like this:

Bench Press / 3x8 / progress: dp(4, 5lb)

It will keep increasing reps from 8 to 12 (8 + 4), and then reset the reps to 8 and increase the weight by 5lb.

The autocomplete for those progressive overloads contains more details.

Examples

Here're some examples of workouts you can build with the workout planner:

Stronglifts 5x5

// Workout A Squat / 5x5 / progress: lp(10lb, 1, 10%, 3) Bench Press / 5x5 / progress: lp(5lb, 1, 10%, 3) Bent Over Row / 5x5 / progress: lp(5lb, 1, 10%, 3)

// Workout B Squat / 5x5 / progress: lp(10lb, 1, 10%, 3) Overhead Press / 5x5 / progress: lp(5lb, 1, 10%, 3) Deadlift / 5 / progress: lp(10lb, 1, 10%, 3)

Myo reps

Do "activating" set, and then additional sets of the same weight with less reps and short rest:

Squat / 12, 3x5 / 20s 60%

Drop sets

Do a set with 100%, then 85%, then 75%, then 60% of the weight, with short rests:

Bench Press / 5 100%, 8 85%, 10 75%, 12 60% / 40s

5/3/1 Basic Beginner main lift

Bench Press / 5 75%, 3 85%, 1+ 95%, 5x5 75%

Bullmastiff Week 1 Day 1

Squat / 3x6 65%, 6+ 65% Romanian Deadlift, barbell / 3x12 @6 Bent Over Row / 2x12-15 Leg Curl / 2x12-15 Leg Extension / 2x12-15 Cable Crunch / 2x12-15

Exporting to Liftosaur

When you're done and would like to export this program to Liftosaur, press that big purple button "Convert to Liftosaur program". That will generate a link and copy it to the clipboard. You then can go to Liftosaur, and paste that link into the "Import link" field on the Choose Program screen. And that's it!

Check it out, and hopefully you'll find this new Workout Planner useful!

Combine Workout Planner and Liftoscript

2024-01-04T00:00:00Z

This is what Midjourney thinks a good illustration for the post. Who am I to argue with AI overlords?

I recently added "Full Program" mode to the Workout Planner. Now you can edit a whole weightlifting program as just one text file.

And this is so cool! Making weightlifting programs was never easier and faster. But I still have to fall back to a regular Web Editor from time to time for some custom progression logic. And that sucks, there's way too much clicking around, I really would want to build whatever I want in the Workout Planner instead end to end.

So I couldn't stop thinking - could I somehow bring the full power of the regular Web Editor to Workout Planner? Having Liftoscript there, I could implement any possible progression logic in it as well. And after some brainstorming, I think I have something in mind.

The idea is to use Liftoscript syntax right inside the Workout Planner program. But first, we'd need to extend both Liftoscript and Workout Planner with the new features.

Currently, in Liftoscript, you can access required/completed reps, weight, rpe, etc via reps[1], completedReps[1], weights[1], etc. We need to add a way to directly change required reps, weight, rpe and timer in the program in the Finish Day Script. I.e. you'd be able to do this:

reps = 5 // Set all the reps of all the sets to 5
reps[1] = 8 // Set all the reps of the 1st set variation to 8
reps[1:2] = 30// Set the 2nd set reps of the 1st set variation to 3

weight = 5lb // Set all the weights of all the sets to 5lb
weight[1] = 0.5 // Set all the weights of the 1st set variation to 50% of 1RM
weight[1:2] = rpeMultiplier(6, 10) // Set the 2nd set's weight of the 1st set variation to that RPE multiplier

// Same thing for timer and RPE

Now, if we have that, we can introduce new progress function in the Workout Planner - custom(). In that function, in the curly braces, we can add our Liftoscript code!

Bench Press / 5x5 / progress: custom() {
  if (completedReps >= reps) {
    state.weight += 5lb
  }
}

Between the parentheses in the custom function we can define the state variables. Some state variables would be available by default (like weight). E.g. if we want to increase weight after 3 successful attempts, and reduce weight after 2 failures, it'd be:

Bench Press / 5x5 / progress: custom(success: 0, failures: 0) {
  if (completedReps >= reps) {
    state.success += 1
    if (state.success > 3) {
      state.weight += 5lb
      state.success = 0
      state.failures = 0
    }
  } else {
    state.failures += 1
    if (state.failures > 2) {
      state.weight -= 10lb
      state.success = 0
      state.failures = 0
    }
  }
}

Unlike regular Liftoscript and Web Editor, you cannot use state variables in reps/weight/timer/etc. But you can directly change them for the next workout in the script using our new Liftoscript syntax we introduced above. Like for the double progression:

Bench Press / 3x8 / progress: custom(success: 0, failures: 0) {
  if (completedReps >= reps) {
    reps = reps[1] + 1
  }
  if (reps[ns] > 12) {
    reps = 8
    state.weight += 5lb
  }
}

We can also introduce set variations in the Workout Planner, just by listing them one after another, like:

Bench Press / 5x3 / 6x2 / 10x1 / progress: custom() {
  if (!(completedReps >= reps)) {
    state.setVariation += 1
  }
}

This way, we'll have 3 set variations - '5x3', '6x2' and '10x1'. And you can switch between them by assigning a value to state.setVariation (also a default built-in state variable). Similar way you can specify multiple descriptions and switch between them via state.description state var:

// First description

// Second description
Bench Press / 5x3 / 6x2 / 10x1 / progress: custom() {
  if (completedReps >= reps) {
    state.description += 1
  }
}

We also will introduce new Workout Planner syntax to reuse logic of exercises, which will look like this:

Bench Press / 5x5 Squat / ...Bench Press

This way Squat will reuse whatever sets/reps, progression, etc are defined for the Bench Press.

Using all of that, we can e.g. implement GZCLP:

# Week 1
## Day 1

t1: Squat / 5x3 100% / 6x2 100% / 10x1 100% / progress: custom(increase: 10lb) {
  if (completedReps >= reps) {
    state.weight += state.increase
  } else if (sets == 3) {
    state.setVariation = 1
  } else {
    state.setVariation += 1
  }
}
t2: Bench Press / 3x10 100% / 3x8 100% / 3x6 100% / progress: custom(state1weight: 0lb, increase: 5lb, state3increase: 10lb) {
  if (completedReps >= reps) {
    state.weight += 5lb
  } else if (state.stage == 1) {
    state.stage1weight = state.weight
    state.stage += 1
  } else if (state.stage == 2) {
    state.stage += 1
  } else {
    state.stage = 1
    state.weight = state.stage1weight + state.stage3increase
  }
}
t3: Lat Pulldown / 3x15 100%, 15+ 100% / progress: custom() {
  if (completedReps[ns] >= 25) {
    state.weight += 5lb
  }
}

## Day 2
t1: Overhead Press / ...t1: Squat / progress: custom(increase: 5lb)
t2: Deadlift / ...t2: Bench Press / progress: custom(state1weight: 0lb, increase: 10lb, state3increase: 15lb)
t3: Bent Over Row / ...t3: Lat Pulldown

## Day 3
t1: Bench Press / ...t1: Squat / progress: custom(increase: 5lb)
t2: Squat / ...t2: Bench Press / progress: custom(state1weight: 0lb, increase: 10lb, state3increase: 15lb)
t3: Lat Pulldown / ...

## Day 4
t1: Deadlift / ...t1: Squat / progress: custom(increase: 5lb)
t2: Overhead Press / ...t2: Bench Press / progress: custom(state1weight: 0lb, increase: 5lb, state3increase: 10lb)
t3: Bent Over Row / ...

Note that reusing exercises can define their values for the state variables via the same custom(foo: 3) syntax, just without the block withing the curly braces - it'll be reused from the original exercise.

And that's it! That pretty much would be the whole GZCLP program, with all the autoincrements, changing stages on failures, and all the proper logic for T1s, T2s and T3s.

All that stuff makes the Workout Planner pretty much as powerful as the regular Liftosaur's program editor. And a big advantage is that you don't really need to know/use all of that, you still can do simple programs like:

Squat / 5x5 Bench Press / 3x8 @8 / progress: lp(5lb)

But if you really want something very custom and unusual for you progression, you can use this new custom() { } syntax to do whatever you want realy.

One caveat here is that if I integrate Workout Planner into the app fully and make it the default program editor, then when people open e.g. built-in GZCLP program to tweak it, and see that blob of code for T1/T2 exercise, that could be quite intimidating. Currently it's kinda buried in UI and doesn't look as scary.

But IMHO that's a step in the right direction, and would unlock a lot of potential.

What do you think? Would love to hear your thoughts on that! Please comment on Reddit what do you think about it!

New Experimental Program Editor

2024-01-25T00:00:00Z

In the latest post I tried to envision what would it take to combine Planner syntax with Liftoscript, and write Liftosaur programs using that new syntax. And it's finally here!

IMHO it worked out amazingly! I really like the new syntax, IMHO it makes it WAAAY simpler to write programs, they're easier to comprehend. Each program is essentially just a blob of text, it's easy to share it, edit it, etc. I can't wait to see what y'all going to create in it! :)

So, there's now a way to create "experimental" Liftosaur program - if you select "Create experimental program" in the program creation modal in the app. There, you use Workout Planner syntax to create those new programs - you just type exercises and sets x reps you want to have.

I described it in one of the previous posts, but will quickly remind you here.

Reminder on the existing Workout Planner syntax

Basics

Each exercise goes on a separate line. It consists of sections separated by a slash (/). First should go the exercise name, and then in any order you can put the sections. The simplest exercise is written like this:

Bench Press / 3x8

You can do rep ranges too:

Bench Press / 3x8-12

You can list multiple sets, separated by commas, like this:

Bench Press / 1x5, 1x3, 1x1, 5x5

That would be 8 sets total - first 5 reps, then 3 reps, 1 rep, and then 5 sets of 5 reps.

If you don't specify the weight, it'll use the weight calculated from RPE tables, like this one. By default it'll assume you want to do exercises til failure (@10 RPE), so e.g. if you write:

Bench Press / 3x12

Bench Press / 3x12 @8

Then the weight would be lower - 60%. You can specify the weight explicitly, as a percentage of 1RM, like this:

Bench Press / 3x12 80%

Or you can specify the weight in kg/lb, like this:

Bench Press / 3x12 60kg

RPE, percentage and weight can be specified for each set or range of sets individually, so you can mix and match:

Bench Press / 1x5 @8, 1x3 @9, 1x1 @10, 5x5 50%

You can specify the rest time. E.g. this is how you could do myo-reps - i.e. doing heavy 12, and then doing 5x5 with short rest times and same weight:

Bench Press / 1x12 20s 60%, 5x5 20s 60%

You can also specify the rest time, weight, 1RM percentage and RPE also, for all sets, so you don't have to repeat yourself. Do it in a separate section like this:

Bench Press / 1x12, 5x5 / 20s 60%

To add AMRAP sets, add + after the reps number. And to log RPE, add + after the RPE number. Like this:

Bench Press / 4x5, 1x5+ @8+

If you want to enable "Quick add sets" feature (where you may have more sets than you planned), add + after the set number:

Bench Press / 3+x5

So, an example workout may look something like this:

Bench Press / 3x5 80% Incline Bench Press / 3x8-12 @8 / 90s Skullcrusher / 3x15 @8 Lateral Raise / 3x15 @8

By default, it'll use default equipment - e.g. for Bench Press it'll use Barbell. If you want to specify different equipment, add it after the exercise name, like this:

Bench Press, Dumbbell / 3x5

Progressions

You can also specify the progressive overload for each exercise. There're 3 built-in types of progressive overload:

Linear Progression (lp) - increase or decrease the weight by a fixed amount or percentage after N attempts.
Double Progression (dp) - increase the reps within a range, then reset the reps and increase the weight.
Reps Sum (sum) - increase the weight if the total sum of reps of all sets more than the threshold.

You can add a progression like this:

Bench Press / 3x8 / progress: lp(5lb, 3)

That will increase the weight by 5lb after 3 successful attempts. Or like this:

Bench Press / 3x8 / progress: dp(5lb, 8, 12)

It will keep increasing reps from 8 to 12, and then reset the reps to 8 and increase the weight by 5lb.

Full mode, weeks and days

There's a way to switch to the "Full Mode", where your whole program is just one blob of text. There, to specify different weeks/days, you use this syntax:

# Week 1 ## Day 1 Squat / 5x5 / progress: lp(5lb)

## Day 2 Squat / 3x8

# Week 2 ## Day 1 Squat / 5x4

I.e. prefixing week names with #, and day names with ##.

Descriptions

You can add descriptions to exercises via // comments, like this:

// Pause **2 seconds** at the bottom Squat / 5x5 / progress: lp(5lb)

You can use Markdown syntax there, and also the descriptions would be reused in the following weeks/days, until you overwrite them. E.g. if you have description on Week 1 and Week 3, Week 2 would reuse Week 1 description, and Week 4+ would reuse Week 3 description. You can stop that by adding empty // comment, like this, then this week and following weeks won't reuse the description. Like this:

# Week 1 ## Day 1 // Pause **2 seconds** at the bottom Squat / 5x5 / progress: lp(5lb)

# Week 2 ## Day 1 Squat / 5x5 / progress: lp(5lb)

# Week 3 ## Day 1 // Squat / 5x5 / progress: lp(5lb)

# Week 4 ## Day 1 Squat / 5x5 / progress: lp(5lb)

In this case, Week 1 and Week 2 will have the description about the pause, and Week 3 and Week 4 won't.

Exercise Labels

If you want the same exercises to be separate (e.g. you have Squat as a main lift, and Squat as an accessory lift, and you want to apply different progressions for them), you can mark exercises with different labels. Like this:

# Week 1 ## Day 1 main: Squat / 5x5 / progress: lp(5lb)

# Week 2 ## Day 1 accessory: Squat / 3x8 / progress: dp(5lb, 8, 12)

Set Labels

If you can add labels to the sets (8 characters max!), just putting them in parentheses () when you specify the sets x reps:

Squat / 4x5 (Main), 1x5+ (AMRAP) / progress: lp(5lb)

Warmups

By default, it will add some warmups, but if you want to change that, you can use warmup section, like this:

Squat / 5x5 / warmup: 1x5 45lb, 1x5 135lb, 1x3 80%

Syntax is very similar to the regular sets x reps, but you cannot specify timer and RPE there. Also, percentages are not 1RM percentages, but percentages of the weight of the first set.

If you don't want warmups at all, you can specify warmup: none:

Squat / 5x5 / warmup: none

New syntax

The new experimental programs work somewhat different from the former Liftosaur programs.

Previously, it was all about state variables. You can define them, and use them in weights, reps, timer, etc. And by changing them in the Finish Day Script, you can program progressive overload.

It's quite different in the new programs. You still can use state variables, but mostly to remember some state through the workouts - like number of successful workouts in a row, or some weight you had at the beginning of the mesocycle, or something like that. Most of the time you won't need them.

Instead, you'll change the weights, reps, timer and RPE directly in the exercises. And for that, you'll use the Liftoscript together with the planner syntax. There's a new progress property that you can apply to the exercise - custom(). It looks like this:

Bench Press / 5x5 / 100lb / progress: custom() {~ if (completedReps >= reps) { weights += 5lb } ~}

Note that we include Liftoscript inside {~ ~} - curly braces with tildas! This is so that we can distinguish Liftoscript syntax from the regular Workout Planner syntax.

So, instead of changing the state variable state.weight, you just directly change the built-in variable weights. And when you finish the workout and open the program again, you'll see that weight went up and the program now looks like this:

Bench Press / 5x5 / 105lb / progress: custom() {~ if (completedReps >= reps) { weights += 5lb } ~}

Instead of 100lb now it says 105lb! And that's another important feature of the new programs - they will update based on the progressive overload. If you update reps, weight, timer, etc in your custom() {~ ~} block, it will be reflected in the program text.

Bench Press / 5x5 / 105lb 30s @8 / progress: custom() {~ if (completedReps >= reps) { weights += 5lb /// Update weights of all sets reps = 7 /// Set reps of all sets timer = 90 /// Set timers between all sets } ~}

After completion, it'll look like this:

Bench Press / 5x7 / 110lb 90s @8 / progress: custom() {~ if (completedReps >= reps) { weights += 5lb /// Update weights of all sets reps = 7 /// Set reps of all sets timer = 90 /// Set timers between all sets } ~}

Similar to old Liftosaur programs, you can specify set variations. You don't need to use them for various weeks/days like in the old editor, it's more for falling back to other set schemes e.g. if you failed to finish sets.

To add set variations, just list sets x reps in another section, like this:

Bench Press / 3x5 / 2x7 / progress: custom() {~ if (!(completedReps >= reps)) { setVariationIndex += 1 } ~}

Here you have 2 set variations - 3x5 and 2x7. You can switch between set variations via a special setVariationIndex variable. By default, first set variation is selected, and if you want to use another one, you add exclamation mark (!) in front of it, like this:

Bench Press / 3x5 / ! 2x7 / progress: custom() {~ if (!(completedReps >= reps)) { setVariationIndex += 1 } ~}

Now, 2x7 would be selected. After finishing a workout, when it runs the finish day script, it'll automatically add exclamation mark to the newly selected set variation if it's not the first one.

When you update weights, reps, etc - you can target specific sets, set variations, days or weeks. Like this:

Bench Press / 5x7 / 110lb 90s @8 / progress: custom() {~ if (completedReps >= reps) { weights[1] += 5lb /// Only update weight of 1st set weights[1:2] += 5lb /// Only update 2st set of 1st set variation weights[1:*:2] += 5lb /// Only update 2st set of ALL set variations on the first day weights[3:1:*:2] += 5lb /// Only update 2st set of ALL set variations on the first day of 3rd week } ~}

So, the syntax is reps[week:day:setvariation:set]. You can use * instead of a number to target all weeks/days/sets. If you omit week, day, set variation or set, it'll assume it's * for them. I.e. weights[1:2] is the same as weights[*:*:1:2], weights[1] is the same as weights[*:*:*:1], and weights is the same as weights[*:*:*:*].

If you want to use state variables, you need to specify them inside custom() parentheses, like this:

Bench Press / 5x7 / 110lb 90s @8 / progress: custom(increment: 5lb) {~ if (completedReps >= reps) { weights += state.increment } ~}

It will create a state variable increment, which you can use in your Finish Day Script.

You can also reuse Finish Day Scripts, like this:

Bench Press / 5x5 / progress: custom(increment: 5lb) {~ if (completedReps >= reps) { weights += state.increment } ~} Squat / 3x4 / progress: custom(increment: 10lb) { ...Bench Press }

Here, we reuse the same finish day script for both Bench Press and Squat, but for Squat we'll increment the weight by 10lb. I.e. we also can use state variables to parameterize our Finish Day Scripts. Note that in this case it's just curly braces { }, without tildas - because it's still Workout Planner syntax.

In-workout Updates

Similar to progress: custom(), you can use another property: update: custom(). It won't change the program, but it will change currently ongoing workout. You can use it to update sets based on your performance. E.g. adjust weights if RPE was higher or lower than expected, or if you did more or less reps than expected during AMRAP.

It's almost the same script as in progress: custom(), just you cannot use state variables, and you cannot change the program - you can change only the current workout. You can access any other variables, and a special variable setIndex, that is set to the index of the set you just finished.

Those scripts are run after completing any set, or changing completed reps on any set. You can change:

reps
minReps
weights
RPE

You can either target all sets, or specific sets. To target all sets, you could do:

reps = 5 weights[*] = 100lb

and to target specific set, you could do:

reps[2] = 5 weights[1] = 100lb

You can only change non-completed sets. You cannot change already completed sets, both successfully or unsuccessfully.

For example, if you want to adjust half-sets after the first AMRAP set, you can do:

Squat / 1x6+, 3x3 / update: custom() {~ if (setIndex == 1) { reps = floor(completedReps[1] / 2) } ~}

That will change all the rest sets after finishing the first AMRAP set, and will set reps == half of the reps of the 1st set.

Percentages

I added new numeric type to Liftoscript - percentage (both in old and new programs!). You can set percentages in state variables, use them in weight expressions, etc. Percentages mean % of 1RM. So, you can e.g. write in your weight expression field 50%, and it'll be 50% of 1RM for that exercise.

Some features were removed

Two features were removed from the Liftoscript syntax:

Reusing of previous week sets x reps via ..., like Bench Press / ...
Omitting set number when there's just one set. I.e. previously you could write 5 50lb for 5 reps and 50lb. Now, you have to specify sets too, i.e. 1x5 50lb.

I had to kill reusing sets x reps because over time weeks can go out of sync, e.g. if you increased reps of the exercise on week 2 or something like that. And for the set numbers - it's to make it more future-proof, when I add e.g. time-based exercises.

Things that are not yet implemented (but will be soon!)

Comments via triple slash /// are not supported yet. I mean you can add them, but they will be wiped out after finishing a workout.

Examples

So, using all of that, here how we could implement various programs:

Stronglifts 5x5:

That one is pretty simple:

# Week1 ## Workout A Squat / 5x5 / progress: lp(10lb, 1, 0, 10%, 3, 0) Bench Press / 5x5 / progress: lp(5lb, 1, 0, 10%, 3, 0) Bent Over Row / 5x5 / progress: lp(5lb, 1, 0, 10%, 3, 0)

## Workout B Squat / 5x5 / progress: lp(10lb, 1, 0, 10%, 3, 0) Overhead Press / 5x5 / progress: lp(5lb, 1, 0, 10%, 3, 0) Deadlift / 1x5 / progress: lp(10lb, 1, 0, 10%, 3, 0)

Greyskull LP

Also pretty trivial :)

# Week 1 ## Workout A Bench Press / 2x5, 1x5+ / warmup: 5 45lb, 4 55% , 3 70%, 2 85% / progress: lp(2.5lb, 1, 0, 10%, 1, 0) Bent Over Row / 2x5, 1x5+ / progress: lp(2.5lb, 1, 0, 10%, 1, 0) Squat / 2x5, 1x5+ / warmup: 5 45lb, 4 55% , 3 70%, 2 85% / progress: lp(2.5lb, 1, 0, 10%, 1, 0) Triceps Extension / 2x12, 1x12+ / progress: lp(2.5lb, 1, 0, 10%, 1, 0) Ab Wheel / 2x12, 1x12+ / 0lb

## Workout B Overhead Press / 2x5, 1x5+ / warmup: 5 45lb, 4 55% , 3 70%, 2 85% / progress: lp(2.5lb, 1, 0, 10%, 1, 0) Chin Up / 2x5, 1x5+ / progress: lp(2.5lb, 1, 0, 10%, 1, 0) Deadlift / 2x5, 1x5+ / warmup: 5 45lb, 4 55% , 3 70%, 2 85% / progress: lp(5lb, 1, 0, 10%, 1, 0) Bicep Curl / 2x12, 1x12+ / progress: lp(2.5lb, 1, 0, 10%, 1, 0) Shrug / 2x12, 1x12+ / progress: lp(10lb, 1, 0, 10%, 1, 0)

GZCLP

That one really challenges the approach :) There's a lot of logic, several set variations, custom progressions, etc. But we still can do it! It'd look like this:

# Week 1 ## Day 1 /// Note that we specify 4 set variations. The last one is a testing week, /// to get the new weight before going back to the first set. t1: Squat / 5x3 75% / 6x2 75% / 10x1 75% / 1x5 (5RM Test) / progress: custom(increase: 10lb) {~ /// Fourth set is 5RM retesting week. So, we'll use 85% of the new 5RM for the weights, /// and also we'll update our 1RM for the exercise based on that - and that value would be transferrable /// to other programs too! if (setVariationIndex == 4) { setVariationIndex = 1 weights = weights[1] * 0.85 rm1 = weights[1] / rpeMultiplier(5, 10) } else if (completedReps >= reps) { weights = weights[ns] + state.increase } else { setVariationIndex += 1 } ~} /// Here we have 3 set variations, and we use a state variable to remember stage 1 weight. t2: Bench Press / 3x10 35% / 3x8 35% / 3x6 35% / progress: custom(stage1weight: 0lb, increase: 5lb, stage3increase: 10lb) {~ if (completedReps >= reps) { weights = weights[ns] + 5lb } else if (setVariationIndex == 1) { state.stage1weight = weights[ns] setVariationIndex += 1 } else if (setVariationIndex == 2) { setVariationIndex += 1 } else { setVariationIndex = 1 weights = state.stage1weight + state.stage3increase } ~} /// That one is simple - we just increase the weight by 5lb if we did 25 reps on the last set. t3: Lat Pulldown / 3x15 60%, 1x15+ 60% / progress: custom() {~ if (completedReps[ns] >= 25) { weights = weights[ns] + 5lb } ~}

## Day 2 /// All the logic is the same for all T1s, T2s and T3s, so we just reuse the Finish Day Scripts t1: Overhead Press / 5x3 75% / 6x2 75% / 10x1 75% / progress: custom(increase: 5lb) { ...t1: Squat } t2: Deadlift / 3x10 35% / 3x8 35% / 3x6 35% / progress: custom(stage1weight: 0lb, increase: 10lb, stage3increase: 15lb) { ...t2: Bench Press } t3: Bent Over Row / 3x15 60%, 1x15+ 60% / progress: custom() { ...t3: Lat Pulldown }

## Day 3 t1: Bench Press / 5x3 75% / 6x2 75% / 10x1 75% / progress: custom(increase: 5lb) { ...t1: Squat } t2: Squat / 3x10 35% / 3x8 35% / 3x6 35% / progress: custom(stage1weight: 0lb, increase: 10lb, stage3increase: 15lb) { ...t2: Bench Press } t3: Lat Pulldown / 3x15 60%, 1x15+ 60%

## Day 4 t1: Deadlift / 5x3 75% / 6x2 75% / 10x1 75% / progress: custom(increase: 5lb) { ...t1: Squat } t2: Overhead Press / 3x10 35% / 3x8 35% / 3x6 35% / progress: custom(stage1weight: 0lb, increase: 5lb, stage3increase: 10lb) { ...t2: Bench Press } t3: Bent Over Row / 3x15 60%, 1x15+ 60%

Once you get familiar with the syntax, it's IMHO pretty easy to figure out how it works, just by reading the text.

App Changes

The edit program screen now looks very different from regular Liftosaur editor, and very similar to the Workout Planner web page. Similarly to the Workout Planner, you can see weekly/daily volume per muscle group, exercise intensity/volume undulation graphs week over week. You can also test your changes in program preview. It allows you to quickly simulate various scenarios, and make sure the logic you defined works as expected.

You can also switch to Full Program Mode there, and there's new UI for rearranging weeks and days.

Daily Stats and Exercise Graphs get enabled when you focus a cursor on specific day or exercise.

Conclusion

So, give it a try, and let me know what you think! I'm really excited about this new syntax and new capabilities it unlocks. That was a huge rewrite of the Liftosaur engine, so let me know if something got broken.

Make new Liftosaur programs less repetitive

2024-02-27T00:00:00Z

I'm currently working on porting over the built-in programs to the new syntax, and I've noticed that it's quite repetitive. I expected that, and thought that with Find & Replace (since it's just one text file) it'd be easy to edit the exercises in bulk. But in reality it's not that easy. It's more or less okay when you only create a new program, but if you need to make changes in it, you sometimes need to change it in like 30 places, and it's very easy to make a mistake.

That's especially obvious with the long multi-week programs e.g. GZCL: Rippler or UHF. Like, I was writing those, and then noticed that I forgot to add last set as AMRAP. And I was already on the 7th week. Going back and adding that + sign to every single exercise across all days and weeks is really brutal.

One of the killer features of the old programs was "Reuse Logic". You can define the exercise once, and then you can make other exercises reuse the logic of the original one. That was very convenient.

I initially didn't want to add reusing syntax to the new programs, because it's very complex technically - because of the progressions. For example, you can mark some exercise as reusing another exercise's sets. But then, the original exercise progresses the reps, and the reused exercise - does not. So, we need to break reusing at this point, and change the program text.

After writing some programs though, I realized that it's very important to add reusing logic. Otherwise, it's PITA to create programs in the new syntax.

So, for that, I'm planning to add 3 new features.

Reusing sets

We already have syntax for reusing progressions - like progress: custom() { ...Bench Press }. Let's also add similar syntax for reusing sets. It will look like this:

Bench Press / 5x5 @8 60s 80% / progress: lp(5lb) Squat / ...Bench Press

This will make the Squat reuse the sets of the Bench Press. So, if the Bench Press has 5x5 with 8 RPE and 60s rest timer, the Squat will also have that.

If the Bench Press updates the weight though, after finishing the workout the program will look like this:

Bench Press / 5x5 @8 60s 105lb / progress: lp(5lb) Squat / 5x5 @8 60s 80%

I.e. the app broke the reusing at this point, because Bench Press changed its weight, and they're not the same with Squat anymore.

By default, it'll try to reuse the exercise from the same week at any day. But if there're 2 same exercises at the same week, it'll show an error. You can make it more specific like this:

Bench Press / 5x5 @8 60s 80% / progress: lp(5lb) Squat / ...Bench Press[2:4]

This will make the Squat reuse the Bench Press from the 4th day of the 2nd week. I.e. it's [week:day]. You can omit week, and just specify [day], it'll try to find the exercise at the same week then.

You can add overrides on top of the reused stuff, e.g. override weight, RPE or timer, like this:

Bench Press / 5x5 @8 60s / 100lb / progress: lp(5lb) Squat / ...Bench Press / 150lb

This will reuse everything in Squat except the weight - it'll be 150lb.

Reusing exercises across weeks

Usually, weightlifting programs have pretty much the same exercises across all weeks, just changing weights/reps/RPE/etc week over week. Or sometimes not changing anything at all. In that case, it'd be convenient to not write the same thing over and over across all weeks.

For that, you'll be able to specify the week ranges for exercises. It'll look like this:

Bench Press[1, 2, 4-8] / 3x8 @8 90s 100lb / progress: lp(5lb)

In the square brackets after the exercise name you can specify what weeks or week ranges you want to apply this exercise to. In this case, it'll apply to weeks 1, 2, and from 4 to 8. It'll show up at the same days within the weeks, after explicitly specified exercises.

Combining with the reusing sets feature, you can only define the exercise once at the first week, and then just reuse it across all weeks:

Bench Press / 5x5 @8 60s 80% / progress: lp(5lb) Squat[1-8] / ...Bench Press

Bench Press defines different set schemes across like 8 weeks. But Squat is only added at the first week, like Squat[1-8], and it'll reuse the Bench Press exercise across all 8 weeks.

That should give you a quick way of defining exercises across all weeks. E.g. you want to add another T3 to the GZCL: Rippler. You just type something like this at the first week:

Bicep Curl[1-8] / ...t3: Lat Pulldown

and that's it! It'll show up across all weeks.

Template exercises

One popular approach people had in the old programs is to create "template" exercises. They exist in a program, and not added to any day/week, but other exercises reuse the logic of those "template" exercises.

I think it's even more important to allow such "template" exercises in the new syntax. Sometimes, we may want to have an exercise we'll take the sets and progression from, but we don't want to add it to any day/week so that it wouldn't ever change. It'd be just a "template" for other exercises.

For that, there's going to be a new syntax used: none:

Bench Press / 5x5 @8 60s 80% / used: none / progress: lp(5lb)

This way Bench Press will be a "template" exercise, and it won't show up at any day/week. But other exercises can reuse its sets and progression:

# Week 1 ## Day 1 Bench Press / 5x5 @8 60s 80% / used: none / progress: custom() {~ // logic here ~}

Squat[1-8] / ...Bench Press / progress: custom() { ...Bench Press }

Conclusion

Those 3 features IMHO should simplify the process of creating new programs A LOT. Let me know what you think - in the comments to the Reddit post!

Implementing localized pricing for your mobile app

2024-08-26T00:00:00Z

TLDR; I recently implemented localized pricing for the mobile app, which was suprisingly tricky. So, sharing my experience of fighting with Apple and Google APIs to make it work, and sharing Google Sheets and scripts to calculate and upload the prices.

Coming up with fair prices for various countries

I used to have flat pricing for all the users. But it's kinda unfair to charge the same amount for users from US and e.g. India or Phillipines - the purchase power is so different in those countries! In addition to that, Apple and Google try to take into account the local taxes, so sometimes the price gets even higher than in the US - e.g. if you set the price as $70, in Germany by default Apple / Google would set it to be around €80. And people were not super happy about that.

So, I decided to do localized prices. But how to make sure I'm setting a fair price for all those 170+ countries? I have no idea what's the cost of living there for most of them.

I'd frankly expect that Apple or Google solve that, and provide adjust the prices for various countries, but they don't really do that. So, we have to do it ourselves!

To solve that, we could divice that country GDP per capita by the USA GCP per capita, and that's going to be our multiplier for the prices. It probably makes sense to cap it at the top and the bottom, so e.g. the monthly subscription price doesn't go higher than $4.99, and lower than $0.99. The top cap is because likely the most advertised price would be the US one, and people from other rich countries like Singapore or Schwitzerland would be disappointed they have to pay higher than US. And the bottom cap is to avoid super small prices like a tiny fraction of a dollar e.g. in Phillipines, where fees would eat the majority of the price.

I found some data on GDP per capita on the Internet, dumped it into a Google Sheet, and calculated the multiplier. Then, added some columns to specify the base price in USD, then the adjusted price after applying multiplier in USD. Apple and Google require for some countries to provide the prices in local currencies, so I grabbed the exchange rates and created columns with prices in local currencies.

Then, to make the prices prettier (like a "marketing price", with all those $4.99, $19.99) - added another set of columns that would round up the prices to make them look "markety".

It's a bit annoying that Apple and Google use a different set of countries, different country codes (Google uses 2-character ones like US or NL, and Apple uses 3-character like USA or NLD), and also different currencies per country - Google more often prefers local currency, and Apple fallbacks to USD. So, I had to create 2 separate sheets for Apple and Google prices.

My Google Sheet with prices

At the end, the sheets look like this: https://docs.google.com/spreadsheets/d/1BwSqpkqa98nk9Gh7238U7KQbvdvh_tGlXmQKE0Druwk.

There're 2 sheets for Apple and Google prices, and 2 auxiliary sheets for GDP multiplier and currency exchange rates. You could use that to calculate your own localized prices. Just replace the values in "Monthly Base", "Yearly Base" and "Lifetime Base" with your USD prices, and maybe (if you want) adjust the caps in the formulas for "Monthly Adj US", "Yearly Adj US" and "Lifetime Adj US". By default the caps are $1-5 for montly, $8-40 for yearly, and $16-80 for lifetime.

The final prices we'll use are in the Mkt Monthly/Yearly/Lifetime columns - marketing prices in proper currencies.

So, we have prices for Apple and Google, now need to upload them. I expected I'd go to App Connect console or Google Play console, edit the subscription, and upload the prices as some CSV file. Ha, not that fast!

Apparently in both Apple/Google I can only edit one price for one country at a time. So, I'd need to manually enter 170 countries * 3 price plans * 2 platforms = ~1000 times! This is ridiculous. Given their UI is not blazing fast, it'd take days to do so!

Luckily, they have APIs, so we could use the APIs to upload the prices. Unfortunately, those APIs look like they were written by an unpaid intern without any supervision. They're confusing, buggy, return weird cryptic error messages, and even ChatGPT doesn't know how to use them properly.

It took me a couple days to figure out how to upload the prices, but finally I'm done, and I'm happy to share the final scripts with you. The scripts are in JavaScript, so you'd need NodeJS to run them.

Uploading prices to Google

The API and the way how prices for subscriptions and for in-app purchases work internally is VERY different in Apple and Google.

In Google, we send ALL the prices for a subscription as one request. The API is very sensitive to the request body, but the documentation is sparse, so it's hard to figure out what it expects. If you send something that Google doesn't expect, it just responds with generic "Internal error.", and go figure what it doesn't like.

Luckily, the response of listing all subscription info from API and the request body for updating a subscription is pretty much the same JSON, so we can use that:

First, we get all our subscriptions info via androidpublisher.monetization.subscriptions.list.
Then, in the response, we modify subscription.basePlans.regionalConfigs.price values.
We use the modified response as a POST body for androidpublisher.monetization.subscriptions.patch.

Similar for in-app purchases:

First, we get all our subscriptions info via androidpublisher.inappproducts.list.
Then, in the response, we modify product.prices values.
We use the modified response as a POST body for androidpublisher.inappproducts.patch.

For some reason, the number of countries supporting in-app billing is smaller that the subscription billing, so need to filter out some countries as well.

At the end, the script looks like this: https://gist.github.com/astashov/705c45e5f8f6c89cc5f968ba128b1800

To run it, install googleapis (npm install googleapis), modify the script with your service account key, package name, subscription/product ids, then make sure to download the CSV file from the sheet and name it google_prices.csv, and run it as node update_google_prices.js. Hopefully it'll work! :)

Uploading prices to Apple

For Google, the API was a bit tricky, but at the end we could just update all prices for each subscription with just one API call, and provide the prices directly.

This is not the case at all for Apple, it would be too simple. You cannot just set the price for your subscription! Instead, it has a list of "price points", and you should assign that price point to your subscription and territory. I.e. if Apple only has price points $0.99 and $0.79 for Afganistan, you cannot set the price e.g. $0.85. You have to use the price points.

Each country has a few hundreds of price points, and each price point has an id. To know the ids, you need to fetch the price points for each territory from their API. The API seems to have some rate limit, and also pagination with the page size limit, so make sure to not do it in parallel, and need to sometimes retry it too when it fails. Seems like sweet spot is to run 2-3 requests in parallel. Then, you probably want to cache all those price points and their ids on disk to avoid slow repeated network calls when you restart the script.

After you download all the price points, you need to find the closest price point to a price from the spreadsheet/CSV file, get id of that price point, and update the subscription and territory with that price point id. You can only update one price point per subscription and territory, but for some reason you can do it in bulk for in-app purchases and send all price points for all territories for an in-app purchase in one request.

So, that's how it basically works:

Fetch all the price points for the territories
Find closest price point
Update that price point for the subscription / territory

And similarly for in-app purchases.

The script looks like this: https://gist.github.com/astashov/79dd4ef4e91ea012710145623bfe0984

To run it, install jsonwebtoken and node-fetch (npm install jsonwebtoken node-fetch), modify the script with your keys, app id, subscription/product ids, etc, then make sure to download the CSV file from the sheet and name it apple_prices.csv, and run it as node update_apple_prices.js.

Changing the prices

After all of that, updating the prices for your app becomes a pretty trivial routine:

Open the spreadsheet, and update the monthly/yearly/lifetime prices in the Base columns.
Export the updated spreadsheets into google_prices.csv and apple_prices.csv
Run node update_apple_prices.js and node update_google_prices.js

And that's it!

Overview of Liftosaur - scriptable weightlifting planner and tracker app

2025-09-01T00:00:00Z

Check out the video version of this post on Youtube!

In this post I want to go over the main features of Liftosaur - a scriptable workout planner and tracker app. This is probably the most powerful lifting app on the market, incredibly flexible and customizable. You can implement any program you want, and change every bit of it. You can specify any progressive overload logic you want, even script it if it's somewhat unique.

The app is pretty unique, so hopefully this post may help you decide whether you want to use it as your lifting app.

Onboarding

When we first start the app, we're greeted by the welcome screen, and brief overview of featuers in stories-like UI.

We proceed, and pick the unit here. I personally hate long onboarding flows, and I tried to be really considerate, and only ask the things that are important to starting using the app. E.g. unit here is important because the app will need to convert the weights in built-in programs into that unit when you pick them.

Next we can configure the equipment we have, and hide the ones we don't have. Equipment is used for rounding weights, and for the plates calculator. For each equipment we can specify the bar and the plates we have, which would be used for rounding the weights. Totally optional and we can do it later, so we can skip for now.

Now we can choose a built-in program, create our own, or just go without a program. Liftosaur really works best if you have the program you follow, but there're also ways to gradually build it over time as well. There're filters at the top to help you find the program that fits your goals, your schedule, how much time you can spend in a gym, etc. Let's choose e.g. GZCLP to start with.

GZCLP uses 1RM to calculate starting weights, so we can specify them now (or later, we can skip it as well). I can enter my 1RM here, and also use 1RM calculator if I don't know my 1RMs, but know e.g. 5RMs.

Workouts

Okay, now we can do workouts. We can just go ahead and use the default GZCLP, and later I can show how we could also change every bit of it.

On the workout screen, all the weights and reps already prefilled, so for most programs you just tap the check icon when you finish what's prescribed.

The weights are rounded to your equipment, so make sure you've got the right bar weight and plates set up, and it'll set the right weights you can do with your equipment.

When you finish a set, the rest timer shows up. You can specify the rest time either globally, or per program exercise.

Let's say we did successfully all the sets, and we can see it will increase the weight next time. We can switch over to the next exercise.

For the T2 exercise, we can pretend we failed the last set. And we can see the app will switch to a different set scheme (stage 2) next time - instead of 3x10, we'll do 3x8 next time.

Now we're done with the workout, and we can optionally share it in social media or privately, sync to Apple Health, and continue.

Programs

We can see that workout in the history now. In the app, there're 2 main entities - workouts and programs. The only thing that the program does - it defines what the next workout will look like, nothing else. So, you can switch programs at any time, run multiple at the same time, go without program - the only thing that it'll change - what the next workout will look like.

When you finish a workout, it changes the current program. The program under the hood is just plain text, so when you finish a workout - it rewrites that text, with the new weights, reps, sets, etc. That's how it does the progression - it changes the program when workout is finished. All the scripts defined in the program are evaluated, and new program text is generated.

If we go to Program screen, we could actually see and edit the program text. Go to Edit, then tap this coding icon. The program is written using special markup/scripting language called Liftoscript. You can define the weeks, days, exercises, and write the progression logic right there. The syntax is simple, and you don't have to define scripts, you can just use built-in progressions, like linear or double progression.

Programs being just text is a very powerful concept. You can easily share them, you can store them even in your Notes, you can edit them in any text editor. Liftosaur provides IDE for that, so it'd have autocomplete, error checking, etc - both in the app or on the web, in a browser. Editing a lot of text on a phone could be quite inconvenient, so it's usually easier to do that from a laptop.

You don't have to use the text editing though (although it's IMHO the most convenient for large-scope changes). Everything you can do through the text - you can also do through UI, and it's sometimes more convenient if you just need to do small tweaks in your program, like adjust the weight or reps of some exercise, tweak the increments of progression, etc.

Like, this is how I could change the weight, or adjust the increment for progression - go to T1, and do that there. I could do that per set, or just across all of the sets. This is especially useful if you do multi-week programs, so you could tweak weights used across multiple weeks/days.

Now, this is a vanilla GZCLP with just one T3 exercise added - it's a lat pulldown or bent over row. I want to tweak the program, and maybe add a few more T3 exercises. I personally like to do that on my laptop, just because there's larger screen and a keyboard to type faster. Let's check out the web editor for that.

Web Editor

If you open liftosaur.com, you can log in there, go to Your Programs, and edit our GZCLP program.

Here, on the right you can see Week Stats. This is rather important info that helps you to ensure you've got enough volume for the muscle groups you care about. Let's walk it over.

At the top I could see the total sets and split between strength and hypertrophy. It's simply - if it's >= 8 reps - it's hypertrophy. Otherwise - strength. Then, split between core, upper, lower, push and pull sets.

The most important part is below though. It's a weekly number of sets per muscle group. Research shows that you need to hit muscles 10-20 sets per week, 2-3 days per week to get good growth. More for advanced lifters, less for beginners. Here you can see that number per muscle group. If we hover over with the mouse, we'll see what exercises that comes from. Black means that exercise directly targets that muscle, gray - it's a synergist muscle. We use multiplier for synergist muscles, 0.5 by default.

Colors and arrows show whether we're outside of the range - red means significantly outside, yellow - a bit outside, green - within the range. Arrow shows whether we need to increase or decrease the number of sets to get to the range. The range is defined in Settings, and you can change the range there, and also change the synergist multiplier.

So, we can see we're kinda weak on biceps, triceps and forearms, so let's add some exercises to hit those muscles more. We can tap on the muscle group there to filter by it, so for triceps we can add Skullcrushers, for biceps - bicep curls, can also add hammer curl for forearms too, and e.g. Triceps Extension.

Now we can save it, and enjoy our updated GZCLP program. If we open the app now, it will sync the updated program, and we can do workouts with it.

That's the main functionality of the app. There's more stuff - there're graphs, RPE support, body measurements, etc, etc, and the Liftoscript language allows you to do a lot of things.

So, check it out, and hopefully this gives you a good overview of the app!

Documentation | Liftosaur

2026-10-09T02:50:33Z

Contact Us

If you have any questions, don't hesitate to contact us at info@liftosaur.com!

Summary

Liftosaur is an app that combines both weightlifting programming part (that people sometimes use Google Sheets for) and workouts tracking part. I.e. it consists of 2 steps:

You choose and clone a built-in program or create your own program. Program will prescribe what exercises to do over weeks/days, with what sets x reps x weight, and how to progress over time (i.e. applying progressive overload).
You run that program and track your workouts and your progress.

Any built-in program is built using existing Liftosaur features, so those programs are completely customizable - you can change every bit of them.

Instead of clicking around to add exercises like in other apps, Liftosaur takes a different approach - you create the programs by typing your exercises, sets, reps, etc in a text field, using special syntax called Liftoscript. There's some learning curve because of that, but the syntax is very simple and autocomplete helps, and once you get familiar with it - you can create and edit the programs very quickly and efficiently.

The syntax is pretty similar to how people already often describe their programs. Let's take a look!

Basics

Each exercise goes on a separate line. It consists of sections separated by a slash (/). First goes the exercise name, and then in any order - the sections. The simplest exercise is written like this:

Bench Press / 3x8

You can do rep ranges too:

Bench Press / 3x8-12

You can list multiple sets, separated by commas, like this:

Bench Press / 1x5, 1x3, 1x1, 5x5

That would be 8 sets total - first 5 reps, then 3 reps, 1 rep, and then 5 sets of 5 reps.

If you specify neither the weight nor the RPE, like here:

Bench Press / 3x12

then the weight field will be empty during the workout, and you'll have to enter the weight yourself to finish a set.

But if you specify the RPE, the weight will be calculated from RPE tables, like this one. So, if you write:

Bench Press / 3x12 @8

it'll check in the RPE table that for 12 reps at @8 RPE you probably should use 60% of 1RM, so it'll set the weight to 60% of 1RM under the hood. @10 RPE means going til failure - for 12 reps that'd be 65% of 1RM.

You can specify the weight explicitly, as a percentage of 1RM, like this:

Bench Press / 3x12 80%

Or you can specify the weight in kg/lb, like this:

Bench Press / 3x12 60kg

RPE, percentage and weight can be specified for each set or range of sets individually, so you can mix and match:

Bench Press / 1x5 @8, 1x3 @9, 1x1 @10, 5x5 50%

You can specify the rest time. E.g. this is how you could do myo-reps - i.e. doing heavy 12, and then doing 5x5 with short rest times and same weight:

Bench Press / 1x12 20s 60%, 5x5 20s 60%

You can also specify the rest time, weight, 1RM percentage and RPE also, for all sets, so you don't have to repeat yourself. Do it in a separate section like this:

Bench Press / 1x12, 5x5 / 20s 60%

To add AMRAP sets, add + after the reps number. And to log RPE, add + after the RPE number. Like this:

Bench Press / 4x5, 1x5+ @8+

If you want to enable "Quick add sets" feature (where you may have more sets than you planned), add + after the set number:

Bench Press / 3+x5

And if you want the app to ask you what was the weight you did (similar to AMRAP reps), you can add + after the weight:

Bench Press / 3x8 / 100lb+

Bench Press / 1x6 70%+, 5x5 50%

An example workout may look something like this:

Bench Press / 3x5 80% Incline Bench Press / 3x8-12 @8 / 90s Skullcrusher / 3x15 @8 Lateral Raise / 3x15 @8

By default, it'll use the default equipment - e.g. for Bench Press it'll use Barbell. If you want to specify a different equipment, then add it after the exercise name, like this:

Bench Press, Dumbbell / 3x5

Full mode, weeks and days

There's a way to switch to the "Full Mode", where your whole program is just one blob of text. There, to specify different weeks/days, you use this syntax:

# Week 1 ## Day 1 Squat / 5x5 / progress: lp(5lb)

## Day 2 Squat / 3x8

# Week 2 ## Day 1 Squat / 5x4

I.e. prefixing week names with #, and day names with ##.

Exercise Descriptions

You can add descriptions to exercises via // comments, like this:

// Pause **2 seconds** at the bottom Squat / 5x5 / progress: lp(5lb)

# Week 1 ## Day 1 // Pause **2 seconds** at the bottom Squat / 5x5 / progress: lp(5lb)

# Week 2 ## Day 1 Squat / 5x5 / progress: lp(5lb)

# Week 3 ## Day 1 // Squat / 5x5 / progress: lp(5lb)

# Week 4 ## Day 1 Squat / 5x5 / progress: lp(5lb)

In this case, Week 1 and Week 2 will have the description about the pause, and Week 3 and Week 4 won't.

Week and day descriptions

You can also add descriptions to weeks and days. You can also use Markdown syntax there, and the day descriptions would be reused in the following days, until you overwrite them - same logic as for Exercise Descriptions.

You can add them through UI, or in the full mode, you also can add them as comments to # Week and ## Day lines, like this:

// This is a description for week 1 // * Do this // * Then do that # Week 1 // This is a description for day 1 // **Very important to do this:** ## Day 1 Squat / 5x5 / progress: lp(5lb)

Exercise Labels

# Week 1 ## Day 1 main: Squat / 5x5 / progress: lp(5lb)

# Week 2 ## Day 1 accessory: Squat / 3x8 / progress: dp(5lb, 8, 12)

Set Labels

If you can add labels to the sets (8 characters max!), just putting them in parentheses () when you specify the sets x reps:

Squat / 4x5 (Main), 1x5+ (AMRAP) / progress: lp(5lb)

Warmups

By default, it will add some warmups, but if you want to change that, you can use warmup section, like this:

Squat / 5x5 / warmup: 1x5 45lb, 1x5 135lb, 1x3 80%

Syntax is very similar to the regular sets x reps, but you cannot specify timer and RPE there. Also, percentages are not 1RM percentages, but percentages of the weight of the first set.

If you don't want warmups at all, you can specify warmup: none:

Squat / 5x5 / warmup: none

Supersets

You can group exercises into supersets via superset section, like this:

Squat / 3x8 / superset: A Deadlift / 3x8 / superset: A Bent Over Row / 3x8 / superset: A Bicep Curl / 3x8

That would group Squat, Deadlift and Bent Over Row into the Superset A. When you run the workout, after you complete a set of Squat, it'll switch to Deadlift, then to Bent Over Row, and then back to Squat for the second round, and so on.

The syntax looks like superset: GROUP_NAME, where GROUP_NAME could be any string. By default they use superset default rest timer (which you can set up in Me -> Timers), but you can override it with per-set timers. For example:

Squat / 3x8 / superset: A Deadlift / 3x8 / superset: A Bent Over Row / 3x8 180s / superset: A

If you have superset default rest timer set to 15s, then Squat and Deadlift would use 15s rest between sets, and Bent Over Row would use 180s rest.

Progressive overload

It's very important to incorporate progressive overload into your workouts - how you will increase sets, reps, weight, etc over time, to give stimulus for your muscles to grow. In Liftosaur, you can specify progressions for your exercises, and the app will automatically change weights/reps/etc based on the conditions you specify.

There're 3 built-in types of progressive overload:

Linear Progression (lp) - increase or decrease the weight by a fixed amount or percentage after N attempts.
Double Progression (dp) - increase the reps within a range, then reset the reps and increase the weight.
Reps Sum (sum) - increase the weight if the total sum of reps of all sets more than the threshold.

You can add a progression like this:

Bench Press / 3x8 / progress: lp(5lb)

That would increase the weight after each successful completion of 3 sets x 8 reps by 5lb. You only need to add it to one of the days in your program per exercise, no need to repeat it week over week or day over day. It will be applied to all such exercises in a program. You may disable progression for specific days or weeks via progress: none section - for example if that's a deload week. For example:

# Week 1 ## Day 1 Bench Press / 3x8 / progress: lp(5lb)

# Week 2 ## Day 1 /// We don't need to specify progress here, but it still would be applied - same lp(5lb) Bench Press / 3x8

# Week 3 ## Day 1 /// That's a deload week - we want to disable progression for that day Bench Press / 3x8 / progress: none

If you try to specify different progressions for the same exercise in different weeks/days, it'll give you an error - the progressions are applied for an exercise across whole program. You cannot have e.g. linear progression on day 1, and double progression on day 2.

There's a way to have e.g. 2 Bench Press exercises with different progressions though - you can add labels to exercises, and they would be considered different exercises in that case. Label is just some word before an exercise name, with a colon : after it. For example - aux: Bench Press or strength: Squat or anything like that.

So with labels, e.g. you have low-rep range Bench Press and high-rep range Bench Press in your program, and you want both of them have Double Progression, but in different ranges. You could do it like this:

# Week 1 ## Day 1 lowrep: Bench Press / 3x3 / progress: dp(5lb, 3, 6)

## Day 2 highrep: Bench Press / 3x8 / progress: dp(5lb, 8, 12)

Linear Progression

Linear Progression is when you add weight after N (1 or more) successful finishing of all sets and reps, and optionally - also reducing the weight after N (1 or more) unsuccessful finishing of all sets and reps.

You add Linear Progression to exercises by specifying lp progress type, like this:

Bench Press / 3x8 / progress: lp(5lb)

In parenthesis after lp you specify the weight values and conditions for the Linear Progression. It can take 6 arguments max, separated by commas, and this is their meaning:

lp(weight increase, increase attempts, current increase attempt, weight decrease, decrease attempts, current decrease attempt)

You don't have to specify all the arguments, for example if you don't want decreasing weights after failures - you may skip 3 last arguments.

For example:

/// increase by 5lb after 1 successful attempt Squat / 3x8 / progress: lp(5lb)

/// increase by 5lb after 2 successful attempts Squat / 3x8 / progress: lp(5lb, 2)

/// increase by 5lb after 2 successful attempts, and already had 1 successful attempt Squat / 3x8 / progress: lp(5lb, 2, 1)

/// increase by 5lb after 2 successful attempt, and decrease by 10lb after 3 unsuccessful Squat / 3x8 / progress: lp(5lb, 2, 1, 10lb, 3)

/// You can also use percentages for increase (instead of absolute values) Squat / 3x8 / progress: lp(5%)

Double Progression

Double Progression is when you increase reps after successful finishing your sets x reps within some range, and after that - increase the weight. It's good for exercises when you cannot apply Linear Progression easily (e.g for Bicep Curl, adding 5lb each time would stop working quickly), or when you already past the phase when you can add 5lb each session even for big lifts like Squat or Bench Press.

It looks like this:

dp(weight increase, min reps, max reps)

For example:

// Increases the reps from 8 to 12 reps, then adds 5lb to weight and // goes back to 8 reps Bench Press / 3x8 / progress: dp(5lb, 8, 12)

// Increases the reps from 6 to 10 reps, then adds 5% to weight and // goes back to 6 reps Bench Press / 3x6 / progress: dp(5%, 6, 10)

Sum Of Reps Progression

Simply adds weight if the total sum of all reps across all sets is more than the threshold. Looks like this:

sum(reps threshold, weights increase)

For example:

// Increases the weight if the sum of all reps is more than 30 Bench Press / 3x10+ / progress: sum(30, 5lb)

Ways to make written programs less repetitive

Weightlifting programs are often very repetitive - you usually have multiple exercises with the same set schemes, using the same waving progressions over weeks. It's important to have ways to not repeat yourself, so it'd be easier to modify the programs, add exercises, change the set schemes, progressions, etc. E.g. a 12-week program with 4-days per week and 5 exercises in each day in total may have 240 places where you specify the sets! And modifying such program would be a very tedious task.

Liftosaur offers a bunch of syntax sugar to make it easier to write and modify the programs.

Reusing the exercises's sets/reps/weight/RPE/timer, warmups and update/progress scripts via `...Squat`

You can reuse the sets/reps/weight/RPE/timer and warmups of another exercise. You can either specify the exact week/day of the exercise to reuse, or by default it'll look into any day of the current week. The syntax for reusing the sets looks like this:

Bench Press / 5x5 / progress: lp(5lb) Squat / ...Bench Press

The Squat would reuse 5x5 sets of the Bench Press from the current week. And if you change 5x5 of Bench Press to e.g. 3x8, that would be applied to Squat as well. The progress part progress: lp(5lb) of the Bench Press also would be reused!

For multi-week programs it may look like this:

# Week 1 ## Day 1 Bench Press / 3x8 Squat / ...Bench Press

# Week 2 ## Day 1 Bench Press / 3x9 Squat / ...Bench Press

# Week 3 ## Day 1 Bench Press / 3x10 Squat / ...Bench Press

So, Squat would be 3x8 on week 1, 3x9 on week 2, and 3x10 on week 3, because by default it tries to find the original exercise in the any day of the same week.

You can also specify the exact week/day to reuse the exercise from, by syntax ...Bench Press[day] (in the current week) or ...Bench Press[week:day]. Like this:

# Week 1 ## Day 1 Bench Press / 3x8 Squat / ...Bench Press[2]

## Day 2 Bench Press / 5x5 Deadlift / 3x3

This way Squat would use 5x5, and not 3x8.

# Week 1 ## Day 1 Bench Press / 3x8 Squat / ...Bench Press[2:1]

# Week 2 ## Day 1 Bench Press / 5x5 Deadlift / 3x3

And this way Squat also would use 5x5 from Bench Press on week 2, day 1.

You can also override anything in the reusing exercise, like this:

# Week 1 ## Day 1 Squat / 3x8 200lb 60s Bench Press / ...Squat / 150lb

Bench Press would be 3x8 150lb 60s in this case. Or like this:

# Week 1 ## Day 1 Squat / 3x8 200lb 60s / update: custom() {~ // some update logic ~} / progress: lp(10lb) Bench Press / ...Squat / 150lb / progress: lp(5lb)

In this case, Bench Press would have the same update logic as Squat, but instead of 10lb Linear Progression, it'd have 5lb.

One thing to note that if the reused exercise changes their weight, sets, reps, etc - after finishing a workout the app would try to extract the new values into overrides. For example, if you have the following setup:

Bench Press / 3x8 75% / progress: lp(5lb) Squat / ...Bench Press

And then you finished all sets of Squat successfully. That will change the weight of Squat, and the program now would look like this:

Bench Press / 3x8 75% / progress: lp(5lb) Squat / ...Bench Press / 185lb

I.e. the app notices that the weight of the Bench Press and Squat are not the same anymore, so it extracts the weight of Squat into override.

And if you progress in Bench Press - then ALL the reused exercises would move the weights into overrides - because it just went unsync with them.

Repeating the same exercise over multiple weeks via `Squat[1-4]`

Usually in multi-week programs, you have exactly the same exercises on the same days over multiple weeks. So, to avoid typing them over and over, you can specify that the same exercise would be repeated over multiple weeks, by specifying a range of weeks after exercise name.

Bench Press[1-5] / 3x8

The syntax is Squat[fromWeek-toWeek]. If you do that, you don't have to type Bench Press / 3x8 on weeks 2-5. In the full day mode, your days would be empty, and in the per-day mode - the exercises would be listed under the text input on the repeated days, but would be uneditable.

# Week 1 ## Day 1 Bench Press[1-4] / 3x8

# Week 2 ## Day 1 # Week 3 ## Day 1 # Week 4 ## Day 1

Like this - you don't need to write it in the weeks 2-4.

This works especially nice in combination with the previous feature - reusing sets/reps/weights/etc. In multi-week programs, you specify the weekly undulation for one of the exercises, and then other exercises reuse and repeat it, like this:

# Week 1 ## Day 1 Squat / 3x8

## Day 2 Bench Press[1-4] / ...Squat

# Week 2 ## Day 1 Squat / 3x9

## Day 2 # Week 3 ## Day 1 Squat / 3x10

## Day 2 # Week 4 ## Day 1 Squat / 3x11

## Day 2

When repeating, it tries to preserve the order of exercises, but things may get ambiguous if you have multiple exercises starting repeating in various days. In that case, you can specify the order of exercises, within square brackets, like Squat[order,fromWeek-toWeek] or just Squat[order] for non-repeating exercises.

Squat[1,1-4] / 3x8 Bench Press[2,1-4] / 3x8 Bicep Curl[3,1-4] / 3x8

Reusing descriptions

Exactly the same idea as with reusing sets:

# Week 1 ## Day 1 // T1 exercise. Work up to 3RM, and then do 4 singles. Squat / 1x3 80%+, 4x1 80%

## Day 2 // ...Squat Bench Press / 1x3 80%+, 4x1 80%

Bench Press would reuse the description of Squat, and it'd be T1 exercise. Work up to 3RM, and then do 4 singles. too. You can use the same syntax as for reusing sets, like // ...Squat[3:2] to reuse the description from week 3, day 2, or // ...Squat[3] to reuse the description from the current week's day 3.

Exercise templates (or unused exercises) via `/ used: none`

With the features like above, it's often pretty convenient to specify a "template" exercise, which wouldn't be used in a program, but would work as a template for other exercises. To do that, you can specify an exercise and remove it from a program with the / used: none section, like this:

Squat / 1x10+, 3x10 / 70% / used: none / progress: lp(5lb) Bench Press / ...Squat

In this case, the Squat would be used as a template for Bench Press, but wouldn't be used in the program itself.

It's not required that the exercise existed if it's marked as used: none, so you can give the templates arbitrary names:

T1 / used: none / 1x10+, 3x10 / 70% / progress: lp(5lb) t1: Bench Press / ...T1

Templates also solve the problem of the original exercise changing e.g. their weight and therefore breaking the reusing. Since templates would never progress, they would never break the reusing. The reused exercises still may break reusing on progression, but at least only for that specific reused exercise, not for all of them.

Combining it all together

These features work the best when combined together. For example, you can have a template exercise, and then reuse it over multiple weeks, and use repeat syntax to avoid repeating the reused exercises across all weeks. E.g. an example program may look something like this:

# Week 1 ## Day 1 /// Specifying templates for our exercises t1 / used: none / 1x6, 3x3 / 80% t2 / used: none / 1x8, 3x4 / 70% t3[1-4] / used: none / 3x10+ / 60% / progress: sum(30, 5lb)

/// Now the actual exercises: Squat[1,1-4] / ...t1 Romanian Deadlift[2,1-4] / ...t2 Bicep Curl[3,1-4] / ...t3

## Day 2 Bench Press[1,1-4] / ...t1 Overhead Press[2,1-4] / ...t2 Lat Pulldown[3,1-4] / ...t3

## Day 3 Deadlift[1,1-4] / ...t1 Front Squat[2,1-4] / ...t2 Hanging Leg Raise[3,1-4] / ...t3

# Week 2 ## Day 1 /// Now we only need to specify undulating sets for main templates exercises t1 / 1x7, 3x4 / 80% t2 / 1x9, 3x5 / 70% ## Day 2 ## Day 3 # Week 3 ## Day 1 t1 / 1x8, 3x4 / 80% t2 / 1x10, 3x5 / 70% ## Day 2 ## Day 3 # Week 4 ## Day 1 t1 / 1x9, 3x5 / 80% t2 / 1x11, 3x6 / 70% ## Day 2 ## Day 3

Advanced

What's described above is probably enough to cover 95% of the use-cases. But in case you want some custom progressions, you can do it with a special progress: custom() Liftoscript syntax.

There, you can unleash the full power of the scripting in Liftosaur. You can directly change weights, reps, sets, timers, RPE, etc using if/elses, state variables, math and boolean logic.

E.g. this is how a variant of Linear Progression - increasing weight by 5lb if first set was successful - would look like:

Bench Press / 3x8 / progress: custom() {~ if (completedReps[1] >= reps[1]) { weights += 5lb } ~}

If you have ever written scripts in JavaScript, Python, or a similar programming language (or even Excel!), this Liftoscript will look very familiar. If not, no worries, it's a pretty simple and small language.

In the example above, we increase the weight of all sets by 5lb if the completed reps of the first set were equal or more than required number of reps of the first set. Let's take a look at the syntax closer.

The logic is written in the curly braces with tildes - i.e. between {~ and ~}. Inside those curly braces you can access required reps, completed reps, weights, RPE, etc of all the sets that were finished for that exercise, and you can update weights/reps/etc of the program based on that.

The conditional logic written with if (...) { ... } sentence. In the parenthesis you specify the condition when the block of the if should happen. completedReps[1] gives you the number of completed reps of the first set ([1] part - arrays indexes start from 1), and reps[1] gives you the number of required reps that were defined for that set. So completedReps[1] >= reps[1] means that completed reps of the first set are equal or more than the required reps of the first set.

For convenience, you can also check if all completed reps of all sets are equal or more than required reps. You could do: completedReps >= reps (i.e. omit [1] part). It works for all the arrays (weights, reps, RPE, etc) - e.g. you can do weights >= 50lb - it is true if all the weights of all the sets are equal or more than 50lb.

weights += 5lb means we should increment the weights of all sets by 5lb. You can be more specific, e.g. you may want to increment the weight of only one set - e.g. second set - weights[2] += 5lb, or you can increment all weights for the exercise on week 2 day 3, then you could do: weights[2:3:*:*] += 5lb.

Instead of incrementing weights, you can directly assign values to them. E.g. weights = weights[numberOfSets] + 5lb would set all the weights equals to the weight of the last finished set and add 5lb to it.

This is the list of available variables you can get values from in your progress: custom() scripts:

weights[n] or w[n] - initial weight after rounding of an N set. N starts from 1.
originalWeights[n] or cw[n] - initial weight before rounding of an N set. N starts from 1.
completedWeights[n] or cw[n] - completed weight of an N set. N starts from 1.
reps[n] or r[n] - number of reps for an N set.
completedReps[n] or cr[n] - number of completed reps for an N set.
completedRepsLeft[n] - number of completed reps for the left side for unilateral exercises for an N set.
RPE[n] - if exercise has RPE - the RPE expression that's required for an N set.
completedRPE[n] - if exercise has RPE, and the set is marked as Log RPE - RPE that user entered for an N set.
timers[n] - if the exercise sets have explicit timer set up - value of that timer
rm1 - 1 Rep Max of a current exercise. You can set it in the Exercise Stats section (if you tap on exercise name on the workout screen)
day - current day number, starting from 1.
week - for multi-week programs - current week number, starting from 1.
dayInWeek - current index of day in week, starting from 1.
programNumberOfSets - how many sets was prescribed by a program.
numberOfSets or ns - how many sets were in the exercise (could be changed by adding/removing sets during workout).
completedNumberOfSets - how many sets are completed (by a checkmark).
setVariationIndex - current set variation index (see below about set variations)
descriptionIndex - current description index
amraps[n] - whether to mark the set AMRAP, 1 for AMRAP, 0 for not AMRAP
logrpes[n] - whether to ask user what was the actual RPE, 1 to ask, 0 to not ask
askweights[n] - whether to ask user what was the actual weight, 1 to ask, 0 to not ask

And this is the list of available variables you can change (assign new values):

The weights/reps/RPE and timers:

weights
reps
RPE
timers
amraps
logrpes
askweights

For those, you can specify what set, set variation, day or week you want to change it in. To target specific set, you use the following syntax:

weights[week:day:setvariation:set]

Where the values of week/day/setvariation/set is either a number (or expression that calculates to a number), or * - that'd mean any week/day/setvariation/set.

If you omit any leading value, it's assumed it's a *. For example:

Bench Press / 3x8 / progress: custom() {~ // Changes the weights across all sets for the exercise weights = 50lb // same as weights[*:*:*:*] = 50lb

// Changes the 5th set across all weeks/days/setvariations weights[5] = 50lb // same as weights[::*:5] = 50lb

// Changes the 5th set in 3rd day across all weeks/setvariations weights[3::5] = 50lb // same as weights[:3:*:5] = 50lb ~}

You can also change 1RM of an exercise, via assigning to rm1 variable:

Bench Press / 3x8 / progress: custom() {~ rm1 = weights[1] ~}

You can also set the values of the following variables:

setVariationIndex
descriptionIndex

But more about those below in the section about "Set Variations" and "Advanced Descriptions"

State Variables

Sometimes you need to remember some values between the workouts. For example, you want to increase the weight after 3 successful attempts, so you need to know what is the current attempt, and how many already happened.

For that, you can use state variables. Those can hold the value between the workouts. You list them inside the parenthesis of custom(), and then refer to them within the {~ ... ~} block. For example:

Bench Press / 3x8 / progress: custom(attempt: 0) {~ if (completedReps >= reps) { state.attempt += 1 if (state.attempt > 3) { weights += 5lb state.attempt = 0 } } ~}

The attempt variable will be increased across workouts, and then reset to 0 once you hit 3 successful attempts.

Another use case for the state variables is in reusing the progress: custom() logic. The scripts can become pretty large, and usually you want multiple exercises to follow the same logic. So, for that you can reuse it! For that, just specify the exercise you're reusing the logic from like this: Bench Press / 3x8 / progress: custom() { ...Squat }. I.e. add it within the curly braces - { and } (without tildes! So the app would know it's not the script itself). For example, if we want to reuse the logic above, it'd look like this:

Bench Press / 3x8 / progress: custom(attempt: 0) {~ if (completedReps >= reps) { state.attempt += 1 if (state.attempt > 3) { weights += 5lb state.attempt = 0 } } ~}

Squat / 3x8 / progress: custom(attempt: 0) { ...Bench Press }

But we may want to have higher weight increments for Squat. For that, we can parameterize the script with the state variables! Let's add another state variable increment, and use it in the script:

Bench Press / 3x8 / progress: custom(attempt: 0, increment: 5lb) {~ if (completedReps >= reps) { state.attempt += 1 if (state.attempt > 3) { weights += state.increment state.attempt = 0 } } ~}

Squat / 3x8 / progress: custom(attempt: 0, increment: 10lb) { ...Bench Press }

You can see that now we use state.increment in weights += state.increment expression. And we use different values for increment - 5lb in Bench Press and 10lb in Squat.

There's also a way to define user-prompted state variables. For that, add a + sign after the variable name, like this:

Bench Press / 3x8 / progress: custom(shouldBumpWeight+: 0) {~ if (shouldBumpWeight > 0) { weights += 5lb } ~}

In this case, after the last set the app will ask the user for the shouldBumpWeight value. And if user enters 1, the weight would be increased. Otherwise - it'd stay the same.

When reusing progress logic, you may omit the variables with the same value. I.e., this:

Bench Press / 3x8 / progress: custom(attempt: 0, increment: 5lb) {~ // ...some logic ~}

Squat / 3x8 / progress: custom(attempt: 0, increment: 10lb) { ...Bench Press }

and this:

Bench Press / 3x8 / progress: custom(attempt: 0, increment: 5lb) {~ // ...some logic ~}

Squat / 3x8 / progress: custom(increment: 10lb) { ...Bench Press }

are equivalent (note we skipped attempt: 0 in the second example).

Temporary Variables

Sometimes you want to store long math expression value in a variable to use it across the script. You can do it with temporary variables. The syntax looks like this - var.foo = 30lb. I.e. they should be prefixed with var.. For example:

Bench Press / 3x8 / progress: custom() {~ var.foo = floor(completedReps[1] / 2) if (completedReps >= reps) { reps[2] = var.foo reps[3] = var.foo reps[4] = var.foo } ~}

Loops

There's also a way to iterate over the sets with loops. It looks like this:

Bench Press / 3x8 / progress: custom() {~ for (var.i in completedReps) { weights[var.i] = weights[var.i] + 5lb } ~}

That would set the weights of the next workout to 5lb more than finished weights of this workout. The syntax is for (var.i in weights), where var.i should always be a temporary variable (i.e. start with var.), and the expression on the right side of in should return an array. The var.i would contain the index of each set, starting from 1.

Prints

For debugging purposes, there's print function. You can use it to debug your scripts. Liftoscript doesn't support strings, so you can only pass numbers, weights or percentages there. It looks like this:

print(1, 20lb, 30%) print(100, weights[1], completedReps[2]) print(var.max)

It accepts any number of arguments, and you'll see all the prints either in playground or when you finish exercise during workout, after all sets are done.

Update

progress: logic updates the weights/reps/etc in the program, after you finish a workout. But there's also a way to update sets while you're doing a workout! For example, you want to set the number of drop sets or dropset reps based on the first set completed reps, or something like that.

For that, you can use update: custom() syntax, which is very similar to progress: custom(). The difference is that you cannot change program state variables, and you cannot access the program at all - only read the program state, and the currently ongoing workout values. The script would be run before completing any sets (with setIndex == 0), and then every single time user taps on a set.

So, the list of variables you can get values from is pretty much the same:

weights
originalWeights
completedWeights
reps
completedReps
completedRepsLeft
RPE
completedRPE
rm1
day
week
dayInWeek
programNumberOfSets
numberOfSets
completedNumberOfSets
setVariationIndex
descriptionIndex
amraps
logrpes
askweights
setIndex - index of a set that was tapped (it's 0 for the initial run - before completing any sets)

But assigning new values is only allowed to the following:

weights
reps
RPE
timers
numberOfSets

So, to change the 2nd set, you do weights[2] = 60lb, and to change all sets, you do weights = 50lb. You cannot change the sets that already completed, if you try that, it'd be ignored.

You cannot change other set variations, weeks or days, so syntax like weights[1:2:3:4] is not allowed, you can only do weights or weights[1].

By changing numberOfSets you can add or delete sets. E.g. if you had 2 sets, and you do numberOfSets = 5, you'll add 3 more sets. You can also delete the sets - if you had 5 sets, and you do numberOfSets = 2, it'd delete last 3 sets. But again - only if they weren't already finished.

By default, it will add the same sets as the last set in that exercise. If you want to tweak new sets (or change existing), you can use sets() function. It accepts 9 arguments (!), and looks like this:

sets(fromIndex, toIndex, minReps, maxReps, isAmrap, weight, timer, rpe, shouldLogRpe)

If minReps and maxReps are diffrent, it'll make it a rep range. isAmrap and shouldLogRpe should be 0 or 1 (1 means it's enabled).

Using all of that, we can implement the example above - based on how many reps we did - add 3 sets and set the reps to half of the first set reps.

Bench Press / 3x8 / update: custom() {~ if (setIndex == 1 && completedReps[1] >= reps[1]) { numberOfSets = 4 sets(2, 4, floor(reps[1] / 2), floor(reps[1] / 2), 0, weights[1], 0, 0) } ~}

floor(reps[1] / 2) makes sure that if there's a reminder when dividing by 2, we round it down. Like 5 / 2 -> 2.

You usually would want to always add a condition on setIndex, to ensure you're running the update script at the right time, and also to distinguish initial run (wth setIndex == 0) and runs when you complete sets.

We can also reuse the update scripts, similarly to the progress: custom() scripts, with { ...Squat } syntax:

Bench Press / 3x8 / update: custom() {~ if (setIndex == 1 && completedReps[1] >= reps[1]) { numberOfSets = 4 sets(2, 4, floor(reps[1] / 2), floor(reps[1] / 2), 0, weights[1], 0, 0) } ~}

Squat / 3x8 / update: custom() { ...Bench Press }

You can specify both update: custom() and any progress: within the same exercise.

Number of sets

To do number-of-sets-based progressions, you can use numberOfSets variable in your progress scripts, similar to how you could do it in the update scripts. E.g. this is how you could setup a set-based double progression (which would increase sets from 3 to 5, and then would increase weight and reset sets back to 3):

Squat / 3x8 / progress: custom() {~ if (completedReps >= reps) { if (numberOfSets < 5) { numberOfSets += 1 } else { weights += 5lb numberOfSets = 3 } } ~}

You can also target specific weeks/days/setvariations if you want to. E.g. if you only want to change the number of sets on week 2, day 3, set variation 1, you can do numberOfSets[2:3:1] += 1.

Set Variations

Sometimes you may want to have multiple sets x reps schemes within the same exercise, and switch between them on some condition. For example, in a popular weightlifting program called "GZCLP", you do 5x3 sets, but if you fail, you switch to 6x2 sets, and then - to 10x1 sets. To program that in Liftosaur, there's a concept of "set variations" - so that you can specify several set schemes and switch between them. Example above may look like this:

Squat / 5x3 / 6x2 / 10x1 / progress: custom() {~ if (completedReps >= reps) { weights = weights[ns] + 5lb } else { setVariationIndex += 1 } ~}

There, we increase the weight by 5lb if we successfully finished the sets. But if not - we'll increment setVariationIndex, which would become 2, and the next time the first line of the exercise will look like:

Squat / 5x3 / ! 6x2 / 10x1 / progress: custom() {~

Note the exclamation mark ! at 6x2 - that means that this is the current set variation. Putting that exclamation mark in front of a set variation makes it currently selected.

So, to define the set variations you just list them separated by /, and then use the setVariationIndex in the script to define the logic when to choose which set variation. And the app tracks which one is the current one by the ! character.

Advanced Descriptions

Similarly to set variations, you can specify mutliple descriptions per exercise, and switch between the current one by assigning to the descriptionIndex variable. The current one is marked the same as in set variations - by !.

To add mutliple descriptions, simply leave an empty line between them, like this:

// This is the first description. // We explain here how to do an exercise // This is second description. Users already know what to do. Squat / 5x3 / 6x2 / 10x1 / progress: custom() {~ if (descriptionIndex == 1) { descriptionIndex = 2 } if (completedReps >= reps) { weights += 5lb } ~}

After finishing the first workout, you'll notice the program now marks the currently selected description:

// This is the first description. // We explain here how to do an exercise // ! This is second description. Users already know what to do. Squat / 5x3 / 6x2 / 10x1 / progress: custom() {~ if (descriptionIndex == 1) { descriptionIndex = 2 } if (completedReps >= reps) { weights += 5lb } ~}

(note the ! at the beginning of the second description).

Split exercise lines

If the exercise lines get too long, and it becomes inconvenient to read and modify those, you can split them into multiple lines. Just add \ character at the end of a section, like this:

Squat / 1x5 @8 75% 120s, 3x8 @9 60s \ / warmup: 1x5, 1x3, 1x1 \ / progress: lp(5lb)

Script Language Reference

Types

Result of an expression could be a number, weight, percentage or boolean. Number, percentage or weight could be assigned to a state variable. Only number could be used for number of reps for set expressions. Number, percentage or weight could be used for set weight expressions.

Values

The values are numbers (1, 3, 100, 31534532, etc.), and also you can add kg or lb suffix to the number to indicate that it is a weight (like 1lb, 3kg, 100lb, 31534532kg). You can also add '%' to indicate this is percentage (of 1 Rep Max)

Using lb/kg is recommended for when you deal with weights, because they will be converted to kilograms properly if user selects that unit on the settings screen.

Operators

The following operators are available:

Math: +, -, /, *, % Boolean: >, <, <=, >=, ==, &&, || Ternary operator: for example 3 > 4 ? 1 : 2

If/else

You can add conditional logic to your scripts using if/else statements or ternary operators.

if (completedReps[1] > 5) {
  state.someVar = 10;
}

if (completedReps[1] > 10) {
  state.someVar = 15;
} else {
  state.someVar = 10;
}

if (completedReps[1] > 10) {
  state.someVar = 15;
} else if (completedReps[1] > 5) {
  state.someVar = 10;
} else {
  state.someVar = 5;
}

state.someVar = r[1][4] > 10 ? 15 : 10;

Assignment

You can assign values only to state variables, by = operator:

state.someVar = (10 + 15) * 2;

There's also syntax to add/subtract/multiply/divide to the current value, like this:

state.someVar += 5
state.someVar -= 10
state.someVar *= 2 
state.someVar /= 2

Predefined read-only variables

You cannot assign values to them, but you can use their values. They are:

For `progress: custom()`:

weights[n] or w[n] - initial weight after rounding of an N set. N starts from 1.
originalWeights[n] - initial weight before rounding of an N set. N starts from 1.
completedWeights[n] - completed weight of an N set. N starts from 1.
reps[n] or r[n] - number of reps for an N set.
completedReps[n] or cr[n] - number of completed reps for an N set.
completedRepsLeft[n] - number of completed reps for a left side for unilateral exercises for an N set.
RPE[n] - if exercise has RPE - the RPE expression that's required for an N set.
completedRPE[n] - if exercise has RPE, and the set is marked as Log RPE - RPE that user entered for an N set.
rm1 - 1 Rep Max of a current exercise. You can set it in the Exercise Stats section (if you tap on exercise name on the workout screen)
day - current day number, starting from 1.
week - for multi-week programs - current week number, starting from 1.
dayInWeek - current index of day in week, starting from 1.
programNumberOfSets - how many sets was prescribed by a program.
numberOfSets or ns - how many sets were in the exercise.
completedNumberOfSets - how many sets are completed (by a checkmark).
setVariationIndex - current set variation index (see below about set variations)
descriptionIndex - current description index

For `update: custom()`:

Same as progress: custom(), but also setIndex - index of the set user just tapped.

Predefined write variables

You assign new values to them.

For `progress: custom()`:

weights[day:week:setvariation:set] - weight of a set
reps[day:week:setvariation:set] - number of reps for a set.
RPE[day:week:setvariation:set] - RPE that's required for a set.
timers[day:week:setvariation:set] - timer that's assigned for a set.
amraps[day:week:setvariation:set] - whether to mark the set AMRAP, 1 for AMRAP, 0 for not AMRAP
logrpes[day:week:setvariation:set] - whether to ask user what was the actual RPE, 1 to ask, 0 to not ask
askweights[day:week:setvariation:set] - whether to ask user what was the actual weight, 1 to ask, 0 to not ask
rm1 - 1 Rep Max of a current exercise.
setVariationIndex - index of the current set variation
descriptionIndex - index of the current description
numberOfSets[week:day:setvariation] - number of sets for the exercise in this workout

For `update: custom()`:

weights[set] - weight of a set
reps[set] - number of reps for a set.
RPE[set] - RPE that's required for a set.
timers[set] - timer that's assigned for a set.
rm1 - 1 Rep Max of a current exercise.
numberOfSets - number of sets for the exercise in this workout
amraps[set] - whether to mark the set AMRAP, 1 for AMRAP, 0 for not AMRAP
logrpes[set] - whether to ask user what was the actual RPE, 1 to ask, 0 to not ask
askweights[set] - whether to ask user what was the actual weight, 1 to ask, 0 to not ask

State variables

You can access the state variables you defined via state. prefix. E.g. state.myVar. You can write values into them via assignment operator (=)

state.myVar = 4;

Built-in functions

There are some built-in functions you can use in the expressions. They are:

`rpeMultiplier`

Used for calculating the multiplier of 1RM given the reps and RPE. Like for example, for 13 reps at 9 RPE, it'd return multiplier of 0.6, i.e. you probably would be able to lift 60% of your 1RM for 13 reps at 9 RPE.

state.weight * rpeMultiplier(13, 9);

First argument is the number of reps (1-24), second - the RPE value (1-10).

`floor`

It rounds the number down to the nearest integer.

state.nextWeight = floor(152.4lb);
state.reps = floor(2.7);

`ceil`

It rounds the number up to the nearest integer.

state.nextWeight = ceil(152.4lb);
state.reps = ceil(2.7);

`round`

It rounds the number to the nearest integer.

state.nextWeight = round(152.4lb);
state.reps = round(2.7);

`sum`

Sums all values. Accepts any combination of arrays, individual numbers, and weights as arguments.

if (sum(completedReps) >= 15) {
  state.weight += 5lb;
};
state.total = sum(1, 2, 3);
state.allReps = sum(reps, completedReps);
state.adjusted = sum(10, completedReps);

`min`

Finds the minimum value. Accepts any combination of arrays, individual numbers, and weights as arguments.

state.minWeight = min(weights);
state.smallest = min(7, 2, 5);
state.lowest = min(reps, completedReps);
state.capped = min(10, completedReps);

`max`

Finds the maximum value. Accepts any combination of arrays, individual numbers, and weights as arguments.

state.maxCompletedReps = max(completedReps);
state.biggest = max(2, 7, 5);
state.highest = max(reps, completedReps);
state.floored = max(1, completedReps);

`increment`

It's a function that accepts weight, and returns incremented weight - minimum possible increment of the weight, based on the equipment settings. I.e. it will take into account the available plates, or what's the next fixed weight on the equipment.

weights[1] = increment(completedWeights[1]);

`decrement`

It's a function that accepts weight, and returns decremented weight - minimum possible decrement of the weight, based on the equipment settings. I.e. it will take into account the available plates, or what's the previous fixed weight on the equipment.

weights[1] = decrement(completedWeights[1]);

`sets`

To setup new sets (or change existing), it works only for update: custom(). It accepts 9 arguments (!), and looks like this:

sets(fromIndex, toIndex, minReps, maxReps, isAmrap, weight, timer, rpe, shouldLogRpe)

If minReps and maxReps are diffrent, it'll make it a rep range. isAmrap and shouldLogRpe should be 0 or 1 (1 means it's enabled).

sets(2, 4, 6, 6, 0, 50lb, 8, 0)

This will set 6 reps, 50lb, non-AMRAP, 50lb, @8 RPE (without logging RPE) to sets from 2 to 4.

How to delete your account

If you want to delete your account, go to Settings (cog icon at the bottom right corner), then Account - and there's a button to delete an account.

You can also email to info@liftosaur.com, and I can help with that.

You can delete both local account (all your data stored on a device) and remote account - all your data stored on the servers. All the data there would be deleted permanently.

There're 30 days backups on the servers, so the remote account data will be still in the backups for the next 30 days, and after that it'll be gone completely.