Lagerland Apps — Journal

How long to rest between sets: what the studies found, lift by lift

2026-10-21T00:00:00+00:00

The rest timer is the dullest setting in a training log, and it decides how long a session takes. Five exercises, three sets each, three minutes between sets: that is about 40 minutes of rest. Halve the rest and the session loses about 20 minutes. Whether you lose anything else depends on the lift.

How long should you rest between sets?

Situation	Rest	Where the number comes from
Very heavy compound sets, 1-5 reps	3-5 min	ACSM 2009: 3-5 minutes for advanced lifters training heavy
Compound lifts, 6-12 reps (squat, bench, row, press)	2-3 min	ACSM 2009: at least 2-3 minutes for core lifts; 3 minutes beat 1 in a 2016 trial
Isolation and machine work (curls, raises, leg extensions)	60-90 s	ACSM 2009: 1-2 minutes for assistance exercises; a 2024 meta-analysis saw no clear gain past 90 seconds
High-rep, endurance-focused sets	30-90 s	ACSM 2009: under 90 seconds for local muscular endurance
Opposing-muscle supersets (row + press)	Rest after the pair	2025 meta-analysis: shorter sessions, similar volume and results
Short on time	Cut isolation rest first, then add a set	2022 trial: growth tracked total volume, not rest length

In short: rest longer on the heavy lifts you do first, and on anything where your next set comes up well short of the last one. Rest less on small-muscle work, where shorter rest costs the fewest reps.

What does the research say about rest between sets?

The evidence has moved away from fixed prescriptions. Rest now looks like it matters mainly through the reps it lets you keep.

Source	What it compared	What it found
ACSM position stand, 2009	Guideline, not a single study	At least 2-3 min for heavy core lifts, 1-2 min for assistance work and for hypertrophy, 3-5 min for advanced heavy loading, under 90 s for endurance
Schoenfeld et al., 2016	1 vs 3 min rest, 21 trained men, 8 weeks	3 min gave larger squat and bench 1RM gains and more thigh muscle thickness; no difference in muscular endurance
Grgic et al., 2017	Review of 6 studies on hypertrophy	Short and long rest both build muscle; trained lifters may do better with longer rest
Grgic et al., 2018	Review of 23 studies on strength	Strength rises even with under 60 s; over 2 min looks best for trained lifters, 60-120 s is enough for untrained
Singer et al., 2024	Bayesian meta-analysis, 9 studies	Small hypertrophy benefit for rest over 60 s; no appreciable difference beyond 90 s
ACSM overview of reviews, 2026	137 systematic reviews	Inter-set rest did not affect strength; not enough data to say whether it affects hypertrophy

The 2016 trial is the one most often quoted, and it is a good one: trained men, 3 sets of 8-12 reps on seven exercises, three full-body sessions a week, and rest as the only difference between groups. Its limits are size and length. Twenty-one people over eight weeks can show a difference, but they cannot pin down a precise optimum.

The 2026 ACSM document is the newest and the most cautious. Where the 2009 stand gave specific minutes, the 2026 review gives no rest recommendation at all, because across the reviews it covered, rest length was not a significant factor for strength and the hypertrophy data were too thin to call (Currier et al., 2026).

Rest still matters, though less than effort and total volume, and mostly through its effect on volume.

Why does longer rest help, when it does?

It keeps reps on the later sets. Rest a minute between heavy sets and the second and third sets usually come up short of the first. Over weeks, that is less total work.

Longo et al. (2022) tested this directly. Twenty-eight people trained one leg at a time on knee extensions at 80% of one-rep max for ten weeks, with 1 or 3 minutes of rest and some protocols matched for total volume load. Quadriceps growth followed volume load: about 13% in the long-rest and volume-matched short-rest conditions, about 7% in the others. Strength rose similarly across all of them. The authors concluded that volume load drove the growth and the rest interval itself did not.

Singer and colleagues read their 2024 meta-analysis the same way: the benefit of resting past 60 seconds is probably mediated by smaller losses in volume load, and those losses level off as rest gets longer.

In practice, rest long enough that the next set is not cut short. If you rest less, for time or preference, add a set to make up the reps.

How do you shorten a workout without losing much?

Cut rest on isolation and machine work first. Curls, raises and leg extensions recover quickly between sets. Keep the longer rest on the first heavy compound lift of the day.
Pair opposing exercises. A 2025 meta-analysis in Sports Medicine found supersets cut session time while keeping total reps and volume load similar, with similar long-term strength and hypertrophy. Opposing pairs such as a row with a bench press kept volume best. Pairs with similar movements, such as bench press and dips, reduced it, and supersets in general felt harder and caused more fatigue.
Rest less and add a set. Longo’s volume-matched conditions show this works.

Should you time your rest at all?

I think so, though the reason has little to do with physiology. Any progression rule that moves on reps assumes the reps are comparable from one session to the next. If Tuesday’s sets had two minutes between them and Friday’s had four because you were on your phone, the rep counts in your log are measuring the rest as much as the lifting. That matters most under double progression, where the weight only goes up once every set reaches the top of the rep range.

A timer keeps that variable fixed, and it stops rest creeping the other way on days when you are in a hurry.

This is training information and not medical advice. If you have a heart condition or high blood pressure, or get dizzy during heavy sets, ask a clinician how to approach heavy lifting and rest.

How LiftLog times rest

LiftLog starts the rest timer when you log a working set. Warm-up sets do not trigger it, and neither do timed cardio sets. The timer draws as a ring and has buttons to add or remove 15 seconds or skip.

The default is 90 seconds, with 30 seconds, 1, 2, 3 and 5 minutes available in settings. Each exercise in a program can carry its own rest, and you can change it for an exercise during a workout. The bundled example programs set rest per exercise along the lines of the table above: most heavy sets of five reps or fewer get 3 to 4 minutes, most sets of six to eleven get 1 to 2 minutes, and most high-rep work gets 45 to 60 seconds.

For supersets and giant sets there is no rest between the exercises in a group. The timer starts after the last exercise of the round.

The timer keeps counting if you lock the phone or switch apps. Sound, haptics and a rest-complete notification for when the phone is locked can each be turned off in settings. Programs and progression rules are covered in choosing a strength program you will finish.

When does Apple pay developers? The App Store fiscal calendar, payment dates and missing months

2026-10-17T00:00:00+00:00

Apple’s rule is one sentence long: payments are made “within 45 days of the last day of the fiscal month in which the transaction was completed,” to the bank account and currency you entered in App Store Connect (Apple). The fiscal month is the part that needs explaining, because it decides when a sale gets paid and which report it appears in.

When will Apple pay me?

To be paid at all, Apple lists four conditions (Apple):

A Paid Apps Agreement in effect.
Banking information in App Store Connect. Apple pays the primary account on file and doesn’t split payments across accounts.
Proceeds above the minimum payment threshold for each country or region where you sell.
Any monthly invoicing your country or region requires.

Tax forms belong on that list in practice: Apple’s tax pages say you need to submit them, alongside banking information, to receive payments (Apple).

Once those are in place, Apple’s bank combines the proceeds from every currency you sell in and sends “a single payment to your bank per fiscal month.”

How does Apple’s fiscal calendar work?

Fiscal months are built from whole weeks that run Sunday to Saturday. Each quarter has a five-week month followed by two four-week months, and the year ends in late September. Fiscal 2026 ended on Saturday, September 26. In 2026 the App Store’s fiscal quarters have closed on the same days as Apple’s company quarters; Apple’s third quarter of fiscal 2026 ended on June 27 (Apple), the same day as fiscal June.

Apple’s help pages link to the official calendar inside App Store Connect, which needs a sign-in. These are the fiscal months behind this year’s payments, with the payment dates that RevenueCat and ASO.dev both list in their published calendars (RevenueCat, ASO.dev):

Fiscal month	Sales period	Payment
November 2025	Nov 2 to Nov 29, 2025	Fri, Jan 2, 2026
December 2025	Nov 30 to Dec 27, 2025	Thu, Jan 29
January 2026 (5 weeks)	Dec 28, 2025 to Jan 31	Thu, Mar 5
February 2026	Feb 1 to Feb 28	Thu, Apr 2
March 2026	Mar 1 to Mar 28	Thu, Apr 30
April 2026 (5 weeks)	Mar 29 to May 2	Thu, Jun 4
May 2026	May 3 to May 30	Thu, Jul 2
June 2026	May 31 to Jun 27	Thu, Jul 30
July 2026 (5 weeks)	Jun 28 to Aug 1	Thu, Sep 3
August 2026	Aug 2 to Aug 29	Thu, Oct 1
September 2026	Aug 30 to Sep 26	Thu, Oct 29 (expected)
October 2026 (5 weeks)	Sep 27 to Oct 31	Thu, Dec 3 (expected)

The pattern is 33 days from the Saturday a fiscal month ends to a Thursday payment, with New Year’s Day pushing one payment to a Friday. That sits inside Apple’s 45-day promise, but Apple only promises the 45 days. The Thursday is only the pattern so far. Treat the last two rows as estimates until Payments and Financial Reports shows an expected payment date.

A fiscal month can also carry a calendar month’s name while starting in the previous one. Fiscal January 2026 began on December 28, 2025, so a purchase on December 30 sits in a January financial report. Sales and Trends, which uses calendar days in Pacific Time, files the same purchase under December.

Why is a month missing?

Most of the time, nothing is wrong. Because every quarter starts with a five-week month, payments drift against the calendar. In 2026, January, April, July and October each had two payments, and February, May and August had none. If your bookkeeping runs by calendar month, those months will look empty even though every fiscal month was paid.

When a fiscal month really wasn’t paid, Payments and Financial Reports says why (Apple):

Expected Payment Date: the payment date hasn’t come yet.
Balance Carried Forward: proceeds haven’t reached the minimum payment threshold and “will carry over to the next payment period.”
Payment Returned: your bank sent the payment back. App Store Connect shows the reason and a Transaction ID. Once you fix the banking details, Apple says returned earnings can take up to two regular payment cycles to resend.

There are two quieter cases. A fiscal month with no purchases or refunds produces no financial report at all (Apple), and an expired agreement or missing tax form stops payments until it is fixed.

What is the minimum payment threshold?

Apple publishes a table of thresholds by bank country and account currency. Many common pairs, such as a USD account in the United States, a EUR account in the euro area or a GBP account in the United Kingdom, are listed at 0.02 USD. Any bank country or currency not in the table must exceed 40 USD. A small app paid into an unlisted currency can carry its balance forward for months before a payment goes out.

What currency are you paid in, and who takes the fees?

You are paid in your bank account’s currency. Apple’s bank does the conversion, typically at the spot rate on the payment date and no more than three business days before the money reaches your account (Apple). Apple sends low-value transfers instead of wires where it can, but your bank or an intermediary bank may still deduct fees, and the deposit can be smaller than the amount App Store Connect shows.

That is why the estimate and the payment differ. Before a month is paid, App Store Connect shows Total Estimated Proceeds, and Apple says the actual amount can differ mainly because of exchange-rate movement and withholding tax, which is applied when the payment is made (Apple).

Where do you see payments in App Store Connect?

Payments and Financial Reports, which needs the Account Holder, Admin or Finance role. Payment information for the previous fiscal month starts to appear on the first Wednesday of the current fiscal month, and the financial reports for every country and region are ready by the first Friday (Apple). You can ask for an email when they arrive.

A paid month shows the amount in your bank currency, the bank name with the last four digits of the account, the issue date and a seven-digit Transaction ID, also called a Consolidated Credit Identifier. Have that ID ready if you need to ask Apple or your bank about a deposit. For any country or region you can open units, amounts in the local currency, taxes and adjustments, and the exchange rate applied.

The downloadable financial reports come as a single file for all countries and regions, as separate files for each location, or as a detailed version with transaction and settlement dates, and Apple keeps them for ten years. They can also be fetched through the App Store Connect API.

Why doesn’t the payment match Sales and Trends?

Sales and Trends counts a purchase when the customer starts it and estimates USD amounts with last month’s average exchange rates. The financial reports count settled transactions in fiscal months and use the rate applied to your bank’s currency. My July post on proceeds and sales goes through every column and the reasons the two sets of numbers drift apart.

Where AppMeta Pulse fits

AppMeta Pulse reads the daily Sales and Trends reports through the App Store Connect API. It doesn’t read Payments and Financial Reports, so it can’t tell you when a payment will land or what it will be after conversion and fees. For that, the Payments page above is the source.

Payments and Financial Reports is still the first place Pulse sends you: the Vendor Number it needs to download sales reports is shown there, under your legal entity name. After that, Pulse covers the daily side, with proceeds and downloads by app, net of refunds, and subscription figures such as the MRR worked out from Apple’s Subscription report. It also keeps its own copy of the daily reports after Apple’s one-year window for them closes.

When to deload: the signs, the common schemes, and how good the evidence really is

2026-10-14T00:00:00+00:00

A deload is a short, planned stretch of easier training, usually about a week, taken to shed fatigue before you push again. The common version keeps your exercises and training days and changes three things:

Fewer sets, often roughly half.
Lighter loads, especially on the big multi-joint lifts.
More reps in reserve: you stop each set further from failure.

When to take one is the harder question, and the research and the people who coach for a living answer it below.

What is a deload, by definition?

Until recently there wasn’t an agreed definition. In 2023, Bell and colleagues ran a Delphi consensus with expert strength and physique coaches over three rounds (34 coaches started, 21 finished). The definition they arrived at describes a deload as a period of reduced training stress designed to reduce fatigue, promote recovery and prepare the athlete for the training that follows. They separated it from a taper, which is about peaking for a competition.

The panel agreed on surprisingly little beyond that. Reducing volume was the only point with universal agreement. Intensity could go down, stay the same, or even rise, depending on the athlete and the sport. Deloads could be planned in advance, triggered by how the athlete feels, or both.

What are the signs you need a deload?

The best data on real-world triggers comes from Rogerson and colleagues’ 2024 survey of 246 competitive strength and physique athletes, most of them powerlifters.

Trigger	Athletes who used it
The program specifies a deload	65.4%
Feeling beaten up (soreness, joint aches, pain)	62.6%
Performance stalls or drops	54.1%
Previous injuries flare up	31.3%
High stress outside training	30.5%
Holiday or travel	24.4%
Not feeling like training	14.6%

Turned into something you can check on a Sunday evening, the signs worth watching are:

Several lifts have stopped moving at once. One stalled lift usually needs a programming change. Three stalled lifts at the same time point at fatigue.
Your usual weights rate harder. If a load that was an RPE 7 a month ago now feels like an 8.5, on several lifts, for more than one session, that is a recovery signal. How RPE and reps in reserve work covers how to rate that honestly.
Joints and tendons ache before the session starts, not just after it.
Life outside the gym is taking more than usual: a heavy work stretch, a new baby, bad sleep.

One of these on its own is a bad week. Two or more together for a week or longer is what most deload rules are written for.

A note on pain: a deload is for fatigue. Pain that is sharp, localised or getting worse is a different problem, and the right person to see about it is a clinician, not your program.

How do you run a deload?

There are four common shapes. Most real deloads combine the first three.

Scheme	What changes	What stays the same	Where it fits
Volume deload	Fewer sets, often about half; sometimes fewer reps per set	Exercises, training days, loads close to normal	High-volume and hypertrophy-focused training
Intensity deload	Lighter loads	Sets, reps, exercises	Heavy, low-rep strength phases
Effort deload	Stop further from failure, more reps in reserve	Program structure	Programs written in RPE or RIR
Week off	No lifting at all	Nothing, apart from walking or other sport	Travel, illness, or when you need a mental break

The survey shows what athletes actually do. During a deload, 78.9% cut their weekly sets and 52.8% cut reps per set. On multi-joint lifts, 83.7% used lighter loads and 84.9% stopped further from failure. Meanwhile 63.0% kept the same number of sessions per week, and 70.3% kept the same multi-joint exercises. The pattern is clear enough to copy: same days, same main lifts, less of everything.

Some programs build the deload into the structure. 5/3/1’s fourth week is one, as the table in the program-choosing post shows.

How often should you deload?

The survey’s athletes deloaded every 5.6 weeks on average, with a spread of plus or minus 2.3 weeks and a range from 1 to 12, and each deload lasted about 6.4 days. The Delphi paper describes pre-planned deloads every 4 to 8 weeks as common practice, while its panel declined to set a fixed interval and said frequency should follow how the athlete responds.

Planning one every 4 to 6 weeks and moving it when the signs above show up is a reasonable default. Bring it forward when several signs line up early; push it back a week when training is going well and nothing aches. A deload taken because the calendar said so, in a week when you feel great, costs you little, but it isn’t buying much either.

What does the evidence actually show?

Less than the confidence of most gym advice would suggest. Most of what we know is expert opinion (the Delphi panel) and self-report (the survey), and the survey’s own authors call their findings broad guidelines until experiments test whether deloading helps. In that survey, 65.0% of athletes said they felt they could progress without deloading at all.

The controlled trials so far are small:

Coleman and colleagues (2024) had 39 resistance-trained adults run a 9-week, high-volume program. One group took the whole of week 5 off. Muscle growth, power and local endurance came out about the same in both groups. The group that trained straight through gained somewhat more lower-body strength (squat 1RM rose by about 16 kg against 13 kg), though the statistical uncertainty around that difference included zero. Note that this was a full week off, not a reduced-load deload.
Pancar and colleagues (2026) trained 19 untrained young men, with each person’s arms and legs randomly assigned to continuous training or to a deload of one session and two sets per exercise in weeks 4 and 8. Muscle thickness and 10-rep strength improved similarly under both conditions.

Put together: a well-run deload doesn’t appear to cost muscle, a complete week off may cost a little top-end strength, and no trial I know of has shown that deloads make you stronger over the long run. They remain a sensible way to manage fatigue and to make hard training sustainable. Treat any deload schedule as a starting point you adjust.

How GymLogger X schedules deloads and flags plateaus

GymLogger X handles deloads in three places.

In the programs it builds, the Smart Program Creator schedules a deload week every 4 weeks for beginners, every 5 for intermediates and every 6 for advanced lifters in linear, undulating and wave programs. Block programs end each block with one. A deload week halves the sets (never below one per exercise), keeps the rep ranges, and raises the reps-in-reserve target, by three in most program styles, so the loads come down with the effort. That matches what most of the surveyed athletes did.

In your history, sessions logged during a program’s deload week are marked as deloads automatically, and any other session can be marked as one from its menu. The flag matters because a light week would otherwise drag down your strength trend and your weekly set counts. The app also notices unplanned deloads: if your weekly training volume falls by 30% or more after two hard weeks, the recovery screen marks that week on its load chart and tells you how long ago your last deload was.

In the plateau rule, a Pro feature, deload sessions are dropped before the rule runs, so a deliberately light week can’t create a false stall. Detection stays off for your first 12 weeks of logged training and needs at least eight sessions on a lift, or five if you train it rarely. It then fits a trend through the estimated 1RM of your four most recent sessions on that lift, using the Epley formula from the one-rep max post, and compares it with a threshold built from your own rate of gain over the last 90 days, kept between 0.05% and 1% per session. If the trend misses that bar while volume hasn’t dropped by more than 3%, three sessions earn a Monitoring flag. A confirmed plateau needs four, plus either a fatigue sign (training the lift twice in a week, on back-to-back days, or with volume rising while strength stays flat) or at least six non-deload sessions logged on that lift, and a confidence score of at least 0.4.

A confirmed flag lists a likely cause and two suggestions. When volume has been climbing, it suggests cutting volume by about 20% or taking a deload week; when the cause is unclear, it suggests a deload week or a change of rep range. It doesn’t move your program for you. Whether this is the week to deload is still your call, and the signs above are the ones I’d check first.

Designing a puzzle with no words: how Tare teaches its rules, and what accessibility took

2026-10-09T00:00:00+00:00

Update, version 1.1: Tare now has 200 levels in ten chapters of twenty. Chapter I, onboarding included, is still free, and one purchase unlocks the other 180. This post is the launch-day essay, written when Tare had 80 levels.

Every level of Tare is a hanging mobile that you balance with numbered weights, and none of the 200 has a word on the playing field. There is no tutorial screen, hand icon or arrow. The puzzle had to teach the rule, the hidden weights and the cards that reveal them on its own. And because there is no text to label, accessibility couldn’t be a layer of button labels added at the end.

What the first levels teach, and how

You need to know	How Tare shows it	Level
Level and still means solved	One piece in the tray, one empty hook. The only move balances the beam, and its pivot flashes as it crosses level	1
Every hook takes a piece	Two hooks, two equal 3s	2
The heavy side drops, and distance multiplies	A 2 and a 4 for notches 2 and 1. With the 4 far out the beam tips; swapped, 2 × 2 = 4 × 1	3
The hook matters as much as the piece	A 3 already hangs three notches out; a 2 and two 1s must fill notches 1, 2 and 3 on the other arm	4
Anything hung can be moved	A 4 starts on the wrong hook and has to come off	5
A hanging beam pulls with everything below it	The first nested beam: a 1 three notches out balances a small beam carrying 3	7
A card is a true statement	Two different shapes, both 4s, level on a card above a lever the card doesn’t picture	10
A beam with a secret won’t tell you	A “?” starts hung, and its beam sways instead of tilting	11
The sway climbs	A “?” on a lower beam makes the beam above it sway too	13

Two signals run through every level.

Every known weight states its value twice, as a numeral and as domino pips, and its size grows with its weight: 32 points across for a 1, 96 for a 9. A hidden “?” is always 52 points, whatever it weighs.

A full but wrong board shudders once, a damped 1.2° shake over half a second with a soft haptic. There is no red, no buzzer and no failure screen. A drop that misses every hook doesn’t even get a shudder; the piece glides back to its slot.

Levels with one way forward

The rule for the first five levels was no text, no hand icons and no tutorial overlay. Each level offers so little that the next thing to try is the lesson. Level 1 has exactly one possible move, and it solves the level. By level 5 you have dragged, filled, swapped and re-hung, because level 5 can’t be solved without moving the piece it starts with.

Three wordless helpers sit around those levels:

Live tilt preview. Hold a weight over a hook and the whole mobile leans to where it would rest if you let go.
A teaching line, on levels 1 to 5 only. After 15 seconds without a touch, a faint line arcs from a piece to a hook. It shows a move, not the solution.
A short introduction for each kind of card. The first time a card appears, and again for the first secret, tilt, sum and ratio, the room dims on the card and the pieces it quotes, a line joins them, and one piece lifts once. There are at most five in the whole game, and none is saved: the game works out what you’ve seen from the levels you’ve solved.

From then on, picking up a piece lifts every card that mentions it, so the shape of the piece is the pointer.

No channel leaks a hidden weight

The deduction only works if the game keeps its own secrets. A beam carrying an unsolved “?” sways about 3° either side of level and never settles, because, as the design notes put it, “the scale cannot weigh a secret”. How to solve a balance puzzle explains why that matters. The same rule holds on every other channel. The “?” bubble is one fixed size. With Sound on, each weight has its own note, and heavier is lower, but a “?” makes an unpitched thud. A “?” always gives the same haptic strength. VoiceOver calls it “hidden teal drop” and never says a number, and its beam “cannot settle, hidden weight”.

What accessibility took

With no words on the canvas, labelling the buttons covers almost nothing, so the board itself had to become something a screen reader can walk.

Need	What Tare does
Playing without sight	VoiceOver reads the mobile as a tree: “Beam 2, hanging from Beam 1, left, notch 2.” A hook says what hangs on it or “empty hook”. Select a piece and every hook offers “Place the…”; a hung piece offers “Return to tray”. Each beam reports balanced, which side is heavier, or that it cannot settle. Cards read as sentences: “Reference scale, level. Left, notch 1: …”
Colour blindness	Colour never carries meaning alone. Each of the ten shapes has one colour, and every known weight shows its numeral and pips
Low vision	Numerals and pips clear 3:1 by default. The High contrast switch, or the system’s Increase Contrast, swaps in flat fills that clear 4.5:1
Large text	The numeral grows with Dynamic Type; at the accessibility sizes it gives way to the pips instead of overflowing a small piece
Motion sensitivity	Reduce Motion stops the idle drift and the tilt parallax, and turns the sway into a slow pulse in opacity, which keeps the meaning without the movement
Transparency	Reduce Transparency swaps the glassy bubble for a matte one with a dashed rim, at the same fixed size
Precise touch	A hook catches a piece from 60 points away, every piece has a touch target of at least 48 points, and a tap sends a hung piece home
Sound and haptics	Sound ships off, and no level needs it. The Haptics switch appears only on devices that have haptics, so not on iPads

Tests check all of this. One fills every hook of every shipped level using voice actions alone. Another plays levels 1 to 3 as a player who cannot see the screen: it knows only what an empty hook and a level beam sound like, and how to put a piece back. Others recompute every contrast ratio when the tests run, and check that two pieces share a colour only when they share a shape.

Where the words went

Tare does use words in places. Settings, the four chapter names (The Hang, The Secret, The Cascade, The Exhibition), the four world names and the unlock screen all have them. The app’s whole string catalog is 108 entries, and about two-thirds of them exist only for VoiceOver.

A test keeps the canvas to its rule: it reads the code that draws a level and fails if it finds any text other than a weight’s numeral and the “?”.

The plan had been English-only VoiceOver at launch, on the reasoning that the gameplay is wordless. That holds for the canvas, but for a player who can’t see it, the spoken clauses are the game, and shipping an English game inside a store listing written in 50 locales was where the wordless argument broke down. On 20 September I made the whole app ship in all 50 locales. Every spoken line was already a whole clause with placeholders, so a translator could reorder it.

Right-to-left languages turned up a different problem. In Arabic, Hebrew and Urdu, SwiftUI mirrored the drawing of the mobile but not the drag, so a player had to touch the mirror image of a piece to lift it. A mobile is a physical toy, so it is now drawn left to right in every language while the menus mirror, and VoiceOver’s “left arm” matches what’s on screen.

Decisions that changed late

Sound off by default, 20 September. I played the finished build and didn’t want its sounds on unless a player asks. That cost a teaching channel, since the notes taught weight by ear. Level 1’s lesson now rests on the beam going level and still, which works because the level allows no other action.
The idle line became a teacher only, 19 September. It used to appear by itself after 8 seconds on every level, and it made levels too easy. Now it appears unasked only on levels 1 to 5. Elsewhere, hints are a Settings switch, off by default: each press draws one line from the next piece to its hook, never for the last piece, and the first press on an attempt costs that attempt’s third star.

Tare is a free download for iPhone and iPad on iOS and iPadOS 18 or later. Chapter I’s 20 levels, onboarding included, are free to keep, and one $2.99 purchase unlocks the other 180; why it is priced that way is its own post. If you came for the rule-learning, compare Baba Is You, whose rules are built out of word blocks, and DragonBox Algebra, which also teaches through balancing. For the wider field, see the best logic puzzle games for iPhone.

No ads, no subscription: why Tare is free to start and $2.99 once

2026-10-09T00:00:00+00:00

Update, version 1.1: Tare now has 200 levels in ten chapters of twenty. Chapter I is still free, and the one purchase now unlocks Chapters II to X, the other 180 levels. This post is the launch-day record of version 1.0, which had 80 levels, so the table, button names and chapter numbers below describe Chapters II to IV.

Tare is out today, and the price fits in a sentence: the download and the first 20 levels are free for good, and one $2.99 purchase opens the other 60. There are no ads or subscriptions and nothing else to buy.

The full model comes first, then how it ended up this way, including the paid-app plan it replaced and the purchase App Review couldn’t find.

What’s free, what’s $2.99, and what’s never sold

	What it is	Cost
The download	The game, Settings, and every accessibility option	Free
Chapter I · The Hang	20 levels: the wordless onboarding, the first nested beams, the first hidden weights and cards	Free for good, not a trial, never gated
Chapters II to IV	60 levels: The Secret, The Cascade and The Exhibition, in three more worlds	$2.99 once, one non-consumable, Family Sharing on
Hints	Off until you switch them on in Settings	Never money. The first hint on an attempt costs that attempt’s third star
Stars and chapter canvases	Earned by playing. Finishing a chapter lets you pick its world as the backdrop for the whole game	Never sold
Ads, subscriptions, consumables, lives, energy, timers	None	n/a

The unlock screen gets its price from the App Store, so it shows your own currency. $2.99 is the US base, and Apple sets the equivalent in every other storefront. No price is written into the app anywhere.

Where the offer appears, and where it doesn’t

You can open the purchase from three places:

the Open Chapters II-IV button under Chapter I on the chapter wall, which carries no price;
any unlit level of Chapters II to IV;
the same button in Settings, directly above Restore purchases.

It never opens by itself, whether at launch, when you come back, after a solve, or over the celebration when you finish Chapter I. In that last case the wall simply returns with the button in view. Nothing inside a level advertises, and the pause menu has no offer. The unlock isn’t a promoted purchase on the App Store page either, since that would sell it to someone who has never hung a weight.

Levels in chapters you haven’t bought are drawn in full but darkened, with no padlock. In Tare a padlock means that playing on will open a level, and playing alone will never open a chapter you haven’t bought. For the same reason VoiceOver says “not purchased” and never “locked”. The unlock screen doesn’t show your star total either, because a total next to a Buy button looks like something being priced, and nothing in the game is gated on stars.

The plan before this one

Until 2 September, Tare was going to be a paid app: $3.99 up front, with “In-App Purchases: none” on the store page. The reasoning was about strangers judging six screenshots. A solo developer with no track record can’t ask much of someone deciding that way.

On 1 September I played the first two finished chapters and found every level a single flat beam, which the post on solving balance puzzles covers. The next day, while rebuilding the 80-level arc, I made Chapter I free and put Chapters II to IV behind one purchase.

A free chapter settles the screenshot question. By the time anyone sees the price, they have solved twenty levels, read their first picture cards and watched a “?” open. The launch plan now leaves the persuading to the free chapter instead of the price tag. The store description says exactly what’s free in its second line, because a free listing that doesn’t say so reads like a demo.

Why $2.99, and why it won’t be on sale

$2.99 is the lowest price that, by the launch plan’s judgement, still reads as something crafted and not a trinket. It is set once in US dollars, with worldwide automatic pricing.

There is no launch discount, and the plan rules out discounts for the first year. It reckons that no price below $2.99 would earn back what it costs in credibility. For the first year at least, that also means nobody who buys early pays more than someone who waits for a sale.

Why no ads, subscription or consumables

Tare has no networking code. It plays the same in airplane mode, and its App Store privacy label reads Data Not Collected. Ads would bring network code and a third-party SDK into a game built to have neither.

The purchase leaves the label as it was. StoreKit is Apple’s own store, not an SDK the game reports through. The game records nothing about the purchase beyond the fact that the chapters are open, and no analytics are attached to the offer, neither when it is shown nor when it is dismissed.

Subscriptions and consumables are ruled out entirely; the plan’s words are “no consumables, no subscriptions, ever”. The blueprint describes Tare as a crafted object, and it is sold like one, once. Hints cost a star. Nothing in a level can be bought, and stars and canvases can only be earned. If anything else is ever sold, the plan limits it to optional cosmetic theme packs released alongside free levels, and the canvases you earn would never be part of them.

Family Sharing is on. One purchase covers your family group, and the game treats a shared purchase exactly like your own.

Restore purchases is always visible, in Settings and on the unlock screen, whether or not you’ve bought anything. On a new device you have to be able to find it before it has anything to restore.

Once granted, the unlock stays. The app clears it only when the App Store reports the purchase revoked, for example after a refund, and never because the store couldn’t be reached. The design rules out locking a paying player out of an offline game to re-check a purchase.

Chapters still open in order. Chapter II opens when 16 of Chapter I’s 20 levels are solved, and the unlock screen says the chapters open in order before you pay, so buying at level 3 holds no surprise. Within a chapter you can skip past up to three unsolved levels, so no single puzzle walls you off.

There are no error codes. If the App Store doesn’t answer, the unlock screen shows Try again, with Restore and the terms still there, and the button on the wall stays where it was.

The purchase App Review couldn’t find

The offer turned out to be too quiet. App Review answered the first 1.0 submission with Guideline 2.1(b), Information Needed: it could not locate the in-app purchase. The offer lived only on the chapter wall, below Chapter I’s twenty levels, and on the unlit levels, which by design carry no padlock and no price. Settings, where a reviewer looks for a purchase, had only Restore.

So on 1 October the same Open Chapters II-IV button went into Settings, directly above Restore purchases, and the reply to App Review spelled out the path step by step. Both places use one view, so it looks and reads the same, and it disappears once you’ve bought.

Tare asks for a rating only with Apple’s standard prompt, and only in two places: when you finish Chapter II and when you finish Chapter IV, and only if you’ve solved at least three levels in that session. That count lives in memory and is never saved. Finishing the free chapter never triggers the prompt, so it can’t appear anywhere near the purchase.

Settings also has a Share Tare row. It hands the system share sheet the plain App Store link with no campaign or referrer parameter, because in the plan’s words a shared link that reports who shared it is “analytics by another name”. The privacy policy lists what stays on your device.

Tare runs on iPhone and iPad with iOS or iPadOS 18 or later. The free chapter is also where the game teaches itself without a word, which designing a puzzle with no words walks through. To see how other models compare, the best logic puzzle games for iPhone sets Tare beside ad-supported and pay-once games, and the comparison pages cover Good Sudoku, Nonograms Katana and Simon Tatham’s Puzzles. Millrace, from the same studio, is a tile puzzle whose whole game is free, with no ads.

How to solve a balance puzzle, and how Tare proves every level has one answer

2026-10-09T00:00:00+00:00

Update, version 1.1: Tare now has 200 levels in ten chapters of twenty. Chapter I is still free, and one purchase unlocks the other 180. Every one of the 200 levels has exactly one answer. This post is the launch-day record: its level numbers, tables and counts describe the 80 levels of Chapters I to IV in version 1.0.

Every level of Tare is a hanging mobile: beams on strings, hooks on the beams, and a shelf of weights numbered 1 to 9. You hang every weight so that every beam balances at once. Some hide inside a “?” bubble drawn at one fixed size, and the scale won’t tell you what they weigh; small picture cards above the board will. All 80 were built by hand, and none ships until a gate in the test suite has proved three things about it:

Exactly one arrangement balances.
The cards alone pin every hidden weight to a single value.
Every decoy fits no balanced arrangement at all.

First the method, on a real level, then the gate.

The one rule: weight × distance

A beam is level when the turning force on each side of its pivot is equal. Each weight contributes its number times its distance from the pivot, counted in notches from 1 to 4. A 2 two notches out balances a 4 one notch out, because 2 × 2 = 4 × 1. Several weights on one side add up.

Beams can hang from other beams. A hanging beam pulls on its hook with the total of everything below it, and the beams themselves weigh nothing. So a child beam has to balance on its own, and its parent sees only one number: its load.

A level is solved when every hook holds a weight and every beam is level. Two pieces of the same weight are interchangeable, so swapping them is not a second answer.

Read the cards before you hang anything

On a real scale you could weigh a secret by hanging it and watching the beam tip. Tare doesn’t allow that. A beam carrying an unsolved “?” doesn’t tilt: it sways slowly, about 3° either side of level, and never settles, and the sway climbs to every beam above it. If it tilted truthfully, you could binary-search every hidden value by reading angles, and the puzzle would become measurement.

So the cards are the only scale for a secret. Each card is itself a small beam:

Card	What it shows	What it tells you	From the game
Equal	Level, equal arms	Both sides weigh the same; two pieces on one side add up	Chapter II, level 5: “?” = 1 + 3, so 4
Tilted	Heavy side down	That side is strictly heavier; two tilts can bracket a value	Chapter II, level 3: heavier than the 3, lighter than the 5, so 4
Ratio	Level, unequal arms	Multiply each side by its notches	Chapter II, level 10: “?” at notch 1 balances a 4 at notch 2, so 8
Twin rule	No card; it holds everywhere	Pieces with the same silhouette weigh the same	Solve one twin and you know both

A card can also show a weight that isn’t in your tray, drawn only for comparison. Chapter II’s first level sets its “?” against a 3 you don’t own.

A worked example: Chapter II, level 14

A top beam with no hooks of its own carries two beams, two notches either side of its pivot. The left beam has a hook one notch either side. The right beam has hooks two notches and one notch left, and one notch right. The tray holds a “?”, a 3, two 6s and a 7: five pieces for five hooks.

The cards. One card shows the “?” heavier than a 1. The other shows it lighter than the 3. Weights are whole numbers, so the “?” is 2.
The top beam. Both children hang two notches out, so they balance only if they carry the same load. The tray totals 2 + 3 + 6 + 6 + 7 = 24, so each child carries 12.
The left beam. Equal arms with one hook each means two equal weights. The only pair is the two 6s, and 6 + 6 = 12.
The right beam. It gets the 2, 3 and 7, also 12. Its one right-hand hook must match both left hooks. Put the 7 there, the 2 two notches out and the 3 one notch out: 4 + 3 = 7. With the 2 or the 3 on the right, the left side comes to at least 11.
Check the top. 12 × 2 on each side: 24 against 24.

While you play it, the left beam settles level as soon as both 6s are on, because nothing on it is hidden. Once the “?” hangs on the right beam, that beam and the top beam sway until the level is solved.

Habits that solve most levels

Cards first, then arrange. They are always enough to name every “?”.
Work from the bottom up. A parent sees only a child’s total.
Equal distances mean equal loads. Two beams hung equally far either side of a pivot carry the same total.
Count the tray. Every hook takes one weight, so pieces minus hooks is the number of decoys.

How a level is built

These 80 are the second attempt. On 1 September I played the first two finished chapters: every level was a single flat beam, the cards were hard to read, and there was no reason to keep going. The next day the arc was redesigned so that chapters mix mechanics and the mobile changes shape from level to level.

The design notes call the method “sketched by hand, proven by machine”. A level starts as a silhouette, one of ten families: bar, lever, pendant, yoke, fork, outrigger, cradle, ladder, staircase and tree. No structure appears twice in the game, and from level 6 on, no two neighbours on a chapter’s four-column grid share a family.

A search in the test target then fills in the numbers. It runs combinations of weights from 1 to 9, one per hook, through the game’s own solver and keeps those with exactly one answer, every piece hung and no beam side above 36, ranked by how badly a player who never counts does or by how much work the cards have to do. A card assistant proposes cards and keeps only sets the deduction engine accepts. Then I choose by hand: nice numbers, a symmetry that misleads, a satisfying last piece.

Every level stays inside the same limits: weights 1 to 9, hooks at notches 1 to 4, at most eight pieces, eight hooks, three beams deep, three hidden weights, three decoys and three cards, and 36 on any side of any beam, so the arithmetic fits in your head.

What the gate proves

As with Millrace’s levels, the gate is a test that runs over every bundled level, not a script run once.

Exactly one arrangement. The solver tries every way to fill the hooks, up to 40,320 for eight pieces on eight hooks, branching on weights instead of pieces and filling the deepest beams first so a beam that can’t balance is abandoned early. It may call a level unique only if it searched to the end. Its shortcuts are tested against a deliberately naive solver: on an eight-hook test level with 882 solutions, both find the same 882.

Every “?” from the cards alone. A separate check ignores the mobile. It tries every value from 1 to 9 for each hidden weight, at most 729 combinations for three, against every card and the twin rule. Exactly one may survive, and it must be the level’s real weight. Another check confirms each card is true as drawn, using its own arithmetic and not the deduction engine’s, so a bug in one can’t hide a card that lies.

Every decoy fits nowhere. The pieces flagged as decoys must be exactly the pieces no balanced arrangement uses. Because the solver counts by weight, a decoy can never share a weight with a piece that hangs: there would be no fact about which of the two is spare.

No decorative cards. On a level with a “?”, every card must belong to the smallest set of cards that pins down some hidden weight.

Each check has a deliberately broken level in the suite that it must catch: one with two answers, one with a lying card, one whose “?” the cards leave open. A failure names the level and the rule it broke. For this post, all 80 were also re-checked by a brute-force script that shares no code with the app: 80 single answers, every “?” pinned to its real weight, every decoy unused.

The 80-level ramp

Chapter	Levels	Hooks	Beams deep (1 / 2 / 3)	Levels with a “?”	Hidden weights (most in one level)	Decoys	Cards
I · The Hang (free)	1-20	2-6	10 / 7 / 3	4	4 (1)	0	5
II · The Secret	21-40	3-6	6 / 9 / 5	20	33 (2)	0	35
III · The Cascade	41-60	4-7	1 / 9 / 10	13	29 (3)	1	30
IV · The Exhibition	61-80	4-6	2 / 11 / 7	14	28 (3)	30	24
All	80	2-7	19 / 36 / 25	51	94	31	94

Counting all 80 in order, each idea arrives on a fixed level: the first nested beam at 7, the first card at 10, the first “?” at 11, three beams deep at 15, the first sum card at 17, a weight you don’t own at 21, the first bracket at 23, the first ratio at 30, three hidden weights at 51, and one decoy at 60 as a preview of Chapter IV, where every level has one or two.

The solver’s own counts show the climb. Chapter I’s first level took it 2 weight-into-hook trials; Chapter IV’s level 19 took 600. On levels with nothing hidden, a simulated player who never counts hangs everything at random, then keeps making the swap that most reduces the tilt, from 300 fixed starts. It solves the first three levels every time, Chapter I’s level 18 one time in ten, and the finale 13% of the time. Ignore the cards on Chapter IV’s level 17 and 294 combinations of hidden values and arrangements balance; with them, one does. Chapter IV’s level 11 puts exactly 36 on one side of a beam, the cap.

Tare is a free download for iPhone and iPad. Chapter I’s 20 levels are free to keep, and one $2.99 purchase unlocks the other 180. There are no ads, it works offline, and its App Store privacy label reads Data Not Collected; the privacy policy has the details. How the first levels teach all of this without a word is in designing a puzzle with no words, and why the rest costs $2.99 once is in no ads, no subscription. No level needs a guess. The cards are always enough, and the tests have checked that they are.

Xiangqi openings explained: the Central Cannon, its answers, and the quieter first moves

2026-10-07T00:00:00+00:00

Xiangqi openings are named after one move. If Red’s first move puts a cannon on the central file, it is a Central Cannon game, and the opening is then named after Black’s answer. If Red plays anything else, the opening is named after that move. The ten below are the names to learn first.

How to read the moves

The moves here are in WXF notation, named after the World Xiangqi Federation. It is a letter-and-number form of the traditional Chinese notation, and one of the two notations Xiangqiful offers.

The letter is the piece: K general, A advisor, E elephant, H horse, R chariot, C cannon, P soldier.
The first number is the column the piece starts on, counted 1 to 9 from the moving player’s own right. The two players count from opposite sides, so Red’s column 2 is Black’s column 8.
The sign is the direction: + forward, - backward, = sideways.
The last number is the distance for a chariot, cannon, soldier or general moving forward or back. For a sideways move, and for every horse, elephant and advisor move, it is the destination column.
Two identical pieces on one column are told apart by + (front) and - (rear) in place of the column number.

So C2=5 is a cannon moving sideways from column 2 to column 5, and H8+7 is a horse moving forward from column 8 to column 7. Chinese notation follows the same pattern with characters: C2=5 is 炮二平五 and Black’s H8+7 is 马8进7, with Chinese numerals for Red and Arabic numerals for Black (Wikipedia’s xiangqi article describes both).

The ten openings at a glance

Opening	Chinese	First moves	Played by	The idea
Central Cannon	中炮	1. C2=5	Red	Cannon on the middle file, aimed at e6 and the palace
Screen Horses	屏风马	1. C2=5 H8+7 2. H2+3 H2+3	Black	Both horses guard the central soldier and each other
Same Direction Cannons	顺炮	1. C2=5 C8=5	Black	A central cannon from the same wing; near-symmetry and a race to develop
Opposite Cannons	列炮	1. C2=5 C2=5	Black	A central cannon from the other wing; sharper, counterattacking
Reversed Palace Horses	反宫马	1. C2=5 H8+7 2. H2+3 C2=4 3. R1=2 H2+3	Black	Screen Horses with a cannon in the advisor’s corner between them
Elephant Opening	飞相局	1. E3+5	Red	A solid first move that makes no threat and no commitment
Immortal Points the Way	仙人指路	1. P7+1	Red	One soldier forward, keeping every plan open until Black declares
Horse Opening	起马局	1. H2+3	Red	A horse first, keeping the cannon plans available
Cross-Palace Cannon	过宫炮	1. C2=6	Red	The cannon crosses in front of its own palace to attack the far wing
Advisor-Corner Cannon	士角炮	1. C2=4	Red	The cannon stops beside the advisor, flexible and unhurried

Why the Central Cannon comes first

After 1. C2=5, the cannon on e2 already has a screen: Red’s own soldier on e3. It can jump that soldier and take the black soldier on e6, so the move develops a piece and makes a threat at once. Wikipedia calls it the most common opening in the game. Black has to deal with the threat to e6 before anything else.

The Screen Horses deal with it most directly. After 1… H8+7 the horse on g7 guards e6, and after the second horse reaches c7 both of them do. If the cannon takes the soldier now, a horse takes the cannon, and Red has given a cannon for a soldier. Xiangqiful’s lesson on piece values uses exactly this capture as its example of a bad trade.

The other three answers fight back instead. In the Same Direction Cannons and the Opposite Cannons, Black puts a cannon on the central file too, and the difference is which wing it left behind. In the Reversed Palace Horses, Black develops one horse, puts a cannon into the advisor’s corner, and then brings the second horse out around it. The cannon’s square matters: in this move order it goes to d7, because on f7 it would block the leg the g7 horse uses to defend e6.

The main line, move by move

The Central Cannon against the Screen Horses:

1. C2=5 H8+7 2. H2+3 R9=8 3. R1=2 H2+3 4. R2+4 P7+1 5. P5+1 E3+5 6. H8+7 A4+5

2. H2+3 backs the cannon up with a horse. The cannon cannot do the work alone.
2… R9=8 and 3. R1=2 bring a chariot onto the file each side’s horse has just cleared. This is the most important habit in xiangqi openings. Leaving the chariots at home is called the Delayed Chariot (缓开车): a real system when it is chosen on purpose, and the classic beginner’s mistake when it is not.
3… H2+3 completes the screen. Two horses now defend e6.
4. R2+4 is the Riverbank Chariot. It stops on Red’s own bank of the river, just short of crossing, where it is hard to chase away and eyes Black’s horse on the g-file.
4… P7+1 pushes the soldier in front of the g7 horse, which frees the horse’s forward moves.
5. P5+1 advances the central soldier to e4. It still screens the cannon, and it claims space in the centre.
6. H8+7 A4+5 completes development. Both sides are fully developed and nothing has been forced.

You will reach this position again and again, and from here the game turns on who opens a file first.

Which openings to learn first

Learn one opening for Red and one answer to the Central Cannon for Black, and learn the plans in them before you learn them many moves deep. The Central Cannon and the Screen Horses are the natural pair because you will meet them most. Whichever you choose, the chariots decide the opening: get them out early, onto open files. Wikipedia mentions an old saying against moving a chariot in the first three moves and notes that modern play often ignores it. The main line above has both chariots moving by move three.

How Xiangqiful teaches openings

Xiangqiful teaches openings in two places.

The Openings lesson track has ten lessons. “Opening Principles” comes first, then the Central Cannon, the Screen Horses, the Same-Direction and Opposite Cannons, the Reversed Palace Horses, the Elephant Opening, the Immortal Points the Way and the Cross-Palace Cannon. It ends with “Choosing a Repertoire”, which makes the same case as the section above. Every line is played from the standard start and was machine-checked as legal. All 80 lessons in the app are free.

Opening Lab has ten opening families with five lines each, from the first moves into the early middlegame. Most families are played as Red. The Screen Horses and Reversed Palace Horses, where the defence is the subject, are played as Black. The opponent’s replies are played for you. A wrong move does not end the line: the app says so, draws the wanted move on the board and lets you try again from the same move. Move orders that reach the same position are accepted. Some lines show the opponent’s other main reply, and one shows what the cannon on f7 costs in the Reversed Palace Horses. Every line was replayed for legality and checked by the engine. The Central Cannon family is free; the other nine families are Premium.

Moves can be shown in WXF or Chinese notation, and switching relabels the games you have already played. After each game, Pikafish reviews every move on your device, and Game Review names an early slip as an opening inaccuracy. If you are still learning how the pieces move, start with the xiangqi rules for chess players. Shogi players will notice a similar first decision in Static Rook against Ranging Rook.

Xiangqiful is free, with Premium at $1.99 a month or $9.99 a year (each with a one-week free trial) or $19.99 once. To play these openings against people, see the guide to xiangqi apps for iPhone.

Xiangqi rules for chess players: what carries over, and what catches you out

2026-10-04T00:00:00+00:00

A chess player who sits down at a xiangqi board recognises most of it within a minute. There are two armies, a king-like piece to trap, a rook and a knight. Only a few rules differ, but most of them reverse a chess habit, and those are the ones that cost games. Below is the full list, with the board first and the reasoning after.

The board

Nine lines by ten. Pieces stand on the 90 intersections, not in squares, and move along the lines.
The river runs across the middle, between the fifth and sixth ranks. It stops elephants and changes how soldiers move.
The palace is the three-by-three block of points at each end, marked with a diagonal cross. The general and its two advisors never leave it.
Red moves first, as in most modern tournaments (Wikipedia’s xiangqi article covers the history).
The start position: chariot, horse, elephant, advisor, general, advisor, elephant, horse, chariot on the back line; a cannon on each side two lines in front of the horses; five soldiers on alternate points of the fourth line.

Every piece, next to its chess cousin

Piece	Red / Black	WXF letter	Chess cousin	How it moves	The catch	Rough value
General	帥 / 將	K	King	One point orthogonally	Never leaves the palace and never moves diagonally	n/a
Advisor	仕 / 士	A	None	One point diagonally	Never leaves the palace, so it has five points in all	2
Elephant	相 / 象	E	Bishop, loosely	Exactly two points diagonally	Blocked if the point in between is occupied; never crosses the river	2
Horse	傌 / 馬	H	Knight	One point straight, then one diagonally outward	Does not jump: a piece on the first point blocks it	4
Chariot	俥 / 車	R	Rook	Any distance along a line	None. It is a rook	9
Cannon	炮 / 砲	C	None	Like a chariot	Captures only by jumping exactly one piece	4 to 4.5
Soldier	兵 / 卒	P	Pawn	One point forward, and captures the same way	Gains a sideways step across the river; never moves back or promotes	1, then 2

The values are the rough table given on Wikipedia, which rates horse and cannon equal at 4. Xiangqiful’s own lesson on piece values puts the cannon at 4.5 early on. Both agree on the trend: the cannon is stronger while the board is full of screens, the horse once it empties. Sets vary in their characters, and many use 馬 and 車 for both sides.

The rules that cost chess players games

Stalemate is a loss, not a draw

A player with no legal move loses, in check or not. The Chinese term is 困毙 (kùnbì). For a chess player it is the most expensive habit to unlearn, because steering a lost position toward stalemate hands your opponent the win. It works the other way too: boxing in the enemy general without checking it is a real way to win, and a reason to keep an escape point for your own general.

The generals may never face each other

If the two generals stand on the same file with nothing between them, the position is illegal. A move that would create it cannot be played, as if the general could fly down the file and capture. Two things follow. A piece standing between the generals is pinned to that file, whatever it is, and in the endgame your general controls its whole open file, so it can take escape points away from the enemy general from the far end of the board. Many basic mates use your own general this way.

Perpetual check loses

In chess, checking forever is how a losing player saves a draw. In xiangqi the player who repeats the position by checking on every move must deviate or lose. Official rules also forbid perpetually chasing an unprotected piece, although a chase by the general or a soldier is allowed. If both sides check perpetually, the game is drawn. The details differ between rule sets. The World Xiangqi Federation publishes the World Xiangqi Rules used in international play, and its manual explains the repetition rules through 110 example cases. A 2024 paper on implementing them in software used all 110 as test cases.

The cannon needs exactly one screen

The cannon moves like a chariot. To capture, it jumps exactly one piece of either colour, its screen, and takes the first enemy piece beyond. No screen means no capture, and two pieces in between means no capture either. So the cannon becomes dangerous when something steps onto its line, including your opponent’s own pieces. At the start of the game, a cannon moved to the central file already threatens the soldier on the far bank, because your own central soldier is its screen. Check every line a cannon stands on before you move a piece onto it, or off it.

The horse can be blocked

The horse moves like a knight, one point straight and one diagonally outward, but it does not jump. A piece on the point next to it in the direction of travel, the “leg”, blocks both moves on that side. A horse hemmed in by its own pieces can be worth very little, and trapping an enemy horse is a standard plan.

Some pieces can never attack

Advisors stay in the palace and elephants stay on their own side of the river. Neither can ever reach the enemy general. A side left with only a general, advisors and elephants cannot force a win. That is why the attacking pieces, chariots, horses, cannons and crossed soldiers, are what decide most endgames.

The rest of the list

No castling. The general never leaves the palace, and the palace is its castle.
No promotion. A soldier that reaches the last line can only step sideways.
No pawn double step and no en passant.
Soldiers capture straight ahead, the same way they move, and sideways too once they have crossed the river.
The general moves only orthogonally, one point at a time.

How Xiangqiful handles the rules

Xiangqiful enforces checkmate and stalemate as wins. For repetition it uses a simplified rule. If a position occurs three times and one side gave check on every one of its moves in the cycle, that side loses. If both sides were checking, or neither was, the game is drawn. Sixty moves without a capture is also a draw. The app does not adjudicate perpetual chasing, so it is stricter than chess and simpler than a tournament arbiter.

The first time stalemate or a perpetual check decides one of your games, the game-over sheet explains the rule that just applied (“In xiangqi, having no move loses” and “Checking forever loses”). Each explanation appears once, in the first game that rule decides.

The Fundamentals track teaches the same list in ten lessons, among them “The Cannon and Its Screen”, “The Horse and Its Leg”, “Stalemate - the Chess Player’s Trap” and “Perpetual Check Loses”. Each one is a short explanation, a demonstration or a puzzle, and a quiz. All 80 lessons in the app are free. On the board, tapping a piece marks the points it can legally reach. Tap a cannon and the board also marks the screen it would jump over, which is the board’s answer to the question “how did that cannon reach me?”

The pieces come in three sets: traditional characters, western symbols, or a hybrid with the symbol on the character, so you can learn the rules before you learn to read 傌 and 炮. After a game, Pikafish reviews every move on your device, and Game Review names mistakes in these terms, such as a screenless cannon or a trapped horse. When you are ready for xiangqi’s own puzzle form, every move must give check, and stalemate does not count as mate; the post on Xiangqiful’s 902 mate problems explains where they come from.

Xiangqiful is free, with Premium at $1.99 a month or $9.99 a year (each with a one-week free trial) or $19.99 once. It has no online play. To play people, PyChess and Xiangqi.com are the usual places, and the guide to xiangqi apps for iPhone compares the rest.

Puzzle games without ads or lives: how free games make money, and what Millrace sells instead

2026-10-03T00:00:00+00:00

A free puzzle game still has to be paid for somehow, so before you install one it helps to know who pays, and with what. Below are the common models, what each asks of you, and where each shows up on an App Store page, followed by the complete price list for Millrace and the reasoning behind it.

How free puzzle games make money

Model	How it works	What it costs you	Where to spot it before installing
Ads between levels	A full-screen ad after a level or a failed attempt	Time, and attention between levels	App Privacy section; reviews; often a “remove ads” purchase
Rewarded video	You choose to watch an ad for extra moves, a hint or a life	Time, at the moment you’re stuck	Reviews and screenshots
Lives or energy	A failed or abandoned attempt costs a life; lives refill on a timer or for money	Your play is rationed by a clock	Purchases named lives, refills or coins
Boosters and extra moves	Paid items that make a level easier	Money, level by level	Purchases named boosters, power-ups or moves
Subscription	A recurring fee for no ads, perks or all content	Money, every period	The In-App Purchases list
One-time purchases	Ad removal, level packs, hint packs or cosmetics	Money, once	The In-App Purchases list

Many games combine several of these. Lives on a timer, boosters for sale and ads for extra moves are a common bundle in level-based puzzle sagas. Paid-upfront games take the other route: you pay once on the product page and there is usually nothing else to buy. Threes is one, and its comparison page covers how its paid and free editions differ.

Three places on an App Store page tell you most of this:

Next to the Get button. “In-App Purchases” there means something is for sale.
The In-App Purchases list, further down the page. Item names and prices give the model away: lives, refills, coins, boosters, a remove-ads item, a monthly price.
App Privacy, where the developer declares what happens to data under four headings: Data Used to Track You, Data Linked to You, Data Not Linked to You, and Data Not Collected. Tracking, in Apple’s definition, means linking data from the app with other companies’ data for targeted advertising or ad measurement, or sharing it with data brokers.

Recent reviews fill in the rest.

What Millrace sells: the complete list

Millrace has no ads, lives or subscription. It sells cosmetic themes, undo tokens and a tip, and this is every item:

Item	Price (US)	Kind	What you get
Designer Pack 1	$1.99	One-time	Studio Clay, Paper & Ink, Sakura Pastel, Amber, Heartwood
Designer Pack 2	$1.99	One-time	Concrete Studio, Sunset Dunes, Glacier Ice, Brushed Metal, Midnight Neon
Summer Pack	$1.99	One-time	Lido, Riviera, Agrumi
Winter Pack	$1.99	One-time	Hygge Hearth, Aurora Drift, Evergreen Noël
Complete Collection	$5.99	One-time	All sixteen paid themes
10 Undos	$0.99	Consumable	Undo tokens for Freeplay
50 Undos	$2.99	Consumable	Undo tokens for Freeplay
200 Undos	$5.99	Consumable	Undo tokens for Freeplay
Support the Developer	$1.99	Tip	A “Thank you.” and nothing else

The Complete Collection costs less than buying the four packs separately. Theme purchases restore with your Apple Account. There is no subscription. Apple derives the prices for other storefronts and shows your local currency at checkout.

Free: all 64 campaign levels, Freeplay, the daily board, Hint, the Coach, Game Center and the Classic theme, which is one of seventeen. You can preview a paid theme on your own board for five moves before you decide.

Where undo tokens fit, and where they don’t

Undo tokens are the one thing Millrace sells that touches play, and the closest thing it has to a booster, so their exact rules are worth setting out.

Inside a level, Undo is free and unlimited and never touches your tokens. After a failed run, the card’s main button is “Undo that move”, and restarting a level costs nothing either.

Tokens are spent only in Freeplay, the endless board, where tiles spawn at random. By default the app asks before it spends one.

Free tokens arrive on their own: one each day while you hold fewer than three. Opening the app on consecutive days builds a streak, and the milestones at 3, 7, 14 and 30 days pay out 2, 5, 10 and 20 tokens, once each.

Running out interrupts nothing. Tapping Undo with no tokens opens a sheet with the three bundles and a “Not now” button, and the game carries on either way.

Hint is never rationed or sold. In a level it comes from the same solver that verified the level, as the first move of a shortest line from where you stand. The strategy guide covers how to use it, and how to need it less.

Why there are no lives or ads

The project’s planning document set three rules for how the game earns its keep: never gate the base game, never make undo mandatory, and no paywalls mid-run. Everything in the price list follows from them.

Lives would break the first rule most directly. A lives system makes failure cost time: you lose, and then you wait or pay. In Millrace a loss costs one tap on Undo. The comment above that button in the source says the point of a fail state “is that it costs you a thought, not a run.” The levels are hard on purpose, as how they’re made explains, and a hard level with a lives meter attached rewards waiting over thinking.

Free Undo needed one guard. When a run fails, the card can say which move made the position unwinnable, but only afterwards and never live. A live warning plus free Undo would turn every level into swipe, undo, swipe until something sticks, and you’d reach the answer without understanding it.

Ads were first ruled out as a design choice, and now the code makes them impossible. An ad has to come from somewhere, and Millrace contains no networking code; it never uploads or downloads anything itself. It links no third-party SDKs, there is no account, and Apple’s privacy label for the app reads Data Not Collected. Game Center and purchases talk to Apple, and nothing else in the app connects anywhere. The privacy policy has the details.

What this model gives up

A game that sells only optional items depends on some players choosing to buy something they don’t need. The design has other limits too. There are 64 levels, not thousands, and each one was generated, solved exhaustively and screened before it shipped. Progress stays on the device and doesn’t sync. If you want a long saga with events, the Two Dots comparison is fair about where Two Dots does better, and about how its lives work.

A checklist for any free puzzle game

Before installing, five questions answer most of it:

Does failing cost anything: a life, energy, or time spent waiting?
Can every level be finished without buying anything?
Are hints and undos rationed, and are they sold?
What does the In-App Purchases list contain?
What does the App Privacy section declare?

For Millrace, failing costs nothing and every level can be finished free. Hints are never rationed, undos are free inside levels, and tokens are sold only for Freeplay. The list holds themes, undo bundles and a tip, and the label reads Data Not Collected. The app page has the rest.

902 xiangqi mate problems, eight old books, and the problems I left out

2026-10-01T00:00:00+00:00

Xiangqiful has 902 mate problems, and every one is a consecutive-check mate (连将杀). Red must check on every move until the black general is mated, and Black always picks the reply that lasts longest. I composed 194. The other 708 come from eight classical manuals, transcribed position by position and line by line. Each book line was then proved by the app’s own solver. None was edited to pass, and a book problem that failed is not in the app.

The whole corpus, by source and by depth:

Source	Mate in 1	Mate in 3	Mate in 5	Mate in 7	Total
Shiqing Yaqu (适情雅趣, 1570)	50	35	36	106	227
Lanke Shenji (烂柯神机)	39	34	16	77	166
Taolue Yuanji (韬略元机)	30	19	29	51	129
Mengru Shenji (梦入神机)	21	15	15	43	94
Yuanshen Haige (渊深海阁)	22	19	29	14	84
Juzhongmi (橘中秘)	2	1	0	2	5
Zhuxiang Zhai (竹香斋)	2	0	0	0	2
Xinwu Canbian (心武残编)	1	0	0	0	1
Composed for Xiangqiful	78	116	0	0	194
Total	245	239	125	293	902

How much of each book made it in:

Manual	Positions transcribed	Scored by the book as a Red win	In the app
Shiqing Yaqu	549	452	227
Lanke Shenji	258	220	166
Taolue Yuanji	341	225	129
Mengru Shenji	150	134	94
Yuanshen Haige	374	115	84
Juzhongmi	181	42	5
Zhuxiang Zhai	200	25	2
Xinwu Canbian	155	5	1
All eight	2,208	1,218	708

Depth is counted in plies, single moves by either side. Mate in 3 means Red, Black, Red. That is how the app labels its tiers, and it is how tsume problems are counted in shogi. A chess book would call the same problem mate in 2.

What the genre demands

Xiangqi’s native puzzle has the same constraint as tsume-shogi. That is why the solver in Xiangqiful started as a port of the one in Shogiful. It has two rules. Every attacker move must give check. The defender plays the longest defence, so the line a problem records is the one that survives longest, even when a shorter one turns up first.

Xiangqi adds a trap that shogi doesn’t have. A player with no legal move loses, so a quiet final move that leaves the general stranded wins a real game, but it is not a consecutive-check mate. The solver checks that the defender is in check before it counts his replies, and it only accepts a line that ends in checkmate. A straight port of the shogi solver would get this wrong, and it is the first thing the comments in that file warn about. Stalemate as a loss is one of several xiangqi rules that reverse a chess habit; the rules guide for chess players covers the rest.

152 problems was not enough

The app was first going to ship only problems I composed. By early September there were 152 of them: 60 mate-in-1 and 92 mate-in-3. The mate-in-5 and mate-in-7 shards existed in the code but were empty. A Premium player on the long daily session would have seen every unseen problem in 19 days and then started getting repeats. Shogiful had already taught me what that costs. A one-star review there said that with only a few hundred problems, you end up memorising them.

Composing more only went so far. The composer is a generator, and a candidate survives only if it passes a strict bar. Red must have at least two checking moves, and exactly one of them forces mate. Every red piece except the general has to be load-bearing, so removing any one of them destroys the problem. The defender must keep pieces near his general and at least six legal replies. No two problems may share a position or its mirror image. One more run per shard brought the originals to their final 194. The generator only composes mate in 1 and mate in 3, so it could never fill the two empty shards. The deep problems already existed, in books.

Eight books, 2,208 positions

I transcribed eight pre-1900, public-domain manuals from the digital editions on xqdao.com. Each problem became a starting position and the book’s main line, in the notation the app’s rules engine reads. That came to 2,208 positions. 837 of them are draws by the book’s own verdict, 66 are wins for Black, and 87 carry no verdict at all. That left 1,218 the books score as wins for Red.

Most of those don’t fit a mate-in-7 ceiling. The median main line among the 1,218 is 13 plies, the longest is 74, and only 195 are seven plies or shorter. So the import works from the end of the line. For each book problem it tries the whole problem first, then the position the book’s line reaches 7 plies before the mate, then 5, 3 and 1. It keeps the longest version that passes, and it never keeps more than one per book problem.

That is why the data carries two kinds of book credit. classical: marks a whole problem, the book’s own diagram and main line, unchanged. Only 36 problems are used whole. after: marks an ending, and 672 problems are endings. For example, the Shiqing Yaqu’s first problem has an 11-ply main line. Xiangqiful’s first mate-in-7 starts from the position after the book’s fourth ply and plays the book’s last seven moves exactly. The other 194 problems are credited original, and none of them is attributed to any collection.

The book was not corrected to make a problem fit

That sentence is in the provenance field of every shard file, and the import works by it. A book position and line ship only if all of these hold:

The book claims a win for Red. Draws and Black wins are never imported.
Every piece stands where a game could have put it, neither side starts in check, and the line replays legally.
The book’s key move holds against every reply. Books record one defence, and the solver plays out every reply the book leaves out. If any reply escapes, the problem is out.
MateValidator accepts the book’s line at the book’s depth. Every attacker move checks, the line ends in checkmate, no shorter mate exists, and exactly one first move wins.
No later move has a twin. At every Red move along the book’s line, and along every defence the solver added, the recorded move must be the only one that still mates in time. During a problem the app accepts only the recorded move, so a second mate would mark a player’s correct answer as wrong.
It isn’t already in the corpus, in either mirror image.
A slow phone can re-prove it. The solver’s work is capped at 8,000 search nodes, which keeps each problem inside the device’s two-second budget.

There is no step where a failing line gets patched. The import doesn’t swap in a better key move or move a piece to remove a dual. When a book problem fails, the importer moves on to a shorter ending of the same problem. If no ending passes, the problem doesn’t ship. 708 of the 1,218 Red wins produced a problem; the other 510 produced nothing the app would ship. Not all 510 are broken, since the same gate also turns away sound problems, such as one a phone would take too long to re-prove, or one already in the corpus as a mirror image. The counts above are the real yield either way.

The Juzhongmi line in the table shows the effect. Of its 181 transcribed positions, the book scores only 42 as Red wins, and five survived. The manual is still in the app: the advanced lesson track teaches from it, alongside the Plum Blossom manual (梅花谱) and the Seven Stars endgame (七星聚会).

Checked twice, by the same code

MateValidator runs twice: once when a problem is written into the bundle, and again on your device the first time the problems are loaded, before any problem reaches the puzzle database. Both runs use the same Swift source: the authoring tool compiles MateValidator and MateSolver directly, so the gate that admitted a problem and the gate that loads it can’t drift apart.

The second pass is there because a change to the rules engine can break a problem that used to be sound without anyone noticing. If that happens, a player should get a smaller corpus and never a board they can’t solve. A rejected problem never reaches the database. If an entire shard fails, the loader treats that as a shipping error and stores none of it. Mate-in-1 and mate-in-3 problems are checked during launch, and the deeper two shards in the background. Each problem gets two seconds.

When the validator later gained the twin check along every line, I re-ran all 902 shipped problems through it. None was rejected, and the run took about 1.7 seconds in an optimised build. The test suite proves the whole bundled set again on every run. It’s the same idea as proving Millrace’s levels in the test suite: a problem that stops passing should fail by name before it can reach a player.

How the problems reach you

The problems live in Mate Trail, one of Xiangqiful’s nine drill modules. The hub lists one row per depth, mate in 1, 3, 5 and 7, with how many you’ve solved in each. A session opens with “Find the mate. Every move must give check.” You play Red’s moves and the app answers with Black’s. Black’s replies come from the problem’s recorded lines, so the board never stops responding partway through.

Problems you miss come back through spaced repetition. The session header marks a returning problem as a review due today, or, once the unseen ones run out, as seen before with no new problems left. There’s no credit line under the board; the source lives on every problem in the data instead.

The first problem a new player sees comes from the books. During setup, before any trial offer, the app asks you to solve the last move of Lanke Shenji #46, a chariot mate with seven pieces on the board.

Mate Trail is separate from the exercises Xiangqiful cuts from your own analysed games. Nobody has screened those positions for a second mate. So when the answer to one of them is a mate in one, the app accepts any mating move, not only the one it recorded.

The free tier includes three training puzzles a day, and mate problems count toward that. Premium removes the limit for $1.99 a month or $9.99 a year, each with a one-week free trial, or $19.99 once. Everything runs on your device on iPhone, iPad and Mac, with no account. The app page has the rest: ten opponents, Pikafish analysis, 80 lessons and more than 150 drills. A Shiqing Yaqu problem from 1570 is in the app only because a solver confirmed what the book says.

How to plan moves ahead in a tile puzzle: six checks, and Millrace's Level 1 move by move

2026-09-27T00:00:00+00:00

Millrace is a tile-delivery puzzle: build one exact value on one marked cell inside a move budget, while tiles keep arriving through a single inlet on the board’s edge. The board is fixed and every arriving tile is shown before your first move, so a level can be planned to the end. The campaign screen states the core rule in one line: “Tiles keep arriving at the marked cell. Block it and you lose.”

The rules that matter for planning

Rule	What it means when you plan
The board is 4×4. A swipe slides every tile; two equal tiles merge into their sum, once per move.	One swipe changes all four rows or columns at once.
Tiles arrive through one inlet, on an edge, never in a corner.	Every arrival lands on the same cell.
After each move, the next tile in the queue lands on the inlet. Only 2s and 4s arrive, and the whole queue is shown.	You know every future arrival before you start.
If the inlet is occupied when a tile is due, the run ends: Blocked.	While tiles remain, the inlet must be empty after every move.
The goal is one exact value on one marked cell, the vault.	Too small isn’t finished, and merging past it (a 32 when the level asks for 16) destroys it.
The goal is checked before the next tile arrives.	The winning move can’t be spoiled by the inlet.
The move budget is two above the shortest solution on 56 levels, one above on 6, and equal to it on 2.	At most two spare moves; on Levels 51 and 64, none.
Every legal first move leaves the level winnable.	Your first swipe can never lose.

Six checks before every swipe

1. Read the chapter as a number. Each chapter is pinned to one solution length. Every Warm-up level’s shortest solution is exactly 5 moves, Tactics 6, Pressure 7, Precision 8 and Deep Water 9; Mastery runs from 10 to 16. Compare it with the “moves left” counter before your first swipe: a Tactics level that opens with 8 moves left gives you two spare moves.

2. Do the target arithmetic. Every tile is a power of two, so the target is built from pairs: a 32 is two 16s, a 16 is two 8s. Before moving, find the tiles that will become the target, including any still in the queue. Note anything that could merge with the finished value, too.

3. Never slide toward the inlet’s edge while a tile is due. After every arrival, the newest tile sits on the inlet, against the edge. A slide toward that edge can’t move it off. It either stays put or absorbs an equal tile behind it, and either way the cell is still occupied when the next tile comes. So from move 2 on, while the queue isn’t empty, that swipe does nothing, loses, or wins. It can win because the goal is checked before the next arrival, so a slide that completes the delivery still counts. No level is an exception.

4. Check the inlet’s own line on the other slides. Say the inlet is on the left edge. Left is check 3. Right moves the newest tile away, unless its row is still full after merging. Up and Down pack the inlet’s column toward one end, and if it holds enough tiles after merging to reach the inlet, one of them lands on it. Count before you swipe.

5. Count the queue. Each level card shows how many tiles are arriving, and the status bar under the board shows the remaining queue with the next tile highlighted. One tile arrives after each move until the queue is empty. Level 1 has three arrivals and a 7-move budget, so the inlet matters for the first three moves only. After that, the board is a pure delivery problem. In 9 of the 64 levels the queue holds at least as many tiles as the budget has moves, so the inlet never stops mattering.

6. Choose your finish early. A delivery ends in one of two ways. Either you build the value elsewhere and slide it onto the vault, or the final merge happens on the vault itself. In 22 levels every shortest solution ends with a slide, in 29 with a merge on the vault, and 13 can be finished either way. Carrying needs an open lane to the vault; merging there needs the second tile to line up with it. The early moves build one or the other.

Level 1, move by move

Here is the first Warm-up level’s starting board:

	Column 1	Column 2	Column 3	Column 4
Row 1	4	·	2	·
Row 2	inlet	·	·	·
Row 3	vault	·	·	·
Row 4	·	·	4	8

The inlet is on the left edge, second row; the vault is directly below it. The target is exactly 16. The queue is 2, 2, 2, and the budget is 7 moves. The shortest solution is 5 moves, and only one five-move line exists.

Start with the arithmetic. 16 is 8 + 8, and the second 8 can come from the two 4s. The three queued 2s play no part in the target. They are the cost of the level: three tiles to keep off the inlet.

Move	Swipe	What happens	Tiles still due
1	Down	The top-left 4 drops to the bottom-left corner; the 2 in the third column stops on the 4 below it. Bottom row: 4 · 4 8. A 2 arrives on the inlet.	2
2	Right	The bottom 4s merge: · · 8 8. The new 2 slides off the inlet to the right edge. Another 2 arrives.	1
3	Right	The 8s merge into the 16 in the bottom-right corner; the two 2s in the inlet’s row merge into a 4. The last 2 arrives.	0
4	Up	Nothing else is coming, so the inlet no longer matters. The right column rises, lifting the 16 into the vault’s row.	0
5	Left	The 16 slides along the third row onto the vault. Solved.	none

The 16 is built in the far corner, away from the arrivals, and carried to the vault only after the queue is empty. That is check 5 and check 6 working together.

Where it goes wrong:

Move 2, Left or Up: Blocked. Two of the four swipes lose on the spot. Left pushes the 2 that just arrived against the edge (check 3). Up packs the left column, the 2 on the inlet and the 4 in the corner, into the top two cells, which puts the 4 on the inlet (check 4).
Move 3, Up: lost, quietly. Up is legal and blocks nothing. It splits the two 8s: one goes to the top of the third column, the other to the second row of the fourth. With four moves left, no line brings a 16 to the vault. Nothing on screen says so, but if the run ends in a loss, the card reads “Position lost at move 3”.
Move 3, Down: safe, but slower. It still wins, in six moves instead of five, so it costs one of the two spare moves.

Level 8: when the queue never runs out

Level 8, in Tactics, turns check 5 around. Nine tiles are queued against an 8-move budget, so a tile is due after every move the level allows. The inlet is in the top row, second column, and the vault sits right next to it in the third column. The target is exactly 32.

The only shortest line takes six moves: Right, Down, Left, Down, Right, Up. Its last swipe goes toward the inlet’s own edge with four tiles still waiting. That’s the exception in check 3. Up carries a 32 from the third row onto the vault, and the goal is checked before the next tile is due. The same swipe one move earlier would have lost on the spot.

Why the checks are not enough on their own

Every check above looks one move ahead, and one-move play is what the levels are built to beat. Before a level ships, 280 strategies that never look past the current move play it, among them 24 versions of “keep the inlet clear”, 24 that refuse any move that loses at once, and 24 that steer the target toward the vault. If any of them wins, the level is thrown away; how Millrace’s levels are made covers the full battery. The checks keep you alive. Solving takes the next step: where the tile after next will land, and what the board must look like when it does.

When you get stuck

Hint draws the first move of a shortest line from where you stand, with a one-line reason. It runs the same solver that verified the level, and it’s free and unlimited.
Undo inside a level is free and unlimited. After a loss, the card’s main button is “Undo that move”, not Restart. Undo tokens apply only to Freeplay, the endless board.
The result card says “Best possible is N moves” when you solved a level in more moves than it needed.

Millrace is free on iPhone and iPad, with no ads and no lives; the app page has the full rules. The comparisons with Threes, KAMI 2 and Flow Free set out what each of those games asks of you.

Sixty-four levels, none written by hand: how Millrace finds and proves its puzzles

2026-09-24T00:00:00+00:00

A puzzle level is real when thinking is the only way through it. Checked by machine, that idea turns into a list of testable properties. Every one of the 64 levels in Millrace, a tile-delivery puzzle, was found by search, and none ships unless all five of these hold:

It is solvable within its move budget.
Its shortest solution is known exactly. A breadth-first search walks the level’s entire state graph, and the first win it reaches is provably the minimum. The game calls that number the best possible; my own estimate plays no part.
No thoughtless strategy wins it. 280 strategies that never look beyond the move in front of them play it through. If one wins, the level is gone.
Random play almost never wins. The exact odds are computed (no sampling), and above 2% the level is gone.
It is not another level in disguise, whether rotated, reflected or with its tile values relabelled.

Those five head a list of sixteen numbered checks. The others keep levels fair: move one can never lose, some later line always can, a blocked inlet must be a reachable loss, the budget allows at most two spare moves, and there must be at least ten winning lines. So there are many routes through each level, and none of them is a dumb one. The chapters make one check visible:

Chapter	Levels	Shortest solution (moves)	Move budget
Warm-up	4	exactly 5	7
Tactics	12	exactly 6	8
Pressure	12	exactly 7	8-9
Precision	12	exactly 8	9-10
Deep Water	12	exactly 9	9-11
Mastery	12	10 to 16	12-16

What the earlier puzzle mode got wrong

An earlier version of this game’s puzzle mode shipped 22 puzzles, and a test confirmed each had a solution. When I finally solved all 22 exhaustively, the mean shortest solution was 1.91 moves. “Up, then left” solved 19 of them. Random play won at least 98% of the time on 20, and even the hardest fell to it two times in three. One could not be lost by any legal sequence. Nine were the same board with different numbers printed on the tiles.

The cause was structural. Nothing arrived on those boards, so every move made the position easier, and every goal was monotone: once reached, nothing could undo it. No position could be ruined, and a puzzle needs a way to go wrong. The test only asked whether a solution existed, which sets a floor and no ceiling.

Why greedy-friendly goals fail

I assumed the old goals only needed a failure rule. Of 400 forged candidates for “clear the board down to N tiles”, 215 reached the target depth and none passed. Of 400 for “reach a tile of at least T”, 100 reached it and none passed. “Deliver an exact value to a marked cell” passed readily.

The reason is almost embarrassing once written down. A goal that a one-move greedy metric directly optimises can never be a puzzle. A player who grabs the most empty cells is pursuing the clearing goal; one who grabs the biggest tile is pursuing the reach goal. The clearing goal fell to the dumbest strategies in the battery: one direction over and over, or a fixed cycle.

Delivery survives because it can be lost twice over. The target must rest on one cell, so sliding it off loses it. It must also be an exact value, so merging past it (building a 128 when the level asked for a 64) loses it for good. No local score approximates either condition. Millrace has exactly one kind of goal because the measurements left only one.

Why you can see every tile before it arrives

The other half of the fix is the arrival queue. Tiles, only 2s and 4s, enter one at a time through a single inlet on the board’s edge. If the inlet is occupied when the next one is due, the run ends. That brings back the tension a slide-and-merge board depends on, because it fills while you merge.

Chance stays out. The queue is authored and always on screen, so every position is a pure function of the moves played, with at most four moves from each. With random arrivals, “the shortest solution” isn’t a number, since it depends on tiles nobody has drawn, and a solver can only average over futures. With a visible queue there is nothing to average, and breadth-first search is the exact model. The gate knows exactly what you know.

How a candidate level is generated

The generator is simple, and the rigour sits in the gate. A candidate gets a vault on an edge cell (never a corner, which would be marked twice) and a scatter of tiles from 2 to 32. The inlet is chosen last, from edge cells no opening slide can fill; when it was picked first, most candidates buried their own inlet on move one. The target is one or two doublings above the biggest starting tile, followed by a queue of 2s and 4s. A candidate whose tiles cannot sum to the target is dropped before any search runs.

The solver measures the true shortest solution under the gate’s most generous budget, 16 moves, and the candidate stays only if that depth is what the chapter demands. It tries two spare moves, then one, then none, keeping the kindest budget that passes. Depending on the chapter, roughly one to eight candidates in a thousand make it.

280 thoughtless players, and one random one

The battery in the middle of the gate has 4 policies that push one direction until they can’t, 60 that cycle through two, three or four directions, 24 fixed priority orders, 72 greedy players chasing points, empty cells or the biggest tile under all 24 tiebreak orders, and 120 that know the rules. Those last ones keep the inlet clear, keep it clear then score, avoid losing on this move, herd the biggest tile to a corner, or chase the target onto the vault, again under all 24 orders. Each is deterministic, so one playthrough counts as a proof. A level ships only if all 280 fail.

The battery’s first version was circular. Its 70 policies never looked at the inlet, so “none of them solves it” only meant “players who ignore the inlet die to the inlet”. Adding rule-aware players broke six of the eight puzzles that had passed it.

The line sits at one move on purpose. Looking two moves ahead (where will the next arrival land?) isn’t thoughtless, and it is the skill the levels teach. The gate certifies that the content has depth; it doesn’t assume you can’t think. How to plan moves ahead in Millrace shows that lookahead in play, with Level 1 worked move by move.

Chance gets the same treatment. The move budget makes each level’s state graph finite and loop-free, so a random player’s odds are computed exactly by a memoised walk instead of a simulation. The ceiling is 2%, Warm-up included. Across the 64 levels the odds run from about one in a million on the deepest boards to 1.31% on Level 1, with the median near one in a thousand.

Finally, no two levels may share a canonical form: tile values replaced by rank, then the smallest of the eight rotations and reflections of board, inlet, vault and queue together. That check exists because of those nine identical boards.

Why the gate lives in the test suite

The sixteen checks live in the test target and run every time, not once. The generator filters with the same functions, and the suite asserts each property over the shipped library, so a level that stops passing fails the tests and names the property that broke. A search that runs out of budget fails too, since an unproven level can’t ship. The gate also has to prove itself: a board from the earlier library is kept as a fixture, and the suite fails if it ever gets through. Re-proving all 64 levels takes just under a hundred seconds. Tare’s balance puzzles are built by hand, but they pass the same kind of gate; here is how it proves each level.

The Hint inside a level runs the same solver, so the two cannot drift apart, and one check plays every level on the hint alone: it must win in exactly the shortest number of moves. For Chessful’s forty opponents, difficulty was a matter of character. Here it had to be a number the tests check.

What you see of it

Almost none of this is on screen.

The chapter is the depth. Every Tactics level can be solved in six moves and no fewer; every Deep Water level, in nine. In chess, depth is an engine setting, and more of it doesn’t help a club player. Here it is a measured property of the board.
The budget is tight. The deepest level needs all 16 of its 16 moves.
The result card says “Solved in N moves”, and if you used more, “Best possible is X moves”, where X is the proven minimum.
A loss can say when it happened. After a failed run, the card can name the move where the position became unwinnable. It only does so afterwards, because a live warning turns a level into trial and error, and you reach the answer having understood nothing.

Millrace is free on iPhone and iPad; the app page has the rules and the privacy details. If a level ever feels impossible, somewhere in its graph is a line exactly as long as the card says, and the tests have walked it.

Promotional text vs description: which App Store fields you can change without an update

2026-09-19T00:00:00+00:00

App Store Connect splits your product page into things you can change on the live app and things that wait for the next version. Apple’s table of required, localizable and editable properties marks the properties that “can be localized and edited at any time without submitting a new version of your app.” Everything else changes with a version.

Which App Store fields need a new version?

Field	Lives in	Limit	When you can change it
Promotional text	Version	170 characters	Any time, no new version
Description	Version	4,000 characters	With a new version
Keywords	Version	100 characters	With a new version
What’s New	Version	4,000 characters	With a new version (not on the first version)
Screenshots	Version	Up to 10 per display size	With a new version
App previews	Version	Up to 3 per localization and display size	With a new version
Support URL, marketing URL	Version	Full URL	With a new version
Copyright	Version		Any time
App Review information	Version	Notes up to 4,000 bytes	Any time
App name	App Information	30 characters	With a new version
Subtitle	App Information	30 characters	With a new version
Primary and secondary category	App Information		With a new version
Age rating	App Information		With a new version
Primary language	App Information		Any time
Privacy policy URL	App Privacy		With a new version
App Privacy data types	App Privacy		Any time
Price and availability	Pricing and Availability		Any time
App icon	Your build		With a new version and a new build

Sources: the editable-properties table above, Apple’s Platform version information reference, its product page guide, and the Add an app icon page, which says changing the icon after publishing means creating and uploading a new version.

Promotional text vs description: what’s the difference?

They sit next to each other on the product page, but Apple treats them differently.

	Promotional text	Description
Length	Up to 170 characters	Up to 4,000 characters, plain text, no HTML
Position	At the top of the description	Below the promotional text
When it changes	Any time, without a new version	With a new version
Search	Apple says it doesn’t affect search ranking	Not listed among App Store search factors; used for web search engine results
Apple’s suggested use	Current news: limited-time sales, upcoming features	What the app does; the first sentence is what people read without tapping more

The practical rule follows from the third row. Anything that will be out of date in a month (a sale, a seasonal event, a feature that’s coming soon) goes in promotional text, because you can take it out again without shipping. Anything that should stay true for the life of a version goes in the description. Apple also says to leave specific prices out of the description, which is easier to follow once you know the promotional text is the place for a sale.

Putting keywords into promotional text doesn’t help. Apple says so on both its search and product page guides, and the keyword field has its own rules.

What’s the difference between App Information and version information?

App Store Connect has two places for metadata, and the API mirrors them.

App Information is shared across all versions and platforms of the app. In the App Store Connect API it’s an appInfoLocalizations record holding the name, subtitle, privacy policy URL and privacy choices URL, with the categories and age rating on the appInfo itself.

Platform version information belongs to one version on one platform. Its appStoreVersionLocalizations record holds the description, keywords, promotional text, What’s New, support URL and marketing URL, and the version also carries the screenshots, app previews, copyright, version number, App Review information and release settings.

That split explains the first trap. App Information isn’t tied to a version, so it’s easy to assume you can edit it any time, and for most of it you can’t. Apple’s table marks the name, subtitle, categories, age rating and privacy policy URL as not editable at any time, and the product page guide ties subtitle changes to a new version. In the API, while an update is in preparation the app has two App Info records, one for the live version and one for the update, and the update’s record is the one you edit.

The second trap is the promotional text itself. It is a version field, stored right next to the description, yet it’s the only marketing copy you can change on a version that’s already live. Tools that lock every version field once a version is approved get this one wrong, AppMeta included for now (more on that below).

When does a version accept edits?

Apple lists the statuses in which you can upload and submit screenshots for a version: Prepare for Submission, Invalid Binary, Rejected, Metadata Rejected and Developer Rejected (Apple’s screenshot upload help). In other words, a version you’re preparing or one that came back from review. If you spot a mistake after submitting, Apple’s route is to remove the version from review, which sets it back to Developer Rejected; the review starts over when you resubmit (Remove a submission from review).

To start a new version, the current one has to be Ready for Distribution. App Store Connect copies the live version’s metadata into the new one, so a description fix starts from what’s already there (Create a new version). You still need a build: a version can’t be submitted without one, and Apple’s steps include uploading a new build with an incremented build string. So a description-only update is still a full release with a new binary.

What can you change without a new version?

Beyond promotional text, Apple’s editable-properties table marks these as editable at any time:

Price, pricing start and end dates, availability, the pre-order release date, tax category and the last-compatible version setting
App Privacy data types (the privacy label)
App Review information and copyright
Primary language and the custom license agreement
The routing app coverage file, for navigation apps
Accessibility support, for the Accessibility Nutrition Labels
Phased release, which you can pause within its seven-day window

Several review tracks also run without a new app version once your app has an approved one:

Track	What it changes	Apple’s rule
Custom product pages	Screenshots, app previews, promotional text and keywords on an alternate page, up to 70 per app	Submit with or without an iOS app version; keywords come from your latest approved version
Product page optimization	Up to three treatments of icons, screenshots and previews, for up to 90 days	Tests without alternate app icons can be submitted independently of a new version
In-App Events	Event cards and details	Submit with or without an iOS app version
In-App Purchases	New products and their metadata	Only the first product of each type needs a new app version

The custom product page rules are on Apple’s submission page, the test rules on its product page optimization page, and the In-App Purchase rule was clarified in Apple’s release notes on August 19, 2026. A product page optimization test can’t change your default page’s screenshots by itself, but if a treatment wins, Apple lets you apply it to the original product page.

How I plan around it

When a version is in Prepare for Submission, I go through every version field and every App Information field in every localization, because that window is the only time most of them open. Between versions, the levers are promotional text and the review tracks above.

Screenshots follow the same window, and the screenshot guidelines post covers what App Review checks in them. The keyword field is the one I plan furthest ahead, because a keyword change waits for a version just like a description change does.

Where AppMeta fits

AppMeta keeps the same split App Store Connect does. App Information fields (name, subtitle, privacy policy URL) and version fields are separate sections, and each push goes to the right API record. When the newest version on a platform is live, in review or waiting for release, AppMeta locks its version fields and says why, and you can create the next version from inside the app, then copy fields over from the previous one. Before anything is pushed, the preview shows the current App Store Connect value next to your change for every field and localization. AppMeta signs in with an API key you create yourself; the setup guide walks through it.

AppMeta has one gap: it applies that version lock to promotional text too. To change promotional text on a live version with no update in progress, use the App Store Connect website for now.

How to sleep on call: the waiting, the wake-up and the morning after

2026-09-12T00:00:00+00:00

On-call work means being available outside your rostered hours, at home or on site, for a call that may or may not come. Doctors, nurses, firefighters, engineers, IT staff and utility crews all do it. The studies below look at people on call overnight; some measured real call-outs, others only the possibility of one.

What does the research say about sleep on call?

Study	Who	What it found
Torsvall & Åkerstedt, 1988	5 ships’ engineers, EEG	On-call nights with two alarms had shorter sleep, less deep and REM sleep, and a higher heart rate. Many of the changes appeared before any alarm. Sleepiness was higher the next day.
Hall et al., 2017	Systematic review of 8 studies	Being on call from home appears to reduce sleep quantity and, in most studies, sleep quality. None separated nights with calls from nights without.
Vincent et al., 2021	Survey of 228 Australian on-call workers	80% slept under 7 hours when on call; 56% said being on call affected their sleep even when no calls came.
Marcel-Millet et al., 2020	13 firefighters	Parasympathetic heart-rate variability, a sign of the body settling, was lower on on-call nights with or without a simulated call-out. Sleep time and rated quality fell on the night with a call-out.
Kovac et al., 2020	23 young men in a sleep lab	Told they might be woken but never were, they slept about 7.5 hours, yet felt sleepier after waking than on a normal night.
Barger et al., 2005	2,737 first-year doctors	After shifts of 24 hours or more, the odds of reporting a car crash were 2.3 times higher and of a near miss 5.9 times higher.

Two findings run through the list: sleep on call is worse even when the phone stays quiet, and the moments after a call wakes you carry their own risk.

Why does being on call cost sleep even when nobody calls?

The engineers in the 1988 study slept worse before any alarm had sounded, and the authors attributed it to apprehension about being woken. The Australian survey asked on-call workers what they turned over in their heads. The top answers were interruptions to family and leisure time (70%), missing a call (69%), planning in case of a call (69%) and not being able to make plans (67%).

Not every study finds the worry in the sleep itself. In two lab studies from the same Australian group (Sprajcer et al., 2018 and Kovac et al.), telling young men they would face a stressful task rather than an easy one if woken made no difference to how they slept. A lab bedroom with nothing real at stake differs from a bedroom with a pager on the table, though, and the field studies and surveys fairly consistently find real on-call nights shorter and lighter.

The survey doesn’t test fixes, but its list suggests where to start. If the worry is missing the call, make that close to impossible: one alert you have tested at full volume, and Do Not Disturb set so only the call-out number gets through. If it’s the planning, do it before bed. Clothes, keys, bag and charger in one place leave nothing to rehearse in the dark.

What is sleep inertia, and how long does it last?

Sleep inertia is the grogginess and slowed thinking right after waking. A 2019 review by Hilditch and McHill sets out its shape:

It is worst in the first 15 to 30 minutes and then fades, but full recovery can take an hour or more.
It is worse after sleep loss, and worse when you wake near the low point of your body clock in the early hours of the morning.
Right after waking, the impairment can match or exceed that seen after up to 40 hours without sleep.
Naps of 30 minutes or less are less likely to cause it, though not immune.

On call, these add up. A call that wakes you at 3 a.m. after a short night lands on close to the worst version of inertia there is. Where you can, put the minutes it takes to dress and get moving before anything that needs judgement, and check the first decision twice.

Can caffeine or light shake off sleep inertia?

The same review rates the countermeasures. Caffeine taken just before a short nap of about 20 minutes has the best support, because it starts working around the time you wake. Caffeine gum after waking shortened inertia but didn’t help the worst first stretch. Bright light, sound and cooling have weak or early evidence, and no reactive fix has clear, immediate benefit.

In Reyner and Horne’s 1997 driving-simulator study, sleepy drivers given 200 mg of caffeine plus a nap of under 15 minutes had 9% as many driving incidents as on placebo, against 34% with caffeine alone.

On call, caffeine has a cost it doesn’t have on a normal shift: you may want to go back to sleep. A 2022 review on switching on for a call and switching off after it points out that whatever wakes you up for a call may also keep you from falling asleep afterwards, and that this hasn’t been studied well yet. Caffeine’s half-life is about 5 to 6 hours (the night-shift guide does the arithmetic), so a coffee at 2 a.m. for a twenty-minute call is still mostly in you at 6. It makes sense to save it for calls that will keep you up, or for the drive.

How should you nap when you’re on call?

When your sleep might be broken at any moment, sleep you get before the call is worth more than sleep you plan to get after it. That makes short naps the main tool. If you might have to act straight away on waking, Hilditch and McHill suggest keeping naps under 30 minutes. NIOSH’s shift-work course adds that waking after about 20 or about 90 minutes tends to leave you less groggy than waking after about an hour.

A 2025 review of fatigue guidance for on-call workers went through 65 guidance documents from regulators and 17 studies of what works. It found very little research outside limits on working hours. Training, education and call management, such as protected naps during on-call periods, were among the few measures with some supporting evidence.

What should you do after a night of calls?

Treat it like the morning after a night shift, because for your body it was one. The drive home is the riskiest part. In Barger’s study of first-year doctors, each extended shift scheduled in a month raised the monthly risk of a crash on the commute home by about 16%. Get a lift if you can, nap before you drive if you can’t, and see the night-shift guide for the dark room and the rest of the morning.

Then expect recovery to take more than one night. In a lab study by Banks and colleagues (2010), people limited to 4 hours in bed for five nights had still not fully recovered on attention, sleepiness and fatigue measures after a single 10-hour night in bed. A week of broken on-call nights is a different experiment, but the result points the same way: one long sleep helps, and it may not be enough.

If you are on call often and your sleep doesn’t recover between stretches, raise it with your employer’s fatigue policy and with a doctor. The American Academy of Sleep Medicine’s page on shift work disorder describes when poor sleep around work hours becomes a clinical problem.

Where AfterShift fits

On-call is a shift type in AfterShift, and it changes how the app treats the whole window around it. Calendar import recognises event titles such as on call, standby, backup, Bereitschaft or päivystys, and you can mark any shift as on-call yourself. When the window between your shifts contains an on-call shift:

The Shift Recovery Score is capped at 75 and the Sleep Score at 84, so neither can read Excellent. I did that on purpose. The studies above find on-call sleep is worse even before any call comes, and a perfect-looking number in a week of broken nights would be the app claiming to know more than it does.
The plan shows a flexible rest window instead of a set main sleep, and the nap suggestion says short naps are often more reliable on call. The short-window warning is switched off, since a short window is normal on call.
In Premium, the playbook switches to a standby routine when an on-call shift starts within the next 12 hours: lay out what you’ll need and keep the path to the door clear, keep caffeine for the shift, and wind down lightly so you stay easy to wake.
Three or more on-call shifts in seven days count as an on-call week, and the app notes that recovery may come more slowly.

Naps you log count toward the score like any other sleep, which matters on call, where they may be most of what you get. The methodology page explains the caps, and the rotating schedules guide covers the rosters that on-call weeks usually sit inside.

Double progression explained: add reps until the range runs out, then add weight

2026-09-05T00:00:00+00:00

Most strength programs start with linear progression: a little more weight every session. On most lifts it works for a few months and then stops, usually on the press first. How to tell when that phase is over is in choosing a strength program you will finish. What most people run next is double progression. It is also the default rule in the strength log I build, so this is the long version.

What is double progression?

You progress two things in a fixed order: reps first, at a weight you keep, then load, once the reps have run out of room.

Part of the rule	What it means
Rep range	A bracket for every working set, written sets × bottom-top: 3 × 6-10
Hold	Keep the weight while any set is short of the top of the range
Add load	When every working set reaches the top, add the smallest increment you have
Reset	At the new weight, expect to be back near the bottom of the range
Bad session	A set below the bottom is a miss. Repeat the weight. Only several misses in a row call for a lighter restart

None of this is new. The American College of Sports Medicine’s 2009 position stand on progression lists increasing load within a prescribed zone, its example being 8-12 RM, as one of three ways to progress. Its rule for when to move is a 2-10% increase once you can do one or two reps more than the target on two consecutive sessions, at the lower end for small-muscle exercises (ACSM, 2009). Double progression is that rule with the bookkeeping written down.

A worked example: eight sessions of overhead press

Barbell overhead press, 3 × 6-10, starting at 40 kg. The smallest jump in this gym is 2.5 kg.

Session	Load	Reps (set 1 / 2 / 3)	Total reps	Next session
1	40 kg	10 / 8 / 7	25	Same weight
2	40 kg	10 / 9 / 8	27	Same weight
3	40 kg	10 / 10 / 8	28	Same weight
4	40 kg	10 / 10 / 10	30	Add 2.5 kg
5	42.5 kg	8 / 7 / 6	21	Same weight
6	42.5 kg	8 / 7 / 5	20	Same weight (set 3 missed)
7	42.5 kg	9 / 8 / 7	24	Same weight
8	42.5 kg	10 / 9 / 8	27	Same weight

Sessions 1 to 4 are the easy part: the weight never changes while the total climbs from 25 reps to 30, and session 4 is the first time all three sets reach ten.

Session 5 is where people lose faith. Going from 10, 10, 10 to 8, 7, 6 looks like a step backwards. It is the plan working: every set is inside the range at a heavier weight, and the climb starts again.

Session 6 has a set below six. That is a miss, and the response is nothing special: same weight next time. A rough session right after a 6% jump is common.

By session 8 the lifter is doing 27 reps at 42.5 kg. Reps times load has gone from 1,000 kg in session 1 to about 1,148 kg, roughly 15% more work, while the bar moved once. The load moves less often, and the reps show you are still progressing between jumps.

Which add-weight rule should you use?

“Every set reaches the top” is the strict version and the most common one. There are others.

Variant	Add load when	Suits	Catch
All sets at the top	Every working set reaches the top of the range	Most lifts; the safe default	Slowest of the single-session rules. One tired last set holds the lift back
Two sessions in a row	All sets reach the top in two consecutive sessions	Lifts where one good day can be luck	Slower again. Worth it mainly on lifts close to your ceiling
Rep total	The session total reaches a target, say 27 across 3 × 6-10	Lifts where the last set always lags	Lets one set drift low while the others carry it
Top set only	The first, heaviest set reaches the top	A top set followed by lighter back-off sets	Moves load fast; the back-off sets need their own rule

Pick one per lift and keep it for the block. Switching rules midway is how a lift ends up at a weight no rule would have chosen.

Why does adding reps count as progress?

Because, over a couple of months at least, it seems to work about as well as adding load. In Plotkin et al. (2022), 38 trained lifters did eight weeks of lower-body training. One group added load and kept its reps in a range; the other kept its load and added reps. Squat strength rose 21.8 kg in the load group and 19.3 kg in the reps group, a gap the authors called of questionable practical significance, and muscle thickness changes were similar.

The wider rep-range research points the same way. A 2017 meta-analysis led by Brad Schoenfeld found similar muscle growth with light and heavy loads when sets were taken to failure, while one-rep max strength favoured heavier loads. A 2021 re-examination of the repetition continuum, also led by Schoenfeld, argued that adaptations happen across a wide range of loading zones. The ACSM’s 2026 update, an overview of 137 systematic reviews, found hypertrophy did not differ across 30-100% of one-rep max when effort was comparable, and that strength gains were greater at 80% and above (Currier et al., 2026).

So no rep range is magic. For size, pick a range you will push honestly. For a lift where top-end strength is the point, keep the range near the heavy end, where the strength benefit shows up.

How wide should the rep range be?

Wide enough that one load jump does not throw you below the bottom of it.

Range	Typical use	What to watch
3-5	Main barbell lifts, strength focus	Narrow. One standard jump can eat the whole range, so microload
6-10	Compound lifts, mixed goals	Room for a 4-6% jump to cost two or three reps
8-12	Most machines, dumbbells, general size work	The zone ACSM’s 2009 stand used as its example
12-20	Small-muscle isolation: raises, curls, calves	The next dumbbell is often a 15-25% jump, and the range has to absorb it

If you add weight and land below the bottom of the range two or three sessions running, the range is too narrow for the jump. Widen it, or make the jump smaller.

What is microloading, and when do you need it?

Microloading means adding less than the standard 2.5 kg (5 lb) step, with fractional plates from 0.25 to 1.25 kg or small add-on weights for dumbbells. The case for it is arithmetic. The same plate is a very different jump on different lifts:

Working weight	+0.5 kg	+1 kg	+2.5 kg	+5 kg
30 kg overhead press	1.7%	3.3%	8.3%	16.7%
60 kg bench press	0.8%	1.7%	4.2%	8.3%
100 kg squat	0.5%	1.0%	2.5%	5.0%

Against ACSM’s 2-10% band, which asks for the low end on small-muscle exercises, 2.5 kg on a 30 kg press sits near the top of a range meant for big lifts. The same plate on a 100 kg squat is near the bottom. That is a large part of why the press stalls first.

Dumbbells are harder, because the rack decides the jump. Going from a 10 kg to a 12 kg dumbbell for lateral raises adds 20%. Without add-on plates the practical fix is a wider range, such as 12-20, so the reps can absorb the jump.

You need microloading when the smallest standard jump keeps knocking you out of the range: overhead presses, bench press for lighter lifters, most single-joint lifts. You can usually skip it on squats and deadlifts until the weights are well past bodyweight.

When does double progression stop working?

On accessories it may never need replacing. On main lifts, these are the signs I would look for before changing:

Reps flat at the same weight for three or four weeks, on more than one lift at once. One stuck lift is a problem with that lift. Several at once is usually recovery, food or sleep, and no progression model fixes those.
Every jump lands you below the range, even after microloading. The lift may need a heavier, narrower range for a while, or a different variation.
You want to peak a main lift. Double progression is good at building and has no plan for a heavy single on a set date. A percentage cycle off a training max, such as 5/3/1, does, starting from a one-rep max that is tested or estimated.

Before giving up on the model, change one thing inside it: swap the exercise variation, move the range (from 6-10 to 10-15 for a block), or add a set. If one lift does move to a percentage cycle, the others can keep running double progression. Mixing models across lifts is normal.

This is training information, not medical advice. If a load jump hurts rather than just feels hard, have a clinician or a coach who can watch you lift take a look.

How LiftLog runs it

In LiftLog, progression is a setting on each exercise in a program rather than on the program as a whole. The choices are double progression, linear, a percentage of a training max, RPE-based, or off. Nearly nine in ten exercise rows in the bundled example programs use double progression.

The rule is the strict variant from the table above. You set the target sets and a rep range, and the weight goes up only when every target set reaches the top of the range. A session inside the range holds the weight. A session where fewer than the target number of sets reach the bottom counts as a miss, and after three misses in a row the weight drops to 90% and the climb restarts. The increment, the number of misses and the drop are all editable per exercise.

When a workout ends, the recap labels each exercise Progressed, Hold, Missed or Deload and shows the next session’s weight and reps, and the program list previews that next target under each exercise. Bodyweight exercises get a reps-only mode that adds one rep at a time.

For microloading, the increment and the rounding step can both be set in 0.5 kg steps. Change both. With a 1 kg increment and rounding left at 2.5 kg, the next weight rounds back to where it was. The built-in plate calculator assumes a standard plate set down to 1.25 kg, so fractional plates are still your own bookkeeping.

Shogi openings for beginners: Static Rook, Ranging Rook and the first lines to learn

2026-08-29T00:00:00+00:00

Every shogi opening starts with one decision: does your rook stay where it started, or does it move across the board? Shogi players call the two answers Static Rook (居飛車, ibisha) and Ranging Rook (振り飛車, furibisha), and nearly every named opening belongs to one of them. Once you know which family you are in, you know roughly where your king will castle and which file your attack will come down.

Moves below are in English (Hodges) notation, so P-7f is a pawn moving to 7f and Bx8h+ is a bishop capturing on 8h and promoting. If that is new, the piece and notation guide explains it in five minutes. Black (sente) moves first.

Static Rook or Ranging Rook

	Static Rook (居飛車, ibisha)	Ranging Rook (振り飛車, furibisha)
Where the rook goes	Stays on its starting file: 2h for Black, 8b for Gote	Moves to the 5th, 6th, 7th or 8th file (for Black)
Where the king castles	On the left, away from the rook	On the right, where the rook started
Usual castles	Yagura, Boat, Left Mino, Static Rook Anaguma	Mino, High Mino, Silver Crown, Ranging Rook Anaguma
How the game usually goes	Attacks first, up the file the rook already stands on	Castles quickly, lets the opponent commit, counterattacks
Main openings	Yagura, Bishop Exchange, Side Pawn Capture, Double Wing Attack	Central Rook, Fourth File Rook, Third File Rook, Opposing Rook

Each player chooses separately, so there are three kinds of game: Double Static Rook, Static Rook against Ranging Rook, and Double Ranging Rook (Wikipedia’s overview of shogi openings traces how the balance between them has shifted since the Edo period). The rule underneath both families is the same: keep the king away from the rook, because the rook’s file is where the fighting starts.

The main openings at a glance

Opening	Japanese	Family	What defines it	Usual castle
Yagura (Fortress)	矢倉	Double Static Rook	S-7g closes the bishop diagonal; a slow build on both sides	Yagura: king 8h, silver 7g, golds 7h and 6g
Bishop Exchange	角換わり, kakugawari	Double Static Rook	Bishops traded in the first moves, then held in hand	King walks to 7i, behind the 7h gold and 8h silver
Side Pawn Capture	横歩取り, yokofudori	Double Static Rook	After both rook pawns are exchanged, Black’s rook takes the pawn on 3d	Varies
Double Wing Attack	相掛かり, aigakari	Double Static Rook	Both sides push and exchange their rook pawns early	Varies
Central Rook	中飛車, nakabisha	Ranging Rook	R-5h (R-5b for Gote)	Mino
Fourth File Rook	四間飛車, shikenbisha	Ranging Rook	R-6h (R-4b for Gote)	Mino
Third File Rook	三間飛車, sangenbisha	Ranging Rook	R-7h (R-3b for Gote)	Mino
Opposing Rook	向かい飛車, mukaibisha	Ranging Rook	R-8h, facing the opponent’s rook (R-2b for Gote)	Mino

The Ranging Rook names count files from Gote’s side, which is why Black’s Fourth File Rook sits on the sixth file (Wikipedia’s Ranging Rook page has the full list). You will also meet two names early that are attacking methods, not openings. Climbing Silver (棒銀, bōgin) walks the right silver up the rook’s file, S-3h, S-2g, S-2f, S-2e, to support a break on the second file. Right Fourth File Rook (右四間飛車) moves the rook to 4h to hit the opponent’s fourth file, and still counts as Static Rook.

Two lines, move by move

Fourth File Rook into a Mino castle

Black plays Ranging Rook from move one:

1. P-7f P-8d 2. P-6f P-8e 3. B-7g P-3d 4. R-6h S-6b 5. K-4h K-4b 6. K-3h K-3b 7. K-2h P-6d 8. S-3h G6a-5b 9. P-6e Px6e 10. Rx6e S-6c 11. G6i-5h

3. B-7g comes before the king walks. Gote’s rook pawn on 8e wants P-8f, and from 7g the bishop covers 8f, so that exchange never works. Walk the king first and P-8f opens the eighth file straight into your camp.
4. R-6h puts the rook behind the pawn on 6f. From here rook and pawn work as one unit: every quiet move that follows prepares P-6e.
5 to 8. The king walks to 2h and the right silver steps to 3h. King 2h, silver 3h, golds 4i and 5h is the Mino castle, and it is nearly finished before the first exchange.
9. P-6e is the break the whole setup prepares. If Gote does not take, Px6d wins a pawn; after Px6e Rx6e the rook stands on the fifth rank with a pawn in hand.
11. G6i-5h completes the Mino.

The plan fits in one sentence: castle on the right, then open the file your rook is standing on.

The Bishop Exchange

1. P-7f P-8d 2. G-7h P-3d 3. P-2f G-3b 4. P-2e Bx8h+ 5. Sx8h S-2b 6. S-3h S-7b 7. P-4f P-6d 8. K-6h K-4b

2. G-7h before anything else. The gold defends 8h, so the silver can recapture there.
4… Bx8h+ is the exchange. Gote takes first so that Black has to spend a move recapturing.
5. Sx8h recaptures with the silver, not the gold. Both sides now hold a bishop in hand, and a bishop dropped into a gap in your camp can fork two pieces at once.
6. S-3h is the silver every Bishop Exchange plan depends on. It climbs to 2f (Climbing Silver), rushes to 4f (Rushing Silver) or settles on 5f (Reclining Silver), as set out on Wikipedia’s Bishop Exchange page.
8. K-6h starts the king’s walk to safety, because with a bishop in each hand a king left in the open is the first target.

Which opening should you learn first?

Pick one family and stay with it until you know its castle and its main attack without thinking. Switching openings every game means you never get past move ten in any of them.

If you like to build first and hit back later, Fourth File Rook has one of the shortest plans to learn: the line above is the whole idea, and the Mino castle takes only a handful of moves. If you would rather attack, play Static Rook with Climbing Silver. One silver and one file give you a plan you can start on move one, and it teaches the pawn exchanges and drops on the second file that come up in most Static Rook openings.

Leave Side Pawn Capture and the deep Bishop Exchange lines for later. Both turn sharp early, with pieces in hand on both sides, so one missed drop can decide the game. That kind of mistake shows up clearly in an engine review, as the post on reading a shogi engine evaluation explains, but it is easier to avoid while you are still learning how a castle holds together.

How Shogiful teaches openings

Shogiful splits opening study into three parts.

The Openings lesson track has ten lessons. It starts with “Choosing your rook” and covers Static Rook basics, the Ranging Rook families, Fourth File, Central, Third File and Opposing Rook, Climbing Silver and the Bishop Exchange. It ends with “Choosing your opening”, which gives the same advice as above: one family, its castle and its main attack.

Joseki Lab has 55 opening lines in 11 families: Static Rook, Ranging Rook, Fourth File Rook, Third File Rook, Central Rook, Side Pawn Capture, Bishop Exchange, Yagura, Right Fourth File, Anaguma Openings and Double Static Rook. You play your own side’s moves and the opponent’s replies are played for you. Short notes appear at the moments that matter, under “What just happened”. If you play a known sideline, the drill explains how it is punished instead of just marking it wrong. Where the opponent has a second main defence, a card shows it to you. Lines you miss come back sooner through spaced repetition. The two lines above are Joseki Lab lines, and the move notes are condensed from their commentary.

The lines did not always go that far. Until early August, 38 of the 55 contained no capture at all. Each one built the formation and stopped exactly where the real game starts, so the Climbing Silver line ended the moment the silver reached 2f. A two-star App Store review pointed it out before any test did. Every line now plays through the first exchange of pieces, and each family shows two defences in full.

Castle Atelier drills twelve castles, from Mino and Yagura to both Anagumas. You build them, break into them, and repair them after an intrusion. After each analysed game, Game Review shows a badge naming the castle you actually built. YaneuraOu runs the analysis on your device, so there is no account and no server.

Shogiful is free to download, with Premium from $1.99 a month, $9.99 a year or $19.99 once. If you would rather try openings against people, the online platforms such as Lishogi and 81Dojo are built for that, and the guide to shogi apps for iPhone covers the rest of the field.

Puppy and kitten vaccination schedules: what's due when, and which dates to keep

2026-08-22T00:00:00+00:00

There are three sets of guidelines behind almost every small-animal vaccination schedule: the AAHA canine guidelines (2022, updated in 2024), the AAHA/AAFP feline guidelines (2020), both written for North America, and the WSAVA guidelines (2024), written for vets worldwide. They are guidance for vets, not a calendar to follow without one. Your vet adjusts for the animal, the products in stock and local disease, and rabies is set by law. The tables below are what the guidelines say.

Puppy vaccination schedule

Age	Core: distemper, adenovirus, parvovirus (often with parainfluenza)	Leptospirosis	Rabies
6 to 8 weeks	First dose
Then every 2 to 4 weeks	Repeat
From 12 weeks	Series continues	First dose	US products labelled from 3 months; timing set by law
2 to 4 weeks later	Series continues	Second dose
16 weeks or older	Final dose of the series
About 6 months	WSAVA: booster at or after 26 weeks
Within a year of the series	AAHA: one booster	One booster	Booster 1 year after the first dose
After that	Every 3 years	Every year	Every 1 or 3 years, by product and law

AAHA’s table asks for at least three core doses between 6 and 16 weeks, 2 to 4 weeks apart, and its text recommends repeating them until the puppy is older than 16 weeks, with 18 to 20 weeks preferred where distemper or parvovirus risk is high. A puppy that starts at 8 weeks on a 4-week interval gets core doses at 8, 12 and 16 weeks; one that starts at 6 weeks on a 3-week interval needs five visits to reach 16.

Leptospirosis changed category recently. The 2022 AAHA guidelines listed it as non-core, while noting that some task force members wanted it core. In June 2024 AAHA moved it to core, and WSAVA’s 2024 guidelines call it core wherever the disease is endemic, the relevant serogroups are known and suitable vaccines exist. Leptospirosis vaccines are killed bacterins that protect for about 12 to 18 months, so AAHA keeps them annual.

Kitten vaccination schedule

Age	FVRCP: panleukopenia, herpesvirus-1, calicivirus	FeLV (core under 1 year)
From 6 weeks	First dose
Then every 3 to 4 weeks	Repeat until 16 to 20 weeks
From 8 weeks	Series continues	First dose
3 to 4 weeks later	Series continues	Second dose
6 months	Revaccinate
First annual visit		Booster
After that	Every 3 years (injectable), yearly (intranasal)	Non-core after age 1: yearly if contact with FeLV-positive cats is likely, every 2 to 3 years if less likely

That is the AAHA/AAFP schedule for general practice. Rabies sits outside the grid: it is given as the law requires, with a booster at the first annual visit, and the AAHA/AAFP guidelines count it as core for cats even where the law does not require it. WSAVA’s kitten schedule is close: doses every 2 to 4 weeks, the last at 16 weeks or older, and revaccination at or after 26 weeks.

Why the last dose has to wait until 16 weeks

Puppies and kittens get antibodies from their mother, and those maternal antibodies block vaccines as well as infections. They fade at different rates in different animals, even within a litter, and there is no way to predict when a particular kitten’s or puppy’s have gone. AAHA notes that maternal antibodies against parvovirus may last 13 to 15 weeks or longer. The series is a way of making sure one dose lands after they fade, which is why the final dose matters more than the number of doses. WSAVA puts it bluntly: if a puppy or kitten can only have one vaccination, for example because of cost, it should be the core vaccines at 16 weeks or older.

The 6-month booster closes the remaining gap. The AAHA/AAFP guidelines cite studies suggesting that up to a third of kittens may not respond to a final dose at 16 weeks and may still carry blocking antibodies at 20 weeks. WSAVA now advises revaccinating puppies and kittens at or after 26 weeks rather than waiting until 12 to 16 months.

Adult boosters: every three years, or every year?

It depends on the vaccine. AAHA recommends core dog boosters every 3 years after the first-year booster and says annual core boosters are not necessary. WSAVA’s position is that core vaccines should be given no more often than necessary, because modern modified-live core vaccines protect for many years, while most non-core vaccines protect for about one. So a typical adult dog has a core booster every third year and some vaccines every year:

Leptospirosis: yearly.
Kennel cough (Bordetella with parainfluenza): a single intranasal dose for dogs at risk, then yearly. AAHA notes that dogs at high risk may benefit from a dose more often than that, for example before boarding.
Lyme disease: for dogs that live in or travel to areas where it occurs. Two doses 2 to 4 weeks apart, finished 2 to 4 weeks before travel, then yearly.
Canine influenza: two doses 2 to 4 weeks apart, a booster within a year, then yearly.

WSAVA also asks vets to treat the yearly visit as a health check rather than a vaccination appointment, so that visit doesn’t go away when the core shots stop being annual.

What to copy from every vaccination certificate

A vaccination certificate settles questions that memory can’t. For each vaccine, keep:

The vaccine as written, product name included. “Rabies, 3-year” and “rabies, 1-year” are different due dates.
The date given. For a puppy or kitten, check it against the date of birth: the last dose of the series should fall at 16 weeks or later.
The next due date, copied from the certificate rather than worked out yourself, since products and local rules differ.
The lot or batch number, which identifies the exact vial if a reaction ever needs reporting. WSAVA encourages vets to report every possible adverse event to the manufacturer and the regulator.
The clinic and the vet who gave it.

Keep the certificates themselves, not just notes of them, especially for rabies. Kennels and groomers usually want proof of vaccination, and some want it given a set number of days before arrival; the post on what belongs in a pet’s medical record covers who asks for what.

Where Pawza fits

Pawza is a pet health record app for iPhone and iPad. It does not contain a vaccination schedule and does not decide what your pet needs; the dates come from your vet’s paperwork, so it works with any vet’s protocol and any country’s rabies rules. It keeps those dates and tells you when one comes up.

Scanning a certificate. Pawza reads the page on the device. The review screen lists each vaccine with its name, the date administered, the next due date and an optional lot number, and nothing is saved until you have checked them. With Pawza Pro on an iPhone or iPad with Apple Intelligence (iOS 26 or later) the fields fill in automatically; otherwise you fill them in from the recognised text.
A reminder for the printed due date. If the certificate gives a next due date, Pawza offers to add a vaccination reminder for that day.
Adding one by hand. Logging a vaccination record by hand offers the same reminder, set one year from the date given.

Given the schedules above, note that both of those reminders repeat yearly by default. That is right for leptospirosis or kennel cough. It is wrong for a puppy or kitten series 2 to 4 weeks apart and for a 3-year booster. Open the reminder, set the date your vet gave you, and change Repeats to Never; add one reminder per dose for a series. A reminder fires on the date you set, so if a kennel wants boosters given some days before arrival, set it earlier. You can mark a reminder time-sensitive so it breaks through Focus, and the list sorts everything into overdue, today, this week and later.

With Pro, the vet-visit PDF lists every vaccination with its last date and next due date, on pages you can hand to a new clinic or a boarding kennel. The free version covers one pet. There is no Pawza account and no Pawza server: records stay on your device, with optional sync through your own iCloud. The reasons are in why vet paperwork should stay on your phone.

Your vet sets the schedule. If you keep the dates from the certificates, you can answer “when was the last one?” without a phone call.

RPE and RIR explained: the 1-10 effort scale for lifting and how to rate a set honestly

2026-08-17T00:00:00+00:00

RPE and RIR describe the same thing: how close a set came to the point where you could not do another good rep.

RIR (reps in reserve) counts what was left. Two reps in reserve means you stopped two short of failure.
RPE (rating of perceived exertion) scores how hard it was on a 1-10 scale, where 10 is nothing left.

In the usual working range, RPE = 10 − RIR. Most of the remaining detail concerns the ends of the scale.

What does each RPE number mean?

This is the resistance-training scale published by Zourdos and colleagues in 2016. When a program today writes RPE 8 next to a set, this is usually the scale it means.

RPE	Description	Reps in reserve
10	Maximum effort	0
9.5	No further reps, but could increase load	0
9	1 rep remaining	1
8.5	1 or 2 reps remaining	1-2
8	2 reps remaining	2
7.5	2 or 3 reps remaining	2-3
7	3 reps remaining	3
5-6	4 to 6 reps remaining	4-6
3-4	Light effort	n/a
1-2	Little to no effort	n/a

The subtraction breaks in two places. RPE 9.5 exists because a heavy single or double can leave you with no more reps but a sense that 2.5 kg more would still have gone up. And everything from RPE 6 down is deliberately vague, because nobody can tell the difference between five and six reps left with any confidence.

Where did the lifting version of RPE come from?

Perceived-exertion scales are decades older than strength training apps, but the generic ones ask how hard the effort felt, which suits a set of squats poorly. Your legs and lungs can feel terrible on a set of 20 that still had reps left in it.

Zourdos and colleagues tied the number to something you can at least try to count. In their study, 29 people (15 experienced squatters and 14 novices) worked up to a one-rep max, then did singles at 60, 75 and 90 percent of it and a set of 8 at 70 percent, rating each with the new scale while bar speed was measured. Ratings and bar speed moved strongly in opposite directions in both groups: as sets got slower, ratings went up. Experienced squatters also rated their true max higher than novices did, a hint that the top of the scale takes practice.

A companion paper by Helms and colleagues in 2016 laid out how to use the scale in training, and a 2017 study of 15 powerlifters found very strong relationships between RPE and percentage of max on the squat, bench and deadlift. Even at a true one-rep max, those lifters averaged 9.6 to 9.7, short of a flat 10.

How accurate are lifters at judging reps in reserve?

On average, within about a rep, with plenty of individual variation. The best summary is Halperin and colleagues’ 2022 meta-analysis in Sports Medicine, which pooled 12 studies with 414 participants:

People underpredicted the reps they had left by about 0.95 reps. In other words, they tended to stop a little further from failure than they thought.
Predictions got more accurate closer to failure. A guess made on the last rep beats one made on the third.
Sets of 12 reps or fewer were judged far more accurately than longer sets.
Later sets were slightly more accurate than early ones.
Training status didn’t seem to matter much. Experience makes you comfortable under a bar without automatically making the counting accurate.

The variation between studies was large, so treat “about one rep” as a rough figure. In practice, RPE 7 is a fuzzy number and RPE 9 a fairly sharp one.

How do you rate a set honestly?

These are the rules I use, based on what the research above says goes wrong.

Rate the last rep, straight after the set. Rating the whole set, or rating after the rest period when the memory has softened, skews the number.
Ask the RIR question, then convert. With the same technique, how many more could I have done? Answer that, subtract from 10, and you have the RPE.
Count only good reps. A rep that would have needed a different bar path or a bounce is not in reserve.
Use half points only from about 7.5 up. Lower down the scale you can’t actually tell the difference.
Calibrate now and then. On a safe exercise, such as a machine or a lift set up with safety arms, predict your reps in reserve on the last set, then keep going to failure and compare. Do it on a few lifts and you learn which direction your own error runs.
Expect the same load to rate differently on different days. A short night is the classic cause, and it is the reason the original GymLogger X post told lifters to hold their weights the week the clocks change. A higher RPE on a bad day is useful information about recovery.

Also, don’t rate warm-ups. A warm-up rated RPE 4 tells you nothing you need.

What is autoregulation, and does it work?

Autoregulation means letting the day’s rating set the load in place of a fixed number. A typical version: work up to a top set of 3 at RPE 8, then take a planned amount off that weight for the back-off sets. On a good day the RPE 8 triple is heavier than last week; on a bad one it is lighter, and the plan still holds.

The best controlled comparison I know is Helms and colleagues’ 2018 study. Twenty-one trained men ran the same eight-week, three-days-a-week squat and bench program. One group set loads from percentages of a pre-tested max; the other chose loads to land in target RPE ranges. Both gained strength and muscle thickness. The difference between groups wasn’t statistically significant, and the authors’ probability analysis gave the RPE group a likely small strength advantage. It is one study with 21 people, so the fair summary is that both methods work and RPE loading is at least as good.

The decision rules that sit on top of RPE (when to add load, when a falling top set means you need a lighter week) are in the progression-model table of the program-choosing post. And the same idea runs through estimating your one-rep max: an estimate from a set at RPE 7 reads low, because the formula assumes you went close to failure.

Should you log RPE or RIR?

They carry the same information, so pick the one you will actually record. RIR is easier to start with because it is a count. RPE is handy once you lift heavy singles and doubles, where 9.5 says something RIR can’t. If a program is written in one and you think in the other, convert with 10 − x and move on.

Consistency matters more than the choice. A rating you give every hard set, the same way, builds a record of what a given RPE costs you in kilos. A rating you remember once a fortnight records little more than your mood.

How GymLogger X uses reps in reserve

In GymLogger X, RIR is part of the prescription. When the Smart Program Creator builds a program, each exercise gets sets, a rep range and a reps-in-reserve target, and the program preview shows it alongside them, for example 3 × 8-12 at RIR 2. The targets follow a few fixed rules:

The starting point depends on the goal. Compound lifts in a hypertrophy program start at 8-12 reps with 2 in reserve; a strength program starts them at 3-6 reps with 1 in reserve; general fitness at 10-15 reps with 3.
Lifters aged 40 and over get one extra rep in reserve, and 55 and over get two.
If you tell it about an injury, movements that load that area get two or four extra reps in reserve, depending on the phase you are in.
In a linear cycle, the target tightens by up to two reps across the weeks before the deload.
Deload weeks cut the sets roughly in half and raise the reps-in-reserve target, by three in most program styles.

If you import a program from a spreadsheet, the importer reads an RIR column, or an RPE column converted as 10 − RPE.

What GymLogger X doesn’t do is ask you to rate each set. A logged set is the weight and the reps, entered on the iPhone or from the Apple Watch, and the strength trend, estimated maxes and plateau rule are all built from those two numbers. I would rather the app worked from what the bar did than from a rating that research says drifts by a rep. Still, if you want a per-set RPE column in your log, that is a real gap, and you should know about it before you choose.

The bill-splitting math nobody agrees on: tax, tip, shared plates, and the leftover cent

2026-08-13T00:00:00+00:00

Nobody at the table is confused about arithmetic. Four adults can divide $154.65 by four in their heads, near enough.

The argument that follows is about something else. There are roughly six defensible rules for splitting a restaurant bill, they disagree with each other by twenty dollars a head, and no group has ever sat down and picked one in advance. So the rule gets chosen at the moment of maximum social pressure, by whoever speaks first, and the person it disadvantages says nothing.

The rules are below, with the arithmetic worked all the way out. Why the fair rule is hard to propose comes after the numbers, which are the easy half.

What are you actually splitting?

A restaurant bill is four or five separate things stacked on top of each other. Each layer has its own defensible rule, and most bill arguments come from applying one layer’s rule to a different layer.

Layer	What it is	The defensible rule	The common mistake
Line items	What each person ordered	To the person who ordered it	Averaging the whole subtotal across heads
Shared plates	Appetisers, sides, a bottle for the table	Split among the people who actually had it	Charging the whole table by headcount
Sales tax (US)	Added on top of the printed prices	Proportional to each person’s subtotal	Splitting it by headcount, which overcharges the small order twice
VAT (EU/UK)	Already inside every printed price	Nothing to do; it rides along with the item	Adding it again on top of the line totals
Tip	Discretionary; US checks often print suggestions in the 18-25% band	Proportional to each person’s subtotal	A flat amount per head, which is an even split in disguise
Service charge	Printed on the bill, often 12.5% in the UK	Already inside the total; treat it as part of the printed line	Tipping again on top without noticing

Two notes on that table.

US sales tax is added on top, and the rate is local. New York City’s combined state and local rate is 8.875% (4% state, 4.5% city, and a 0.375% Metropolitan Commuter Transportation District surcharge), which you can check in the New York State Department of Taxation and Finance’s Publication 718 rate tables. In the EU and UK, VAT is already baked into every printed price, so there is no tax layer to distribute at all. That single structural difference is why American and European bill-splitting arguments sound nothing alike: in Europe the line item is the whole truth, and in the US it is roughly three-quarters of what you will actually pay once tax and tip land on top.

Whether the tip goes on the pre-tax subtotal or the post-tax total is a matter of convention. The traditional answer is pre-tax, because the tax is not the restaurant’s money. The suggested-tip lines printed at the bottom of many US checks are computed on the post-tax total. On the bill below, that is the difference between $24.00 and $26.13. Neither is wrong, as long as you say which one you used. How large the tip should be in the first place depends on the setting, and the US tipping guide has the ranges, situation by situation.

The UK has a related wrinkle worth knowing: since the Employment (Allocation of Tips) Act 2023 came into force in October 2024, employers must pass on 100% of qualifying tips and service charges to staff. It does not change your arithmetic. It does mean the discretionary service line is now more likely to reach the people who served you than it once was.

Example 1: what proportional tax and tip actually costs the steak

Four people. One ribeye at $58, one salad at $14, and two orders in between. Subtotal $120.00. Tax at 8.875% is $10.65. Tip at 20% of the pre-tax subtotal is $24.00. The bill is $154.65.

Each person’s tax share is (their items divided by $120) times $10.65. Their tip share is the same fraction of $24.00. So Alex’s order, which is 11.67% of the food, carries 11.67% of the tax and 11.67% of the tip.

Person	Ordered	Items	Tax share	Tip share	Pays, by item	Even split	Difference
Dana	Ribeye	$58.00	$5.15	$11.60	$74.75	$38.66	+$36.09
Ben	Pasta, beer	$28.00	$2.49	$5.60	$36.09	$38.66	-$2.57
Cara	Burger	$20.00	$1.78	$4.00	$25.78	$38.66	-$12.88
Alex	Salad	$14.00	$1.24	$2.80	$18.04	$38.66	-$20.62
		$120.00	$10.65	$24.00	$154.66	$154.64

Look at the last column. An even split charges Alex $20.62 more than the salad actually cost, on one dinner at a table of four. Over twenty-six dinners a year with the same group and the same ordering habits, that is $536 moving from the salad to the ribeye.

Notice what the tip column does. Under an even split, Alex pays $6.00 of the tip on $14 of food. Under proportional distribution, Alex pays $2.80. The tip is where even-splitting does the damage nobody notices, because it is the layer people are least likely to check.

Now look at the two totals. The by-item column sums to $154.66. The even column sums to $154.64. The receipt says $154.65. Neither is a mistake and neither can be fixed by being more careful, which is Example 3.

Who pays for the shared appetiser, and who pays for the bottle?

Same table, different night. Four mains, one charcuterie board at $24 in the middle of the table, one bottle of wine at $48. Sam is driving and drank water.

Person	Main	Board (÷4)	Bottle ÷4	Bottle ÷3	By headcount	By consumption
Nora	$26	$6	$12	$16	$44	$48
Ivan	$32	$6	$12	$16	$50	$54
Priya	$22	$6	$12	$16	$40	$44
Sam (no wine)	$20	$6	$12	$0	$38	$26
Totals	$100	$24	$48	$48	$172	$172

Both columns collect exactly $172. The difference is entirely in where the $48 bottle lands: by headcount Sam pays $12 for wine he did not drink, and by consumption the three drinkers pay $16 each instead.

Add a 20% tip and the gap widens, because tip rides on the subtotal. Sam’s total goes from $45.60 by headcount to $31.20 by consumption, a $14.40 swing on one bottle he never touched. The drinkers each move $4.80 the other way.

The harder case is the one people actually argue about: Sam had one glass out of six. Splitting a bottle by pours is arithmetically trivial and socially unworkable, because somebody would have had to count. The rule that survives contact with a real table is binary: you were in on the bottle or you weren’t. If Sam took a glass, he is in for a full share. That imprecision is the price of not auditing a wine bottle, and it is worth paying.

So the board and the bottle follow different rules, and tables go wrong when they treat them as one. The test is visibility: did anyone watch you opt out? Sam refusing wine happened in front of everyone, so the bottle is not his. Nobody could have seen who took two olives and who took five, so the board goes across the head count.

What do you do with the leftover cent?

A bar tab. Six people, everything genuinely shared, $101.00. Divided six ways that is $16.8333…, and there is no way to pay a third of a cent. Maya put down her card.

Three rules, all defensible:

Person	Exact share	A: payer takes the remainder	B: rotate the remainder	C: everyone rounds up
Maya (paid)	$16.8333	$16.85	$16.83	$16.80 effective
Ivan	$16.8333	$16.83	$16.85	$16.84
Nora	$16.8333	$16.83	$16.83	$16.84
Priya	$16.8333	$16.83	$16.83	$16.84
Sam	$16.8333	$16.83	$16.83	$16.84
Tomas	$16.8333	$16.83	$16.83	$16.84
Collected	$101.00	$101.00	$101.00	$101.00

A: the payer takes the remainder. Six times $16.83 is $100.98, so two cents are orphaned. Put them on the card-holder’s own line: five people send $16.83, Maya’s share becomes $16.85. It costs the payer two cents, everyone can see it, and it is over in one step. This is the right default for a bill you will never think about again.

B: rotate it. Identical arithmetic with a different name on the odd line. Tonight Ivan takes the two cents, next time someone else does. This only means anything in a group that eats together often enough for “next time” to be real. Otherwise it is ceremony, and it costs a conversation to administer.

C: everyone rounds up and the payer keeps the surplus. The five others send $16.84 each, Maya collects $84.20, and her own cost lands at $16.80, three cents under her exact share. At the cent level that is invisible. At the dollar level it is not: if everyone sends a flat $17.00, Maya collects $85.00 and pays $16.00, an 83-cent discount for holding the card and then chasing five transfers.

The one rule to avoid is rounding everyone down, because the payer absorbs the gap without anybody deciding that they should. Two cents does not matter; the habit does, because it scales with the unit. A $487.35 bill split eleven ways is $44.30 a head, and a table that rounds down to a flat $44 collects $484 and leaves the payer $3.35 short, every time, without anyone noticing.

Which splitting rule fits which table?

The right rule depends on the social situation. This is how I would map them, with the way each one fails:

Situation	Rule that works	Failure mode
Colleagues, weekday lunch	By item, no rounding games	An even split taxes whoever ordered least, and that is very often the most junior person at the table
Close friends, similar orders	Even split, rotate the odd cents	Fine until one person’s order is consistently double everyone else’s, at which point it becomes a subscription nobody signed up for
A date	One person pays, or a flat 50/50	Itemising reads as an audit, and there is no arithmetic that stops it reading that way
Group trip, many days	A running ledger, settled once at the end	Settling every single meal produces forty micro-transfers and one exhausted treasurer
Family dinner	One payer, rotated across occasions	Nobody tracks the rotation, so the same person pays for four years and then mentions it once, badly
Big table, wildly different orders	Itemise, but privately, and present the result	Itemising out loud takes ten minutes and somebody will leave before it finishes

How do you split a bill in a foreign currency?

Use the rate your card actually charged. The problem is that you cannot know that number at the table, and possibly not for two days. Card networks convert at their own daily rate (Visa publishes an exchange rate calculator and Mastercard a currency converter), applied on the settlement date, not the day you ate, and your issuer may add a foreign-transaction fee on top, commonly in the 0-3% range depending on the card. So the rate printed nowhere on the receipt, the rate in your phone’s currency app, and the rate that eventually lands on your statement are three different numbers.

So fix one rate for the whole trip, in advance, and tell everyone which one. “We’re using 1.08 for the week” is checkable and applies to everyone equally. A rate that changes per meal is no more accurate, it is harder to audit, and it invites the suspicion that whoever picked it picked favourably. Whoever fronted the card can reconcile against their statement afterwards if the drift turns out to be material, which for a week of dinners it almost never is.

Why the arithmetic was never the hard part

Everything above is a solved problem. A calculator handles it, and a spreadsheet handles it better.

Bills still get split badly because proposing the fair rule costs something. Saying “let’s split by item” at a table of six means saying out loud that you noticed what other people ordered and priced it. It is arithmetically neutral and socially loaded, and most people will hand over $20 they do not owe rather than be the one who brought a calculator to dinner. I wrote about the same dynamic from the other side in how to split a Valentine’s dinner without making it weird: the $20 nobody mentions, compounding across a year of dinners into an unfairness that nobody can point at afterwards.

The design answer is to move the itemising off the table: do it privately, on one phone, in under a minute, and hand each person a finished number. People do not mind receiving a total. What they mind is watching one get built about them.

RightSplit is built around that. Scan the receipt with Apple’s on-device Vision framework, tap each line onto whoever ordered it, split the shared plates among the people who shared them, apply a proportional tip, and send everyone their own line over iMessage or WhatsApp. Only the person holding the phone needs it installed. It is iPhone-only. Equal splitting, the tip calculator and your first receipt scan are free; item-level assignment, the subject of this whole post, is Pro+, at $3.99 a year or $7.99 once. The OCR is exactly as good as Apple’s: clean thermal receipts read reliably, faded or badly-creased ones will occasionally mis-read a line, and you fix that by tapping the line and correcting it before you split. Nothing is uploaded, which is the rule every app I ship runs on and which the transparency page states per app.

Where it mostly stops is at one table on one night. Pro+ adds Spaces (a trip, a shared flat) that collect receipts and expenses on your phone and produce a who-pays-whom settle-up plan, but there are no accounts and no sync. If what you have is four flatmates, a shared electricity bill, and eight months of who-owes-whom that everyone wants to log and check from their own phone, Splitwise is the right tool, since a shared running balance is its whole reason for existing. Tricount is that same answer shaped for trips, and Settle Up for groups who want the ledger without the social layer. Tab does item-level splitting for free, which is precisely the feature RightSplit puts behind Pro+. And if you want the split and the payment in one place, Venmo’s split feature does that; RightSplit deliberately does not, because producing a number and letting everyone pay however they already pay is a smaller promise that survives people switching payment apps.

RightSplit splits in the receipt’s currency. With Pro+ it shows each total’s approximate value in your home currency and can settle a mixed-currency Space in one currency, using the European Central Bank’s daily rates; without Pro+, on a trip you are doing the conversion yourself, once, on the totals, which is what the fixed-rate advice above amounts to anyway. If the thing you are actually trying to fix is your own recurring spending rather than a table’s dinner, the bill tracker without a bank connection guide is a closer fit than any of this.

TL;DR

Assign items first, then hand out tax and tip in proportion to each person’s subtotal. On a $120 subtotal, the $58 ribeye carries $11.60 of a 20% tip and the $14 salad carries $2.80, where an even split would charge each of them $6.00.
An even split is not neutral. At a table of four with a $58 order and a $14 order, it moves $20.62 from the light eater to the heavy one in a single dinner.
Shared plates go to the people who shared them. One person abstaining from a $48 bottle is a $14.40 swing once tip is included, and the workable test is whether the table saw them opt out.
The leftover cents need a rule, and three are defensible. The payer takes the remainder, rotate it, or everyone rounds up and the payer keeps the surplus. Rounding everyone down is the only version that under-collects silently.
In a foreign currency, fix one rate for the whole trip and say which one. The real rate is set at settlement, plus roughly 0-3% in issuer fees, and you cannot know it at the table.
The math was never the bottleneck. Itemising in front of people reads as an audit; do it privately and present a result.

Any of these rules works, as long as the table picks it before the bill arrives.

PPL, Upper/Lower, 5/3/1: choosing a strength program you will still be running in twelve weeks

2026-08-06T00:00:00+00:00

Most program arguments are about the wrong variable.

Ask whether PPL beats Upper/Lower and you get a hundred confident answers about frequency, volume distribution and recovery. All of it is real, and almost none of it decides anything. Run two competently written programs, same person, same twelve weeks, and you would struggle to see the difference in your own logbook.

The outcome depends on whether you are still running the thing in week ten: the Tuesday you leave the office at 19:40, the fortnight in March when everyone in the house is ill. So the comparison below is built around days per week, session length, and the specific way each program breaks.

Which strength program should you run?

Program	Days/week	Realistic session	Progression model	Frequency per muscle	Suits	Characteristic failure mode
Full body 3×	3	50 to 70 min	Linear, then double progression	~3×	Beginners, unpredictable weeks, returning lifters	Sessions creep longer as the squat gets heavy. Near-maximal squatting three times a week stops being recoverable, and people quit instead of cutting back.
Upper/Lower 4×	4	55 to 75 min	Double progression, or percentage blocks	2×	Intermediates with four genuinely reliable slots	The fourth day gets dropped, and without anyone deciding it the split becomes a lopsided three-day plan where legs are trained once.
PPL 6×	6	45 to 75 min	Double progression, usually per exercise	2×	People who want six gym days and have a short commute	Miss two sessions and a fixed weekly rotation desynchronises. The make-up logic collapses within a fortnight.
Starting Strength / novice LP	3	45 to 75 min, growing	Linear: add load every session	3×	Untrained or detrained lifters, roughly the first 3 to 9 months of barbell work	The linear phase ends and nobody notices. Lifters reset the same 10% three or four times when they should change model.
5/3/1	3 to 4	40 to 60 min plus assistance	Percentage-based off a Training Max, 4-week cycle	1× per main lift, ~2× per muscle with assistance	Intermediates who want a long plan and few weekly decisions	It feels light in month one, so the Training Max gets inflated. The AMRAP set becomes a grinder and stops adding reps.

Weekly frequency per muscle doesn’t separate these programs much. Full body and PPL sit at three and two, and once weekly volume is held equal, the frequency research shows nothing dramatic in either direction. Greg Nuckols’ review of the frequency literature at Stronger By Science is the most careful public summary I know of. Twice per muscle per week is a fine default and nothing more binding than that.

The failure modes are specific. PPL fails because six fixed slots give a week six places to break; the volume is fine. Novice linear progression fails because it is designed to end, and almost nobody has a plan for what comes after.

What does each progression model actually tell you to do?

The split is the easy half. The progression model decides what you do on a Tuesday when the bar feels heavy, and it is where most self-written programs go vague.

Model	What you add	When you add it	On a failed session	Deload rule
Linear	Load	Every session: typically 2.5 kg / 5 lb upper body, 5 kg / 10 lb lower body early on	Repeat the same weight next session. After two or three consecutive failures, reset ~10% and build back	The reset is the deload. The classic novice template has no scheduled deload weeks
Double progression	Reps first, then load	Add load only when every set hits the top of the bracket. In 3 × 8 to 12: stay at the weight until all three sets reach 12, then add the smallest increment and drop back to 8	Nothing special. Repeat the load and try for one more rep. A failed increase is a normal week	Cut load ~10% or drop a set for a week when two or three lifts stall at the same time
Percentage / Training Max (5/3/1)	A fixed increment to the Training Max (your 1RM is left alone)	Once per completed cycle: +2.5 kg / 5 lb upper, +5 kg / 10 lb lower	If the AMRAP set falls below the prescribed minimum reps, hold the Training Max or cut it ~10% next cycle	Built in. Week four is the deload at 40/50/60% of the Training Max
Autoregulated / RPE	Load, chosen to hit a target RPE or reps-in-reserve	Every set. A top set at RPE 8, back-offs a set percentage below it	No session counts as failed, only lighter. The load that hits RPE 8 today is the prescription	Deload when the load at a given RPE drops for two or more sessions, or on a fixed 4 to 6 week cadence

Here is a worked example, because double progression is the one people describe correctly and then run incorrectly. Dumbbell rows, 3 sets of 8 to 12, at 30 kg. Session one: 12, 10, 9. No increase, because two sets missed the top. Session two: 12, 12, 10. Still no. Session three: 12, 12, 12. Now you take the smallest increment your gym has, go to 32 kg, and expect roughly 9, 8, 8. You haven’t gone backwards; the bracket resets and you climb it again, which may take five weeks. The other versions of the add-weight rule, and the plate arithmetic for lifts where 2.5 kg is too big a jump, are in double progression explained.

What is 5/3/1, exactly?

5/3/1 comes from Jim Wendler. Its central idea is the Training Max: you programme off 85-90% of your tested one-rep max (the original template uses 90%) so the percentages stay honest on a bad week. Every percentage below is of the Training Max, not your actual max.

Week	Set 1	Set 2	Top set
1	65% × 5	75% × 5	85% × 5+
2	70% × 3	80% × 3	90% × 3+
3	75% × 5	85% × 3	95% × 1+
4 (deload)	40% × 5	50% × 5	60% × 5

The “+” is where the progress shows. You take that last set for as many quality reps as you have, and its rep count is your progress signal, while the fixed sets stay at the same percentages forever. Finish the cycle, add 2.5 kg to the upper-body Training Maxes and 5 kg to the lower-body ones, and run it again. That is roughly a year of programming decided in one sitting, which is the appeal.

The failure mode is self-inflicted. Month one feels easy, so people set the Training Max at their real max, or add 5 kg a cycle to everything. Six cycles later the top set is one grinding rep. Wendler’s own advice is worth taking: start lighter than you think.

How many days a week should you lift?

The floor is well established. The US Physical Activity Guidelines for Americans recommend muscle-strengthening activity on two or more days a week for adults, covering all major muscle groups. That is a health floor, and building strength usually takes more.

For building strength, most sustainable programs sit at three to five days. Work out your number from the past, though. Open whatever record you have of the last eight weeks and count the sessions. If it is 19, you train two and a bit days a week, and a six-day PPL is a wish. Add a day only after the existing days have been boring and reliable for a month.

The most common mistake I see is people picking a program for the version of themselves that exists in January.

When does a novice linear progression end?

Novice linear progression (Mark Rippetoe’s Starting Strength is the best-known version) works because an untrained lifter recovers between sessions in a couple of days and adapts fast enough to add load every session. That window is real, and it closes, usually somewhere between three and nine months of consistent barbell work depending on age, food and sleep.

The published stall rule is to repeat the weight, then after two or three consecutive failed sessions reset roughly 10% and build back. The rule doesn’t tell you how many times to do that.

The heuristic I use: two resets on the same lift with no new personal record between them means the linear phase is over for that lift. That applies to the lift, not to you or your other lifts. The press stalls long before the deadlift, so the press moves to double progression while the squat keeps running linear. A lifter can be a novice on one bar and an intermediate on another for months. Treating “am I a beginner?” as one global fact is what keeps people resetting the same 10% four times.

How to choose, in four questions

How many days did you actually train in the last eight weeks? Count them and divide by eight. That is your days per week, whatever you intended and whatever your best month looked like. Three means full body. Four means Upper/Lower. Six means PPL, if and only if six is a number you have hit before.
How long is a session on your worst weekday? Under 50 minutes, two things fit: full body three times a week, or 5/3/1 with trimmed assistance. A 75-minute PPL leg day does not shrink to 45 minutes; it gets skipped. Most of any session is rest, and how long you rest between sets is the first thing to trim, starting with the isolation work and leaving the heavy lifts alone.
What is your training age in this specific lift? Under six months of consistent barbell work: linear. Six months to two years: double progression. Beyond that: percentage cycles or autoregulation, and expect to measure progress per quarter.
What has hurt, and what made it hurt? If flat barbell benching aggravates a shoulder, no split solves that. Pick a structure organised by movement pattern, so you can swap the movement without deleting a day. A fixed list of named exercises makes that harder.

This is training information, not medical advice. If you are working around an injury or a condition that affects loading, have a clinician or a coach watch you lift.

Why the log is the part that decides it

Everything above assumes you know what you did last time, and that assumption carries more weight than any of the programming.

Linear progression is the only model in that second table you can run from memory, because the rule is last time plus 2.5 kg. Every other one is a rule applied to a record. Double progression needs three set counts from last session. A 5/3/1 cycle needs a Training Max and every AMRAP rep count going back months. Autoregulation needs a history of what a given RPE cost you in kilos, or the number is a feeling with a decimal point attached. That is the unglamorous reason logging apps exist, and the two I build take different sides of it.

LiftLog is the iPhone one. It ships 40 programs, among them StrongLifts 5×5, Starting Strength, PPL, Upper/Lower, full-body splits, and 5/3/1, and each exercise carries one of the progression models above: linear, double progression, percent of a Training Max, or RPE. In the 5/3/1 programs the main lifts run the four-week wave from a separate Training Max field, and beating the prescribed reps on the AMRAP top set raises the Training Max. The deload is per lift: three missed sessions in a row and that exercise’s weight drops to 90%, both numbers editable. It does not plan undulating or block periodization for you. RPE is optional; you can add it to any logged set, and no set requires it. The constraints: iPhone only, no Apple Watch app, and pricing is a seven-day trial with no card followed by a one-time pay-what-you-can purchase between $9.99 and $39.99. The reasoning behind that model has its own post.

GymLogger X is the sibling with an Apple Watch app. Core logging is free, and Pro is $1.99/month, $17.99/year, or $39.99 lifetime. It exists because I wanted to log a set from the wrist without carrying a phone to the rack, which is the entire argument for it. Its plateau rule, a Pro feature, is published in plain English: an exercise is flagged when its estimated 1RM stops clearing a threshold set by your own 90-day rate of gain on that lift, across four sessions in which your volume held steady (fell by no more than 3%).

Neither is right for everyone, and several competitors solve problems mine do not.

If your programs die because choosing one is the friction, Fitbod is the better tool. It generates each session for you: you open it and it tells you what to do today, adjusted for yesterday. A manual logger can’t replace that with better templates. The trade-off is subscription-only pricing and reasoning you can’t inspect.

If accountability is what breaks, Hevy has the most generous free tier in the category and a social feed that, for some people, is what gets them to the gym on a Thursday. I do not build social features and never will, so for those people I am the wrong studio. Strong is the best-established logger here, with full standalone Apple Watch support, and Caliber pairs you with a human coach, the only option listed that can change your program when your week changes.

For the category sorted by pricing model, see the guide to workout apps without a subscription; what my apps collect is on the transparency page.

TL;DR

Adherence beats programming. Between two competent programs run for twelve weeks the difference is small; between finishing and quitting in week five it is enormous.
Count your days per week; don’t choose them. Count the sessions you did over the last eight weeks and divide by eight. Three: full body. Four: Upper/Lower. Six: PPL, only if you have hit six before.
Each split has one characteristic failure. PPL desynchronises after two missed sessions. Upper/Lower loses its fourth day. Full body’s sessions grow until heavy squatting three times a week stops being recoverable. Novice linear progression ends and nobody notices.
Match the progression model to training age, per lift. Linear under six months, double progression to roughly two years, then 5/3/1-style percentage cycles or RPE autoregulation.
Double progression in one line: stay at the weight until every set hits the top of the bracket, then add the smallest increment and drop back to the bottom.
Only linear progression runs from memory. Every other model is a rule applied to a written record, so the log decides whether you finish the twelve weeks more than the template does.

How to create an App Store Connect API key: team or individual, the right role, and a .p8 you only get once

2026-08-01T00:00:00+00:00

An App Store Connect API key is a key pair. Apple keeps the public half; you download the private half as a .p8 file and use it to sign the short-lived tokens that every API request carries. A tool will ask you for four things, listed below with where each one lives.

What does a tool need from you?

Item	What it is	Where to find it
Issuer ID	A UUID that identifies your team, the same for every team key	Top of Users and Access > Integrations > App Store Connect API, with a Copy button
Key ID	A short ID for one key, such as `2X9R4HXF34`	Next to each key in the Active list; hover to Copy Key ID
Private key (.p8)	The private half of the key pair, a small text file	Download API Key link, available a single time
Role	What the key is allowed to do	Chosen under Access when you generate the key, fixed after that

The .p8 file is a PEM text file that begins with -----BEGIN PRIVATE KEY-----. If a tool complains that your key is the wrong format and the file says BEGIN EC PRIVATE KEY, you probably have a key made with OpenSSL, not one downloaded from App Store Connect.

Team key or individual key?

Apple offers two kinds, and picking the wrong one causes more trouble than any of the setup steps.

	Team key	Individual key
Who can create it	Account Holder or Admin	Most users, from their own profile (Account Holder, Admin, App Manager, Customer Support, Developer or Marketing), unless an Admin removed that permission
Access	All apps in the account, with the role you pick; app access can’t be limited	The apps and roles of the user who made it
Can’t use	Only what its role rules out	Provisioning endpoints, Sales and Finance, notaryTool
How many	Several; Apple lets you generate multiple	One active key per user
In the token	`iss` set to the Issuer ID	`sub` set to `user`, no `iss`

Sources: Apple’s Creating API Keys for App Store Connect API and the App Store Connect API help page.

Use a team key for anything that works for the whole account: CI, a metadata tool, a sales dashboard. Use an individual key when a script should only ever see what one person sees. Since individual keys can’t read Sales and Finance, they’re no use for revenue tools at all.

How do you create a team key, step by step?

Request access, once. The Account Holder goes to Users and Access > Integrations, clicks Request Access, agrees to the terms and submits. Apple says requests are reviewed case by case.
Open Team Keys. In Users and Access > Integrations, with App Store Connect API selected in the left column, choose the Team Keys tab.
Generate. Click Generate API Key, or the + button if you already have an active key.
Name it. The name is only for you. Name it after the tool or the machine that will use it, so you know what breaks when you revoke it later.
Pick the role. Under Access, choose the role. Apple says you can’t edit a key’s name or access level afterwards; to change either, you revoke the key and make a new one.
Click Generate, then Download API Key next to the new key. Save the .p8 before you leave the page.
Copy the Issuer ID and Key ID into the tool, along with the file.

An individual key is shorter: click your name at the top right, Edit Profile, then Generate Key under Individual API Key, and Download.

Which role should the key have?

The roles for keys are the same ones you give people on your team. The rows below are from Apple’s role permissions table, narrowed to what API tools usually do:

Role	Edit App Store details	Create versions, submit apps	Reply to reviews	Sales and Trends reports
Admin	Yes	Yes	Yes	Yes
App Manager	Yes	Yes	No	No
Marketing	Yes	Create versions only	No	No
Customer Support	Yes	No	Yes	No
Developer	No	No	No	No
Sales	No	No	No	Yes
Finance	No	No	No	Yes

Pick the smallest role that covers the job. A screenshot or metadata tool fits App Manager. A revenue dashboard fits Sales or Finance. A tool that edits metadata, replies to reviews and reads sales needs Admin, and Apple’s docs single that role out: an Admin key can create and delete users. Keep that file somewhere better than your Downloads folder.

Where should the .p8 file live?

Apple’s guidance is short. Treat the private key like a password; don’t share it, store it in a code repository or ship it in client-side code; and revoke it at once if it’s lost or exposed. Apple keeps no copy, so the file you downloaded is the only one.

In practice that means a password manager, the macOS Keychain, or your CI provider’s secret store, and then deleting the stray copy in Downloads. One key per tool helps too. Apple lets you generate multiple team keys, and if each tool has its own, revoking one doesn’t take the others down with it.

How do you revoke a key?

Revoking is immediate and permanent. Apple’s Revoking API Keys page says a revoked key can’t be reinstated; revoked keys stay listed for 30 days under Revoked.

For a team key, an Account Holder or Admin opens Users and Access > Integrations > App Store Connect API, chooses Team Keys, clicks Edit, selects the key, clicks Revoke Key and confirms.
For someone else’s individual key, it’s the same place under the Individual Keys tab, again as an Account Holder or Admin.
For your own individual key, open Edit Profile, find Individual API Key and click Revoke.

Revoke a key when a laptop holding the file is lost, when someone who had a copy leaves, and when you retire the tool that used it.

What is a JWT, in one paragraph?

The API never sees your .p8 file. Each request carries a JSON Web Token (RFC 7519) that the tool builds and signs on your machine: a header saying it’s signed with ES256 and naming your Key ID (kid), and a payload with your Issuer ID (iss), the time it was issued (iat), its expiry (exp) and the audience appstoreconnect-v1, optionally narrowed with a scope list of allowed requests. Apple checks the signature against the public half it kept, so a valid signature proves the request came from whoever holds the private key. Tokens with a lifetime over 20 minutes are rejected for most requests, and Apple suggests reusing one token across requests until it expires (Generating Tokens for API Requests).

Header:  { "alg": "ES256", "kid": "2X9R4HXF34", "typ": "JWT" }
Payload: { "iss": "57246542-96fe-1a63-e053-0824d011072a",
           "iat": 1528407600, "exp": 1528408800,
           "aud": "appstoreconnect-v1" }

Those are Apple’s own example values: an exp 1,200 seconds after iat is exactly the 20-minute ceiling.

What do the common errors mean?

A token App Store Connect won’t accept usually comes back as 401 with the code NOT_AUTHORIZED. The usual causes are an Issuer ID and Key ID that don’t belong together, a token signed with a different key than the one its kid names, a lifetime over 20 minutes, or a computer clock that’s off. Apple’s status code table lists 403 Forbidden for a revoked key, a badly formatted token, or an operation the key isn’t allowed to do. If the token works for some requests and not others, it’s the role. 429 means you’ve hit the rate limit for that key.

How AppMeta uses your key

AppMeta, the Mac client for App Store Connect I wrote about in February, takes a team key: it asks for the Issuer ID, the Key ID and the .p8 file, so individual keys, which have no Issuer ID, don’t fit it. Before it saves anything it signs a token and asks App Store Connect for your app list, so a mismatched ID or a revoked key shows up as an error on the setup screen, before you’ve saved anything.

The three values go into the macOS Keychain as items that stay on that Mac and don’t sync through iCloud. AppMeta signs 20-minute ES256 tokens locally and reuses each one until it’s about two minutes from expiring, and the only server it sends them to is api.appstoreconnect.apple.com. Removing the account in AppMeta deletes the Keychain items.

For the role: App Manager covers editing metadata in every localization, the keyword field included, plus creating and submitting versions. Replying to reviews and the sales views need a role that allows them, and for a single key that means Admin. If you’d rather keep revenue on a separate key, the AppMeta Pulse API access page lists the endpoints Pulse calls and the role it asks for.

What an iPhone app can actually block, and what it structurally cannot

2026-07-29T00:00:00+00:00

Ask most people how an app blocker works on iPhone and you get some version of this: the blocker sits in the background, watches what you open, and slams a door when it spots Instagram.

None of that is possible. A third-party iOS app cannot see which apps you launch, cannot run continuously in the background to watch for one, and cannot draw a single pixel over another app. Every blocker on the App Store asks iOS to do the blocking on its behalf, through three frameworks Apple shipped in 2021 and has extended in small steps since.

That detail decides what your blocker can do, what it will never do however much you pay, and exactly how you get out, which is the part nobody puts in the App Store screenshots.

What actually blocks an app on an iPhone?

Three frameworks, together called the Screen Time API, introduced in the WWDC21 session Meet the Screen Time API. A fourth, ManagedSettingsUI, only controls how the blocking screen looks.

Framework	Its one job	The types you actually touch	What it cannot do
FamilyControls	Get permission, and let the user choose apps	`AuthorizationCenter`, `FamilyActivityPicker`, `FamilyActivitySelection`	Tell your code which apps were chosen
ManagedSettings	Apply the restriction	`ManagedSettingsStore`, `ShieldSettings` (`.applications`, `.applicationCategories`, `.webDomains`), `ApplicationSettings` (`denyAppRemoval`)	Outlive the authorisation that created it
DeviceActivity	Anything to do with time	`DeviceActivityCenter`, `DeviceActivitySchedule`, `DeviceActivityEvent`, `DeviceActivityMonitor`	Run your code continuously; the extension wakes on events only
ManagedSettingsUI	Style the shield	`ShieldConfigurationDataSource`, `ShieldActionDelegate`	Anything except draw a title, subtitle, icon and up to two buttons

In a real app the sequence is short. Ask for authorisation through AuthorizationCenter.shared, in .individual mode for self-restriction or .child mode for a Family Sharing parent. Present the picker. Put whatever came back into a ManagedSettingsStore as store.shield.applications. Register a schedule with DeviceActivityCenter, and let iOS wake your DeviceActivityMonitor extension at interval boundaries and usage thresholds so it can change the store.

Two practical limits keep the category smaller than it looks. The Family Controls capability adds the com.apple.developer.family-controls entitlement, and distributing it on the App Store requires asking Apple for it. And the DeviceActivityMonitor extension is not a daemon: iOS wakes it, gives it a short slice of time, and suspends it. Anything a blocker claims to do “continuously” happens at moments Apple chooses.

Why the blocker never learns which apps you picked

Of all the design decisions in the API, this one has the biggest consequences.

The app-selection UI is FamilyActivityPicker, and it belongs to Apple, not the developer. It renders out of process, it lists your installed apps, and it returns a FamilyActivitySelection containing sets of tokens: ApplicationToken, ActivityCategoryToken, WebDomainToken. Apple’s documentation for Token describes it as a representation of an app or website “that doesn’t reveal its identity,” and the ApplicationToken page says the point is to restrict and filter apps without access to personal user data.

So a blocker holds an opaque blob, which it hands back to ManagedSettings to raise a shield. It never receives a bundle identifier or a display name, and there is no way to reverse the token. A token also means something only to the app that received it, and it stops working the moment you revoke authorisation in Settings, because revocation invalidates the app’s tokens along with its permission.

For privacy this means a screen-time app physically cannot log that you blocked Grindr, or Robinhood, or your ex’s favourite app. It hasn’t promised not to; it is unable to. That is privacy by construction, and the strongest such guarantee in any category I have shipped into.

For the product it is a real tax, and every developer in this category pays it:

You cannot offer a one-tap “block the usual suspects” onboarding, because you cannot name the suspects.
You cannot tell the user, in your own copy, which apps are currently shielded.
You cannot verify from your own data that a user selected anything at all, so support requests (“it isn’t blocking anything”) turn into guided screenshot sessions.

Apple made that trade, not the developer, and I think it made the right one.

Which approach blocks what?

Five approaches get sold as “app blocking”, and they intercept at completely different layers. Price matters less here than where each one sits in the stack.

Approach	What it blocks	What it cannot block	How it is bypassed	Works offline	Who it actually suits
Built-in Screen Time (Apple’s setup guide)	App and category time limits, Downtime, content ratings, web content; syncs across your devices with Share Across Devices	Nothing beyond Apple’s own categories; no custom unlock condition	Your own passcode, or the Ignore Limit button	Yes	Anyone who has not tried it: it is free, and it covers the Mac and iPad too
Family Controls shield app (Opal, one sec, ScreenZen, Jomo, EarnLock)	Any app or Apple category you select, plus Safari web domains, on this iPhone	Notifications, other devices, and anything after you revoke authorisation	Whatever escape hatch the app ships, then revoking authorisation in Settings	Yes, because state is local and enforced by iOS	People who want an unlock condition other than “wait” or “type your passcode”
DNS or VPN content filter (NetworkExtension)	Domains and traffic patterns, system-wide, including apps you did not select	Anything on cellular when the profile is off, encrypted DNS inside an app, or a service sharing a CDN with something you need	Toggle the VPN off in Settings, roughly three taps	No, it is a network mechanism by definition	Blocking whole classes of content (ads, adult sites), not a named app
Separate device or lockbox (dumbphone, timer safe, Brick’s NFC tag)	Everything on the device you left behind	Every other screen in the building	Physically retrieving the object	Yes	People whose problem is one hour in one place: writing sessions, dinners, sleep
Grayscale and friction (Color Filters, Focus modes, apps off the Home Screen)	Nothing; it only makes the phone duller and slower to reach	Anything, if you actually want it	Three taps in Settings, or Spotlight	Yes	Drift more than compulsion: the person who opens an app for no reason and stays for 40 minutes

Two notes on that table. A DNS filter is the only row that touches apps you did not list, which makes it the right tool for adult-content blocking and the wrong tool for “keep me off X between 9 and 5.” And Apple’s own review rules constrain the VPN row: App Store Review Guideline 5.4 requires VPN apps to use NEVPNManager and to come from a developer enrolled as an organisation, and the content-filter entitlement is granted case by case, which is why so few of these exist.

Can an app block Instagram on iPhone?

Yes, with three caveats that matter more than the yes.

The app, properly. Select Instagram in the picker, put the token in store.shield.applications, and tapping the icon shows a shield instead of launching the app. The app does not open in the background, does not refresh, does not get its five seconds.

The website, mostly. ShieldSettings.webDomains covers Safari. Selecting web content in the picker is what makes instagram.com in Safari behave the same way as the app. Coverage inside third-party browsers and in-app web views is less predictable, and I would not build a plan around it.

Not the notifications. A shield stops a launch. It does not stop delivery. If a badge and a banner are what pull you in, the shield fixes the wrong half of the loop, and a Focus mode is the better tool, or the two together.

Not your other screens. The store is local to the device. Your iPad, your Mac, and the work laptop are all untouched. Family Controls does not ship on macOS in a form that supports this mechanic, so any shield app that does cover the Mac uses a different mechanism there.

Is there an app blocker that cannot be bypassed?

No, not on a device you own and control, and that is deliberate. If a third-party app could permanently restrict your phone, the first malicious app to ship would brick a lot of phones, so Apple keeps the exit in your hands.

There is always a way out. The useful question is how long it takes and whether the effort lands somewhere useful. Here is the ladder, cheapest first.

Way out	Roughly how long	What it costs you	Can the app tell?
Tap-through or “I really need this” button, if the app ships one	1 to 2 taps, under 5 seconds	Nothing	Yes, it fired the action
Wait out a timer or a breathing pause	5 to 60 seconds	Attention, the currency you were defending	Yes
Solve a gate: a math problem, a long typed phrase	20 to 60 seconds	Concentration, which is the point	Yes
Delete the blocker	~10 seconds, unless `denyAppRemoval` is set	Your settings, history, streak	No, it is gone
Revoke Family Controls in Settings	~15 seconds if you know the path	Every shield drops at once; tokens are voided	Yes, `authorizationStatus` is observable
Turn off Screen Time entirely	~20 seconds	Your limits and your usage history	Yes
Erase and restore the device	30+ minutes	Everything	No
Someone else holds the Screen Time passcode	Not available to you	Autonomy, a real cost and sometimes worth paying	N/A

Two rows need comment. ApplicationSettings.denyAppRemoval is real: a blocker can prevent app deletion device-wide, which closes the cheapest exit. And revocation is observable, so an app can watch its own authorisation status and know the moment you walked out. Whether it should do anything with that beyond recording it for you is a design question with an obvious wrong answer.

Read down that ladder and “unbypassable” stops meaning anything. What varies is how many seconds sit between the impulse and the app, and whether those seconds buy you anything.

What the API reality means for design

I wrote a while ago that the unlock cost has to live outside the app: a cost you set yourself, inside the software, is a cost your craving can renegotiate in the middle of the craving. The API facts above make the same argument at the level of the platform. Revocation is always about fifteen seconds away, so the wall is not the product. The price is.

And the price should be paid somewhere your future self benefits. Waiting fails that test: you pay in attention, which is exactly what you were trying to protect, and you get nothing back. Body movement passes it, because the cost lands in the rest of your life.

The other designs are not wrong for that. Several are good for problems mine does not solve:

one sec interrupts before the app opens, with a breath, a pause or a question. If your thumb arrives before your intention does, that suits you better than a hard gate, because it targets the reflex. A gate you have already earned your way past does nothing about a reflex. one sec also runs on Android, which nothing of ours does.

Brick puts a physical NFC tag in the loop, around $59 one time. Leaving the tag at home is a commitment you cannot undo from the couch, and it is the only design in the category where the friction is made of atoms instead of software you authorised. The cost is an object to buy, carry, and lose. Unpluq works on the same physical principle, paired with a subscription.

ScreenZen is free, with escalating pauses, and being free is a real advantage that EarnLock’s $19.99 lifetime tier does not erase. Opal and Jomo are more polished than we are, and Jomo covers iPhone, iPad, and Mac.

EarnLock uses exactly the same three frameworks as all of them and does nothing Apple does not publish. What it changes is the price: your selected apps stay shielded until you hit a daily activity goal read from Apple Health (steps in the free tier, active minutes or active energy in Premium). The shield is a ShieldConfiguration extension that paints a live progress ring with the number remaining, where Apple’s version shows a generic restriction screen. 3,412 steps until unlock tells you where you’re going; This app has been restricted just stops you. The Apple Watch app reads HealthKit on the wrist, so the count keeps running on a walk without the phone. Which number to set is its own question, covered in what the step-count studies support. $1.99/month, $9.99/year, or $19.99 once, each price checked in August 2026.

EarnLock has the same constraints as everything else on this page. It cannot see which apps you blocked either. It does not stop notifications. It is iPhone and Apple Watch only, with no iPad or Mac version, because the framework does not support the mechanic there. It ships one math-gated emergency unlock per day, on purpose, because people delete a tool with no exit. And if you open Settings and revoke its authorisation, every shield drops and it can do nothing about that. The same is true of every Family Controls app named on this page, and worth knowing before you pay any of us. (The data rules behind that, and behind every other Lagerland app, are on the transparency page.)

TL;DR

No third-party iPhone app blocks anything itself. It asks iOS to, via FamilyControls (permission and the picker), ManagedSettings (the shield), and DeviceActivity (schedules and thresholds).
The picker returns opaque tokens, not app names. Your blocker cannot log, sell, or leak which apps you chose, because iOS never gives it the names. The same rule stops it from pre-filling a recommended list for you.
A shield blocks launching, not notifying. It covers the app and, via web domains, Safari. It does not cover your iPad, your Mac, or the banner that pulled you in.
Nothing is unbypassable, by Apple’s design. Revoking Family Controls in Settings takes about fifteen seconds and voids every shield at once. denyAppRemoval closes the cheapest exit; nothing closes the last one.
So compare the price, not the wall. What varies is what stands between the impulse and the app (a tap, a wait, a physical tag, or a step count) and whether paying it leaves you better off.

How to compress a video for email: the size limits and the bitrate math

2026-07-25T00:00:00+00:00

At the 8 Mbps that YouTube recommends for 1080p uploads, one minute of video is 60 MB. That is more than twice what Gmail will attach. Getting a clip into an email is a small sum: pick a target below your provider’s limit, work out the bitrate that fits it, and re-encode at that bitrate. This post gives the numbers for each step, then shows how MediaKit does it on iPhone and Mac without sending the clip anywhere first.

How big a video can you email?

Service	Limit	What it counts	Over the limit
Gmail, personal account	25 MB	All attachments in the message together	Gmail replaces the attachment with a Google Drive link
Outlook app, internet accounts such as Outlook.com	20 MB	The attachments plus the email itself	Microsoft suggests compressing, or sharing a cloud link
Exchange, work accounts	10 MB by default	The whole message; administrators can change it	As above
iCloud Mail	20 MB	Incoming and outgoing messages	Up to 5 GB with Mail Drop turned on
Mail Drop (Apple Mail, iCloud Mail)	5 GB	The message including attachments; each link expires after 30 days	Mail Drop can’t send it

Limits as each provider’s help page stated them in July 2026: Gmail Help, Microsoft Support, and Apple’s pages on iCloud Mail limits and Mail Drop. Work and school accounts can be set lower by their administrators, and the receiving server applies its own limit. Microsoft’s Exchange documentation says a message must fit the limits of both sender and recipient, so the smallest limit on the route decides.

Why a 25 MB limit does not take a 25 MB file

Email is a text format. Before a video can travel as an attachment it is Base64-encoded: every three bytes of the file become four characters of text, broken into lines of at most 76 characters (RFC 2045, section 6.8). The message that crosses the network is about a third larger than the file on your disk.

Whether a limit is measured before or after that encoding varies, and consumer help pages rarely say. Microsoft’s Exchange documentation does: Base64 adds about 33%, so a 64 MB message limit means a realistic maximum of about 48 MB. Its Outlook page adds that the 20 MB limit includes the email, not just the attachment.

So the working rule is three-quarters of the stated limit:

Stated limit	Aim for a file of about
25 MB (Gmail)	18 MB
20 MB (Outlook, iCloud Mail)	15 MB
10 MB (Exchange default)	7.5 MB

Undershooting costs a little picture quality. Overshooting means a bounce, or a link where you wanted an attachment.

How to work out the bitrate that fits

File size is bitrate multiplied by duration. Run it backwards:

Convert the target to kilobits. Megabytes × 8,000, counting a megabyte as 1,000,000 bytes.
Divide by the clip’s length in seconds. That is the total bitrate in kbps.
Subtract the audio. 128 kbps is a common stereo setting; 64 kbps is plenty for speech.
The rest is the video bitrate. Leave a few percent for the container’s own overhead.

A 90-second clip for Gmail: 18 MB × 8,000 = 144,000 kilobits. Divided by 90 seconds, that is 1,600 kbps. Take away 128 kbps of audio and about 1,470 kbps is left for the picture.

The same sum for common lengths, with 128 kbps of audio taken out first:

Clip length	7.5 MB file	15 MB file	18 MB file
30 seconds	1,870 kbps	3,870 kbps	4,670 kbps
1 minute	870 kbps	1,870 kbps	2,270 kbps
2 minutes	370 kbps	870 kbps	1,070 kbps
5 minutes	70 kbps	270 kbps	350 kbps

Figures are rounded down.

Which resolution and codec to choose

A bitrate is only generous or thin relative to the frame it has to fill. For scale, YouTube’s recommended upload settings for standard frame rates ask for 8 Mbps at 1080p, 5 Mbps at 720p, 2.5 Mbps at 480p and 1 Mbps at 360p. Those figures are high, because YouTube re-encodes everything it receives, but they show how fast the need falls with frame size: 1080p has 2.25 times the pixels of 720p.

A rough rule: if your video budget is well under half of YouTube’s figure for the clip’s resolution, step down one resolution. By that rule, a one-minute clip at 18 MB (2,270 kbps) sits better at 720p than at 1080p, and at 7.5 MB (870 kbps) it belongs at 480p or below. Three other settings move the result:

Audio bitrate. For a talking-head clip, 64 kbps instead of 128 kbps hands the difference to the picture. On a five-minute clip at 15 MB, that is nearly a quarter more video bitrate.
Frame rate. A 60 fps clip spreads its bits across twice as many frames as a 30 fps one. YouTube’s figures for 48 to 60 fps are about half as high again as for 24 to 30.
Codec. Apple says HEVC compresses better than H.264, and recent Apple devices play it. But you don’t control where the attachment is opened, and H.264 in an MP4 plays almost everywhere. Apple’s page also notes that its devices might convert HEVC to H.264 when sharing to a device that can’t play it; for a file you have already compressed, it is simpler to pick H.264 yourself.

When to send a link instead

The five-minute row of the table is where compression stops being useful: 270 kbps is about a quarter of what YouTube suggests for 360p. When the budget falls that low, a link serves the recipient better than an attachment.

Mail Drop in Apple Mail and iCloud Mail sends files up to 5 GB as a download link that expires after 30 days. Mail offers it when a message is larger than your provider allows.
Gmail swaps an attachment over 25 MB for a Google Drive link on its own.
Outlook points you to compressing the file or sharing it from cloud storage.

With a link, the recipient gets the full-quality original, and a copy sits on a server for as long as the link lives.

Doing it in MediaKit

MediaKit runs the arithmetic above on the device, on iPhone and on Mac, and never uploads the clip. Video Compress is one of the five tools that stay free after the three-day trial.

Open the clip. On a Mac, drag it onto the window. On iPhone, add it from Photos or Files, or send it from another app’s share sheet.
Choose the video Compress tool and set Mode to Target size.
Type the target from the three-quarters table, for example 18, with the unit on MB. MediaKit counts a megabyte as 1,000,000 bytes.
Open Advanced. Set Max resolution using the bitrate table, leave Codec on H.264 for email, and choose 64 kbps (voice) under Audio bitrate if the clip is mostly speech.
Run it, then check the size of the result before you attach it.

In Target size mode MediaKit does steps one to four of the sum itself: it divides the target by the clip’s length, takes out the audio bitrate you chose and holds back 3%, encodes, then measures the file it wrote and encodes again with a corrected bitrate if it missed. A 4K or 1440p source starts with Max resolution set to 1080p; for a small target, set it lower.

If you already use HandBrake for this job, the HandBrake comparison covers where the two differ, and the Compress Videos & Resize Video comparison does the same on iPhone. Why the studio keeps this work off other people’s servers is the subject of an earlier post, and the wider toolkit is in this one.

App Store proceeds vs sales: what each money column in App Store Connect means

2026-07-20T00:00:00+00:00

Sales is what customers paid. Proceeds is what you keep. In Apple’s own words, proceeds are “the Customer Price minus applicable taxes and Apple’s commission” (Apple). Below: which column holds which figure, which rate applies, and why the totals move from one report to the next.

What does each number in App Store Connect mean?

Paraphrasing Apple’s definitions for Sales and Trends, the Summary Sales Report and the financial reports:

Term	Where it appears	What it counts	Tax included	Commission removed
Units	Sales and Trends, Sales report	First-time purchases of an app or bundle, plus In-App Purchases. Sales and Trends leaves out updates and redownloads unless you filter them in. Refunds count as negative units	n/a	n/a
Sales	Sales and Trends	The total billed to customers for apps, bundles and In-App Purchases	Yes, taxes Apple collects and remits	No
Proceeds	Sales and Trends	What you earn on those sales, as an estimate until the financial reports close	No	Yes
Customer Price	Sales report	The price per unit billed to the customer; negative on refund rows	Yes	No
Developer Proceeds	Sales report	What you receive per unit; stays positive on refund rows	No	Yes
Partner Share	Financial reports	Final proceeds per unit	No	Yes
Extended Partner Share	Financial reports	Quantity multiplied by Partner Share	No	Yes

In the downloadable report, both money columns are per unit, which is easy to miss. Apple’s sample row has 100 universal app purchases in the United States, where “Customers paid .99 USD for each unit and you received .70 USD for each” (Apple). That row is 99.00 USD of sales and 70.00 USD of proceeds. Add up the Developer Proceeds column without multiplying by Units and a busy app’s revenue shrinks to a fraction of itself.

How does a customer price turn into proceeds?

Per unit, the order of operations is:

Developer Proceeds = (Customer Price − tax included in it) × your proceeds rate

Apple’s subscription terms spell out the order: you receive 70% of the price “minus applicable taxes”, or 85% once the higher rate applies (Apple). Tax comes off first, and the rate applies to what is left.

A rough example for a 4.99 EUR price in Germany, where the price includes 19% VAT:

Step	Standard rate	Small Business Program or subscription year two
Customer Price	4.99	4.99
Price without 19% VAT	4.19	4.19
Proceeds rate	70%	85%
Developer Proceeds, about	2.94	3.56

That is my arithmetic, not Apple’s figure. Apple works out proceeds for each storefront from its own price points and tax rules, so the real figure can be a cent or two off. The same price point earns different proceeds in different countries because the tax inside the price differs, and Apple notes that it “may need to adjust prices or your proceeds due to changes in tax regulations or foreign exchange rates” (Apple).

What commission rates does Apple charge?

Under Apple’s standard App Store terms:

Situation	Commission	You keep
Standard rate on paid apps and In-App Purchases	30%	70%
App Store Small Business Program member	15%	85%
Auto-renewable subscription, first year of a subscriber’s paid service	30%	70%
Auto-renewable subscription after one year of paid service	15%	85%
Any subscription, Small Business Program member	15%	85%

The Small Business Program is for developers who, together with any associated developer accounts, earned no more than 1 million USD in proceeds in the previous calendar year and stay under it in the current one. You have to enrol; it isn’t automatic. Apple adjusts proceeds fifteen days after the end of the fiscal month in which it approves you. Cross the threshold during a year and the standard rate applies to future sales.

For subscriptions, the 85% rate follows days of paid service, counted per subscription group (Apple). Free trials don’t count toward the year; paid introductory offers do. If a subscription lapses and the customer comes back within 60 days, the count resumes. After 60 days it starts again. In the Sales report, rows earning the higher rate carry Rate After One Year in the Proceeds Reason column.

These are the standard terms. Storefronts in Japan and the European Union run under separate Apple business terms with their own rate tables, and Apple has changed both since 2024. If a large share of your sales comes from either, check those pages before modelling proceeds with the percentages above.

Where does tax come out?

Apple’s definition of Customer Price says it is “inclusive of any applicable taxes we collect and remit” (Apple). So sales, built from Customer Price, includes that tax, and proceeds never do. When you compare two storefronts at the same price, the one with the higher VAT or GST pays you less.

Income tax and withholding are a separate layer. They don’t appear in Sales and Trends at all. Financial reports carry a Taxes and Adjustments field, and Apple applies any withholding tax when it makes a payment (Apple).

How do refunds show up?

In the Sales report, a refund row has negative Units and a negative Customer Price, while Developer Proceeds stays positive (Apple). Multiply proceeds by units, as you do for every row, and the refund subtracts itself. A Units value of 0 can mean a partial refund.

Sales and Trends folds processed refunds into its daily unit totals and shows them as negative units; to see the refund count on its own, add a filter. A refund appears on the day Apple processes it, which is rarely the day of the original purchase, so a quiet day can show negative proceeds.

Why doesn’t Sales and Trends match Payments and Financial Reports?

Apple’s short answer is that Sales and Trends provides next-day data, while Payments and Financial Reports provide final proceeds (Apple). The reasons underneath, from Apple’s page on differences in reporting tools:

Sales and Trends records a transaction when the customer starts it. Financial reports include only settled transactions where Apple collected the payment, so a purchase late in one month can land in the next fiscal month, and a payment Apple never collects never appears.
Financial reports follow Apple’s fiscal calendar, whose months run Sunday to Saturday and don’t line up with calendar months. Sales and Trends reports use Pacific Time days.
Sales and Trends estimates USD amounts from a rolling average of the previous month’s exchange rates. Financial reports use the rate that converts each currency to your bank account’s currency.
Taxes, adjustments and withholding appear only on the financial side.

Use Sales and Trends to see direction: which app sold, in which country, this week against last. Use the financial reports when the number has to match a bank statement.

Where AppMeta Pulse fits

AppMeta Pulse is the iPhone dashboard I built for the daily look at these numbers. It downloads the daily Sales report and the subscription reports through the App Store Connect API with a key you create, and keeps Apple’s names for things. The main amount is Proceeds by default, described in the app as Apple’s payout after commission; in Settings, under Display, you can switch it to Sales, the full customer price. Refunds are counted from rows with negative units. Each row is converted from its own currency into the display currency you pick, using the European Central Bank’s monthly average rates.

Pulse reads Sales and Trends, not Payments and Financial Reports. Its figures are next-day numbers with the same caveats as the Sales and Trends page itself. For subscription revenue on a monthly footing, the earlier post on calculating MRR from the Subscription report covers the formula, and this post explains why a quick revenue check belongs on the phone.

The same Wikipedia article is a different article in another language

2026-07-16T00:00:00+00:00

Open the English article about a Finnish lake and click Suomi in the languages sidebar. You will probably not get that article in Finnish. You will get a different article, longer and differently sourced, with several paragraphs on fishing rights and local place-name history that English never had, and without the geology section you came for.

The sidebar looks like a language switcher, and every other website has trained you to read it that way: same page, different words. On Wikipedia it is a list of independent encyclopedias that each happen to have an article about the same subject.

Most questions people have about Wikipedia and languages are answered once that misreading is cleared up, so start there.

Are Wikipedia articles translated into other languages?

Usually not. Each language Wikipedia is a separate project with its own editors, administrators, notability rules, sourcing norms, deletion process, and article set. Articles are written locally by people working in that language. There is no English master copy for them to be derived from.

That has four consequences:

The languages sidebar links concepts, and says nothing about the text. Since 2013 those links have lived centrally in Wikidata: one Wikidata item groups the pages that are about the same subject across editions. The item says nothing about their length, structure, sourcing, or agreement.
Translation exists, as a seed for new articles. MediaWiki’s Content Translation tool lets an editor start a new article from an existing one in another language, and has produced a large cumulative number of articles since 2015 (the running total is on the tool’s own dashboards). It is still small next to the tens of millions of articles across all editions, and a translated article stops being a translation as soon as a local editor works on it, which usually happens right away.
Image policy differs. English Wikipedia permits a narrow class of non-free images under its non-free content policy. Several large editions, German among them, accept none at all. The same subject can have a photograph in one language and, permanently, no image in another.
So do inclusion thresholds. English works from a general notability guideline built on significant coverage in independent reliable sources. German has its own Relevanzkriterien, stricter in several areas and the subject of a long-running internal argument about exactly that. Other editions are looser than either. A subject can be notable in one encyclopedia and deleted from the next.

So two editions can disagree about facts, framing, article length, and whether the subject deserves an article at all. That is what independent projects do, and none of it is a defect waiting for repair.

How big is each Wikipedia language edition?

All figures below are heavily rounded and approximate as of 2026. Article counts change every hour; check the live table on Wikimedia’s List of Wikipedias for current numbers.

Edition	Articles (approx., 2026)	What the number hides
English (en)	~7.0M	The largest predominantly human-written corpus; also the default most readers never leave
Cebuano (ceb)	~6M	Overwhelmingly machine-generated by one bot (Lsjbot); the total moves as the community deletes batches
German (de)	~3.0M	Strict inclusion rules, comparatively low stub ratio, no non-free images
French (fr)	~2.7M	Broad coverage of francophone Africa and the Caribbean that English thins out fast
Swedish (sv)	~2.6M	Large bot-created share, same Lsjbot lineage as Cebuano
Dutch (nl)	~2.2M	Very high article count relative to speaker population
Russian (ru)	~2.0M
Spanish (es)	~2.0M	Coverage split across two dozen national contexts
Italian (it)	~1.9M
Polish (pl)	~1.6M
Egyptian Arabic (arz)	~1.6M	Separate edition from Arabic (ar); heavily bot-assisted
Chinese (zh)	~1.4M
Japanese (ja)	~1.4M	Deep domestic coverage, notably in rail, media, and local history
Ukrainian (uk)	~1.3M
Vietnamese (vi)	~1.3M	Large historical bot-import share
Arabic (ar)	~1.2M
Portuguese (pt)	~1.1M
Persian (fa)	~1.0M
Finnish (fi)	~600K	The size most European editions actually are
Hindi (hi)	~200K	Enormous speaker population and a small edition, a recurring pattern

Two things about that column of numbers.

First, “article” has a precise and unglamorous definition: a page in the main namespace, not a redirect, containing at least one internal link. A one-sentence stub about a river in the Philippines counts exactly as much as a book-length featured article on quantum chromodynamics. Ranking editions by article count ranks them by a measure that ignores everything you care about.

Second, edition size does not track speaker population. Dutch has more articles than Arabic; Hindi has a fraction of Finnish. Size tracks how many people chose to write an encyclopedia in that language over twenty years, plus whatever bots ran there.

Why do two editions disagree about the same topic?

The divergences fall into recognisable kinds. The table describes each kind in general terms, since the specifics of any one article change weekly.

Kind of divergence	What you actually see	Why it happens
Local-interest depth	The home-country edition has six sections and forty references; English has four sentences	Editors write about what is near them, and the sources are in the local language
Contested history and naming	Different article titles, different framing, different dates given for when something started	Titles and framing are settled inside each community, from that community’s reliable-source pool
Biography emphasis	A national figure gets a long career section at home and a stub abroad, and the sections chosen differ	Significance is judged locally, and so is which part of a life is the interesting part
Science and technical depth	Usually English is longest; sometimes it very much is not	Depth follows whichever subject community showed up, which is not distributed evenly
Images	A photograph in one language, no image at all in another	Non-free content policy is per-edition
Existence	A blue link in one edition, a red link in the next	Notability thresholds differ, and deletion discussions are local
Bot stubs	Thousands of near-identical settlement or species articles	Some editions ran mass-creation bots; others banned the practice outright

The contested-history row deserves the most thought. When editions disagree about a border, a war, a name, or a leader, it is rarely because one is careless. Each edition’s editors read a different body of published sources, in a different language, from a different set of institutions, and each edition’s neutrality policy is applied by people inside that source environment. Two well-run editions working honestly from different literatures can land in different places, and you only find that out by reading both.

What happens when an edition has very few active editors?

Editing capacity is not spread evenly. English Wikipedia’s active-editor count runs in the tens of thousands (live figures on Wikimedia Statistics); most editions are in the hundreds or below, and many have single-digit regulars. Below some point, bot-created stubs dominate the count, errors and vandalism survive longer because fewer eyes pass over each page, and a very small group can shape a large share of the edition.

The Wikimedia Foundation commissioned and published a disinformation assessment of the Croatian Wikipedia in 2021 after a small group of administrators had steered content there for years. The Scots Wikipedia case in 2020 was a different kind of problem and just as instructive: a single prolific editor had written tens of thousands of articles in a version of Scots that fluent speakers did not recognise, and it went unchallenged for years because almost nobody was reading.

Both were documented and addressed openly, and neither is a reason to distrust Wikipedia in general. They are a reason to know which edition you are reading. A small edition is thinner, which does not make it worse, but you should be able to see how thin it is.

How do you actually read a topic in a second language?

The technique is short:

Start from the article you have and open the languages sidebar. Every listed edition is a separately written article about the same concept.
Prefer the edition closest to the subject. For a Japanese rail line, a Finnish municipal reform, or a Brazilian composer, the home edition almost always has more, and has it from sources nobody translated.
Let the browser translate the page. Safari and Chrome both do full-page translation. You do not need to read the language to find out whether the article is four paragraphs or four screens.
Read the references section even when the prose is machine-translated. The source list is often the most useful part: local newspapers, national archives, ministry publications, regional academic presses.
Note where the editions disagree. Where two editions differ on a date, a name, or a cause, you have found a place where the published literatures differ.
Do not quote the machine translation. It is a reading aid; if a specific claim matters, go to the cited source.

It is unglamorous and it works. It is also the fastest way to notice that the English Wikipedia you have been treating as the encyclopedia is one among roughly 340.

Why a deck holds up better than a feed

Everything above is reference. The rest is a design argument, and it is the reason WanderWiki is a swipe deck and not a scroll.

A feed ranks items by predicted engagement, has no bottom, and treats you leaving as a failure. Every mechanism follows from that. The ranking input is your behaviour, because behaviour predicts engagement better than anything you would tell it. The list is infinite, because a bottom is an exit. Continuation gets rewarded, because a reason to return tomorrow is worth more than a good session today. I have written about the streak half of that machinery elsewhere, and about what this studio refuses to build here.

A card deck of encyclopedia articles reverses three of those properties, almost by accident of the form.

The best outcome is that you leave the deck. A card exists to make you open the article, and opening the article means you stop swiping and start reading something long. A feed whose best outcome is “user departs into a long article on the Antikythera mechanism” is a bad feed and a good deck.

The ranking input can be a setting. In a multilingual reading app the strongest personalisation lever is the language edition, and you choose it in a menu; nothing infers it from dwell time. Interest categories work the same way. A declared preference is worse at maximising engagement than a behavioural model, and better at what a reader wants, which is to be handed something interesting.

The deck carries no state to defend. Swiping does not level you up, and the deck is no better on day 200 than on day 1. You put it down when you are satisfied, before any supply of bait runs out, which was the whole argument in reading without a feed. WanderWiki does keep one count outside the deck, the days in a row you have found a new article, shown on its Profile tab, plus an optional daily reminder. Neither changes what the deck shows you.

A deck is not automatically virtuous. A swipe deck ranked on dwell time with a streak counter bolted on would be a feed in a costume. The form makes the honest version easy to build and the dishonest version obviously unnecessary, and that is all it does.

Where WanderWiki fits, and where it does not

WanderWiki is a discovery client, and that rules some things out.

It runs on iPhone and iPad, iOS 18.2 and later. It carries 32 Wikipedia language editions out of roughly 340, which is a real limitation. There are four ways in: Random across the full encyclopedia, Browse and For You across 16 interest topics, and Today in History. How random that Random draw really is, and how to make one land on a featured article, is covered in a guide to finding interesting Wikipedia articles. The app has no ads and no account, and the articles you save stay on the device, in folders. It is free for 20 articles a day; WanderWiki Plus, which adds For You, Today in History and unlimited swiping, is $1.99/month, $8.99/year, or $24.99 once. Paying is what replaces ads and an engagement model.

The part relevant to this post is the category mapping. In 17 of the 32 editions, interest topics are mapped against that edition’s own category tree, so choosing German plus Science queries Wissenschaft, Physik, and Chemie, and not machine-translated English category names. In the other 15, For You and Browse fall back to random articles from that edition, because English names pointed at a category tree that does not use them would return the wrong articles or none. That is the point from the top of this page applied in one place: the German Wikipedia’s category structure belongs to the German Wikipedia. The data side is documented per app on the transparency page.

There are things it does not do. It does not translate: if an article does not exist in the edition you selected, WanderWiki cannot produce it, and that is the correct behaviour. There is no side-by-side view; switching editions switches the deck. And there is no web version.

Two competitors do some things better. If you want the whole encyclopedia offline, in a place with no connection, Kiwix is the answer and nothing else is close; downloadable ZIM archives are a different engineering problem from caching the articles you saved. If you want to edit, watch pages, use talk pages, or reach every edition and not just 32, Wikipedia’s own official app does that and is free. WanderWiki sits in the narrow gap between them, as a way to read the parts of the encyclopedia you were not searching for.

TL;DR

Wikipedia language editions are written locally, not translated. Each is an independent project with its own editors, notability rules, sourcing norms, and image policy. No English master copy exists for the others to render.
The languages sidebar links concepts. Those links live in Wikidata and assert only that two pages are about the same subject. They say nothing about length, framing, or agreement.
Article counts are a bad size ranking. English is around 7 million and Cebuano near 6 million, but the second is almost entirely bot-generated stubs. Check the live List of Wikipedias before trusting any number on a blog, including this one.
Reading a topic in a second edition is a real research technique. Open the edition closest to the subject, let the browser translate, and go through the references list, where local sources usually turn up.
Small editions are thinner, which makes them fragile. The published Croatian and Scots cases show what happens when very few people are watching.
A deck is defensible where a feed is not. Its best outcome is you leaving to read something long, its ranking input can be a declared setting, and it has no accumulating state to defend.

Your vet paperwork is a household document, and it should never leave the phone

2026-07-12T00:00:00+00:00

Ask someone whether they would upload a photo of their driving licence to a free web tool and they will say no straight away.

Ask the same person to photograph the dog’s rabies certificate into a pet app and they will not think about it at all. It is the dog’s certificate. The dog does not have a credit rating.

People file the certificate mentally under the pet, but on paper it is a document about a household with an animal named in it. This post is about that mismatch between how the document feels and what it contains.

What is actually printed on a vet invoice or vaccination certificate?

Pull one out of the drawer and read it field by field. The exact layout varies by country and practice-management software, but the contents are very consistent.

What is printed	Whose data is it	Why it matters if it leaves
Owner full name	Yours	The primary identifier on every other field below
Home address	Your household	Physical location, tied to a name and a phone number
Phone number, often email	Yours	The two fields that make a record joinable to other databases
Animal name, species, breed, DOB, sex	The pet	Common security-question and password-reset material
Microchip transponder code	The pet, registered to you	A permanent, unique, lifelong identifier for the animal
Clinic name and address	Third party	Places you geographically, often within a few kilometres of home
Treating vet’s name, sometimes licence number	Third party	Professional identity, not yours to redistribute
Drug names, dose, route, batch or lot number	Clinical	Health data about the animal; batch numbers are traceable to supply
Diagnosis or presenting complaint	Clinical	The most sensitive line on the page, and often free text
Invoice number, date, amount, payment method	Financial	Sometimes a masked card reference or a practice account number

Two of those deserve a closer look.

The first is the microchip code, which identifies more than the pet. Transponders sold today generally follow the ISO 11784/11785 standard and carry a 15-digit code, while older chips in the United States may be 9 or 10 digits (Wikipedia’s summary of animal microchip standards is a decent overview of the encoding). That code is the key into a registry that holds your name, address and phone. Anyone can type a chip number into the AAHA Universal Pet Microchip Lookup Tool and find out which registry it is enrolled with. The tool returns the registry and not your details, but it is a useful reminder that the number is an index into a database about you. It is more than a serial number on a piece of hardware.

The second is travel paperwork. The EU pet passport model, described on the European Commission’s pet movement pages, binds the transponder code to the owner’s name and address in a single booklet, alongside the rabies vaccination record. If you have ever photographed a pet passport, you photographed an identity document with two subjects on it.

Where does the image go? On-device versus cloud extraction

To the user, the feature looks the same either way: you point the camera at a page, a moment passes, and the fields fill in. Underneath are two different architectures, and they differ in the things you cannot see.

Dimension	On-device extraction	Cloud extraction
Where the image goes	Stays in the app’s container on the phone	Uploaded to the operator’s infrastructure, often via a CDN and a queue
Airplane mode	Works. Capture and OCR are OS frameworks	Fails, or queues the scan for later upload
Latency	Bounded by the device; no round trip, no rate limit	Network round trip plus queue time; degrades on poor connections
What a breach exposes	Nothing. There is no copy to breach	The image, the extracted text, and the account it is attached to
What a policy change can do retroactively	Nothing. It cannot reach data it never had	Re-scope, re-use, or transfer everything already held
Retention and deletion	You delete the record, the file is gone	Deletion applies to the live store; backups and logs are a separate question
Accuracy on hard scans	Bounded by what fits on the device	Usually better on creased, faded or unusual pages
Improvement over time	Requires an OS or app update	Improves server-side with no action from you
Cost model	Compute is free once the device is bought	Per-page inference cost, which someone has to fund

The last row explains much of the rest of the table. Server-side extraction has a marginal cost per page, and that cost has to be recovered through a subscription, a clinic partnership, or the data. Local extraction has no marginal cost at all, which is why a local app can offer scanning without a recurring bill and a cloud app usually cannot.

Cloud wins two of those rows outright, and anyone selling on-device processing should say so. A hosted model is not constrained by a phone’s memory ceiling or thermal budget, so on a faded thermal printout, a fax of a fax, or a vet’s handwriting in the margin, cloud OCR will frequently read a line a local model misses. It also improves while you sleep: the operator ships a new model and every future scan gets better, with no App Store update and no action from you.

Which Apple frameworks actually do the reading?

Two frameworks do it, and both ship inside iOS.

Capture is VisionKit’s document scanner, the same camera sheet you have used in Notes and Files. It finds the page edges, corrects perspective so a photo taken at an angle comes out rectangular, handles multi-page documents, and returns clean images.

Reading is the Vision framework’s text recognition, which locates and transcribes text in an image. The set of languages it recognises is enumerable at runtime and has grown across framework revisions, so an app should ask the OS for the list and not hard-code a marketing number.

Neither framework tells you anything about privacy on its own, and this is where people get caught out. An app can present the VisionKit sheet, get a beautiful deskewed image back, and then POST it straight to a server. The capture UI proves nothing. What matters is what happens to the UIImage in the next twenty lines of code, and you cannot see those.

So you test the behaviour instead.

How can you tell whether an app uploads your documents?

There are four tests. None of them requires you to read code, and they work on any health app, pet apps included.

Test	How to run it	What a clean answer looks like
Airplane mode	Enable airplane mode, then scan a document and try to save it	Extraction completes and the record saves, with no spinner and no queue
Privacy nutrition label	On the App Store listing, open App Privacy	Nothing under Data Used to Track You; anything collected is Not Linked to You
Account requirement	Try to use the core feature on first launch	No sign-up wall. An account implies a server that stores something
Required Reason API disclosure	Check the developer’s stated privacy manifest and SDK list	A short list of mundane APIs, and few or no third-party SDKs

The airplane-mode test is the strongest of the four because it tests behaviour. A marketing page can say “privacy-first” for free, but a scan that completes with the radios off cannot be faked.

The other three are declarations, and they are worth reading closely. Apple’s app privacy details are self-reported, which is a genuine weakness, but they are a public commitment with consequences if false, and the “Linked to You” versus “Not Linked to You” distinction is the one that matters most. Privacy manifest files go further: they declare tracking status, tracking domains, and the Required Reason APIs an app calls, each with a category code. A long Required Reason list is not automatically bad, but it is worth reading, and so is the third-party SDK list: an analytics SDK you have never heard of is a data flow you did not choose.

That is why this studio publishes all of it on a single page. Our transparency page lists, per app, the declared tracking status, tracking domains, third-party SDKs, network calls and Required Reason API codes. For Pawza that comes to two Required Reason APIs (app-specific user defaults and file timestamps within the app’s own container), one third-party dependency, an archive library with no network access, and zero tracking domains. Don’t take my word for it: read the page, then run the airplane-mode test yourself.

Why the trade is asymmetric

The upload is permanent and the convenience is momentary.

You save a few seconds by having a server read the page instead of the phone. In exchange, a copy of a document containing your name, your address, your phone number and your pet’s lifelong identifier exists on infrastructure you have never seen, governed by a document you did not negotiate, for a period you cannot verify.

Everything on the company’s side of that trade can change. Policies get revised. Companies get acquired, and the acquirer inherits the database along with the terms, then revises the terms. Retention windows get longer when storage gets cheaper. A deletion request usually reaches the live database and rarely reaches the backup snapshots, the log lines, or the extracted text already sitting in a derived table.

On your side, nothing can change, because you cannot un-upload the scan.

The other half of the asymmetry is who pays for a breach. If a pet-records service is compromised, the company writes a blog post, offers credit monitoring, and continues. You are the one whose home address was in the dump, attached to a phone number, a nearby clinic, and a note about which nights you board the dog. That is exactly the shape of data that makes ordinary fraud and ordinary stalking easier. The same argument applies to any file you casually hand to a web service, which is a point I have made before about image converters and about apps that ask for your bank login.

The architectural answer is to arrange things so that trust is not required. A scan that never leaves the device is not covered by any future version of anyone’s terms, because there is nothing on the other end to apply them to.

What on-device processing actually costs you

Our own app has trade-offs too, and a post like this is worthless if it only lists the other side’s compromises.

Pawza is built to pass its own airplane-mode test. Capture and extraction both run on the device, there is no Pawza account and no Pawza server to upload to, and you confirm every extracted field before it is written. Records stay on iPhone and iPad with optional sync through your own iCloud.

The constraints are real. The best extraction needs Pawza Pro and Apple Intelligence, which means iOS 26 or later on a supported device; on older hardware Pawza falls back to OCR-assisted entry, and you confirm more by hand. There is no Android app and no web app, because the entire privacy argument rests on Apple’s on-device frameworks. The free tier also limits how many documents you can scan, which is a business constraint and not a technical one.

The features we give up are, almost without exception, the ones that need a server. VetKeep answers questions about your records in a conversational AI chat, which is far easier to build when the records already sit on a server; if that is the feature you want, the cloud is the honest way to get it today. PetDesk’s clinic booking and 11pets’s Android and web apps are the same story.

We won’t route the page through a server without telling you and call it scanning. For which documents are worth keeping, what each of them costs, and the full category rundown, the companion post on what to keep in a pet medical record covers the paperwork side.

TL;DR

A vet document is a household document. Owner name, home address, phone, email, the animal’s microchip code, the clinic, the treating vet, the drugs and doses, and sometimes a payment reference. The pet is one field among a dozen about you.
The feature looks identical either way. You point the camera and the fields fill in. The difference is where the image goes, which you cannot see from the UI.
Airplane mode is the honest test. VisionKit capture and Vision text recognition are OS frameworks and need no network. If a scan completes with the radios off, the reading is local.
Cloud extraction wins on hard scans. Its bigger models do better on faded and creased pages, and they improve without an app update.
The trade is lopsided. The convenience lasts seconds; the copy is permanent, and every term governing it can be rewritten afterwards by someone you never met.
Check four things on any health app: airplane mode, the App Store privacy nutrition label, whether an account is forced, and the declared Required Reason APIs and third-party SDKs.

The drawer of paper in your kitchen has one useful property no cloud service can match: nobody can query it from another continent.

Rotating shift schedules explained: DuPont, Pitman, 4-on-4-off, Continental and which are hardest on sleep

2026-07-05T00:00:00+00:00

A rotating schedule is a roster in which your shift times change on a repeating cycle, usually so that a fixed number of crews can cover a workplace around the clock. A handful of named patterns cover most of them. The names are used loosely, and two employers can mean different rosters by the same word, so the sequence matters more than the label.

What are the common rotating shift schedules?

D is a day shift, E an evening (afternoon or swing) shift, N a night shift. Average hours assume no overtime.

Pattern	Shift length	Sequence	Cycle	Average hours a week	Moving between days and nights
DuPont	12 h	4N, 3 off, 3D, 1 off, 3N, 3 off, 4D, 7 off	28 days	42	Four switches per cycle
Pitman / Panama (2-2-3)	12 h	2 on, 2 off, 3 on, 2 off, 2 on, 3 off	14 days	42	Fixed days or nights, or a swap every 2 or 4 weeks
4-on-4-off	12 h	4 on, 4 off; rotating version 4D, 4 off, 4N, 4 off	8 or 16 days	42	Four days off before every switch
Continental	8 h	Runs of 2 or 3 mornings, afternoons and nights, then days off	28 days	42	Forward, every 2 to 3 days
Southern swing	8 h	7D, 2 off, 7E, 2 off, 7N, 3 off	28 days	42	Forward, weekly
2-2-2 fast forward	8 h	2D, 2E, 2N, 2 off	8 days	42	Forward, every 2 days
Fixed five and two	8 h	5 on, 2 off, always the same shift	7 days	40	None

Why does almost every row say 42? A week has 168 hours. Four crews covering it in turn work 168 ÷ 4 = 42 hours each on average, whatever the shift length. What differs is how the hours bunch up. Start DuPont on a Monday and its four weeks come out at 48, 72, 48 and 0 hours. Start Pitman on a Monday and it alternates a five-shift week that includes the weekend with a two-shift week that leaves Friday to Sunday free, which is where its every-other-weekend-off reputation comes from.

Why do Pitman, Panama and 2-2-3 sound like the same thing?

They mostly are. Scheduling guides use all three names for the same 14-day, 12-hour cadence, and some keep Panama for the version where crews also alternate between days and nights. Continental is looser still: in some workplaces it means the 8-hour, 28-day forward rotation in the table, in others any 2-2-3 rota. Whatever your roster is called, write out the next 28 days as D, E, N and off, since that sequence is what your sleep responds to.

How does each pattern move between days and nights?

How hard a switch is depends on which way the clock moves and on how many hours you get between the last shift of one kind and the first of the next.

NIOSH’s free training course for nurses names the direction (Module 5). Day to evening to night is a forward rotation; night to evening to day is a backward one. It also names the speed: fast rotation changes shift within a week, slow rotation keeps each shift for two weeks or more, and weekly rotation sits in between.

In an 8-hour, three-shift system the gaps get small quickly. Move forward from a 14:00 to 22:00 afternoon to a 22:00 to 06:00 night the next day and you have 24 hours between shifts. Move backward from that night to an afternoon shift the same day and you have 8. A 22:00 finish followed by a 06:00 start also leaves 8 hours, and those 8 hours have to cover the commute, a meal and sleep.

Twelve-hour systems have only days and nights, so the gap matters more than the direction. Applied to the table:

DuPont’s tightest point is the middle of the cycle: three day shifts, one day off, three nights. The other switch, nights to days, comes after three days off.
A rotating 4-on-4-off always puts four days off between a block of days and a block of nights.
Pitman crews on fixed days or fixed nights never switch. Rotating Pitman crews switch every two or four weeks, which is a slow rotation.
Continental and 2-2-2 rosters change every two or three days, always forward.
Southern swing rotates forward but weekly, with seven nights in a row.

Why is backward rotation harder on sleep?

The usual explanation is that the human body clock runs slightly longer than 24 hours, so it is easier to push it later, as a forward rotation does, than to pull it earlier, as a backward one does.

The largest study I found on rotation direction and sleep is Shon and colleagues’ 2016 study of 4,750 Korean electronics workers on a three-shift system with 06:00, 14:00 and 22:00 starts. About 38% of the backward-rotating workers had poor sleep quality on the Pittsburgh Sleep Quality Index, against about 28% of the forward-rotating ones. After adjustment, backward rotation carried 1.95 times the odds of poor sleep, and the link was stronger in workers aged 30 and over. It was a cross-sectional study and didn’t record rotation speed, so it shows an association, not proof.

Studies that changed people’s schedules point the same way. A review of field research by Sallinen and Kecklund (2010) found that moving workers from slowly backward-rotating to rapidly forward-rotating shifts improved alertness and, to some extent, sleep. NIOSH’s guidance says forward rotations are easier to adjust to, and that weekly rotation is the hardest speed and best avoided (Module 5, continued).

What the evidence doesn’t settle is fast versus slow. NIOSH notes that some U.S. researchers favour slow rotations of two weeks or more, which give the body clock time to adjust, while some European researchers favour fast forward rotations, which mean fewer nights in a row. Its conclusion is that it isn’t clear which is best for healthcare workers.

Why do quick returns matter so much?

A quick return is a changeover with 11 hours or less between two shifts. Vedaa and colleagues’ 2016 systematic review of 22 studies found signs that quick returns harm sleep, sleepiness and fatigue in the short term; the evidence on longer-term health and work-life balance was inconclusive. Sallinen and Kecklund saw the same pattern across shift systems: night shifts, early-morning shifts and quick returns went with shorter sleep and more sleepiness.

The eleven-hour line comes from regulation and guidance. It is the minimum daily rest in the EU Working Time Directive, which allows exceptions when shift workers change shift, and the minimum gap between shifts that NIOSH’s course cites from Knauth and Hornberger. The course’s own example is an evening shift ending at 11:30 p.m. followed by a 7 or 8 a.m. day shift. Take out the drive both ways, a meal and the time it takes to fall asleep, and even a full 11 hours leaves well short of a full night.

Which schedules are hardest on sleep?

No schedule is best for everyone. NIOSH says researchers cannot recommend a single best design. Its scheduling guidelines (part 1, part 2) and the reviews above still make a fair checklist to hold a roster against:

Feature	What the guidance says	Where it turns up
Backward steps	Forward rotation is easier to adjust to	Any roster with a late finish followed by an early start
Quick returns	At least 11 hours between shifts	Backward steps in 8-hour systems, overtime added to a late shift
Weekly rotation	The hardest speed, best avoided	Southern swing
Long runs of nights	Keep consecutive nights to a minimum on rotating schedules	Southern swing (7), DuPont and rotating 4-on-4-off (4)
Early starts	6 a.m. or earlier tends to shorten sleep	06:00 mornings in Continental and other 8-hour rotations
Long night shifts	8 hours or less is better tolerated on evenings and nights	12-hour nights in DuPont, Pitman and 4-on-4-off
Rest after a run	Consider two rest days after three 12-hour shifts	DuPont’s three days, one day off, three nights

On twelve-hour shifts, Sallinen and Kecklund found that moving from 8- to 12-hour shifts did not necessarily harm sleep. Longer shifts mean fewer changeovers and so fewer chances for a quick return, which is part of why 12-hour rosters have spread despite the long nights.

What can you do on a roster you didn’t choose?

Most people can’t redesign their schedule, but they can find its weak points. Write out a full cycle and mark every gap under 11 hours and every switch onto nights. Those are the days to protect: a nap before the first night (the night-shift sleep guide covers how long and when), nothing extra planned on the changeover day, and an honest look at whether you are fit to drive after the last night.

NIOSH also says nurses adjust better when they have some control over their schedules. If your workplace allows swaps, the backward steps and quick returns are the shifts to trade away first. If you still can’t sleep after several weeks on a rotation, the American Academy of Sleep Medicine’s page on shift work disorder describes when that becomes a conversation with a doctor.

Where AfterShift fits

I built AfterShift for people on these rosters, and it doesn’t need to know what your pattern is called. It reads shifts from your calendar, working out from the title and start time whether each is a day, evening, night or on-call shift, or you add them by hand. Then it measures each window from the end of one shift to the start of the next, not a midnight-to-midnight day.

Two parts of it are written for the switches above. When your next shift starts earlier on the clock than the last one, a backward step, the plan calls the gap an available sleep window, notes that fast shift changes often shorten continuous sleep, and suggests a nap. When the whole gap is shorter than your sleep target, the Shift Recovery Score is capped at 79, the top of Good, because a full sleep was never possible in that window; days off are exempt. The methodology page has the weights and caps, and a sleep-debt trend shows which stretches of a cycle left you furthest behind.

The app can’t change your roster, but it gives you a record of which changeovers cost you the most sleep, which is useful evidence if you ever ask to swap them. The design post explains why the app measures shift to shift in the first place.

Find every recurring charge you are paying, without linking a bank account

2026-07-01T00:00:00+00:00

The standard advice for finding your subscriptions is to look at your bank statement, which is the worst place to start.

A statement is a record of what already charged inside the window you happen to be looking at. Open three months of it and you will see every monthly subscription you have, which are the ones you already remember, and roughly a quarter of your yearly ones, which are the ones you don’t. The charges that hurt renew long after the decision that created them, and a short statement scan cannot show them to you.

There is no single list. Your recurring charges are scattered across four billing systems and four records only you can search, none of which talk to each other, and each already has a screen showing its own slice. The audit is a route through those screens in a sensible order, and the statement comes last.

The audit checklist, in order of what it finds

Run these top to bottom. The first four are billing screens you already own, and together they take about five minutes once you know where they live. The last four are the sweep.

#	Where	How to get there	What it catches
1	Apple subscriptions	Settings, tap your name at the top, then Subscriptions (on Mac: App Store, click your name, Account Settings)	Everything billed through the App Store, active and recently expired, with next renewal date and price
2	Google Play subscriptions	Play Store app, tap your profile icon, Payments and subscriptions, Subscriptions	Android-side app subscriptions, plus anything you first bought on an Android device years ago
3	PayPal automatic payments	paypal.com, Settings, Payments, then the automatic payments or recurring payments list	Merchant billing agreements set up outside the app stores: hosting, newsletters, older SaaS, donations
4	Amazon memberships	Amazon Account, Memberships and Subscriptions; then separately Subscribe and Save	Prime, Audible, Kindle Unlimited, channel add-ons, and every household item on a recurring shipment
5	Email receipts	Search your inbox for receipt, your subscription, renews on, invoice, auto-renew	Direct-to-merchant subscriptions that appear in none of the screens above
6	Purchase history	Apple’s purchase history page (a separate record from the Subscriptions screen)	One-off purchases and lapsed subscriptions, useful for reconstructing what you once signed up for
7	13 months of card statements	Your card issuer’s site; export CSV if offered and sort by merchant	Everything the first six missed, including annual renewals (see the arithmetic below)
8	Password manager	The saved-logins list in your browser, iCloud Keychain, or 1Password	An inventory of accounts you forgot you created, each of which may or may not be billing you

Some notes on the paths, which change over time.

Apple. For most iPhone users this one screen finds the most, and people skip it because they assume it lists only apps. It lists anything billed through your Apple Account, including subscriptions bought inside apps that are themselves free. Apple documents the screen and the cancel flow in If you want to cancel a subscription from Apple. The entry point has moved across iOS versions, so if the path above does not match your device, search Settings for the word subscriptions.

Google Play. Even if you have not owned an Android phone in years, check it. Play subscriptions started before you switched keep billing the card on file. Google’s own instructions are on the Play Help page for cancelling or changing a subscription.

PayPal. Almost everyone skips this step, and the strangest charges live here, because PayPal billing agreements were a common way for small merchants to take recurring payments long before the app stores existed. PayPal calls them automatic payments and explains the list in What is an automatic payment and how do I update or cancel one.

Amazon. There are two separate lists, and the second is easy to miss. Memberships and Subscriptions covers Prime and the digital add-ons. Subscribe and Save is a different screen entirely, reached from the same account page, and it is full of things you set to repeat every two months in 2023 and have been receiving ever since.

Email and purchase history. Search your inbox for renewal language, not brand names, because you are looking for the merchants you cannot name. If your mail client supports it, restrict the search to messages containing the word renew and a currency symbol. Then read Apple’s own record, which is separate from the Subscriptions screen and reaches further back: View your purchase history for the App Store and other Apple media services.

Statements. Read 13 months, not three, for the reason in the next section.

Password manager. It is not a billing record, so do it last, but it is a good memory aid. Sort your saved logins by date created and read the oldest hundred. Some of those accounts are still charging you, and a name you had genuinely forgotten is often the fastest route to the receipt.

Which recurring charges hide best?

Some charges are harder to find than others. These categories survive a casual audit, ranked roughly by how often I have seen them survive one.

What hides	Why the usual audit misses it	Where it actually shows up
Annual renewals	Bought 11 months ago, invisible on a 90-day statement scan, no monthly reminder	Platform subscription screens, or a 13-month statement sweep
Converted free trials	The signup and the first charge are separated by 7 to 30 days, so the charge arrives with no decision attached to it	Apple or Play subscriptions screen; email receipt for the first real charge
In-app subscriptions inside a free app	The app icon says free, so nobody thinks to check it	Apple or Play subscriptions screen, which exists for exactly this
Per-seat tools bought for one project	Billed to whoever set it up, often at 2 to 5 seats, long after the project ended	Email receipts, PayPal, or the tool’s own billing page
Family plans someone else administers	The charge is not on your card at all, so it is invisible to every method in this post	Ask. There is no technical route to this one
Domain and hosting renewals	Usually annual or biennial, and registrars renew silently by design	Registrar billing page, PayPal automatic payments, email
Insurance and memberships renewing by post	Never touched a card or an app store; renewal notice arrives on paper	Direct debit list at your bank, and the paper itself

The last row is where any app-based audit stops working. A direct debit set up by post is not in Apple’s records, PayPal’s or your inbox, and on the statement it looks like an ordinary bank transfer, not a card charge. The only reliable route is your bank’s own standing order and direct debit list, which you can read without granting anyone else access to it.

Why does a yearly charge survive audits a monthly one cannot?

Because you see it one-twelfth as often. The numbers are worth spelling out, because intuition says the opposite: people assume the big annual charge is the memorable one.

Billing cycle	Charges per year	Chance it appears in a 30-day scan	In a 90-day scan	In a 13-month scan
Monthly	12	~100%	100%	100%
Quarterly	4	~33%	~100%	100%
Every 6 months	2	~16%	~50%	100%
Annual	1	~8%	~25%	100%

The percentages are just the window divided by the cycle length: a 90-day window is 90/365 of a year, so it contains an annual charge about a quarter of the time. We audit in three-month windows out of habit, and three months is the wrong window for a twelve-month event.

Add cost to that. A $99-per-year subscription and a $8.25-per-month subscription cost you the same amount over a year. You meet one of them twelve times. You meet the other once, in a month you were not looking, in an amount large enough that you assume it was something else. The yearly plan is usually the better deal and always the harder one to keep track of, which is also why companies push the annual discount so hard.

So scan 13 months, not 12, so a renewal sitting on the boundary cannot slip through. And when you find an annual charge, write the renewal date down on the spot: you will not see it again for a year, and the audit that found it will not run again in time.

What does a bank-linked app catch that a checklist does not?

Three specific things, and they are worth naming.

Charges you never knew existed. A checklist can only find things that appear in a record you thought to open. A transaction feed finds the charge that arrives under a merchant descriptor you cannot decode, such as a payment processor’s name, a parent company or an eight-character string. No amount of manual discipline reproduces that.

Price rises. You entered $9.99 for a service in 2024 and it is $13.99 now. A manual list keeps telling you $9.99 until you notice. Software reading the actual charge sees the new number the month it changes.

Duplicates. Two accounts for one service because you signed up on two devices, a charge that continued after a cancellation that did not take, a trial you converted twice. A list built from memory repeats these errors, because memory is where they came from.

Rocket Money does all three, and does them well. If your problem is I do not know what I am paying for, an aggregator-connected tool is the right choice. The cost is the one I wrote about at length in I will not ask for your bank login: connecting a bank grants an aggregator persistent read access to every transaction in the account, including the ones that are not recurring, and that access continues until you revoke it. You get automatic discovery; the aggregator gets your grocery shopping, your medical copays, and your salary.

The checklist above answers how do I get the discovery without the access. It is slower, an afternoon of work against one tap. It also ends: once you have the list, you have it, and upkeep is a few minutes a quarter.

What do you do with the list once you have it?

Most audits fail at this step. People find eleven forgotten charges, cancel four, feel good, and then rebuild the same mess over eighteen months, because nothing captured the seven they kept or the renewal dates attached to them. Once you know what you are keeping, a bill calendar built around your paydays shows which paycheck has to cover each charge.

The list needs to live somewhere that projects forward. A note does not, and a spreadsheet does until about the third week. AllPaid is the studio’s app for this job: you type a service name, it auto-fills the typical price, billing cycle and category from a built-in catalogue of 40 common services (Netflix, Spotify, ChatGPT, Claude, Adobe, Microsoft 365, iCloud, rent, utilities), and from then on every bill is projected onto a monthly calendar with one reminder before each due date. It is free, with Pro at $1.99/month, $12.99/year, or $24.99 once, and it never asks for a bank login because it has no mechanism to use one. Bills stay in local storage on the iPhone; the transparency page lists third-party SDKs (none) and the empty tracking-domain list.

That limitation is the reason this post exists. AllPaid cannot find a charge you never typed in, and it will not notice a price rise until you edit the amount yourself. It holds the list; the checklist above is how you build it.

If what you want is a subscriptions-only tracker with a lighter footprint, Bobby and Subby are both good and both on-device. Bobby unlocks unlimited subscriptions for a small one-time purchase and Subby is freemium with its own premium unlock, but neither covers rent, utilities and one-off bills alongside the subscriptions. If you want the same list readable from a laptop and a phone and a work machine, TrackMySubs is browser-based and syncs across everything, though it is a web account, not a local file. The broader category comparison lives in the guide to bill tracking without a bank connection.

When to re-run it

Quarterly for the four platform screens, which is five minutes once the paths are muscle memory. Annually for the 13-month statement sweep and the password-manager read, in the same calendar month each year so consecutive sweeps overlap and leave no gap.

The most useful habit is to write down the conversion date the moment you start a free trial. Converted trials are the one category on the hiding list you can remove at signup, a year before you would otherwise go looking.

TL;DR

There is no one list. Recurring charges live in Apple subscriptions, Google Play, PayPal automatic payments, Amazon memberships and Subscribe and Save, your email receipts, and your card statement. Check them in that order.
Start with Apple, not the bank statement. Settings, tap your name, Subscriptions: it covers everything billed through the App Store, including subscriptions inside apps that are themselves free.
Scan 13 months of statements, not three. A 90-day window contains an annual renewal only about a quarter of the time, which is why yearly charges survive audits that monthly ones cannot.
PayPal and Subscribe and Save are the two most-skipped steps. Years of small-merchant billing agreements live in the first; recurring household shipments live in the second.
A bank-linked app does better on three things: charges you never knew existed, price rises, and duplicates. The price is aggregator read access to every transaction, forever, including the ones that are not recurring.
The checklist finds the charges. Something that projects renewal dates forward keeps them from coming back.

How to calculate MRR for App Store subscriptions from Apple's Subscription report

2026-06-27T00:00:00+00:00

Monthly recurring revenue, for an app that sells subscriptions through the App Store, is what your active paid subscriptions earn you per month once every plan is put on a monthly footing. App Store Connect’s daily Subscription report holds every input. For each row:

MRR = Developer Proceeds × Active Standard Price Subscriptions ÷ plan length in months

Add the rows, converting currencies before you add across them, and that is the day’s MRR. The rest of this page is about which columns go into that line, and why.

Which columns in the Subscription report matter?

The report comes in a daily version only, and you can download it from Sales and Trends or through the App Store Connect API’s salesReports endpoint. One subscription usually fills several rows, broken out by columns such as country, price and proceeds rate. These are the columns that decide MRR, paraphrasing Apple’s definitions:

Column	What it holds	Role in MRR
Standard Subscription Duration	The plan length: 7 Days, 1 Month, 2 Months, 3 Months, 6 Months or 1 Year	The divisor
Developer Proceeds	What you earn per subscription on that row	The amount per subscriber
Proceeds Currency	The currency those proceeds are earned in	Add per currency before converting
Proceeds Reason	Rate After One Year when a renewal earns 85% of the price instead of 70%	Nothing to do: the proceeds already reflect it
Active Standard Price Subscriptions	Paid subscriptions currently active, without free trials, subscription offers, introductory offers or marketing opt-ins	The multiplier
Active Free Trial Introductory Offer Subscriptions	Introductory offers currently in a free trial	Left out: a trial earns nothing yet
Active Pay Up Front and Pay as You Go Introductory Offer Subscriptions	Introductory offers at a reduced price	Left out of a standard-price MRR
Billing Retry, Grace Period	Subscriptions with a billing problem Apple is still trying to fix	Left out
Subscribers	People with access, including family members, filled in only when a row covers more than 3 subscriptions	Not a multiplier: it counts people, not paid subscriptions

How do you turn each plan length into months?

Standard Subscription Duration	Divide the row by	Same as
7 Days	0.23 (7 ÷ 30.4375)	multiplying by about 4.35
1 Month	1	the row as it stands
2 Months	2	half the row
3 Months	3	a third of the row
6 Months	6	a sixth of the row
1 Year	12	a twelfth of the row

30.4375 is the length of an average month (365.25 ÷ 12). Treating a month as four weeks instead understates weekly plans by about 8%.

A worked example

Made-up numbers for an app with a monthly plan and an annual plan, from one day’s report:

Row	Duration	Developer Proceeds	Active Standard Price	Calculation	MRR
Monthly	1 Month	3.49	120	3.49 × 120 ÷ 1	418.80
Annual, first year	1 Year	20.99	300	20.99 × 300 ÷ 12	524.75
Annual, Rate After One Year	1 Year	25.49	80	25.49 × 80 ÷ 12	169.93
Annual, free trial (45 active)	1 Year	n/a	0	not counted	0.00
Total					1,113.48 USD

The 380 annual subscribers contribute more MRR than the 120 monthly ones, yet in a sales report they appear only as lumps on their renewal days. That gap is the reason MRR exists.

Four decisions that make two MRR numbers disagree

1. Proceeds or price. Customer Price is what the buyer paid, including Apple’s commission and, in many storefronts, tax. Developer Proceeds is what you are owed. Under Apple’s subscription terms you receive 70% of the price minus applicable taxes during a subscriber’s first year of paid service and 85% after that. Members of the Small Business Program receive 85% from the start. An MRR built on price overstates your income by the commission and any included tax. For what every money column in the sales reports holds, from Customer Price to Developer Proceeds, see App Store proceeds vs sales.

2. Who counts as paying. Free trials are pipeline, not revenue. Introductory and promotional offers are the judgment call: they bring in money, but at a temporary price. Using only Active Standard Price Subscriptions gives the conservative figure, made of subscribers paying the standard price. Including discounted offers raises the number and makes it less stable.

3. Currency. Rows arrive in many proceeds currencies. Add per currency first, then convert. Apple’s availability notes say Sales and Trends estimates USD amounts from a rolling average of the previous month’s exchange rates. Other tools use other rates, so cross-currency totals can differ slightly even from identical inputs.

4. Time. MRR is a level, like a balance, not a flow like sales. For a week or a month, average the daily values; adding thirty days of MRR produces a number thirty times too large. Apple’s availability table also lists the Subscription report’s condition as at least one auto-renewable subscription sold, introductory prices included. When a day’s report isn’t there, treat that day as missing, not as zero.

Why doesn’t MRR match last month’s proceeds?

Sales reports record an annual renewal in full on the day it renews; MRR spreads it over twelve months. A month heavy with annual renewals shows proceeds well above MRR, and the quiet month after it shows them below. One-time purchases, paid-app sales and refunds land in proceeds and never in MRR.

The two sources also differ in finality. Apple describes Sales and Trends as next-day data and points to Payments and Financial Reports for final proceeds (Apple). Use MRR to read the direction of your subscriber base, and the financial reports to reconcile money.

Doesn’t App Store Connect show MRR now?

It does, in Analytics. The Subscriptions dashboard that Apple previewed at WWDC25 shows active plans, paid plans and monthly recurring revenue. Apple’s metric definitions describe MRR as “revenue earned from active paid subscriptions, normalized to a monthly timeframe.” The definition doesn’t say whether revenue means proceeds or price, which exchange rates apply, or how each plan length is normalized. If your own figure and Apple’s differ, the four decisions above are where to look.

In the same session Apple said two new subscription reports in the Analytics Reports API, a subscription state report and a subscription event report, will replace the older Sales and Trends subscription reports. The Sales and Trends Subscription report is still available through the API, and the formula doesn’t depend on which file the numbers arrive in.

When does each day’s report arrive?

Daily Sales and Trends reports are available the following day, generally by 8 a.m. Pacific Time (Apple), and a report day runs from midnight to 11:59 p.m. Pacific Time (Apple). Daily reports are kept for one year after they become available, so anyone building a long MRR history has to store the files as they arrive.

How AppMeta Pulse calculates it

AppMeta Pulse downloads the daily Subscription report through the App Store Connect API, using a key you create that stays in your Keychain. The API access page lists the endpoints it calls and the role the key needs. For each row, Pulse multiplies Developer Proceeds by Active Standard Price Subscriptions and divides by the number of months the plan covers: 1, 2, 3, 6 or 12, or about 0.23 for a weekly plan. Trials are counted and shown on their own; they never enter MRR. Introductory and promotional offers stay out too, because the standard-price column already excludes them.

The totals are kept per proceeds currency. Conversion happens only when a number is shown, into the display currency you choose in Settings, using the European Central Bank’s monthly average rates.

Where the number appears:

Subscriptions screen. MRR for the newest day Apple has published, next to active subscriptions and trials, plus a By Product list with one row per subscription and plan length, showing its MRR, active subscriptions and trials.
Trends and the per-app view. MRR over a period is shown as an average (Avg MRR) across the days that have a report, compared with the previous period. Days without a report are skipped, not counted as zero.
Widgets. The Subscriptions widget on the Home Screen and its Lock Screen counterpart show trials, active subscribers and MRR.

Pulse doesn’t forecast MRR or make Apple’s data arrive sooner. The newest day in the app is the newest day Apple has published, usually yesterday in Pacific Time. For why a quick revenue check belongs on the phone at all, see the earlier post on AppMeta Pulse; for how it differs from AppStats, App Sales and Appfigures, the comparison pages cover each one.

Whichever tool you use, write down its four decisions before comparing its MRR with anyone else’s. Two MRR figures rarely part ways over the formula.

How to read a shogi engine evaluation (and why it is not a chess centipawn)

2026-06-23T00:00:00+00:00

A chess player opens a shogi game record, runs the analysis, and sees the graph spike to +1800. Out of chess habit they divide by a hundred and read eighteen pawns. Two moves later it is back to +200, and they conclude the engine is broken or the position is insane.

The engine is fine, and the position probably is too. The division was almost right, which is the trap: a YaneuraOu pawn is 90 points, so +1800 is nearer twenty pawns than eighteen. What does not carry over is everything the number implies: how likely that edge is to hold, and how far a single capture can move it in a game where captured material comes straight back.

Nobody hands you a conversion table, so here is one. The reference comes first, and the argument about what an evaluation is for sits at the bottom.

What is a shogi engine evaluation, exactly?

It is a single signed integer that the engine emits at the end of a search, in units it defined for itself. Under USI, the Universal Shogi Interface adapted from chess’s UCI, the engine prints a line containing score cp <n> for a positional evaluation or score mate <n> when it has found a forced mate.

Two conventions matter before you read a single digit.

The sign is from the side to move. USI reports the score from the perspective of whoever is on move in the position being searched. Almost every graphical front-end flips it so that a positive number always means Black (先手, sente, the first player) is better. If your numbers seem to alternate sign every ply, you are reading raw engine output and not a normalised display.

The scale belongs to the engine. YaneuraOu, the strongest open-source shogi engine, inherits the material table computer shogi has used since the Bonanza and Apery lineage: a pawn is worth about 90, a rook about 990. The NNUE network that produces the evaluation departs from pure material immediately, but the scale stays anchored there. That is close to a chess centipawn, 90 units per pawn against 100. Shogi evals look like four-digit numbers and chess evals like small decimals only because of display convention: chess front-ends divide by a hundred before drawing anything, and shogi front-ends print the integer. Tunings shift these constants, so if you need them exact, read them in the source instead of trusting a blog.

What do the evaluation bands mean for a club player?

Japanese broadcast coverage has settled on a rough set of bands, and they translate well to a club player’s decisions. The win-probability column comes from the logistic curve computer shogi uses to convert an evaluation to a win rate, 1 / (1 + e^(-eval/600)). The 600 comes from win-rate fitting in the elmo and YaneuraOu learning code; it is a tuning constant, not a law.

Evaluation (your side)	Rough win probability	What it usually means	What to do with it
0 to ±150	50-56%	Level, inside the noise of any club game.	Nothing. Do not chase it.
±150 to ±400	56-66%	A small edge: a tempo, a better-placed silver, a marginally safer king.	Read the plan more than the number.
±400 to ±900	66-82%	A clear advantage, usually a piece won cleanly or a castle with a hole in it.	Find the move where it moved. That move is the lesson.
±900 to ±2000	82-97%	Winning, if you convert: a major piece up, or an attack already landing.	Study the conversion.
Beyond ±2000	97%+	Decided. The rest is bookkeeping.	Scroll back to where it crossed.
`mate N`	100%	A proof, not a magnitude.	Solve it yourself before you look.

Two caveats matter more than the table does. The boundaries are conventions: a different engine, network or search budget draws them elsewhere, and nobody has a principled reason to prefer 400 over 450. And the win probability is a machine’s. Between two 1200-rated club players a +1500 position gets thrown away often enough that the number is advice and not a forecast.

Why do shogi evaluations swing harder than chess centipawns?

Because a captured shogi piece stays in the game. It goes to your hand, the mochigoma (持ち駒) that sit on the wooden stand beside the board called the komadai (駒台), and from there it can be dropped onto almost any empty square as an entire move.

A capture is a subtraction and an addition in the same move, and the evaluation moves by roughly the sum of both. Using the default material constants:

Piece captured	Kanji	Its value to them	Arrives in your hand as	Approx. total swing
Pawn	歩	90	pawn (90)	~180
Lance	香	315	lance (315)	~630
Knight	桂	405	knight (405)	~810
Silver	銀	495	silver (495)	~990
Gold	金	540	gold (540)	~1080
Bishop	角	855	bishop (855)	~1710
Rook	飛	990	rook (990)	~1980
Tokin (promoted pawn)	と	540	pawn (90)	~630
Promoted silver	成銀	540	silver (495)	~1035
Horse (promoted bishop)	馬	945	bishop (855)	~1800
Dragon (promoted rook)	龍	1395	rook (990)	~2385

The bolded rows hold the most useful piece of shogi arithmetic: promoted pieces revert when captured. A tokin is worth a gold to the player who owns it and only a pawn to the player who takes it. That asymmetry is why building tokin is such a cheap, strong plan, and why losing one hurts you six times more than it helps your opponent.

Put the numbers together and winning a silver cleanly moves the evaluation about 990 points, which on the same scale is eleven pawns. In chess, winning a bishop moves you three pawns and you are pleased. In shogi, winning a silver drops you from “level” into the “winning” band in one move, and the engine is reporting the game correctly when it shows that.

The other half of the answer is what does not happen. Chess evaluations settle because material leaves and positions simplify toward technically drawn endings. Shogi has no such drain: trades load both komadai and sharpen the position. Shogi also has no stalemate draw and no draw by insufficient material. The only two draw mechanisms are sennichite, the fourfold repetition that gets replayed with colours swapped, and the rare double-entering-king impasse called jishogi (both are laid out on Wikipedia’s shogi page). An eval near zero in shogi means “unclear”, not “heading for a draw”.

Side by side:

	Chess (Stockfish)	Shogi (YaneuraOu)
Unit shown	Centipawns, normalised in modern Stockfish so +1.00 is roughly a 50% win probability	Engine points on a table where a pawn is about 90
Captured material	Leaves the game	Goes to the capturer’s hand
Swing of a clean capture	About the piece’s value	About twice the piece’s value
Legal moves in a typical middlegame	Roughly 35	Roughly 80-90 (game-complexity figures)
What ten pawns of material is worth	A decided game	About 82% win probability on the standard curve
Effect of trades	Simplification toward drawn endings	Sharpening, with fuller hands
Forced mate	`score mate N`	`score mate N`, same protocol shape

Why is a piece in hand worth more than the same piece on the board?

The material table gives one value per piece, but the two states are not equal, and the NNUE network, which is not a material table, prices the difference where the table cannot.

A piece in hand has no travel time. A knight on your second rank needs several moves to matter; a knight in hand can arrive on any legal square in one move.

It has not committed to anything. A silver on the board is an argument about one part of the board. A silver in hand threatens every weak square at once, and your opponent has to answer all of them.

It is not blocking your own pieces, which counts for a lot on a 9x9 board where all nine of your pawns start on one unbroken rank.

The effect is strongest for the two pieces that can only move forward. A lance or a knight stuck behind your own lines is close to dead weight, since, as the piece guide explains, neither can ever turn around. The same lance in hand drops deep in enemy territory, aimed at a castle. The evaluation reflects that change even though the material table does not.

The drop restrictions are worth memorising, because the engine has already accounted for them and you have not: no two of your unpromoted pawns on one file (nifu), no pawn drop that delivers immediate checkmate (uchifuzume), and no drop onto a square where the piece would have no legal move.

What does a mate score mean in shogi?

It means the engine has stopped estimating. score mate 7 says “there is a forced mate, and here is the proof, seven moves long”, which is a different statement from “very good”. Three consequences follow.

It is off the eval scale. Mate in 11 is not worse than mate in 3; both are 100%. Engines store mate as a sentinel near the top of their integer range, so a bare five-digit figure in a front-end is a mate flag leaking through as a number.

A negative mate score is the one to read. score mate -5 means you are being mated in five, and it is the most instructive line any shogi engine hands you, because it usually starts with a drop you never considered.

An engine mate is not a tsume. Tsume-shogi is a strict problem form: every attacking move must be a check, the defender resists as long as possible, and every piece in hand must be used. Xiangqi has the same form without pieces in hand, the consecutive-check mate (连将杀); here is how Xiangqiful checked 902 of them. An engine’s forced mate has none of those constraints. Nor is there any score for hisshi (必至), the brinkmate where mate is unavoidable next move but not yet forced by checks, and club games are decided in that gap constantly. The engine shows you a slightly worse number and never mentions that the game was over.

How much depth does a club player actually need?

I have argued the general case elsewhere: engine depth at club level should be tuned down, not up, because analysis deeper than a player can calculate produces lines that are correct and unteachable. Shogi strengthens that argument in two ways.

The first is cost. With roughly 80 to 90 legal moves in a typical position against chess’s 35, each extra ply in shogi costs more and buys less. A shogi “depth 20” and a chess “depth 20” can’t be compared, because no honest conversion exists.

The second is what the extra plies contain. In chess, deeper search mostly surfaces quiet positional moves whose payoff arrives ten moves later. In shogi it mostly surfaces longer drop sequences, such as five-move nets that start with a pawn dropped on an empty file to be promoted three moves later. A club player had no chance of finding those at the board and no chance of generalising from them afterwards. The mistakes that actually decided your game are visible far shallower: the hanging silver, the knight drop that would have forked king and rook, the reflexive promotion, the edge pawn that opened your mino castle.

So this post gives no ply number, unlike the chess post does for Stockfish. The right depth moves with the position, the hardware and how full the komadai are. Search deep enough to prove the mistake, then stop.

Where can I get a free shogi engine evaluation?

Lishogi is free, open source and excellent. It runs online play, gives you a server-side analysis that searches harder than any phone will, produces a shareable URL for the game, and, because it is open source, lets you read exactly what the analysis did instead of trusting a description of it. If what you want is the number, on a board you can send to someone, lishogi is the answer and it costs nothing. PiyoShogi is also a good free app, with an analysis function and finely graded opponents. The honest guide to shogi apps for iPhone covers the rest of the category, 81Dojo included.

What an evaluation doesn’t tell you

Once you can read the number, it still doesn’t tell you what to do. -980 is a verdict: you are losing, and roughly by how much. It does not say why, which of your last thirty moves caused it, or what to practise tomorrow. An evaluation graph with a cliff in it is a crime-scene photo with no detective.

Turning the verdict into a sentence is the whole job of a training app, and it is harder in shogi than in chess because the chess vocabulary does not carry over. A chess trainer has fork, pin, skewer, back-rank, discovered attack. Shogi needs categories that chess’s taxonomy lacks: the drop that would have forked, the promotion that cost you a retreat, the castle brick you removed yourself, the mating race you lost by one tempo. Shogiful builds its categories from scratch (missed drop tactic, wrong promotion decision, castle weakness, missed tsume, hanging piece, endgame error), turns each detected mistake into one or two sentences, and generates tomorrow’s training from whichever category keeps recurring. YaneuraOu’s NNUE network runs on the device, so there is no server, account or server-side rate limit. Free covers two full game analyses and three training puzzles a day. Premium is $1.99/month, $9.99/year, or $19.99 once, and it is the tier that raises engine depth and shows multiple candidate lines.

That design has a cost. Shogiful leads with the sentence and puts the number second, and it has no online human play at all, so if you wanted the eval graph itself, deep and shareable, lishogi does it better and for free. Chessful makes the same trade on the chess side with Stockfish, which is how I know it is a real trade and not a rationalisation: both apps give up the raw number as the headline in exchange for a sentence you can act on.

TL;DR

A shogi eval is not a centipawn, but the units are close enough to fool you. YaneuraOu anchors to a table where a pawn is about 90 against a centipawn’s 100, and shogi front-ends print the integer without dividing. Divide by roughly 90 to get pawns, then stop trusting the comparison: ten pawns is a decided chess game and an 82% shogi position.
The bands for a club player: under ±150 level, ±150-400 a small edge, ±400-900 a clear advantage, ±900-2000 winning if converted, beyond ±2000 decided. These are display conventions, and they move with the engine.
Every capture counts twice, because the piece goes to your hand. Winning a silver swings the number by about 990, eleven pawns’ worth. Promoted pieces revert when captured, so a tokin is a gold to its owner and a pawn to its taker.
In most positions a piece in hand beats the same piece on the board: it has no travel time, no positional commitment, and it threatens every weak square at once. This is most extreme for the lance and knight, which cannot turn around.
A mate score is categorical. Mate in 11 is worth exactly as much as mate in 3, and a negative mate score is the most instructive output a shogi engine produces. An engine mate is not the same as a tsume, and no engine reports hisshi at all.
More depth doesn’t make analysis more instructive. Shogi’s branching factor makes plies expensive, and what they buy are long drop sequences a club player could never have found. Search deep enough to prove the mistake, then stop.

How many steps a day should you aim for? What the large studies found, and how to pick a goal you'll keep

2026-06-20T00:00:00+00:00

Most adults get the bulk of the benefit the research can see somewhere between about 6,000 and 10,000 steps a day. Where exactly depends on age, and benefits start far lower than that. The 10,000 figure came from a slogan. Most of the numbers you read about steps come from the four studies below.

What did the large step studies find?

Study	Who was measured	What they found
Lee et al., JAMA Internal Medicine, 2019	16,741 US women, average age 72, followed for about 4 years	About 4,400 steps a day was linked to lower mortality than about 2,700. Risk kept falling with more steps until about 7,500 a day, then levelled off
Saint-Maurice et al., JAMA, 2020	4,840 US adults aged 40 and over, followed for about 10 years	Compared with 4,000 steps a day, 8,000 was linked to about half the risk of death from any cause (hazard ratio 0.49), and 12,000 to about a third (0.35)
Paluch et al., Lancet Public Health, 2022	47,471 adults pooled from 15 cohorts	Risk fell with more steps until about 6,000 to 8,000 a day in adults 60 and over, and 8,000 to 10,000 in adults under 60, then levelled off
Ding et al., Lancet Public Health, 2025	57 studies from 35 cohorts	Curves bent at around 5,000 to 7,000 steps for all-cause mortality, new cardiovascular disease, dementia and falls. 7,000 steps a day was linked to 47% lower all-cause mortality than 2,000

Two cautions apply to every row. All four are observational: people who walk more differ from people who don’t in ways no adjustment fully captures, and Ding’s team names residual confounding among their own limitations. And in the two US studies, steps were measured once, with a research device worn for about a week at the start, not tracked for years. The numbers show where the curve bends. They are no guarantee that a given dose produces an outcome.

They still agree on the shape: more steps go with lower risk, the steepest gains come early, and the curve flattens somewhere in the high thousands. Saint-Maurice’s study is the one that still saw lower risk at 12,000 than at 8,000; the pooled analyses mostly saw the flattening sooner.

Where did 10,000 steps come from?

It did not come from a study. In a 2004 review, Tudor-Locke and Bassett traced the figure to Japanese walking clubs and a business slogan from more than three decades earlier. They proposed rough bands for healthy adults that are still quoted:

Steps a day	Their label
Under 5,000	Sedentary
5,000 to 7,499	Low active
7,500 to 9,999	Somewhat active
10,000 or more	Active
Over 12,500	Highly active

The same review noted that 10,000 may not be sustainable for some groups, including older adults and people living with chronic disease, and pointed to goals set relative to a person’s own starting point as a promising alternative. Twenty-one years later, Ding’s meta-analysis landed in a similar place: 10,000 can still be a target for people who are already active, while 7,000 may be more realistic for many.

Does pace matter, or only the total?

Mostly the total. In Lee’s study and in Saint-Maurice’s, the measures of how fast people walked were linked to lower mortality at first, but once total steps were taken into account, most of those links were no longer clear. Paluch’s meta-analysis found one exception that held: the fastest 30 minutes of the day still showed a link after adjusting for the total, while time spent above 100 steps a minute did not.

For a sense of what brisk means, the CADENCE-Adults study measured treadmill walkers aged 21 to 40 and set 100 steps a minute as a practical threshold for moderate intensity and 130 for vigorous. Pace may add something, but get the daily total right first.

How long does each goal take?

At about 110 steps a minute, a brisk walk, here is how long each goal takes as a single continuous walk:

Daily goal	Continuous walking at 110 steps a minute	Where it sits in the research
4,000	about 35 minutes	Just under the roughly 4,400 that Lee linked to lower mortality than about 2,700 in older women
7,000	about 65 minutes	Ding’s comparison point: 47% lower all-cause mortality than 2,000
8,000	about 75 minutes	Inside Paluch’s flattening range for adults over 60; the bottom of it for under 60
10,000	about 90 minutes	The top of Paluch’s range for adults under 60
12,000	about 110 minutes	Still lower risk than 8,000 in Saint-Maurice’s US sample

Those minutes overstate the effort, because a daily total counts every step in the kitchen, the office, and the shop. The deliberate part is the gap between your goal and what an ordinary day already gives you. If you have a heart condition, an injury or another reason to be careful with exercise, ask a doctor before you tie anything to an activity target.

How do you pick a goal you’ll keep?

Find your baseline. The Steps chart in the Health app shows a daily average for the last week or month. Start from that number, whatever it is.
Set the goal one walk above it. A goal you reach without trying does nothing, and one you only reach on your best days locks you out most of the time. Aim for a number that an ordinary day reaches only if you add one deliberate walk.
Raise it when it gets easy. Moving up after a few weeks of hitting it costs little; starting too high usually ends in quitting.
Plan for the days that differ. A desk day and a Saturday rarely produce the same count, so it can make sense to give them different goals.

Step count is a weak number to read for health day to day; it moves with where your phone was and what kind of day it was (more on that). As a target it works better, because a daily total is exactly what these studies measured.

How EarnLock uses the number

EarnLock keeps the apps you choose shielded until you reach a daily activity goal, so the goal you pick decides whether it feels like a fair price or a wall. The argument for paying in movement is a separate post; this is how the goal itself works.

Three presets and a custom number. Onboarding offers Light (4,000 steps), Standard (8,000, selected by default) and Challenge (12,000), each with a walking-time estimate based on 110 steps a minute rounded to five minutes: about 35, 75 and 110 minutes. A custom number can be set later from the goal settings.
Steps, or Apple’s own activity measures. Steps is the free goal. Premium adds active minutes, which is Apple’s Exercise time, the green ring that Apple describes as minutes of brisk activity (presets 20, 30 and 45), and active energy (150, 300 and 500 kcal).
One total per day, from Apple Health. EarnLock asks HealthKit for today’s total since local midnight. HealthKit’s statistics queries merge data from all sources before adding it up, and Health ranks overlapping sources, so steps your iPhone and Apple Watch both counted aren’t counted twice. The Apple Watch app reads Health on the wrist, so the count is there on a walk without the phone.
The shield shows the gap. A blocked app shows how many steps are still needed. If the shield’s copy of your count is too old to trust, it asks you to open the app and shows no number.
The day resets at midnight. Reach the goal and the apps stay open until local midnight; then the count starts again from zero.
Raising is free; lowering waits. You can raise the goal at any time. Lowering it starts a 24-hour cooldown before it can be lowered again. Premium has an optional bypass, usable once every seven days.
Different goals for different days. Premium schedules can swap in Light, Standard or Challenge for chosen days and hours, which is the weekend-versus-desk-day point above.
A week to calibrate. For the first seven days nothing is blocked. EarnLock records how often the goal would have stopped you, so you can adjust before it starts to cost anything.

Some step apps sell screen time by the step; Steppin, for example, pays out minutes per hundred steps. EarnLock’s threshold asks for one daily total, which is the unit all of the studies above used.

If you don’t know where to start, take the Health app’s daily average, add a walk, and round to the nearest preset. Standard’s 8,000 sits where the pooled studies see the curve start to flatten for most adults. Light’s 4,000 is meant as a starting point for someone with a much lower baseline.

What actually belongs in your pet's medical record (and who asks for what)

2026-06-14T00:00:00+00:00

Ask ten owners where their dog’s vaccination record is and most will say some version of “the vet has it.” That is true, and it doesn’t help much. The vet has their record of their visits. It does not include the shot the shelter gave before you adopted, or the course of antibiotics from the emergency hospital on the far side of town, or the weight you took at home last month, or the microchip registry your pet was enrolled with by a rescue in another country.

The other common answer is the folder: a manila envelope in a kitchen drawer with fourteen pieces of paper in it, filed in the order they arrived. It is a real record, and it fails when it is needed, because emergencies do not happen at home.

First the reference: what a pet’s medical record is made of, and who asks for which part.

What belongs in a pet’s medical record?

Category	What to keep	Who asks for it	How often it changes
Vaccinations	Vaccine name, date given, date due, product and lot if printed, issuing vet	Kennels, groomers, daycare, a new vet, travel authorities, some landlords and insurers	One to three events a year
Parasite prevention	Flea and tick product, heartworm preventive, deworming: name, dose, dates	Your vet at the annual exam; kennels and groomers ask about fleas	Monthly for most products
Medications	Drug name, strength, dose, frequency, start and stop dates, prescriber	Every clinician, and most urgently an emergency vet who does not know your pet	Whenever treatment changes
Weight history	Dated weights, ideally including home weigh-ins	Every vet visit, since almost all drug dosing is by weight	Every visit, plus whenever you weigh at home
Allergies and adverse reactions	What the reaction was to, what happened, how it was treated	Every clinician. In an emergency this is the most useful line in the record	Rarely, and each entry is permanent
Microchip number and registry	The 9, 10 or 15-digit number, the registry holding it, your current contact details	Shelters and vets scanning a found animal, import authorities	Number never; your contact details every time you move
Surgeries and procedures	Procedure, date, surgeon, anaesthetic protocol and any complications	A new vet, a referral surgeon, an insurer	A handful of times in a life
Chronic conditions	Diagnosis, date, current management plan	Every clinician; emergency vets first	Slowly, but the plan changes often
Lab and imaging results	Bloodwork, urinalysis, radiograph and ultrasound reports, with dates	Any vet comparing today’s values to last year’s	Per test
Insurance policy and claims	Insurer, policy number, start date, exclusions, claim history	The insurer; the clinic if it bills directly	At renewal
Diet	Current food and brand, amount, feeding times, treats, known intolerances	Boarding facilities, sitters, and vets investigating weight or GI problems	Occasionally
Practice contact details	Your clinic, its after-hours emergency hospital, the local poison line	You, at 2am, when you cannot think straight	Rarely; verify once a year

Three of those are left out of almost every home record, and they cost you most when they’re missing. One is the adverse-reaction line, because nobody writes down the thing that went wrong two years ago. Another is the registry behind the microchip number, because the number alone is meaningless without knowing which database holds it. AAHA’s universal pet microchip lookup tool exists to answer that question, but it will not help if your contact details in that registry are three addresses out of date. The third is the after-hours hospital, which people tend to look up for the first time in the worst ten minutes of the year.

Which documents does each situation need?

Situation	What they ask for	Who issues it	Lead time
Routine visit, your own vet	Nothing on paper. Know the current weight, every medication and dose, and what has changed since last time	Not needed	None
Emergency or after-hours at a practice that is not yours	Current medications and doses, allergies and past reactions, chronic diagnoses, recent lab results, current weight, your vet’s name	You	None. It has to already exist
Boarding kennel	Proof of vaccination (typically rabies plus a distemper-adenovirus-parvovirus combination and usually Bordetella for dogs; rabies plus FVRCP for cats), flea and tick status, medications with written dosing, emergency contact	Your vet’s certificate	Days to weeks; many require the shot a set number of days before arrival
Groomer or daycare	Usually rabies proof; many also ask for Bordetella	Your vet	Often same-day
Transfer to a new vet	Full history: vaccination record, lab and imaging results, surgical and anaesthesia reports, current prescriptions	Your old clinic, on written request	A few days
Pet insurance claim	Itemised invoice, the clinical notes for that visit, and often a year or more of prior history to test pre-existing exclusions	The treating clinic	Days
Domestic travel	Airline and carrier policy, which commonly means a health certificate issued by a vet within a short window before travel	An accredited vet	Days; the carrier sets the window, so check the policy first
International travel	Set by the destination country: an official export health certificate, microchip, rabies vaccination in a prescribed order, sometimes a rabies antibody titre and a waiting period	Your government’s authority: USDA APHIS in the US, GOV.UK in Great Britain	Weeks to months

Take the international row seriously, and don’t take pet-travel rules from a blog post, including this one. The requirements depend on the pair of countries, they change, and if you get them wrong your animal can be refused at the border. Start at the government authority. The US also has separate rules for bringing a dog into the country, run by the CDC, which since August 2024 has required all imported dogs to be microchipped and at least six months old.

Core vs non-core vaccines

This section covers the categories only. Intervals are set by your veterinarian and, for rabies, by local law, which varies by country, state and municipality. Nothing here is veterinary advice. The week-by-week timing the guidelines describe for puppies and kittens is laid out in puppy and kitten vaccination schedules.

The category system comes from the WSAVA Vaccination Guidelines Group, which publishes global guidance, and from two regional bodies in the US: the AAHA canine vaccination guidelines for dogs and the 2020 AAHA/AAFP feline vaccination guidelines for cats.

	Dogs	Cats
Core	Distemper (CDV), adenovirus (CAV-2), parvovirus (CPV), usually combined as DAPP or DHPP, plus rabies where required by law, and leptospirosis for most US dogs under AAHA’s guidelines as updated in 2024	Panleukopenia (FPV), herpesvirus (FHV-1), calicivirus (FCV), combined as FVRCP, plus rabies where required by law, and FeLV for kittens
Non-core, by risk	Bordetella, canine influenza, Lyme, and regional options such as rattlesnake vaccine	FeLV for adult cats based on exposure, Chlamydia felis, Bordetella
Legally driven	Rabies, in most jurisdictions, with the interval fixed by statute instead of by your vet	Rabies, same

The “core” list changes over time. In a 2024 update to its 2022 canine guidelines, AAHA moved the leptospirosis vaccine to core for most dogs in the US, having previously classed it as non-core. AAHA’s own announcement is the primary source, and the classification applies to the US, not globally. Because of changes like this one, check the current guideline instead of trusting anything written on a fixed date, including this table.

Why does the paper folder fail?

It fails for two reasons. The obvious one is location. The folder lives at home; the emergency happens in a car park, on a walk, at a kennel, in a clinic you have never been to. A record you cannot reach is no use to anyone.

The second is structure, and it does more damage. A folder is append-only and unsorted. “When was the last lepto booster?” requires reading every sheet in it. “Has she ever reacted to a vaccine?” requires remembering that the reaction was written on the back of a discharge note from 2023. The paper is a pile of source documents. A vet wants the answer, in a form they can scan in seconds while doing four other things.

Photos of documents in a camera roll fail the same way. The information is there but hard to find, filed between thousands of unrelated pictures and a screenshot of a parking receipt.

What does a 20-second record require?

Here is the test. You are standing at a counter, someone in scrubs is waiting, and you have about twenty seconds before you start apologising. That test implies four constraints, and most apps fail at least one.

First, it has to work with no signal and no login. Veterinary waiting rooms are often concrete boxes with terrible reception, and what ruins the twenty seconds is a login screen followed by a password reset email you cannot receive.

Second, it has to produce one document. A single PDF with vaccinations, medications, weight, and history can be handed over, emailed ahead, or printed. Fourteen photos in a camera roll can’t.

Third, it has to answer the question directly. “Next due” is more useful than “here is the certificate.”

Fourth, it has to keep the original. A structured record that has lost its source document cannot settle a dispute with a kennel or an insurer. Keep both: the parsed fields and the scan they came from.

Pawza is our attempt at a record that meets all four. You photograph a vet document, Apple’s on-device Vision OCR reads the text, and, with Pro on devices with Apple Intelligence, an on-device model turns it into fields (vaccine, date given, date due, medication, dose, clinic), which you review and correct before anything is saved. It tracks weight as a trend over time, holds the microchip number, keeps the insurance policy and pet-passport documents alongside the clinical history, can schedule a local notification for each due date, and with Pro exports the whole file as one vet-visit PDF. There is no Pawza account and no Pawza server; records sit on the device in SwiftData with optional sync through your own iCloud. Our transparency page lists what every app declares, field by field.

It has limits. It is iPhone and iPad only, and the full AI auto-fill wants Apple Intelligence on iOS 26 or later; on older devices you get OCR-assisted entry and confirm more by hand. The PDF export is a Pro feature: free covers one pet, and Pro is $2.99/month, $19.99/year or $39.99 once with Family Sharing.

PetDesk does something Pawza cannot. It connects to participating veterinary clinics, so it can carry appointment booking and the reminders your clinic itself sends. Pawza never will, because a clinic integration needs a server to talk to and Pawza does not have one. If your vet uses PetDesk and you want to book through the app, use PetDesk. Plenty of owners run both: the clinic app for talking to the clinic, and a private record that survives switching vets.

The rest of the category splits along similar lines. 11pets is broader and cross-platform with provider collaboration. Medika and PetNoter both run on Android, which we do not. Pawprint, now Great Pet Care, built its reputation on fetching records directly from participating US clinics. VetKeep offers a conversational AI chat over your records, which requires the cloud that we deliberately do not have. Pick the trade you actually want.

TL;DR

A complete record has twelve categories: vaccinations, parasite prevention, medications, weight history, allergies and reactions, microchip plus registry, surgeries, chronic conditions, labs, insurance, diet, and clinic contacts.
Different people ask for different slices. Emergency vets want meds, allergies, weight and diagnoses. Kennels and groomers want proof of vaccination, often given a set number of days before arrival. Insurers want invoices plus prior history.
Core vs non-core is a risk category. WSAVA, AAHA and AAFP set the categories, and your vet and local rabies law set the intervals. The categories also move, as canine leptospirosis did in AAHA’s 2024 update to its canine guidelines.
International travel is governed by the destination country. You need an official export health certificate from your government’s authority; a summary you made yourself won’t count. Start months ahead.
The record that counts is the one you can produce in twenty seconds with no signal and no login, as one document, with the original scan still attached.

Shogi pieces in English: how to read the board without learning kanji

2026-06-11T00:00:00+00:00

A chess-playing friend gets curious about shogi (an anime, a YouTube clip, the strange fact that captured pieces come back fighting for the other side), installs an app, opens it, and stares at a 9×9 grid of identical wooden wedges covered in characters they cannot read. Then they close it. They never got as far as the rules.

The kanji on the pieces are the wall. So before the design story, here is every piece in English, with its character, its movement, and what it turns into.

The eight shogi pieces in English

Piece (English)	Kanji	Rōmaji	How it moves	Promotes to
King	王 / 玉	ōshō / gyokushō	One square in any direction	Cannot promote
Rook	飛	hisha	Any distance orthogonally (like a chess rook)	Dragon (龍): rook + one diagonal step
Bishop	角	kakugyō	Any distance diagonally (like a chess bishop)	Horse (馬): bishop + one orthogonal step
Gold general	金	kinshō	One square orthogonally, or one diagonally forward	Cannot promote
Silver general	銀	ginshō	One square straight forward, or one in any diagonal	+Silver (成銀): moves as a gold
Knight	桂	keima	Two forward + one to the side; forward only, jumps over pieces	+Knight (成桂): moves as a gold
Lance	香	kyōsha	Any distance straight forward only	+Lance (成香): moves as a gold
Pawn	歩	fuhyō	One square straight forward; captures straight, not diagonally	Tokin (と): moves as a gold

Eight base pieces, six of which promote, all sharing one silhouette: that makes fourteen distinct things to tell apart by character alone. Chess gives every piece its own shape, so “I’ll just learn the six shapes” works there and has no equivalent here.

How the pieces move, for a chess player

If you already play chess, the same few things will trip you up every time.

The gold general. It moves one step in any orthogonal direction plus the two forward diagonals: six squares, with no diagonal retreat. It matters far beyond its own movement because four other promoted pieces all become a gold: promoted silver, knight, lance, and pawn move identically to it. Learn the gold’s six-square step once and you have learned the endgame behaviour of half the board.

The silver general. One square straight forward, or one square in any diagonal, five squares in all. It can retreat diagonally but not straight back. Promote it and it gains a gold’s straight-back step but loses its diagonal retreats, which is the kind of trade you regret when you needed the silver to come home diagonally two moves later. (Ask me how I learned to double-check that.)

The knight and lance cannot turn around. The knight jumps to one of two squares, two ranks forward and one file to the side, leaping over anything in between, and only forward; there is no backward knight move in shogi. The lance is a rook stripped down to a single direction: straight ahead, any distance. Once either one advances, it does not come back.

The pawn captures straight. A shogi pawn moves one square forward and captures one square forward, never with the diagonal capture you have wired into your hands from chess. There is no two-square first move and no en passant. Shogi has the drop instead.

Drops. When you capture a piece it joins your hand, and you can later place it (drop it) onto any empty square as your whole move, where it fights for you. A piece changes sides several times in a normal game. Pieces always drop in their unpromoted state, and there are a few legal limits worth knowing: you can’t have two of your own unpromoted pawns on the same file (nifu), you can’t drop a pawn to deliver immediate checkmate (uchifuzume), and you can’t drop a piece where it would have no legal move (a pawn or lance on the last rank, a knight on the last two). Drops are also the reason a shogi engine’s evaluation swings harder than a chess engine’s.

Promotion itself is optional in the zone (the opponent’s back three ranks), except when a piece would otherwise be stuck with no move, in which case it must promote.

Reading and writing shogi moves in English

You do not need Japanese to read a recorded game either. English shogi notation is built straight from chess algebraic, with two conventions you’ll see in the wild.

Every piece is a letter: K king, R rook, B bishop, G gold, S silver, N knight, L lance, P pawn. A promoted piece gets a + in front (+R dragon, +B horse, +P tokin). A move is piece · connector · square, where the connector is - for a quiet move, x for a capture, and * for a drop from hand; a trailing + means you promoted on that move, = that you declined.

Squares are file then rank. Files run 1 to 9 right-to-left from Black’s side, and ranks run top to bottom. The two systems differ only in how they letter the rank:

Hodges (the standard in English shogi books, set by George Hodges in Shogi magazine in 1976) uses letters a to i for ranks: P-7f is a pawn to the 7th file, 6th rank.
Hosking uses numbers 1 to 9 for ranks instead, so the same square is 76 and the move is P-76. Hosking also writes drops with an apostrophe: S'45 where Hodges writes S*4e.

A few worked examples:

P-7f: pawn moves to 7f (a standard opening move).
S*4e: a silver, held in hand, dropped onto the empty square 4e.
Bx8h+: bishop captures on 8h and promotes to a horse.
S3ax2b: if you have seen the Hosking-numeric form S31x22, it is the identical move: a silver on file 3, rank 1 capturing on file 2, rank 2.

That’s the whole system: piece letter, what happened, where. (Full tables, including the rarer disambiguation marks, live on the Wikipedia shogi-notation page.) To see it in use, the beginner’s guide to shogi openings writes out two opening lines in this notation.

Why the characters are the barrier, and why I didn’t just translate them

Everything above is reference. The rest is the design story behind Shogiful, because “just use English pieces” turns out to hide three separate problems, and most internationalised sets solve only the first.

Why can’t shogi simply draw a knight as a horse the way chess does? Because the piece design carries the rules. All forty pieces are one shape and one colour, and ownership is shown by which way the wedge points, since that has to survive the drop rule: a captured piece joins your hand and comes back fighting for you. Fixed colours would show the wrong owner, and a wedge that turns around can’t. So the characters do all the identity work. 歩 is a pawn, 銀 a silver, 飛 a rook. Flip a piece on promotion and the character changes, usually to red, because promotion changes the piece’s state and keeps the piece. It is a compact system if you read the characters, and a field of identical wedges if you don’t.

A board you can actually read needs three things:

Identity: a distinct symbol per piece that you can read at a glance. This is the easy part, and where most sets stop.

Movement, which matters most. A newcomer doesn’t know that a lance only goes forward, that a knight has exactly two destination squares, or that a silver can’t step sideways. Shogiful’s Western icons carry a small movement diagram in the piece itself, so the icon teaches its own legal moves. That pays off most with the gold family, where promoted silver, knight, lance, and pawn all move alike, and the icons show the resemblance so you don’t memorise four separate facts.

Promotion state. Traditional sets flip to red characters. A Western set needs a change just as hard to miss, more than a tint, because “did that silver promote?” is the question you can’t afford to get wrong when you’re working out whether it can retreat.

Then there is the default. Shogiful shows the Western set outside Japanese locales, because a first-launch screen asking a brand-new player to choose between “traditional” and “Western” pieces asks for an informed decision before they’ve seen the board. The locale already answers the question, and the toggle in Settings is there for when they change their mind.

Learn the pieces first, the kanji second

There is a real trade-off: the wider shogi world runs on kanji. Books, problem collections, Japanese apps, real boards and every diagram on every shogi site use kanji. A player who stays on Western pieces forever has a ceiling on what they can read.

So the Western set is meant to be temporary. The piece guide is one tap from every game and shows both styles side by side, and training introduces the characters gradually. You meet 銀 after you already know how a silver behaves, which is much easier than learning symbol and behaviour at once. Nobody learns chess by memorising the letters K, Q, R, B, N before their first game, yet shogi outside Japan has effectively demanded the equivalent for decades and then wondered why the game doesn’t travel.

A board you can read on move one

The readable board is the front door. Behind it is the reason Shogiful exists: every game analysed on-device by YaneuraOu, the strongest open-source shogi engine, with mistakes explained in plain sentences (the missed knight-drop fork, the edge pawn that cracked your castle) and training generated from your own recurring errors. None of that coaching reaches a player who bounced off the board on day one, so every other feature depends on the piece set.

If you want ranked play against humans, the online platforms are the right tools, though the board there is all kanji, the problem this page is about. Lishogi (free, open-source), 81Dojo (the international dojo), and PiyoShogi (a fine free beginner app) are the usual starting points. For the full category, offline trainers included, see our guide to the best shogi apps for iPhone.

Shogiful itself is on the App Store for iPhone, iPad, and Mac. It is free to try, with the full coaching loop from $1.99/month or $19.99 once. The app page has the methodology, a comparison with the online platforms, and six worked examples of what a plain-language shogi mistake looks like.

How to estimate your one-rep max: Epley, Brzycki and five other formulas, worked through

2026-06-06T00:00:00+00:00

The short version: take a set you pushed close to failure and run it through one of these.

Epley: 1RM = weight × (1 + reps ÷ 30)

Brzycki: 1RM = weight × 36 ÷ (37 − reps)

A set of 100 kg for 5 comes out at 116.7 kg with Epley and 112.5 kg with Brzycki. Both are reasonable answers. The rest of this page is about why they differ, which set to feed them, and when a formula stops being worth asking.

Which formulas estimate a one-rep max?

These are the seven you will meet in most calculators and validation studies. In each, w is the weight lifted and r is the number of reps.

Formula	Equation	Original source
Epley	w × (1 + r/30)	Boyd Epley, Boyd Epley Workout (1985)
Brzycki	w × 36 / (37 − r)	Matt Brzycki, Journal of Physical Education, Recreation & Dance (1993)
Lander	100w / (101.3 − 2.67123r)	Jeff Lander, NSCA Journal (1985)
Lombardi	w × r^0.10	Vincent Lombardi, Beginning Weight Training (1989)
Mayhew et al.	100w / (52.2 + 41.9e^(−0.055r))	Mayhew and colleagues, Journal of Applied Sport Science Research (1992)
O’Conner et al.	w × (1 + 0.025r)	O’Conner, Simmons and O’Shea, Weight Training Today (1989)
Wathen	100w / (48.8 + 53.8e^(−0.075r))	Dan Wathen, in the NSCA’s Essentials of Strength Training and Conditioning (1994)

They look different, but most of them encode the same idea: each extra rep you can do with a weight means your max is a few percent higher than that weight. Brzycki’s paper puts the anchor plainly: about 10 reps at roughly 75 percent of a maximal load. Epley lands on the same point.

What does each formula say about the same set?

This is every formula applied to 100 kg. The formulas are proportional to the weight, so for 140 kg multiply a row by 1.4.

Reps at 100 kg	Epley	Brzycki	Lander	Lombardi	Mayhew	O’Conner	Wathen	Spread
3	110.0	105.9	107.2	111.6	114.0	107.5	109.0	8.1
5	116.7	112.5	113.7	117.5	119.0	112.5	116.6	6.5
8	126.7	124.1	125.1	123.1	126.3	120.0	127.7	7.7
10	133.3	133.3	134.1	125.9	130.9	125.0	134.7	9.7
12	140.0	144.0	144.4	128.2	135.4	130.0	141.5	16.2
15	150.0	163.6	163.3	131.1	141.7	137.5	150.9	32.5
20	166.7	211.8	208.9	134.9	151.2	150.0	164.5	76.8

From 3 to 10 reps, the spread between the highest and lowest estimate stays under 10 kg on a 100 kg set. Epley and Brzycki meet exactly at 10 reps; below 10, Epley reads a little higher.

Past 10, the curves split. Brzycki and Lander accelerate, because their denominators shrink toward zero as reps climb. Lombardi and O’Conner flatten out. By 20 reps the same set implies anything from 135 kg to 212 kg, which is not an estimate any more.

At one rep, most of the formulas don’t return the weight you lifted. Epley says a 100 kg single means a 103.3 kg max. The sensible reading is to take a single at face value.

Why do the estimates drift past about 10 reps?

The clearest evidence comes from Reynolds, Gordon and Robergs (2006), who had 70 adults aged 18 to 69 test their 1, 5, 10 and 20 rep maxes on the bench press and a plate-loaded leg press. The load people could lift fell off nonlinearly as reps rose, 5-rep-max data predicted the true max best, and the authors concluded that no more than 10 repetitions should be used in linear equations to estimate a 1RM.

The second reason is that the relationship between reps and load is not the same on every lift. In Shimano and colleagues’ 2006 study, trained and untrained men did more reps on the back squat than on the bench press or arm curl at 60 percent of their max. The gap shrank at 80 and 90 percent. A formula fitted on one lift and applied to another is borrowing someone else’s curve, and the borrowing gets worse the lighter the load.

The third reason is that a long set tests something different. Twenty reps is as much a test of how well you tolerate fatigue as of how much force you can produce once. Two lifters with the same single can have very different 20-rep maxes.

The last one is about you, not the maths. Every formula assumes the set ended at or very near failure. If your set of five stopped with three reps left in the tank, the formula treats it as a five-rep max when that weight was really closer to an eight-rep max, and the estimate reads low.

Which formula should you use?

Whichever one you will use every time. An estimated max is most useful as a trend line, and any of the mainstream formulas applied the same way to similar sets will show the same trend. Switching between them week to week manufactures progress or regression that never happened.

Some habits that keep the number honest:

Feed it sets of about 3 to 8 reps, taken close to failure. That is where the formulas agree most.
Compare like with like. A 5-rep estimate this month against a 5-rep estimate last month means more than a 5-rep estimate against a 10-rep one.
Use the heaviest working set of the session, not warm-ups or back-off sets.
Treat the estimate for a lift you rarely train heavy, like a lateral raise, as a curiosity.

The same formulas work in reverse, for choosing a working weight from a known max:

Reps	% of 1RM (Epley)	% of 1RM (Brzycki)
2	93.8	97.2
3	90.9	94.4
5	85.7	88.9
6	83.3	86.1
8	78.9	80.6
10	75.0	75.0
12	71.4	69.4

Read it as a starting point. Given the Shimano result, expect the squat to allow more reps at a given percentage than the bench press or an arm curl, especially at lighter loads.

When should you test a true single?

When the exact number is what you need. A powerlifting meet is the obvious case. So is a program whose percentages are built on a tested max, or the end of a peaking block, when you have tapered and are fresh enough for the number to mean something.

It is a poor idea when you are stalled and want reassurance, at the end of a hard training week, or when you are coming back from a layoff. A single tested tired tells you less than a good set of five tested fresh.

If you do test one, the usual shape is a gradual warm-up through progressively heavier sets of fewer reps, then a small number of heavy single attempts with generous rest between them. Use safety arms or a spotter on anything that can pin you. And if you are working around an injury or a condition that affects heavy loading, get advice from a clinician or a coach who can see you lift before you go looking for a max.

What GymLogger X uses

GymLogger X uses Epley everywhere an estimated 1RM appears: the strength trend for each exercise, the rep-max table, and the plateau rule, which watches that trend. I picked it for the reason in the section above. It is one of the mainstream formulas, it agrees with Brzycki at 10 reps, and it is simple enough that you can check the app’s arithmetic yourself. There is no setting to switch formulas, on purpose.

A few details follow from the reasoning in this post:

A logged single is its own 1RM. The app doesn’t run a single through the formula and hand you 103.3 kg for a 100 kg lift.
The rep-max table on each exercise shows your best weight at 1, 3, 5, 8, 10 and 12 reps. Slots come from sets you actually lifted where possible, and any slot the app had to estimate is labelled as an estimate.
Only a single you really did counts as an actual 1RM in that table. Until you log one, the 1RM slot shows an estimate, and the screen says so.

The plateau rule built on top of this is published in full on the app page, and the reasoning behind making the Apple Watch the logging surface is in the post on why GymLogger X exists. If you are still choosing an app, the guide to workout apps without a subscription compares the field by pricing model.

How much to tip in the US: every common situation, with the arithmetic

2026-05-30T00:00:00+00:00

If you are unsure how much to tip, you are in the majority. In a 2023 survey of 11,945 US adults by the Pew Research Center, only about a third said it was extremely or very easy to know whether to tip (34%) or how much (33%). And 72% said tipping is expected in more places than it was five years earlier.

The rules themselves are short. The table comes first, then the arithmetic for the cases where they get awkward.

How much to tip, by situation

The ranges are the Emily Post Institute’s, from its general tipping guide. The last column applies them to example bills.

Situation	Usual guidance	Worked example
Sit-down restaurant	15 to 20% of the bill before tax	$60 of food: $9 to $12
Buffet	10% before tax	$30: $3
Takeout	No obligation; 10% for curbside service or a large, complicated order	$45 order: $0, or $4.50
Food delivery	10 to 15% of the bill; $2 to $5 for pizza, by size and difficulty	$32 order: $3.20 to $4.80
Bartender	$1 to $2 per drink, or 15 to 20% of the tab	See the bar tab below
Tip jar	No obligation; tip now and then for extra effort, or if you are a regular	Your call
Taxi	15 to 20% of the fare, at least $1, plus $2 for the first bag and $1 for each one after	$38 fare, 2 bags: $8.70 to $10.60
Hair stylist	15 to 20%, shared among everyone who worked on you	$70 cut: $10.50 to $14
Hotel housekeeping	$2 to $5 per day, left daily	4 nights: $8 to $20
Valet	$2 to $5 when the car comes back
Bellhop	$2 for the first bag, $1 for each additional bag	3 bags: $4

The guide covers tip jars but not the tip screens now common at counters. A screen asks the same question as a jar, so the jar row is the closest guide.

Why the restaurant row is different

Under the federal Fair Labor Standards Act, an employer can pay a tipped worker a cash wage of $2.13 an hour and count up to $5.12 an hour of tips toward the $7.25 federal minimum wage, according to the Department of Labor’s Fact Sheet #15. Some states, including California, Oregon and Washington, require the full state minimum wage before tips, as the Department’s state-by-state table shows. Where the tip credit applies, the restaurant tip is counted toward the server’s wage itself.

What Americans actually tip

Pew asked how often people tip in different settings. The share who say they always or often tip:

Setting	Always or often tip
Sit-down restaurant	92%
Haircut	78%
Food delivery	76%
Drink at a bar	70%
Taxi or rideshare	61%
Buying coffee	25%
Fast casual restaurant	12%

The amounts sit lower than the etiquette range. A majority would tip 15% or less for an average meal at a sit-down restaurant, and only about a quarter would tip 20% or more. So guidance and habit overlap at 15%, and 20% is the top of the range for most people.

Pre-tax or post-tax? The arithmetic

The Emily Post guide calculates the restaurant tip on the bill before tax. If you tip on the after-tax total instead, the gap is always the tip rate times the tax.

Dinner for four, $148.00 of food, and a sales tax of 8% (an example rate; yours depends on where you eat): $11.84 of tax, $159.84 in total.

Tip	On $148.00 before tax	On $159.84 after tax	Difference
15%	$22.20	$23.98	$1.78
18%	$26.64	$28.77	$2.13
20%	$29.60	$31.97	$2.37

At an 18% tip and an 8% tax, tipping on the total adds 1.44% of the food bill: $2.13 here, about 53 cents a head. Neither choice is rude; it helps to pick one and use it every time.

The bill that already includes a tip

Some restaurants add an automatic gratuity, often for large parties, so read the bill before you reach for a percentage. Under the Fair Labor Standards Act a compulsory charge for service is not a tip (DOL Fact Sheet #15). The IRS lists a large dining party’s automatic gratuity as a service charge, because a tip has to be voluntary and its amount set by the customer (IRS fact sheet FS-2017-08).

Missing the line gets expensive. Take a party of eight with $420 of food and an 18% automatic gratuity of $75.60. Add a reflexive 20% ($84.00) on top and service has cost $159.60, or 38% of the food. You can still leave something extra for exceptional service, as long as you mean to.

The bar tab: per drink or percentage?

The bartender row offers two rules, and which one is more generous depends on the price of the drink.

Round	$1 a drink	$2 a drink	15 to 20% of the tab
6 beers at $7 ($42)	$6 (14%)	$12 (29%)	$6.30 to $8.40
6 cocktails at $15 ($90)	$6 (7%)	$12 (13%)	$13.50 to $18.00

The rules meet at about $10 a drink, where $1.50 to $2 is 15 to 20%. Below that, $2 a drink runs well above 20%. Above it, $1 a drink falls well under 15%, and the percentage is the rule to use.

When a group splits the tip

The tip follows the food. If everyone ordered about the same, divide the total with tip by the number of people. If not, give each person the same percentage on what they ordered: at 20%, a $16 salad carries $3.20 of tip and a $52 steak carries $10.40. The social side, who proposes what and when, is in how to split a Valentine’s dinner without making it weird.

Where RightSplit fits

RightSplit puts the tip on the same screen as the split. The tip control has four presets, 0%, 15%, 18% and 20%, and a slider from 0 to 30% in whole-percent steps. On an iPhone set to the US or Canada region, the first tip it suggests is 18%; in the UK it starts at 10% and in Japan at 0%. After that it remembers whatever you used last.

The free equal split applies the percentage to the total amount you type. Enter the after-tax total from the dinner above and choose 18%: $188.61, which Round fairly, on by default, splits as $47.16 for one person and $47.15 for the other three, so the shares add up to the cent. That is the post-tax tip, $2.13 more than the pre-tax version. If the bill already includes a service charge, the 0% preset is the one to tap.

In Pro+, item splitting gives each person the tip on what they ordered, and when a scanned receipt has tax and tip lines, RightSplit spreads both in proportion to each person’s items. There are no accounts; only the person holding the phone needs the app.

RightSplit won’t choose the percentage for you. It doesn’t know whether you are at a buffet or a steakhouse, so that part comes from the table above.

TL;DR

Sit-down restaurants: 15 to 20% of the bill before tax. Buffets 10%. Most Americans tell Pew they would leave 15% or less.
Delivery 10 to 15%, taxis and haircuts 15 to 20%, housekeeping $2 to $5 a day, valets $2 to $5. Takeout and tip jars carry no obligation.
Tipping after tax adds the tip rate times the tax: $2.13 on an 18% tip for $148 of food at 8% tax.
At the bar, $1 to $2 a drink and 15 to 20% meet at about $10 a drink. On pricier cocktails, use the percentage.
An automatic gratuity is a service charge under DOL and IRS rules. Read the bill before adding 20% on top.

The unlock cost has to live outside the app

2026-05-23T00:00:00+00:00

Every screen-time blocker on the App Store has the same secret. If you tap hard enough, it folds.

Open Opal mid-session and tap “I really need to use this.” Open one sec and wait the ten seconds. Open ScreenZen and dismiss the pause. Forest lets you give up a tree. Even Brick, which goes as far as shipping you a physical NFC tag, lets you unlock with the tag from across the room.

What these apps add is friction, which is different from blocking.

A blocker has a cost you cannot pay in the middle of a craving. Friction has a cost you can pay in two taps, and the design relies on the hope that you won’t.

App Store ratings are why every app in this category eventually adds a tap-through escape. The user sets up the blocker on a Sunday afternoon when they are calm and runs into it on a Thursday night when they are not. The Sunday version of the user wants a wall. The Thursday version wants a door. Whichever one drives the rating distribution ships in the next release.

So the apps end up with a door, and it gets easier to open with every version.

Where the cost has to live

If the cost of unlocking lives inside the app, the user can lower it. They wrote the PIN, set the timer, and picked the pause length. In the moment of craving none of these is an obstacle. They are notes left by an earlier self, and the current self has the credentials.

The cost has to live somewhere the craving cannot reach. There are two reasonable candidates: time and the body.

Time is already taken by the wait-out model that one sec and ScreenZen use. It doesn’t work, because waiting is itself a tap. The user puts the phone down, picks it back up, ten seconds have passed, and the lock is gone. They paid in attention, the same thing they were trying to protect in the first place, and the wait gives them nothing they benefit from later.

The body is the other candidate. If the unlock costs steps, active minutes, or active calories, the user cannot pay it from the couch. They have to go outside, get on the floor, or move around the room. What makes the design defensible, and more than merely strict, is that the user’s life also benefits from the payment. It is the only kind of unlock cost that is both real and useful.

That’s what EarnLock does. The blocked apps stay blocked until the user hits a daily activity goal measured in Apple Health: steps in the free tier, active minutes or active energy in Premium. The user picks the goal on a calm day, and the Thursday version of the user can’t renegotiate it because there is no tap-through.

Why the shield matters

A second design choice follows from the first.

By default, Apple’s Family Controls API renders a generic restriction screen over any app you block: This app has been restricted by Screen Time. It looks like a system prompt. It tells the user nothing about what is left, how it relates to the goal, or whether the cost is reachable.

EarnLock paints its own shield, with a circular progress ring, the current step count, and the exact number remaining: Earn 2,026 more steps to unlock. A user who tries to open Instagram isn’t told they are restricted. They’re told they are 2,026 steps from Instagram, which is a place they can walk to.

It’s a small detail with a big effect. A wall produces resentment, and a destination gets people moving. The shield is what turns the body-cost mechanic from a punishment into a price tag.

Where the failure modes live

Designing it this way has two real costs.

The first is that on some days the user won’t hit the goal and won’t see Instagram that day. The product has to make that survivable without making it easy to undermine. EarnLock includes one math-gated emergency unlock per day: solve a real arithmetic problem, get one unlock, then nothing until midnight. The math is hard enough that you cannot solve it mid-doomscroll without breaking concentration. That door is for genuine emergencies only.

The second is that streaks are dangerous in this category. If the app tells the user “you’ve blocked Instagram 47 days in a row,” they start protecting the number for its own sake, and then a sick day or a snowed-in day breaks the streak and they quit the whole thing. EarnLock ships a streak because users ask for it, but a single rest day per week protects the count, and no notification shames the user for missing a day. The streak can exist, but it can’t become the thing the user is actually optimising.

(I wrote a separate essay about why streak counters are a debt instrument. The short version: any time you ship a streak, you owe the user a rest mechanism, or you’re building a guilt loop under another name.)

The shadow week

One more piece deserves a name, because most blockers get it wrong on day one.

When a user installs a screen-time app, the app knows nothing about them yet: which apps they overuse, what time of day the urge spikes, or how much real time they would have spent if nothing blocked them. So it picks a default, usually generous and sometimes hostile, and the user leaves either because it is too strict or because it does nothing.

EarnLock starts in shadow mode for the first week. Nothing is blocked. The app watches which apps the user opens, when, and for how long. At the end of the week it shows a screen that says, in effect, here is what you would have lost, about 30 minutes a day and 23 separate block events this week, based on your own behaviour. Enable real blocking? The user decides with their own data and not with a stranger’s guess about a phone they’ve never seen.

I think this is the right default for any tool that proposes to change someone’s behaviour. In the first week the tool should earn the right to act, by showing it understands what is actually happening, before it acts on the user at all.

Why no account, no server, no SDK

The last piece is about structure.

A screen-time app sees more about a user’s habits than almost any other software they install: which apps they want to avoid, how often they try to break the rules, what time of day they fail, how long their attention lasts. By a wide margin it is the most psychologically intimate dataset a phone can produce, more intimate than location, messages, or the photo library.

The only safe thing to do with that data is to keep it on the device.

EarnLock has no account, no sign-up screen, no analytics SDK, no advertising SDK, no third-party SDKs of any kind, and no EarnLock server anywhere. HealthKit is read on-device only and never transmitted. Family Controls hands EarnLock opaque tokens, so even we cannot see which apps the user picked to block. Apple’s App Privacy nutrition label reads “Data Not Collected” for every release.

Any app that sits between a user and their own behaviour should work this way. No database should know the user tried to open Instagram 47 times last Tuesday, no server should know they missed their step goal for a week in February, and no account should tie any of it to an email address. The data is intimate, and the right response to that is restraint.

What this trades away

The cost of this design is reach.

A screen-time app with no account cannot sync state through a third-party backend. (EarnLock uses CloudKit through the user’s own Apple ID for the iPhone-to-Watch handoff, which is the only acceptable alternative.) Without an analytics SDK it cannot run growth experiments on cohorts of strangers. And with no tap-through escape it will get some one-star reviews from people who wanted a door.

I think those are the right costs to pay.

A screen-time blocker that can be talked out of blocking in the moment is decoration. One that ships behavioural data to a third-party server is a study you didn’t sign up for.

EarnLock takes both of those positions seriously. Free; Premium $1.99/month, $9.99/year (with a 7-day free trial), or $19.99 lifetime. Every paid tier (Monthly, Yearly, and Lifetime) is Family Sharing eligible.

If you can unlock it in two taps, it isn’t a blocker.

How the App Store keyword field works: 100 characters, commas, and the words Apple already indexes

2026-05-16T00:00:00+00:00

The keyword field in App Store Connect is a single line of text per localization, and nobody browsing the App Store ever reads it. Apple’s search guide says keywords “help determine where your app appears in search results.” Below are its rules in one place, each with its source.

What are the rules for the App Store keyword field?

Rule	What Apple says	Source
Length	100 characters total per localization (the reference page says 100 bytes)	Product page, Platform version information
Separator	Commas, no spaces. Spaces are allowed inside a phrase: Property,House,Real Estate	App Store search
Word length	Each keyword greater than two characters	Platform version information
Don’t repeat	Words already in your app name, subtitle or category; the reference adds your company name	App Store search, Platform version information
Plurals	Avoid plurals of words already included; “climbs” and “climb” count as duplicates	App Store search
Avoid	Generic terms such as “app” or “game”, filler words such as “the” and “to”, special characters such as # or @ unless they’re part of your brand	App Store search
Not allowed	Trademarked terms, celebrity names, competing app names, irrelevant or offensive terms	App Store search, product page
Scope	One field per localization; part of the app version’s metadata	Platform version information

Apple calls improper keyword use a common reason for App Store rejections, so the last two rows matter for review as well as for ranking.

How does App Store Connect count the 100 characters?

Everything in the field counts, letters, commas and spaces alike, which is why the no-spaces rule matters. Write the field the way people write lists, with a space after every comma, and ten terms cost you nine characters for nothing.

Apple’s own pages disagree on the unit. The product page and search guides say 100 characters; the App Store Connect reference says 100 bytes. The counter in the App Store Connect form follows neither exactly: it counts the way JavaScript measures text length, in UTF-16 code units. For English, the other Latin-script languages, Cyrillic, Greek, and almost all Chinese, Japanese and Korean characters, that is one unit per character, so the distinction never comes up. It does come up in scripts that write vowels as combining signs. The Hindi word किराना (grocery) reads as three syllables but is six units. A Hindi keyword field can look two-thirds full and already be at the limit, so trust the counter in App Store Connect over a text editor’s.

Which words are already indexed somewhere else?

Most wasted characters go on words like these, and Apple documents more of this than the folklore suggests.

Where the word appears	Searchable?	What Apple documents
App name	Yes	Named as text relevance (“title”) in the search guide
Subtitle	Yes	Named as text relevance in the search guide
Keyword field	Yes	Named as text relevance
Company (developer) name	Yes	App Store Connect help: your app is searchable by “app name, app subtitle, keywords, and your company name”
Primary and secondary category	Yes	“Your primary category and optional secondary category are indexed”
Promotional text	No	Apple says it “doesn’t affect your app’s search ranking”
Description	Not listed	Used for web search engine results after release; Apple asks you not to stuff it with keywords

The company name line comes from the FAQ on Apple’s view and edit app information page, and the reference page adds that you shouldn’t duplicate those values in the keyword list. So if your seller name is “Northwind Labs”, “northwind” is already working for you without costing a character.

A worked example: one wasted field, one fixed

A made-up app: Kestrel: Habit Tracker, subtitle Daily goals and routines, primary category Productivity. First draft of the English (U.S.) keywords, 94 characters:

habit tracker, habits, daily goals, routine, routines, app, streaks, reminders, best habit app

What those characters buy:

Term	Problem
habit tracker	Both words are already in the name
habits	Plural of a word already in the name
daily goals	Both words are already in the subtitle
routine, routines	Already in the subtitle, once as a plural
app	Generic word Apple tells you to skip
best habit app	Repeats habit and app; “best” is the only new word
8 spaces after commas	8 characters that do nothing

Out of 94 characters, the new words are streaks, reminders and best. The rewrite, 98 characters:

streak,reminder,checklist,planner,journal,mood,water,sleep,focus,discipline,self care,todo,morning

That is fourteen words, none of them in the name, subtitle or category, with no spaces after commas and one form of each word. It only works if the app really does track mood, water and sleep, because Apple’s rule against irrelevant terms applies to the rewrite too.

What does Apple not document? The ASO folklore

Plenty of keyword advice is reasonable and still unverified. These are the claims I see most, sorted by what Apple has written down.

Claim	Status
Apple combines words from the name, subtitle and keywords into phrases, so single words beat phrases	Folklore. Widely reported from testing, not in Apple’s documentation. Apple’s own example keeps “Real Estate” as a phrase.
Plural matching works the same in every language, including irregular plurals	Folklore. Apple’s example is English (climbs, climb) and it says nothing about other languages.
Words in the app name count for more than words in the keyword field	Folklore. Apple lists the fields it matches, not their weights.
Some storefronts also search your keywords from other localizations	Folklore. Apple’s localization table lists additional supported languages per storefront (the U.S. includes Spanish (Mexico), among others) but says nothing about search.
The description is indexed for App Store search	Not documented. Apple doesn’t name it as a search factor.
Competitor names in keywords work if nobody notices	Against the rules. Apple names competing app names as not allowed, and reviewers do notice.

Some of the folklore is probably right. Acting on it is still an experiment, so change one thing per version and watch the results.

How do localizations change the keyword field?

Each localization gets its own 100-character field. App Store Connect accepts metadata in 50 languages and locales now that Apple added eleven more in March, including Bangla, Tamil and Urdu. Write each one for its language. People search with their own words, and a literal translation of the English field often lands on terms nobody types.

The English variants are a good example. English (U.S.), English (U.K.), English (Canada) and English (Australia) are four localizations with four fields, and Apple’s table lists a different one as the default language in each of those storefronts. Spelling and vocabulary differ (color and colour, cell phone and mobile), so the U.S. field pasted into the other three still needs a pass for each.

When do keyword changes go live?

The keyword field sits in the version section of App Store Connect, beside the description, so an edit ships with your next approved version. There’s no way to change keywords alone on a live version. So plan a small keyword change for each release; a hurried rewrite has to wait for review like any other version. Apple also notes that metadata updates can take up to 24 hours to appear in every storefront.

Where AppMeta fits

I check every keyword field I ship in AppMeta, the Mac client for App Store Connect I wrote about in February. Its keyword checks run on the Mac against the metadata you’ve already entered, with no AI involved. They flag keyword words that already appear in the app name or subtitle, words repeated across keyword phrases, exact duplicate phrases, fields over 100 characters, and the same keywords copied across localizations of one language. That last check leans on the same storefront folklore as the table above, and the app’s Storefronts tab keeps Apple’s documented structure and the ASO heuristics in separate, labelled sections. It doesn’t detect plurals: “routine” and “routines” are two different words to it, so that one is still on you.

All the localizations sit side by side, so you can see the gaps without opening each one. If you want suggestions, AppMeta can ask an AI provider you choose, with your own key, or Apple Intelligence on the Mac.

Why Mac-native is the right architecture for App Store screenshots, and why it's so rare

2026-05-13T00:00:00+00:00

Looked at closely, the App Store screenshot tool category is a slightly absurd one.

Open the top three Google results for “App Store screenshot generator” and try the workflow. You drop your pre-release screenshots, which by definition are still under embargo, into someone else’s web browser. The browser uploads them to someone else’s servers. The rendering, the device framing, and the AI translation pass all happen on infrastructure the vendor owns. Then you download the finished files and upload them, by hand, to App Store Connect.

The workflow is perfectly normal. As an architecture it is odd for a tool whose entire input is content that hasn’t been announced yet. Once you notice that, you start to wonder why almost nobody builds the obvious alternative: a native Mac app that does the same job while every byte stays on your machine until you push it to Apple.

This post tries to answer both halves of that: why Mac-native is the better architecture in this category, and why almost nobody builds it anyway.

What “Mac-native” actually means here

Here “Mac-native” means a few specific things, all of which come from running the workflow in a real macOS app and not in a browser:

Rendering happens on your machine. When you place a screenshot inside a 3D iPhone frame, the geometry is rendered locally: your Mac’s GPU runs the Metal shaders that produce the final image. There is no upload, no remote render farm, and no waiting in someone else’s queue.
Files stay on disk. Your raw screenshots, your localised text, and your project files all sit in ~/Documents or wherever you put them. The screenshot tool reads and writes locally, and nothing leaves the machine unless you choose to push it.
AI translation calls your provider directly. When you ask the tool to translate “Track every workout in one tap” into Japanese, it makes the API call from your Mac to OpenAI / Anthropic / Google, using your API key and billed to your account. The screenshot tool’s vendor never sees the request.
App Store Connect authentication uses Keychain. When you push the finished screenshots to ASC, you authenticate via Apple’s official API. Your credentials live in Keychain, accessed by the app inside its sandbox, and not in a SaaS vendor’s database.

That is what “native” buys you. Nostalgia for desktop software has nothing to do with it. It is one specific property of the architecture: every byte of input, computation, and credential stays on your machine until you explicitly send it to Apple.

Why it’s the right architecture for this category

Several reasons, roughly in ascending order of how often they come up:

NDA exposure. This is the strongest case. If you’re shipping pre-release work for a client under a master services agreement, or pre-launch features for an embargoed announcement, “the screenshots passed through a third-party SaaS server” is almost certainly a contractual problem you don’t want. A vendor policy that says “we delete uploads after rendering” is still only a policy, and it sits on the wrong side of your trust boundary. With native rendering the question never comes up.

Deterministic re-renders. When the rendering happens on your machine with deterministic GPU shaders, re-rendering tomorrow produces byte-for-byte identical output. Web-based renderers often re-render with slight differences across releases: different fonts loaded by the browser, different colour spaces, different anti-aliasing. If you may need to re-render the same project six months later for a minor update, that determinism matters.

Speed. Local Metal rendering at 4K, with full 3D device geometry and lighting, takes milliseconds per screenshot. The same render through a remote service typically takes 1 to 10 seconds per screenshot once you count upload, queueing, render, and download. For a project producing 234 screenshots (6 device sizes × 39 locales), that is a 5-second render against a 5-minute one. The local version also doesn’t depend on the vendor’s servers staying up tonight.

Lower total cost. When the rendering happens locally, the natural pricing model is a one-time purchase. A Mac app distributed via the App Store has no server bills and can live comfortably on a $20 to $50 one-time price. A SaaS web app runs render farms 24/7 and pretty much needs a subscription. That is why Mockly is $12.99 once and most competitors are $19 to $49 per month.

No account or login required. There is simply nothing for an account to authenticate against. The app stores nothing server-side because there is no server, and you don’t need to recover your account when you change machines, because there isn’t one. Less friction and better privacy both follow from “the rendering happens here.”

So why doesn’t everyone build it this way?

Because the business model decides the architecture, not the other way round.

A SaaS subscription needs three things: a recurring infrastructure cost to justify the recurring price, lock-in to keep churn down, and costs that grow more slowly than revenue as users are added. The web architecture provides all three. The render farm is the recurring cost, the cloud project files you can’t take with you are the switching cost, and one more user costs about $0.10/month in compute.

The Mac-native architecture provides none of them. The render is on the user’s machine, so there’s no recurring infrastructure cost to recoup. The project files are on the user’s disk, so there’s no lock-in; if anything it runs the other way, since users can mail their projects around. And the marginal cost per user is zero, so there’s no incremental revenue per active user to chase.

So the Mac-native architecture is better for the user and worse for the vendor. That is the usual pattern for indie software, and it is why SaaS dominates the category even where SaaS is the wrong shape for the product.

The SaaS competitors aren’t doing anything wrong. AppLaunchpad, Screenshots.pro, Screenshot Studio, and the others are reasonable products built under a reasonable business constraint. They optimise for a different goal, and that goal pushes them toward an architecture where your pre-release screenshots end up on someone else’s server.

What Mockly actually does differently

Mockly is the Mac-native version. Specifically:

Metal rendering pipeline. Real 3D device geometry, GPU-accelerated and deterministic, so a project re-rendered tomorrow comes out bit-for-bit identical. The same renderer handles every device class from iPhone 6.9” (1290×2868) down to Apple Watch (410×502) and up to visionOS (3840×2160).
AI translation against your own API key. When you localise overlaid text into the 39 App Store locales, the translation calls go from your Mac directly to whichever model provider you configure: OpenAI, Anthropic, whatever. Mockly never sees the text. No Lagerland server is in the path, because there is no Lagerland server.
App Store Connect upload via Keychain. When you push the finished screenshots to ASC, you authenticate via Apple’s framework, and credentials live in Keychain. The upload goes straight to App Store Connect’s API, matched to each device and locale, with no manual browser uploads and no third party in between.
One-time $12.99. Family Sharing for up to six people. The architecture makes the low cost possible, and the low cost makes the one-time price possible.

The price follows from the architecture. Marketing didn’t set it.

A note on Fastlane

For many indie developers, the honest answer to “why use a GUI tool at all” is that Fastlane takes real work to set up. Fastlane snapshot + frameit is the de facto open-source standard for automated App Store screenshot generation, and for teams with mature CI/CD it’s the right answer. The setup curve is steep, though: Snapfile, Snapshfile, UI tests in Xcode that drive the screenshot states, then frameit to overlay device frames, then deliver to upload. First-time setup takes several days.

For solo developers and small teams, an hour of GUI-tool setup against a few days of Fastlane setup usually favours the GUI tool, especially if you ship new screenshots a few times a year. Mockly is a GUI alternative for those people; Fastlane is the right answer for teams that have already paid the setup cost.

TL;DR

Every credible App Store screenshot tool is web-based: you drop screenshots into a browser, they render on the vendor’s server, and you download the result.
For a workflow whose input is pre-release content under NDA, that’s a strange architecture, with a third party in the data path for no functional benefit.
Mac-native means rendering happens on your machine via Metal, AI translation calls your own provider directly, and App Store Connect auth lives in Keychain. Every byte stays local until you push to Apple.
Web apps dominate because the SaaS subscription business model only works if rendering happens on the vendor’s infrastructure. User preference has little to do with it.
Mac-native is better for the user and worse for the vendor, which is why it’s rare.
Mockly is the Mac-native version: $12.99 once, with no subscription, no server, and no account.

What 14 days of Apple Health data is enough to reveal, and what isn't

2026-05-13T00:00:00+00:00

Most people I talk to have an Apple Watch and a Health app holding two or more years of data they have never opened or queried, let alone learned anything from.

That’s not their fault. The Health app stores everything and interprets very little. It shows you yesterday’s resting heart rate. It does not tell you which of your habits keeps moving that number.

Observa is meant to do that interpreting. Before getting into how it works, though, there is a practical question I get asked more than any other.

How much data do you actually need before any of this matters?

It depends on the question you’re asking, and the answer falls into three tiers.

Tier 1: Two weeks for single-variable patterns

Two weeks of consistent wear is the floor. After about 14 days you have enough nights of sleep, morning HRV readings, and workouts to start seeing single-variable correlations: did this one habit consistently move this one metric? Insights at this stage look like this:

Days you trained legs after 18:00, your deep sleep averaged 18% below baseline.
Nights with screen time within 30 minutes of sleep onset showed −24% deep-sleep share.
Coffee logged after 14:00 correlated with +4 bpm resting heart rate the following morning.

Each one pairs a single cause with a single effect, backed by enough same-condition observations (n ≥ 10) and enough opposite-condition observations for a statistical comparison to mean something. Observa’s threshold is p ≤ 0.10. That is looser than academic research, which suits self-experimentation, where the cost of being wrong is “you try something else for two weeks.”

What 14 days can’t give you yet is anything multi-variable, seasonal, or dependent on training cycles. The data is real; the slice is too thin.

Tier 2: 60 days for multi-variable correlations

Around the 60-day mark, two things become possible. Your personal baseline (the rolling mean and standard deviation for each metric: HRV (SDNN), RHR, sleep efficiency, deep-sleep share, REM share) settles enough that deviations from it mean something. And you have enough non-overlapping weekly samples to run multi-variable analysis.

A multi-variable question is “did caffeine combined with screen time on the same evening affect my HRV more than either alone?” where a single-variable one is “did caffeine affect my HRV?” Most of the useful self-knowledge sits in compound patterns like that. A late workout alone may cost you 4% deep sleep, while a late workout plus a caffeinated afternoon may cost you 19%.

Sixty days also happens to be around two menstrual cycles, two training mesocycles, and enough weekly variation to capture how your body changes through ordinary life. Observa’s Pro multi-variable engine uses this window.

Tier 3: 90 to 365 days for trend analysis

At this range baseline drift becomes visible. Your resting heart rate is not a constant. It drops as you build aerobic fitness, drifts up during stressful periods, falls during taper weeks, and climbs through respiratory infections you don’t always notice. Tracking RHR week over week against last quarter shows you what “normal” looks like for your body. HRV works the same way: seasonal swings of 10 to 20% are common, and a common misreading is to take a winter dip as “I’m broken” when it only means “winter HRV runs lower.”

Ninety days is enough to see one full mesocycle of training adaptation. Six months shows seasonal swings. A year is enough to detect anything meaningful about how your physiology changes.

What no amount of Apple Health data can tell you

Causation. Consumer health apps routinely paper over this, and it matters a lot.

Correlation analysis can tell you that on days you train legs after 18:00, your deep sleep drops 18%. It cannot tell you that the workout caused the drop. Something you happen to do on the same days (caffeine timing, meeting load, stress, food choice, alcohol) may be the real cause. Statistical correlation alone never proves cause.

So use correlation insights as hypotheses worth testing, not as verdicts. If Observa flags “your sleep efficiency drops after late workouts” with high confidence, the useful response is to train earlier for two weeks and see whether your sleep efficiency improves. That is the only way to turn a correlation into something close to causal knowledge.

That is also why Observa shows the n (sample size) and confidence on every Pro insight. You should be able to judge for yourself whether to act on a pattern with n=14 at 87% confidence vs one with n=8 at 60%.

Why personal baselines matter more than recovery scores

Many consumer health apps compute a single daily score: WHOOP-style 0 to 100 recovery, an Apple-Watch-style “Mind & Body Hello”, Athlytic’s recovery percentage, a Bevel-style biological age. These work as summaries you can read at a glance. They are also opaque, and you can see very little of what’s moving them from day to day.

Observa never shows a single score. It always shows the underlying metric measured against your own 60-day baseline. “Your HRV (SDNN) is 18% below your personal 60-day baseline” tells you something specific. “Your recovery is 58/100” tells you something averaged, and when you ask “why?”, the score has no answer.

For the same reason, comparing your numbers to someone else’s is almost always a waste of time. Absolute HRV varies enormously by age, sex, fitness, measurement timing, and which wrist your watch is on. The comparison that tells you something is you, today, vs. you, on average, over the last two months. Everything else is noise.

A note on Apple Watch HRV specifically

Apple Watch measures HRV as SDNN (the standard deviation of successive heartbeat intervals), at variable times during the day and overnight and mostly when you’re still. Most sports-science tools use RMSSD instead. The absolute numbers are not directly comparable to chest-strap measurements or to numbers from a different watch. What you can compare is your watch’s reading of you over time, so track that SDNN reading against a 60-day mean and don’t hold your raw number up against a friend’s.

Apple Watch also captures ECG sinus-rhythm data on Series 4 and later, which adds real recovery signal when read in context. Sleep stage data (deep, REM, core, awake) comes from a combination of motion and heart rate variability. It is accurate enough for tracking trends and not accurate enough for clinical sleep staging.

Observa reads all of this from your Health app, computes a 60-day rolling baseline for every metric, and shows single-variable patterns on the free tier and multi-variable patterns on Pro. Everything runs on your device, with no upload, no account, and no servers. The aim is to make use of what Apple Health has been collecting for years.

TL;DR

14 days is enough for single-variable patterns: late workouts and deep sleep, caffeine and RHR, screen time and sleep latency.
60 days is the minimum for multi-variable correlations (training load × caffeine × sleep) and for a stable personal baseline.
90 to 365 days is needed for trend analysis: seasonal HRV swings, RHR drift, training adaptation curves.
Correlation is not causation. Treat every insight as a hypothesis worth testing for two weeks.
Compare yourself to your baseline, not to other people. Absolute HRV/RHR numbers vary enormously between bodies.

The data has been piling up in your Health app since you got the watch. What it lacked was something that could read it.

How to ship a localised App Store screenshot set in 39 languages without losing your weekend

2026-05-13T00:00:00+00:00

App Store Connect accepts screenshots in 39 locales. Almost every indie app ships in one, usually en-US, sometimes also Japanese or German. The gap between what’s possible and what gets done comes down to the manual workflow, which takes long enough to consume an entire weekend on the first attempt and an evening on every subsequent release.

This post is the workflow I’d recommend to any indie developer going from one locale to 39, with the upfront cost cut to about 90 minutes and the per-release cost to about 15 minutes. The manual workflow is expensive because most screenshot pipelines bake text into images, which makes the localisation pass O(n) in human hours. If you keep text as an editable overlay layer, the localisation pass becomes O(1) in human hours and O(n) in machine compute, which is a much better trade.

Why the manual workflow is so slow

If you’re doing this manually today, your time probably looks something like this for a release with 6 screenshots per device class across 4 device classes (iPhone 6.9”, 6.7”, iPad 13”, Mac):

Design pass: 1 to 2 hours to build the 6 base screenshots in Figma or your design tool of choice. This is the actual creative work, and the time is well spent.
Localisation prep: 1 to 3 hours getting feature copy translated. Either you wait for human translators (multi-day roundtrip), or you batch-paste into ChatGPT/Claude/DeepL and edit the worst output, or you’ve already invested in a translation memory tool.
Layout pass: This is the slow part. 6 screenshots × 39 locales = 234 unique layouts. If each takes 1 minute to render (in a fast workflow with text-as-layer) you get 4 hours. If each takes 5 minutes (baked-text workflow with per-locale edits and re-renders) you get 20 hours.
App Store Connect upload pass: The web UI is a per-locale, per-device-class form. You select a locale tab, drag in 6 files for iPhone 6.9”, wait for upload, switch to iPhone 6.7”, drag in 6 more, repeat for iPad and Mac, switch to the next locale, and do it all again. Plan for 2 to 4 hours of attention.

That’s 8 to 30 hours total per release, depending entirely on whether your screenshot pipeline keeps text as a layer or bakes it in. Every subsequent release that changes a single source screenshot or a single string repeats most of the pain.

That is why almost every indie app ships in one or two locales. Apple is right to want localised screenshots, and its requirements are reasonable; the consumer tooling makes the workflow so expensive that nobody actually does it.

The architecture that makes 39 locales cheap

Keep your text as a separate, editable overlay layer, and never bake it into the screenshot image. Once you adopt that constraint, everything downstream becomes mechanical.

What that means in each tool:

In Figma: the base screenshot is one component (a flat image layer). The feature copy is a separate Text node on top of it. To localise, you duplicate the frame and edit the Text node’s content; the base image stays referenced from the same source.
In Sketch: same pattern. Flat screenshot layer, text node on top. Localise the text node.
In Mockly: the architecture is built in. Every screenshot is a project with the raw capture as one layer, the device frame as a 3D rendered layer, and overlaid text as separate editable text elements. AI translation operates on the text elements only; the captured screen content is byte-identical across all 39 locales.

Once text is a layer, you can:

Run AI translation against all 39 locales in seconds rather than days.
Render each (locale × device size) combination from the same source in milliseconds rather than minutes.
Re-render the entire 234-screenshot bundle bit-for-bit identically when you change a single string.

That is how a release gets down to 15 minutes: the expensive parts (rendering, layout, upload) become mechanical compute instead of human labour.

The 90-minute first-release workflow

Assuming you’ve done the initial design pass already (the 1 to 2 hours of actual creative work) and you have base screenshots with text-as-layer:

Step 1 (15 min): Set up locale list. App Store Connect supports 39 locales; you don’t have to ship all of them. Pick the 5 to 10 that match your largest addressable markets. Most indie apps see meaningful conversion lift from English + Japanese + Simplified Chinese + German + Spanish + Korean. Expand from there as data justifies.

Step 2 (10 min): Configure your AI translation provider. OpenAI’s GPT-4, Anthropic’s Claude, and DeepL are the three I’d recommend in 2026. All produce App-Store-acceptable output with English/Japanese/Chinese/German source-target pairs. For RTL languages (Arabic, Hebrew), spot-check Claude or use a native speaker review pass for the first release.

Step 3 (5 min): Run translation. If you’re using Mockly: paste your base text strings, select target locales, click “Translate.” Output goes straight into the layered project per locale. If you’re using a manual workflow: paste each base string into the AI tool, get the 39-locale output, paste back into your design tool one locale at a time.

Step 4 (20 min): Render every (device × locale) combination. Mockly handles this with one button and ~50 milliseconds per render. A manual Figma workflow can be scripted with the Figma API but requires upfront setup; without scripting, this is the part where the 90-minute workflow stretches.

Step 5 (10 min): Spot-check the RTL languages and any high-stakes locale (typically Japanese, where the character density differs from English and overflow is common). Adjust text overlay sizes if anything looks off.

Step 6 (5 min): Upload via App Store Connect API. Mockly’s direct upload pipeline handles this; Fastlane deliver is the open-source alternative if you’ve invested in Fastlane setup. Either way, it takes ~3 minutes of compute for a full 234-screenshot bundle.

Total: about 65 minutes if everything goes smoothly, 90 if you hit one or two spot-check issues. After this, every subsequent release is 15 minutes because the architecture is in place.

What goes wrong, and how to avoid it

RTL languages need explicit handling. Arabic and Hebrew layouts flip: left-aligned overlay text should become right-aligned, and visual reading order may need to mirror. Tools that use Apple’s standard text-direction APIs handle this automatically; tools that don’t will produce broken-looking Arabic output. Always native-speaker-review the first Arabic release.

Japanese and Chinese character density is different. A 7-word English headline fits in a header band; the same headline in Japanese may be 3 characters wide, and in German may be 12 words long and overflow. Build the text overlay with auto-resize or explicit length budgets per locale instead of fixed pixel widths.

Sometimes the AI translation gets a domain term wrong. “Workout” in fitness context translates differently from “workout” in general fitness. Use a glossary or instruct the AI translation tool with brand-specific term mappings. For a fitness app: provide a 5-term glossary mapping reps / sets / RPE / etc. to native equivalents.

Don’t translate proper nouns. Your app name stays “Strava” in every locale. Some translation tools will helpfully render “Strava” into the target script (it shouldn’t); confirm proper-noun handling on first run.

App Store Connect rate limits matter for bulk upload. The Connect API has burst limits. Tools that respect them (Mockly’s pipeline, Fastlane deliver with proper config) upload cleanly; tools that hammer the API can get temporary backoff.

What the actual tools cost

The economics for 2026 indie pipelines:

Figma + manual translation + manual upload: Free (within Figma free plan). Time cost is the 10 to 30 hours described above. For an app shipping 3 releases per year that’s 30 to 90 hours per year, or half a developer-week.
Figma + AI translation (BYO API) + manual upload: ~$2 to $5 of API calls per release. Time cost drops to 4 to 10 hours.
Subscription SaaS (Screenshots.pro / AppLaunchpad Pro / Screenshot Studio): $19 to $49 per month, or $228 to $588 per year. Time cost drops to 1 to 3 hours per release.
Mockly (one-time $12.99): Time cost drops to 90 min first release, 15 min subsequent releases. AI translation against your own API key (~$0.50 to $2 per release at 2026 API prices).

The price of the tool is small next to the cost of the time. What matters most is which workflow architecture you adopt.

TL;DR

39-locale localisation manually costs 10 to 30 hours per release and most indie apps skip it entirely for this reason.
The fix is architectural: keep overlaid text as a separate editable layer in your design tool, and never bake it into the screenshot image.
Once text-as-layer is in place, AI translation runs in seconds, rendering in milliseconds, and the App Store Connect API bulk-uploads in minutes.
First release: 90 minutes. Subsequent releases: 15 minutes. The first hour of architecture work pays back many hours over each year of releases.
Watch for RTL handling (Arabic/Hebrew), character density differences (Japanese/Chinese/German), proper-noun preservation, and App Store Connect API rate limits.
Related reading: Why Mac-native is the right architecture for App Store screenshots explains why local rendering matters for the architecture above, and What every App Store Review Guidelines screenshot rule actually means covers the compliance side of the same pipeline.

Whether you can ship 39 locales comes down to whether your text layer is editable. Get that right and the rest is mechanical.

How Plan Mode builds a wedding (or trip, or pregnancy) checklist

2026-05-13T00:00:00+00:00

Most countdown apps stop at days because days are easy. Subtract one date from another and you get a number. You can render that number large, pin a photo behind it, and ship.

Soon. does that too. Plan Mode is the layer after the number, and it is what makes Soon. a planner: a checklist of what to do between now and the date, matched to the event type, scheduled backward from the date, and shown one task at a time.

This post is the design note for that engine: what it does, what it leaves out on purpose, and why.

Templates instead of generation

Every Plan Mode checklist is a template. There are templates for Trip, Wedding, Birthday, Pregnancy, Graduation, Move, Concert, and Anniversary, plus a blank Custom type for anything else.

The templates are written once, shipped in the app binary, and the same for every user. We chose that on purpose, and the choice needs some defending.

The alternative is generation: when an event is created, send the event type and date to a server (or an on-device LLM) and get back a personalised checklist. We considered it and decided against it for four reasons.

Generation requires data leaving the device. Even with a local model, the design pressure is to give the model more context so the output gets better, and the more context you collect, the weaker the privacy guarantee gets. Templates that ship in the binary cannot leak event details.
Generated checklists are inconsistent. A wedding template written once is the same checklist for every user, so two friends comparing notes start from the same baseline. A generated checklist might include the rehearsal dinner one time and skip it the next, or add a task that doesn’t exist. We optimise for stability.
Writing templates by hand is slow, and that helps. Writing a good wedding template forces a person to ask whether a task comes seventh or first. An LLM doesn’t ask that, and the slow part of writing is where the order gets fixed.
Templates can be audited. A user can read the entire wedding template before installing the app. Nothing is hidden behind it.

So every Plan Mode template is a list, written by a person, and the same for everyone.

T-minus, not T-plus

The second design decision is that tasks are anchored to T-minus offsets from the event date, not to calendar dates.

A Plan Mode template entry looks like this internally:

Trip · T-14 · “Buy travel adapter, check passport expiry”

When you create a trip event with a date of, say, August 12th, Plan Mode walks every entry in the template and computes its calendar day from the event date: T-14 becomes July 29th, T-3 becomes August 9th, T-1 becomes August 11th. Every task lands on its own day.

Offsets let the template work for any event date in any year. A trip in seven months and a trip in three weeks use the same template; only the dates the offsets land on change. It is also how people think about prep. You tell your photographer “two weeks before the wedding,” not “July 29th.”

The widgets benefit too. The Lock Screen, StandBy, and Home Screen widgets all show days to go, so T-minus is already the app’s native unit, and the planning layer uses the same one.

One notification per task

If you opt into event notifications (Premium), Soon. sends one notification per Plan Mode task, on the day that task is due. That means no daily notification and no single notification for the whole event.

For a trip 30 days out, the notifications across the month look like this:

T-30  Book flights
T-21  Reserve accommodation
T-14  Buy travel adapter, check passport expiry
T-10  Destination weather appears on widget
T-7   Refill any prescriptions
T-3   Pack (with weather-aware suggestions)
T-1   Charge devices, check-in opens

That’s seven notifications over a month, each one something you can act on the day it arrives. A generic countdown app would fire “30 days until your trip!” every morning for thirty mornings, which tells you nothing new.

The free tier of Soon. doesn’t notify at all. Plan Mode shows on the event card and the widget; notifications are a Premium addition for people who want to be prompted, where the free tier only shows the list.

What Plan Mode leaves out

It doesn’t restructure your checklist. If you hide a task, it stays hidden, and Soon. won’t re-add it next week. If you move a task from T-14 to T-21, that is where it stays.

It doesn’t share. Soon. is on-device only. Plan Mode checklists don’t sync between users, so two people planning the same wedding each install Soon. and create the event separately.

It doesn’t optimise. No algorithm watches which tasks you complete and reweights the template. The template you start with is the template you get, and any personalisation comes from your own edits.

It doesn’t track you. Soon. has no analytics SDK, no event-completion telemetry, and no feedback loop reporting whether a notification worked. We don’t know which tasks users check off, ignore, or reschedule, and we don’t want to.

We didn’t forget these features. We considered and prototyped each of them, then removed them.

The templates, in full

Every Plan Mode template is listed on the Soon. landing page: Trip (30-day), Wedding (90-day), Pregnancy (40-week), Birthday (14-day), Graduation (21-day), Move (45-day). Each is the exact task list you get when you create an event of that type, with the exact T-minus offsets that schedule the tasks.

The Pregnancy template counts in weeks (Week 28, Week 32, Week 35) because that’s how pregnancy is discussed, by clinicians and by everyone else. The Wedding template starts at T-90 because the slow prep (vendor confirmation, save-the-dates, dress fittings) begins earlier than for other events. The Trip template starts at T-30 because in practice most trips aren’t planned further ahead than that.

Those offsets are the author’s judgement, with no usage data behind them. If they’re wrong for your event, edit them.

Beyond Soon.

Most apps that try to do planning end up either (a) too generic to be useful, or (b) so configurable that they need setup work nobody wants to do. Templates per event type sit between the two: they ship with sensible defaults, can be edited, and don’t try to learn anything about you.

For a countdown app the engineering is light. A template is a list, and a T-minus offset is subtraction. The hard part is writing the lists well, which is a writing problem more than a technical one.

If you build planning features into a vertical app (workout, cooking, study, project), the same shape works: ship templates, anchor them to a meaningful zero such as the date, the deadline or the milestone, schedule backward, fire one prompt per task on its day, and stop there. Leave out the AI, the tracking and the auto-tuning, and ship the list.

Soon. is available on the App Store. It is free with 5 events, with no time limit; Premium unlocks weather intelligence, daily notes, recurring events, and one-task-per-day Plan Mode notifications. The full Plan Mode template gallery is on the Soon. landing page.

How Chessful turns a Stockfish evaluation into adaptive training

2026-05-13T00:00:00+00:00

When a chess app says “adaptive training,” it usually means one of two things: “we have a difficulty slider,” or “we have a recommendation algorithm over a fixed puzzle library.” Chessful does neither.

Chessful’s adaptive training adapts to your specific games. The session you get tomorrow is generated from the mistakes in the games you played yesterday. If you spent last weekend hanging back-rank defenders, this week’s queue drills back-rank defenders. If you finally stop doing that and start misjudging king-and-pawn endgames, the queue moves on to opposition technique.

This is the design note for how that works, organised around the five stages between “you played a game” and “tomorrow’s training session is ready,” in order. None of it is new computer science. It combines well-understood techniques (engine analysis, rule-based classification, spaced repetition), and most of the work went into the judgement calls that decide whether the feature works.

Stage 1: Stockfish on-device

At the end of every Chessful game, the position goes to a local Stockfish process on the same device. There is no cloud call. The engine’s depth is tuned to the device (deeper on Macs and recent iPads, shallower on older iPhones), and it produces a centipawn evaluation per move.

This part of the pipeline looks most like Chess.com, Lichess, and every other chess analyser. It’s a commodity. In Chessful, though, the centipawn output is the input to the next stage and not the thing the user gets. Other apps show a centipawn graph and call it “analysis,” and Chessful is structured specifically to avoid that.

On engine depth: it’s tempting to run the engine deeper to find more mistakes, and we decided against it. A 13-ply analysis finds the mistakes that matter for a club player rated 800 to 1800; a 25-ply analysis turns up lines that even good players can’t read. We want patterns the user can act on, and a show of engine strength doesn’t help with that.

Stage 2: Motif classification

This is where Chessful departs from other chess analysers. The centipawn evaluation goes through a layered motif classifier: hand-curated rule-based detectors plus a small on-device language model. The classifier takes a position where the user lost a significant amount of centipawn value and labels it with one of about thirty motif categories.

Some of the categories (the list isn’t complete):

Tactical motifs: hung piece, missed fork, missed pin, missed skewer, missed discovered attack, missed double attack, missed deflection, missed overload, back-rank threat, smothered mate possibility.
Defensive motifs: defender-removal blindness (the piece you captured with was the only defender of another of your pieces), king-safety underestimate, prophylactic skip, weakening pawn push without compensation.
Positional motifs: wrong piece traded (good bishop for a bad knight), wrong side castled, weak square allowed, wrong pawn break, time-on-the-clock-on-the-wrong-move.
Opening motifs: repertoire drift (you deviated from your usual opening setup), book-move missed, transposition into a known-bad line.
Endgame motifs: opposition direction error, king-too-late, wrong rook activation, drawn-but-played-on, wrong-color bishop endgame mistake.

Each significant mistake gets exactly one label, chosen by the strictest matching detector. The rules are ordered and the first match wins, so one position can’t be classified as five different things and dilute the training signal.

We use hand-curated rules instead of a learned classifier for two reasons. First, rules are auditable: if the trainer drills the wrong pattern, we can read the rule and fix it. A learned classifier for chess motifs would be opaque, and it would drift between app updates as the model gets retrained, so the user’s “improvement” might just be the algorithm changing what it counts as a mistake. Second, the chess motif catalogue is small enough to handle by hand. Roughly thirty mistake categories matter for club players. Encoding them as rules over the engine’s output is real engineering work, but the amount is bounded, and a trained classifier wouldn’t beat rules on a problem this constrained.

The small on-device language model works on the explanation layer. It turns the motif label and the engine evaluation into the one or two sentences the user reads, and it doesn’t do any classification.

Stage 3: Skill-bucket flagging

Each of the thirty or so motif categories maps to one of five skill dimensions: tactics, defense, positional play, openings, and endgames. When a mistake is classified, its skill bucket gets a flag. The flag holds the motif label, the position, the move you played, the move you should have played, and a plain-language explanation.

You can see the buckets in the app: how many tactical motifs were flagged this week, which ones they were (mostly missed forks? mostly back-rank threats?), and how the count compares with two weeks ago. Premium adds long-term trend graphs (90 / 180 / 365 days), so you can see whether, say, your defense flag count is really going down over a quarter or has levelled off.

Showing this matters because adaptive training only works if the user trusts the algorithm. If the next session drills “back-rank threats” and the user has no idea why, they lose interest. If they can see that the algorithm is drilling back-rank threats because they made the same mistake in three of their last five losses, they do the session, and the session works.

Stage 4: Spaced-repetition queue generation

Each training session pulls a set of positions from the flagged buckets, scheduled with spaced repetition.

Spaced repetition is the standard memory technique for pattern recognition. Anki popularised it for languages; SuperMemo formalised the underlying schedule decades ago. The mechanics are simple: positions you’ve seen recently come back sooner, positions you’ve solved correctly several times in a row drop out of rotation, and positions you got wrong recently come back fast.

It suits chess because chess pattern recognition is more a memory task than a calculation task. A 1600 player beats a 1400 player on the same tactical position mostly because the 1600 has seen the pattern often enough to recognise it within two seconds. Making the 1400 player see the pattern again and again at growing intervals is the right way to teach it. It’s dull, and it works.

Chessful uses a Leitner-style schedule (boxes 1 through 5, with intervals of roughly 1 day, 3 days, 7 days, 14 days, and 30 days). A newly flagged motif starts in box 1. A correct solve moves it up a box; a wrong one sends it back to box 1. After two correct solves in box 5 the motif leaves rotation, though it can come back if a new game flags the same motif again.

Free tier: three sessions per week. Three sessions cover the highest-priority bucket flags, but you have to choose. Premium gives unlimited sessions. Premium makes sense for players who are serious about improving; the free tier is real training for casual players.

Stage 5: Skill graphs and the feedback loop

After each session the graphs for each skill dimension update. The Free tier shows the current week and the previous week. Premium adds 90 / 180 / 365-day views.

The graphs exist for the feedback loop. If you’re three weeks into drilling defense motifs and the defense bucket count is still going up, the drills aren’t working and you need to try something else. Maybe the motif you keep missing isn’t a defense problem at all but a calculation problem that’s been misclassified. Maybe you’re tired and rushing the drills. Maybe you’re playing in time trouble, the motif is fine, and time management is what’s holding you back. The graphs let you answer those questions.

This part of the engine takes longest to pay off. Most users ignore the trend graphs until they’ve used the app for a month or two. After that, the graphs are what keep them training, because they can see the curve move, or see that it doesn’t, and react.

What adaptive training in Chessful doesn’t do

It doesn’t replace studying. Drilling motifs from your own games closes specific gaps, but you still need to work through an endgame book or a structured course on the Sicilian Dragon. Many improving players use Chessful alongside Magnus Trainer, Chessable, or printed books. Structured study and adaptive drilling on your real losses add up.
It doesn’t replace playing. The engine needs your games to work with. Chessful has 40 AI opponents to play against, but the training queue depends on having games to draw from. Three games is the minimum for useful training; at ten games the queue gets really specific.
It doesn’t replace live human play. Chessful has no live matchmaking and we aren’t planning to add it. Our view is that the improvement that happens between games has too few tools, while Chess.com and Lichess cover live play well. The two complement each other.
It isn’t personalised by an opaque AI. The motif categories and skill buckets are explicit, and the spaced-repetition schedule is well known. You can read what the trainer is doing and argue with it.

Why publish this

Most chess apps with adaptive training don’t say what the algorithm does. Usually it isn’t a trade secret. “Adaptive training” often just means “we picked a difficulty curve,” and saying so would deflate the marketing. By publishing ours we’re saying there is a real mechanism here, built on established techniques (Stockfish + rules + Leitner-style spaced repetition), and you can check over a month of your own games whether it works.

It’s also because we publish our algorithms by default at Lagerland. Plateau detection in GymLogger X is documented the same way. The pattern recognition rules in Observa are published. The Plan Mode template engine in Soon. is documented in a separate post. Across the catalogue, if the algorithm is the product, people should be able to read it.

Chessful is available on the App Store. The free tier includes 40 AI opponents, Stockfish analysis on every game, plain-language mistake summaries, and three training sessions per week. Premium unlocks unlimited deep analysis, unlimited adaptive training, full progress tracking with 90/180/365-day skill-trend graphs, and alternative-move exploration: $2.99/month, $17.99/year, or $29.99 once for lifetime access with a 7-day free trial. The companion design note on the forty AI opponents is Forty chess opponents, and none of them are me.

Why engine depth at club level should be tuned down, not up

2026-05-13T00:00:00+00:00

Every chess app advertises its engine depth. Chess.com’s Game Review runs Stockfish to depth 22. Lichess’s cloud analysis offers depth 28. Stockfish on a modern desktop will happily run depth 35 if you give it the time.

Chessful runs Stockfish considerably shallower than any of them. It doesn’t have to; it does it because, for the players Chessful is made for, deeper analysis makes the training worse.

Here is the argument. It’s a contrarian position in chess software, where “depth” is treated as a quality metric the way horsepower is in cars. Below roughly 2000 rating, engine depth above 15 ply produces lines that the user cannot read or apply. The lines are correct, and nobody at that level can learn from them. The mistakes that decide games at 800-1800 are visible at depth 10-15, and deeper analysis surfaces subtleties that crowd them out.

The choice has a measurable side effect: analysis runs fast on-device, which is what makes the iPhone, iPad, and Mac on-device promise possible. But the teaching reason came first.

What “engine depth” actually means

In chess engine terminology, depth is the number of half-moves (plies) the engine looks ahead. Depth 13 means the engine evaluates positions assuming both players will play their best moves for the next 13 ply (roughly 6 full moves for each side, give or take). Depth 25 means roughly 12 full moves of look-ahead.

Each additional ply expands the search tree by a factor of roughly 4-5 (the branching factor of chess after pruning). Going from depth 13 to depth 25 costs something like 10,000-50,000× more work, far more than double. Modern engines soften this with alpha-beta pruning, transposition tables and aggressive heuristics, but that cost growth is why cloud analysis exists at all: most depth-25 analyses are too expensive to run on a phone.

Chess.com and Lichess can offer depth 22-28 because they run the analysis in the cloud, on rented compute, and send back the result. The cost is the cloud round-trip, plus, in Chess.com’s case, a daily quota on the deep analyses.

Chessful runs Stockfish on-device, and its cost is the hardware: an iPhone has roughly 1/50th of the compute of a desktop, and deep analysis on a phone is slow enough to be unusable.

Most people stop reasoning here. The usual version goes: “Chessful runs shallower because it has to; Chess.com / Lichess run deeper because they can.” Put like that, deeper is better and Chessful is making the best of a hardware limitation.

That version is wrong, and the error matters, because it decides whether the training the app produces actually helps you improve. The real argument runs the other way.

What club players can read

Take a specific example. Imagine a position from a 1400 vs 1400 club game, move 18. The user has just played Bd3, intending to bolster the kingside. Stockfish evaluates this position.

At depth 12, Stockfish reports: eval -1.4. Best move: Qe2. Line: Qe2 Nf4 Bxf4 Qxf4 Rxe6. The line is five plies long, and the user can read it: queen to e2 defends, knight comes in, bishop trades, queen recaptures, rook lifts to take on e6. A five-move sequence is within calculation reach for a 1400 player. They can see why Qe2 was right (it stops Nf4 from being effective), play through the line on a board, and generalise it to “when the e-file is open and the queen is exposed, develop the queen toward the defence.”

At depth 22, Stockfish reports: eval -1.9. Best move: Re1. Line: Re1 Nf4 Bxf4 Qxf4 Re5 Qg4 h3 Qxd1+ Kh2 Qxa1 Re8+ Rxe8 Qxa1. The line is 13 plies long. It begins with a quiet rook move that pays off ten moves later as a queen trade. The 1400 player cannot read this line. They cannot calculate to move 13 in their head, and playing through it on a board won’t show them why Re1 beats the Qe2 line the depth-12 engine recommended.

Both engine recommendations are correct. The evaluations differ (-1.4 vs -1.9), but neither is wrong; each is Stockfish reading the position to its own horizon. What matters is which one teaches anything.

For the 1400 player, the depth-12 line teaches them something about defensive piece placement. The depth-22 line teaches them that the engine knows better than they do, which they already knew, and which gives them nothing to carry into the next game.

That is the central claim: at club level, engine depth beyond what the user can calculate is noise.

Why the noise actively harms training

Deeper analysis does more than fail to help. It crowds out the help that’s available.

Suppose the depth-22 analysis flags Re1 as the best move and rates the user’s Bd3 as a “blunder” (the eval difference is greater than the platform’s blunder threshold). Suppose the depth-12 analysis flags Qe2 as the best move and rates Bd3 as a “mistake” (a smaller eval drop, since the comparison is to a shorter calculation horizon).

The depth-12 verdict is the more useful one. Bd3 was a defensive misjudgement the user can recognise and drill: they missed the importance of getting the queen to e2 before letting Nf4 in. That’s a defender-placement motif, and it can be drilled and carried into the next game.

The depth-22 verdict is technically correct and produces no training. “You should have played Re1 for a 13-move forcing sequence” is not a lesson the player can absorb. It’s a fact about the position that changes nothing about how they play.

Train a player on depth-22 analyses and they learn to nod at engine output and accept that the engine sees further than they do. They don’t learn to find better moves themselves. The engine’s accuracy ends up replacing the development of their own calculation.

What the right depth is

For Chessful’s audience (800-1800 rating range), depth 12-15 is the band where:

The engine’s recommendations are short enough for a careful club player to calculate.
The mistakes the engine flags (hung pieces, missed tactics, defender-removal blindness, prophylactic skips, opposition errors) are the ones that decide games at this level.
The drills built from the analysis target patterns the player has a realistic chance of recognising in their next game.

At depth 13 specifically, Stockfish reliably finds:

All hung pieces (depth 2-3 is enough).
All one-move tactics (forks, pins, skewers): depth 3-5.
All two-move forcing sequences (most tactical combinations club players miss): depth 7-9.
Most three-move forcing sequences (the long end of a club player’s tactical horizon): depth 11-13.
Defensive misjudgements whose consequences show up within 3-5 plies: depth 10-13.

Depth 13 covers the whole calculation horizon of a typical club player’s actual games. Going deeper finds additional mistakes, and those are also mistakes the player cannot fix.

The balance shifts at the top of the club range. Around 1800-2000, players start to read longer engine lines reliably, and the right depth creeps up. By 2200, deeper analysis is genuinely useful. By 2400, players want depth 30+ because they can use it.

Chessful’s audience is below that band, and for them the mistakes live at depth 13-15.

Puzzle design uses the same idea in the other direction, with depth as the measure of what a player can use: in Millrace, every chapter is pinned to an exact shortest-solution depth, from five moves to ten or more, and the levels are generated and verified by search to guarantee it.

The hardware side effect

Running Stockfish at depth 13 on an iPhone is fast. A modern A-series chip produces the analysis in roughly 0.5-2 seconds per move on a typical middlegame position. A full 50-move game analyses in 30-90 seconds, comfortably inside the “I closed the app and reopened it and it’s done” budget.

Running Stockfish at depth 22 on the same phone is slow. The same game would take 5-20 minutes, the phone would be hot by the end, and the battery cost is real.

So the speed follows from the teaching choice. Chessful’s analysis is fast on-device because depth 13 is fast on-device. The on-device-only promise (no cloud, no daily quota, no account) is enabled by the depth choice, but the depth choice came first.

If depth 22 produced better training for club players, Chessful would run depth 22 and accept the slower analysis and the battery cost. It would probably also have to fall back to cloud analysis on older phones, which would weaken the privacy story. That didn’t happen because depth 22 doesn’t produce better training; the privacy story was never ranked above the training. The teaching choice and the privacy story happen to point the same way.

What deeper analysis is useful for

Deep engine analysis has real uses:

Players above 2000 rating, whose calculation horizons extend into the 6-12 ply range.
Opening preparation, where you want the objectively best moves in book positions you’ll see again.
Correspondence chess, where the time control lets the player actually work through engine lines.
Engine vs engine games, where the goal is engine accuracy, and human improvement doesn’t come into it.
Theoretical exploration, where the question is “what is the truth of this position” and not “what should this player do next.”

None of these apply to club-level improvement. That training aims to fix the patterns the player gets wrong in actual games, and those patterns are visible at depth 13. Deeper analysis adds patterns the player cannot act on.

The chess software industry settled on “more depth = better app” for two reasons. Depth is an easy metric to compete on (rent more cloud compute). And the most visible chess players, titled players, streamers and content creators, can use deeper analysis and praise it accordingly. The metric became a marketing claim before anyone asked whether it served the median user.

Chessful is betting that the median user is better served by training they can read.

Chessful is available on the App Store. The full training method, including how Stockfish output becomes motif classifications and spaced-repetition drills, is in How Chessful turns a Stockfish evaluation into adaptive training. The complete catalogue of the 30 mistake motifs the analyser flags is in The 30 chess mistake motifs Chessful detects.

Countdown psychology: why anticipation beats reminders

2026-05-13T00:00:00+00:00

Tourism researchers established something about fifteen years ago that the holiday-planning industry knows but rarely mentions: statistically, the happiest part of a vacation is the lead-up.

Jeroen Nawijn’s 2010 study “The holiday happiness curve: a preliminary investigation into mood during a holiday abroad” tracked holidaymakers’ mood across the whole trip, before, during, and after. The resulting chart is well known in the field. Happiness peaks in the pre-trip weeks, sometimes higher than during the trip and reliably higher than after. The post-trip dip is real, and so is the happiness mid-trip. But the most reliable and longest-lasting positive affect comes in the weeks of anticipation before departure.

The same holds outside holidays. Weddings, births, graduations, moves, long-planned reunions, big concerts, and retirement all have this emotional shape. The lead-up is a reward of its own, separate from the event and often longer-lasting.

Countdown apps are a way to collect that reward.

Below: what the research says about anticipation as a motivational and emotional state, why it works better than reminders for this kind of event, and what a countdown should do with the space it takes up on a phone’s Home Screen.

What the research says

George Loewenstein, an economist at Carnegie Mellon, formalised anticipatory utility in 1987 in a paper called “Anticipation and the Valuation of Delayed Consumption.” The setup was simple. Subjects chose when they would prefer to receive a defined future reward (in Loewenstein’s case, a kiss from a movie star of their choosing). Standard economic theory predicted everyone would pick “as soon as possible”, following delay discounting, the same logic that makes a dollar today worth more than a dollar in a year.

Loewenstein found that a significant fraction of subjects chose to delay the reward. They still wanted it; they also wanted to savour the anticipation. Looking forward to the kiss was a source of utility in its own right, and they were willing to pay for a longer anticipation phase with delayed gratification.

The finding has been replicated and extended in many domains:

Van Boven and Gilovich (2003) found that subjects who reflected on past experiential purchases (trips, concerts, dinners) felt more positive than those reflecting on material purchases (electronics, clothes). They proposed that experiences give utility in three phases, anticipation, consumption, and memory, and that anticipation is often the strongest of them.
Nawijn (2010, 2011) showed empirically that holidaymakers report higher subjective well-being in the lead-up to a trip than during or after it.
Sevdalis and Harvey (2007) found that anticipation effects hold even when participants are unsure whether the event will happen at all, a kind of pre-emptive enjoyment.
More recent positive psychology calls this prospection, the brain’s capacity to simulate future positive states, and counts it among the four pillars of well-being, alongside connection, meaning, and engagement.

So anticipation is a form of consumption in its own right, and the wait is part of the experience.

Why anticipation outperforms reminders

Reminders and countdowns look alike, since both put a future event on your phone, but they set up different psychological frames.

A reminder frames a future task as an obligation. The implicit verb is do: “remember to do this thing.” The feeling it carries is neutral at best and mildly unpleasant at worst. People often turn reminders off, ignore them, or dismiss them angrily, especially when there are many. A reminder is a debt.

A countdown frames a future event as a reward. The implicit verb is expect: “this thing is coming.” The feeling is positive. People keep countdowns in view, photograph them to send to friends, and screenshot them at milestones. A countdown is a savings account.

The same future event can arrive through either frame, and people respond to the two in measurably different ways. “Wedding in 30 days” in a generic reminder app reads as a low-grade panic prompt. “Wedding in 30 days” with a full-bleed photo of the venue, a Plan Mode checklist that handles the prep and a widget you glance at over morning coffee reads as something you’re glad about.

Reminders still have their place. They suit negative or neutral obligations: bills, recurring chores, appointments you have to keep whether you want to or not. A reminder is the right frame for the dentist.

Countdowns suit positive future events, where the lead-up is part of the reward. A reminder is the wrong frame for a honeymoon.

Most countdown apps fail because they are built like reminders. They make the number bigger, ship widgets, and add a theme picker, but they still treat the date as an obligation to manage. The photo is missing, the checklist is generic, and the notifications fire daily. Anticipation ends up feeling like work.

They should be designed for savouring.

What a good countdown does

It needs three things, listed here in priority order. Get any one of them wrong and the app stops working as a source of anticipation.

1. A sensory anchor

The countdown needs a photograph the user picked of the specific future: the venue, the beach, the maternity ward, the new apartment. A stock image or theme background doesn’t do the job. Anticipation runs on mental simulation, and simulation runs on sensory cues. “30 days until vacation” is abstract; “30 days until [photo of the actual hotel pool you booked]” is concrete.

So in this category the full-bleed photo background carries much of the emotional weight. Without it the countdown is a number. With it, each day becomes a small rehearsal of the event.

2. A sense of agency

The countdown needs a checklist that handles the prep, and it should know what kind of event this is and what the prep rhythm looks like. A generic to-do list won’t do.

The reason is anxiety. A bare countdown to a wedding often makes people slightly anxious: they know the date but not the path, and the distance between the two grows as the day approaches. A countdown that comes with a plan closes that distance. The number stops saying “you should be doing something” and starts saying where you are: “you are 21 days out, and here is what 21 days out looks like.”

The checklist also gives the anticipation a path. You cross off “send save-the-dates” and feel, fairly, that the wedding has partly started. Anticipation combined with progress keeps the good feeling going much longer than anticipation alone.

3. One notification per task, not one per day

Most of the time, a good countdown should stay quiet.

Countdown apps shaped like reminders all fail the same way, with a daily “X days to go!” notification. The first one feels good and the second one is fine. By the seventh, the user has turned off the app’s banners. One notification a day for 90 days gives you 90 notifications and one useful signal.

A good countdown notifies only on the day a Plan Mode task is due. T-30 has a “book transport” prompt, T-14 has “buy travel adapter, check passport expiry”, and T-7 has “refill prescriptions.” Over a trip month the user gets six or seven notifications, each one actionable on the day it arrives. The rest of the time the countdown sits on widgets (Home Screen, Lock Screen, StandBy), visible without interrupting.

Anticipation lasts when the event stays quietly in view, and interruptions wear it down.

What this means for product designers

If your product involves a positive future event, whether it’s a planning app, a booking app, a goal tracker, or a course-completion app, you are probably not using the countdown frame enough.

Some specific implications:

Anywhere you have a “deadline” or “due date” UI, ask whether the user wants a deadline frame or an anticipation frame. Course completion, fitness milestones, savings goals, and product launches are mostly positive events the user looks forward to, and the UI should treat them that way. A photo on a savings goal page (the apartment, the trip, the camera) does real emotional work in that feature.
Separate reminder-frame and countdown-frame events in the data layer. They need different defaults, notification cadences, and visual treatments. Mixing them in one “events” model produces a UI that pleases no one.
Limit notifications to task days by default. Most users will never change this setting themselves, so the default has to be quiet.
Treat the run-up as part of the product. The experience starts when the user creates the event. Design the 30-day or 90-day run-up as a feature, and don’t let it become a loading bar.

None of this is radical. It is what Loewenstein, Nawijn, Van Boven, and Gilovich’s findings look like when applied to product design, and it applies well beyond countdown apps.

How Soon. applies this

Soon. exists because none of the major countdown apps treat anticipation as the main thing they offer; they treat it as a number to display. Soon. is built around the three components above: the photo, the plan, and the notification rule. That follows from what the research says makes a countdown worth having.

Plan Mode, the part of Soon. that ships event-type templates and schedules tasks backward from the event date, provides the agency. The full-bleed photo background is the sensory anchor. The one-notification-per-task rule (Premium) keeps notifications down.

This post is mainly for anyone building products in this space: countdowns deserve to be taken seriously as support for looking forward to good events, more than as a novelty UI element. The research is decades old, and most products in the space still just display a number.

Few tools treat anticipation as the main experience, and there is room for many more. We expect the next generation of planning, productivity, and life-events apps to be built on this idea, and the psychology is the place to start.

Soon. is available on the App Store. Free for up to 5 events, with no time limit; Premium adds Apple WeatherKit destination forecasts, daily notes, recurring events, and one-task-per-day Plan Mode notifications. The full set of event-type templates (Trip, Wedding, Pregnancy, Birthday, Graduation, Move) is documented in How Plan Mode builds a checklist.

Why your Apple Watch HRV number means almost nothing without a baseline

2026-05-13T00:00:00+00:00

Apple Watch measures one of the most informative numbers in consumer physiology, and almost nobody uses it correctly.

Open the Health app and tap Heart Rate Variability. You’ll see a column of numbers from the last few weeks, probably some 25s, some 45s, some 80s, and a “Range” chart that looks vaguely informative. If you’ve fallen into the wrong corner of the internet, you may have read that HRV “should” be above 50ms or that anything below 30 is “concerning.” That is about as useful as being told your “normal” body temperature should be 99°F regardless of who you are. The number is real. The frame is wrong.

What HRV actually measures

HRV, or heart-rate variability, is the variation in time between consecutive heartbeats. Apple Watch reports SDNN, the standard deviation of the intervals between successive normal heartbeats (the NN, or RR, intervals), in milliseconds. Higher generally means more parasympathetic (“rest-and-digest”) nervous-system activity, and lower generally means more sympathetic (“fight-or-flight”) activity. A consistently higher trend correlates with cardiovascular fitness, recovery quality, and parasympathetic dominance.

So far, so good. The trouble starts when the same words apply to two people whose absolute numbers differ by a factor of three.

The variation between people is enormous

Absolute HRV in healthy adults ranges roughly from 15ms to 150ms in SDNN terms, a 10× spread. These factors move someone’s individual baseline:

Age. Most longitudinal studies find HRV declines roughly 0.5 to 1ms per year after age 30. A 45-year-old with 35ms HRV and a 25-year-old with 70ms may both be in perfect parasympathetic health for their age.
Sex. Average HRV is somewhat lower in adult women than men, though the variation within each sex is much larger than the difference between them.
Fitness level. Endurance-trained people routinely show 50 to 100% higher resting HRV than untrained people. That isn’t proportionally informative either: well-conditioned athletes often sit in ranges a generic chart would call “elevated.”
Body position. HRV is higher lying down than seated, and higher seated than standing.
Time of day. Higher overnight, lower during active hours.
Measurement method. Apple Watch’s optical PPG at variable times produces different numbers than a chest strap or a research-grade ECG, even on the same person at the same moment.

HRV is one of those biological metrics where yours is the only one that means anything. Comparing your 42ms to a friend’s 65ms tells you nothing.

The right frame: your own 60-day baseline

The only HRV readings you can reliably interpret look like one of these:

“Today’s HRV (SDNN) is X% above/below my own 7-day rolling average.”
“This week’s mean is X% above/below my own 60-day rolling average.”

Both compare you with yourself, which cancels out nearly every confounder above. Your age and sex don’t change in 60 days, your fitness doesn’t change dramatically, and your watch is the same watch. What does change is whatever moved your physiology this week compared with last quarter, and that’s the question worth asking.

Sixty days works as a baseline window for three reasons. It’s roughly two menstrual cycles, so cyclical variation averages out. It covers two typical training mesocycles, so short-term adaptation doesn’t dominate. And it gives enough non-overlapping weekly samples for a standard deviation to mean something; with fewer, the SD itself is noisy.

Observa uses this baseline window, and so do most peer-reviewed sports-science HRV studies, for the same reasons.

What a single low reading does and doesn’t mean

A morning where your HRV is 30% below your 7-day average means something happened: late food, alcohol, poor sleep, a stressful evening, the start of an illness, hard training the day before, or ordinary day-to-day biological noise. By itself it doesn’t tell you to rest, train hard, panic, or rejoice.

A pattern is diagnostic. Three consecutive days more than one standard deviation below baseline is signal. A single 25% drop after a known stressor tells you about that stressor, not your health. A 25% drop with no identifiable cause that hasn’t resolved within 72 hours warrants attention, from a clinician and not a consumer app.

For self-experimentation, I think this threshold is roughly right: at least 10 same-condition observations across a 60-day window, and at least one standard deviation of separation between conditions, before you treat a finding as anything but noise. Most consumer apps surface “insights” with far thinner statistical backing, which is mostly why those insights are mostly wrong.

Why HRV drops in winter (and other seasonal noise)

If you wear an Apple Watch through a northern-hemisphere winter, expect your HRV baseline to drop 10 to 20% from October to February. The usual causes are cold exposure, less daylight, less aerobic activity, more time indoors, and altered sleep. None of them is pathological, and all of them pull the number down.

Reading a winter dip as “I’m broken” is one of the most common interpretation mistakes. The correct reading is “winter HRV runs lower for me, and here’s the new baseline to measure deviations from.” The baseline is supposed to drift, because your physiology drifts with the world.

What this means in practice

A few practical rules follow from all this:

Never compare your number to anyone else’s. Not a friend’s, not a stranger’s on Reddit, not a “normal range” infographic. Compare yourself to yourself.
Track trends. A single day’s HRV is mostly noise. The 7-day rolling mean is signal, and the 60-day baseline is the frame that makes the signal interpretable.
Read it as a deviation from your own baseline. HRV is roughly log-normally distributed, so the same millisecond gap means more at a low baseline than a high one. Expressing today’s SDNN as a percentage deviation from your personal rolling mean is what makes it interpretable.
Identify your stressors. If your HRV consistently drops after late workouts, alcohol, or long screen time, you can act on that. The drop isn’t the problem; the unknown cause is.
Expect seasonal drift. Lower in winter and higher in summer is normal. A pandemic, an illness, life stress, or a new baby will all move the baseline too. Treat it as a moving frame of reference.

Observa does this automatically. It computes your 60-day rolling HRV (SDNN) baseline, scores each day’s reading against your own deviation, and tells you in plain English when something is genuinely outside your normal range and when it isn’t. Everything runs on-device, so the only comparison Observa ever makes is you, today, against you, on average, which is the only HRV comparison worth making.

TL;DR

Absolute HRV varies 3 to 10× between healthy adults. Comparing your number to anyone else’s is meaningless.
Your 60-day rolling baseline is the only frame that makes HRV usable. Day-to-day swings of 10 to 25% are normal.
Trends matter; single points don’t. Three consecutive days more than one SD below baseline is signal. One day is noise.
Winter HRV runs lower than summer. Seasonal drift is normal, and treating it as illness is the common error.
Read SDNN as a deviation from your own baseline. HRV is roughly log-normally distributed, so compare each day to your personal mean as a percentage, not to raw millisecond thresholds.

The number has always been in your Health app. What was missing is a baseline to read it against.

The 6 Apple Health metrics worth interpreting (and the 12 worth ignoring)

2026-05-13T00:00:00+00:00

Apple Health has become, almost by accident, the largest passively collected health dataset most people will ever own. The watch on your wrist measures more than 80 distinct signals across heart rate, activity, sleep, environmental exposure, mobility, and mindfulness, and most of them are noise.

That says less about Apple Health than about how consumer health apps display data they have no frame for. Using Apple Health well means knowing which numbers are worth tracking against a personal baseline, and which you can stop opening the app to check.

Below is the short list, with the reasoning for each cut.

The 6 that reward interpretation

With these metrics, consistent attention pays back in actual self-knowledge. Each has good signal-to-noise on weekly timescales, moves measurably with habits you control, and has a baseline stable enough that deviations mean something.

1. HRV (SDNN)

Heart-rate variability is the single most informative metric Apple Watch collects. The watch records it as SDNN, the standard deviation of the intervals between successive heartbeats. It folds autonomic nervous system state, recovery, training adaptation, alcohol load, sleep quality, and acute stress into one number, and it changes measurably within 24 to 48 hours of a habit shift.

The caveat is that it only means something against your own 60-day baseline, because absolute HRV (SDNN) varies wildly between people. See the dedicated post on why.

2. Resting heart rate (RHR)

RHR moves more slowly than HRV but is easier to interpret. Apple Watch reports an averaged RHR that smooths nicely over a week. It’s useful for spotting:

Aerobic fitness trends (drops of 5 to 10 bpm over 3 to 6 months of consistent cardio)
Pre-illness signals (a sustained 5 to 10 bpm above baseline often comes 24 to 48 hours before a cold)
Alcohol load (RHR routinely rises 5 to 15 bpm the morning after drinking)
Training overreaching (sustained elevation with no obvious cause)

Read it as a 7-day rolling average against your 60-day baseline, not as a daily number.

3. Sleep efficiency

This is the percentage of time in bed you’re actually asleep. Apple Watch sleep tracking is mediocre at staging but very good at total time. Sleep efficiency above 90% is excellent; if it’s consistently below 80%, that often points to wind-down issues, caffeine timing, or anxiety.

It holds up even after a short night, and it’s one of the easiest sleep numbers to act on: small wind-down changes typically move it 3 to 5 percentage points within two weeks.

This is the fraction of your night spent in slow-wave sleep. Apple Watch sleep staging is approximate, but the trend is reliable. Most physical recovery and memory consolidation happen in deep sleep, and alcohol, late workouts, late food, and bedroom temperature disrupt it more than any other stage.

What moves it, roughly in order of impact: alcohol within 3 hours of bed (20 to 40% less), a workout after 18:00 (10 to 20% less), a large late meal (10 to 15% less), a warm bedroom (5 to 15% less), and heavy screen exposure within 30 minutes of sleep onset (5 to 25% less).

5. Heart-rate dip during sleep

This is the percentage your heart rate drops from the daytime resting average to the overnight average. A dip of 15 to 25% is typical. Dips that stay below 10% can indicate poor sleep quality even when the headline “hours slept” looks fine.

AutoSleep popularised this metric and almost nobody else surfaces it, yet for many people it correlates more strongly with subjective recovery than total sleep duration does. Apple Health has the data; you have to compute it yourself or use an app that does.

6. Active energy (weekly)

Daily active calories are too noisy and too dependent on measurement accuracy. The weekly rolling total is one of the cleaner load metrics in Apple Health. Use it for:

Spotting training-load creep (week-over-week increases above 10% predict overuse injury risk)
Identifying recovery weeks (planned drops of 30 to 40%)
Long-term consistency, which is what moves cardiovascular fitness

Read it weekly, since the daily figure is mostly noise.

The 12 worth ignoring (or skimming at best)

These metrics look meaningful but mostly aren’t. Some are fine as adherence prompts and give you nothing to interpret. Others carry enough sensor error or definitional ambiguity that they cost more attention than they pay back.

7. Daily step count

Step count is a near-perfect proxy for “did you wear your watch today.” It depends on phone-in-pocket vs watch-on-wrist, on where you live (urban walkers vs suburban drivers), and on what counts as a step (treadmill desks generate phantom counts). 8,000 mostly deliberate steps beat 14,000 of urban drift, and the number can’t tell them apart.

8. Move ring closure

The ring prompts adherence and offers nothing to interpret. It helps you get started and stops being useful once the habit has stuck.

9. Stand hours

Apple’s algorithm credits one minute of standing per hour for 12 hours. It’s generously calibrated, easy to game, and doesn’t correlate with anything else.

10. Daily exercise minutes

Apple’s “exercise minute” counts any minute at brisk-walk heart rate or above. That’s adequate for tracking aerobic adherence and unreliable for strength training (little heart-rate elevation despite high muscular load), gentle yoga, or skill sports.

11. VO2 Max (estimated)

Useful, but it moves quarterly, and the day-to-day variation in the estimate is almost entirely noise. Check it monthly and leave it alone the rest of the time.

12. Cardio recovery

This is the 1-minute heart-rate recovery after exercise. Apple Watch’s calculation depends on whether you stop moving at the right moment. Even when it’s measured well, individual variation is high and the baseline shifts with fitness over months. It has uses in clinical contexts and is mostly noise in consumer use.

13. Daily resting energy

This is Apple’s estimate of your basal metabolic rate, derived from height, weight, age, and sex. It’s a formula, so it changes only when you update your profile.

14. Walking heart-rate average

A useful sanity check for fitness trends over 6+ months, and too noisy to read week over week.

15. Headphone audio exposure

Useful for protecting your hearing. Beyond a “turn it down” reminder there’s nothing to act on, and the only question it answers is whether the number is high or low.

16. Environmental sound exposure

The same applies here: good for protection, not for self-knowledge.

17. Mindful minutes

If you meditate, log it. The metric is a participation count, so there’s no signal-vs-noise question: you either meditated or you didn’t.

18. Daily flights climbed

A general activity number that depends heavily on whether you live in a building with stairs. There’s no frame for interpreting it.

How to tell the difference

To decide whether an Apple Health metric is worth interpreting, ask:

Does it have a 60-day baseline? Quarterly-moving metrics (VO2 Max, body weight) don’t.
Does it move measurably with habits you control? Step count doesn’t, really. HRV does.
Is the measurement error smaller than the signal you’re looking for? Sleep efficiency error is ~3 percentage points and its signal is 5 to 15 percentage points. Active calories error is ±20 to 30%, and the daily signal is often smaller than that.
Is the baseline stable across seasons and life events? If not, you’re tracking environmental noise.
Can you act on a deviation? If a 20% drop in the metric wouldn’t change anything you do, don’t track it.

Six metrics pass all five tests. About a dozen pass one or two. The rest are vanity numbers, adherence counts, or sensor data that looks like insight and isn’t.

What an interpretation app actually does

Most consumer health apps put 30+ metrics on a dashboard for product reasons, not scientific ones: more numbers look like more value. A useful interpretation app shows six because every extra number pulls attention toward noise.

Observa is built around the short list. It computes rolling 60-day baselines for the six metrics that reward attention, surfaces correlations between your habits and those metrics, and ignores the rest. Apple Health still collects step count, move-ring closure, and stand hours, but Observa gives them no dashboard tile and doesn’t make you stare at them.

For most people, getting self-knowledge out of Apple Health is less about tracking more and more about subtracting. The data has been collecting itself for years. The hard part is deciding which numbers deserve your weekly attention and politely ignoring the rest.

TL;DR

The 6 worth interpreting, each on a 60-day personal baseline:

HRV (SDNN): the single most informative number
Resting heart rate: signals illness and fitness trends
Sleep efficiency: the most actionable sleep metric
Deep-sleep share: what most habits actually move
Heart-rate dip during sleep: an under-used recovery signal
Active energy (weekly): a clean training-load measure

The 12 worth ignoring or skimming: step count, move ring, stand hours, daily exercise minutes, VO2 Max (weekly), cardio recovery, daily resting energy, walking heart rate, headphone exposure, sound exposure, mindful minutes, daily flights climbed.

The 60+ others Apple Health offers are probably not worth your weekly attention either, unless you’re a researcher with a specific question.

In short: pick six metrics, read them against sixty-day baselines, and treat everything else as noise.

App Store screenshot guidelines (2026): sizes, requirements, and what gets rejected

2026-05-13T00:00:00+00:00

App Store screenshots hold up apps for two unrelated reasons, and most guides only cover one. The first is technical: wrong size, wrong format, or a missing required device, and App Store Connect bounces the upload before a human sees it. The second is editorial. The screenshot uploads fine, a reviewer decides the screen isn’t showing the real app, and at 2 AM the night before launch you get the polite “your screenshots don’t appear to show actual functionality” rejection.

Below are the current specifications first, then a working developer’s read of Review Guideline §2.3.3: which patterns reliably pass and which get rejected.

App Store screenshot specifications (2026)

The biggest change: you only need one iPhone size now. Apple scales a single 6.9-inch (or 6.5-inch) set down to every smaller iPhone automatically, so you no longer export separate 6.7-inch, 6.5-inch, and 5.5-inch bundles.

iPhone, required (pick one):

Display	Portrait dimensions	Devices
6.9-inch	1320 × 2868 · 1290 × 2796 · 1260 × 2736	iPhone 17 / 16 Pro Max, Plus models
6.5-inch	1242 × 2688 · 1284 × 2778	iPhone 14 Plus, 13/12 Pro Max, XS Max

Provide one of those, and the 6.3-inch, 6.1-inch, 5.5-inch, 4.7-inch, and 4-inch versions are generated by scaling. You may still upload size-specific screenshots when you want pixel-perfect control on a given device; it just isn’t required anymore.

iPad, required if your app runs on iPad:

Display	Portrait dimensions	Devices
13-inch	2064 × 2752 · 2048 × 2732	iPad Pro (M4), iPad Air (M2/M3/M4)

The 11-inch and smaller iPad sizes scale from the 13-inch set.

Mac, required if your app runs on Mac: a 16:10 image at 1280 × 800, 1440 × 900, 2560 × 1600, or 2880 × 1800.

Count, format, and order:

1 to 10 screenshots per localization, per display size.
PNG or JPEG, RGB, flattened (no alpha/transparency), at the exact pixel dimensions above.
Only the first two to three appear in App Store search results without tapping in, so put your strongest screenshots first and treat the rest as extra detail.

Apple revises these as new hardware ships; the numbers above are current as of June 2026. Before any release, check them against Apple’s official screenshot specifications. The specs can’t protect you from the other half, which is content.

What §2.3.3 actually says

Apple has reworded §2.3.3 a few times since 2017, but the intent has stayed the same: a screenshot represents the app a user will receive. That means the actual app in actual use, and excludes a future version, a concept, or a marketing illustration of what you wish the app did.

The boundaries:

What’s allowed: Overlaid feature copy on top of a screen capture. Colored background fields around the device. Gradient or photographic backgrounds. 3D device frames. Decorative typographic emphasis. Multiple screenshots in a sequence telling a story.
What gets rejected: Fictional UI that isn’t in the app. Features that haven’t shipped yet. Pure marketing illustration with no real screen content. Screenshots whose UI was Photoshopped after capture to look prettier than the app does.

In plain language: the content inside the device screen must be the real app. Everything around the device frame is decorative styling and mostly up to you.

The five rejection patterns I’ve seen most often

1. The “future-build” screenshot. The most common one. A marketing team shipped a previous version’s UI in the screenshot bundle, or used a Figma concept that hasn’t been built yet. The reviewer downloads the app, can’t find the feature, and rejects it. Re-render screenshots from the build you’re submitting, every time.

2. The “concept-art” screenshot. Especially common in apps with heavy graphics: games, drawing apps, AR apps. The screenshot looks more like a website hero shot than an in-app capture, and the reviewer reads it as misleading. The fix is to find a moment in the app that looks like the hero shot and capture that.

3. The “deleted-feature” screenshot. A feature existed in version 2.4 and was removed in 2.7, but the 2.4 screenshots are still uploaded for 2.7. Re-uploading old screenshots is an easy way to inherit a rejection from your own past.

4. The “in-app-purchase price mismatch.” The screenshot says “$0.99, limited time” and the App Store listing says $4.99. The reviewer flags the inconsistency. Either show real IAP prices that match the listing, or leave prices out of screenshots altogether.

5. The “fictional metric” screenshot. Common in fitness, finance, and analytics apps. The screenshot shows “247,891 active users this month” or “+42% sleep score”, but the demo data in today’s shipping app shows different numbers. The reviewer treats this as misrepresentation.

App Preview videos: specs and the same content rule

App Preview videos have their own specifications, and §2.3.3 applies to them as well.

Up to 3 previews per localization, each 15 to 30 seconds.
iPhone: 886 × 1920 portrait (886 covers 6.9-inch through 6.1-inch). iPad: 1200 × 1600.
Formats: .mov, .m4v, or .mp4: H.264 at roughly 10 to 12 Mbps or ProRes 422 (HQ), 30 fps, AAC audio.

The content rule is enforced strictly here. The video must be actual app footage captured from a device. A screen-recorded mockup, an animated concept reel, or camera footage of someone holding a phone will not pass. Apple checks this closely, especially for new apps.

How to make your screenshot pipeline §2.3.3-safe

Capture from a build, not a design tool. Use Simulator, Xcode UI tests, or manual capture from a TestFlight build to produce the raw screen content. If it didn’t come from a running build, it doesn’t belong inside the device frame.
Re-capture for every release. Reusing screenshots after minor UI changes is tempting, and each time you do it you risk a rejection over a feature that disappeared without anyone noticing.
Strip IAP prices unless you’re certain. If the prices are dynamic, regional, or change with promotions, leave them out of screenshots entirely and show what the features do.
If you do show metrics, match the demo state of the shipping build. Use the same fixture data your TestFlight build uses. Don’t render “247K users” if the demo state shows “1.2K.”
Treat the device frame as cosmetics. Pick whatever visual style fits your brand: 3D Metal render, flat outline, tilted angle, transparent background, or no frame at all. Reviewers don’t care about the frame, only about what’s on the screen inside it.

A capture-first tool like Mockly complies with §2.3.3 by default because its workflow runs in the safe order: capture the real screen first, render the device frame around it second. The screen content is your actual app, and the frame is a render placed around it. The reverse workflow (mock up a concept screen in Figma, drop it into a phone outline, export) is the one most likely to drift into rejection territory, because it invites you to design screens the app doesn’t have yet.

TL;DR

One iPhone size now. 6.9-inch (1320 × 2868 / 1290 × 2796) or 6.5-inch (1242 × 2688); Apple scales it to smaller iPhones. iPad apps add 13-inch (2064 × 2752).
1 to 10 screenshots per localization, PNG or JPEG, flattened. The first 2 or 3 show in search, so put the best ones first.
§2.3.3 covers the screen content and ignores the device frame. Overlay text, backgrounds, and 3D frames are fine.
The screen must be the real shipping app. Concept art, future-build UI, deleted features, fake metrics, and mismatched IAP prices are the common rejection paths.
App Previews: up to 3, 15 to 30 seconds, 886 × 1920 on iPhone, with the same “real footage only” rule.
Capture-first workflows pass cleanly; design-first workflows tend to drift.

For the surrounding workflow, see the native screenshot tooling argument, shipping screenshots in 39 languages, and the rest of the indie iOS developer tools. The specs change with each new device, while the intent of §2.3.3 has held for nearly a decade. The rejection emails keep arriving because most indie pipelines treat compliance as an afterthought.

The 30 chess mistake motifs Chessful detects (and why each one matters)

2026-05-13T00:00:00+00:00

After the earlier post, How Chessful turns a Stockfish evaluation into adaptive training, went up, the most common follow-up question was simple: what are the motif categories?

That post described the pipeline and left the catalogue as a black box of “about thirty categories.” Here is the full current taxonomy, organised under the five skill dimensions Chessful tracks, with the structural cause of each motif and the drill that fixes it.

The taxonomy isn’t proprietary. Most of these categories are standard chess teaching, covered in Aagaard’s Excelling at Chess series, Yusupov’s nine-volume Build Up Your Chess curriculum, Silman’s How to Reassess Your Chess, and de la Maza’s Rapid Chess Improvement. A few (repertoire drift, book-move missed, time-on-wrong-move) are things an analyser with your full game history can see and a coach reviewing one game can’t. The rest is standard improvement material under a name a club player can remember during the next game.

We publish the catalogue because you can only argue with an algorithm if you know what it is looking for. Without the list, you can’t tell whether Chessful’s classifier flagged the right thing in your game. With it, you can check.

Skill dimension 1: Tactics (10 motifs)

In a tactical motif the mistake was a failure of calculation or pattern recognition in a forcing sequence. These are usually the easiest to act on: they drill well, you learn to spot them quickly, and they come up again in every opening.

1. Hung piece

The classic. You moved a piece (or left one) on a square where it can be taken for nothing, or for less than it’s worth. Drilling pattern: a piece-safety scan of the position before you commit to a move.

2. Missed fork

An enemy piece (often a knight) could reach a square that attacks two of your pieces at once and wins material. Drilling pattern: knight-radius blindness, meaning learning to see where an opposing knight could land next, especially around the king.

3. Missed pin

You moved a piece so that another piece behind it could no longer move (or would be unprotected if it did). Drilling pattern: awareness of files and diagonals around long-range pieces (bishops, rooks, queens).

4. Missed skewer

A piece attacked a more valuable piece in front, forced it to move, and took the less valuable piece behind. Drilling pattern: noticing when pieces line up, particularly rooks on the back rank and queens on a shared diagonal.

5. Missed discovered attack

A piece moved out of the way and uncovered an attack by the piece behind it, often with check. Drilling pattern: x-ray vision through your own pieces.

6. Missed double attack

One move that attacks two separate enemy pieces or squares, not necessarily a fork. Drilling pattern: spotting two threats at once.

7. Missed deflection

A piece needed to be lured off a critical defensive square, and the deflecting move was there but wasn’t played. Drilling pattern: finding which enemy piece is over-loaded (defending several squares) and the move that exploits it.

8. Missed overload

A defending piece had too many jobs, and a single attack forced it to choose and won material. Drilling pattern: counting attackers and defenders on every critical square before you commit.

9. Back-rank threat

Your own pieces blocked your king’s escape squares, and a back-rank mate was available but not seen (in either direction). Drilling pattern: prophylactic h-pawn pushes and recognising rook-plus-back-rank shapes.

10. Smothered mate possibility

A knight on f7 / f2 (or similar) gives mate when the king’s own pieces block its escape squares. It’s less common, but when it appears it usually decides the game.

Skill dimension 2: Defense (5 motifs)

Club players train defense less than anything else. Generic puzzle apps drill attacking tactics, while failing to recognise defensive problems is what costs games in the 1200 to 1800 range.

11. Defender-removal blindness

The piece you just moved was the only defender of a critical square (often on the back rank, often next to the king). Drilling pattern: before any capture or trade, check whether your piece is currently defending something. This is the most common motif at club level; Chessful logs flag it more than any other category.

12. King-safety underestimate

You played a move that opens lines toward your king (a pawn move, a piece trade) and did nothing about the structural weakness it created. Drilling pattern: counting attackers near the king before each move.

13. Prophylactic skip

A defensive move (often h3 / h6, or a piece retreat to a defensive square) was available and would have stopped a threat that arrived three moves later. Drilling pattern: looking for the opponent’s plan before you make your own.

14. Weakening pawn push without compensation

A pawn push (often f3 / f6 or g3 / g6) created a hole or weakened a diagonal without giving you enough activity back. Drilling pattern: pawn-structure awareness, meaning knowing which pawn moves leave permanent weaknesses.

15. Wrong piece exchanged for defender

A trade you started removed one of your own defenders and left a critical square uncovered. It differs from defender-removal blindness because you chose the trade. Drilling pattern: counting defenders after the trade.

Skill dimension 3: Positional play (5 motifs)

Positional motifs take longest to drill, but the improvement lasts longest too, and it carries over from one opening to another.

16. Wrong piece traded

You traded a structurally important piece (a good bishop, an active knight) for a less important enemy piece. Drilling pattern: judging piece quality before any trade.

17. Wrong side castled

You castled on one side when the pawn structure or piece placement made the other side safer. Drilling pattern: a structural check before castling.

18. Weak square allowed

You let an enemy piece reach an outpost (often c4 / c5 / d4 / d5 / e4 / e5 / f4 / f5) where nothing could challenge it. Drilling pattern: spotting outposts before your opponent gets there.

19. Wrong pawn break

A pawn break (the move that resolves central tension or opens an attacking path) came too late, at the wrong moment, or in the wrong direction. Drilling pattern: learning the standard pawn break for each pawn structure.

20. Time-on-the-clock-on-the-wrong-move

This one is specific to Chessful. You spent far too much clock time on a move that didn’t need it (often a forced recapture or a routine developing move) and were short of time for a critical decision later. Drilling pattern: budgeting time per move. It’s only flagged in games played with a clock.

Skill dimension 4: Openings (3 motifs)

Opening motifs depend most on the individual user, because they depend on the repertoire you actually play. Over time Chessful builds a profile of your most-played lines and flags deviations from them.

21. Repertoire drift

You left your usual opening setup in a way that lost a tempo, allowed an early exchange you normally avoid, or transposed into a structure outside your repertoire. Drilling pattern: reviewing the opening line around the point where you deviated.

22. Book-move missed

A widely known book continuation was available and was the principled move. You played a reasonable-looking non-book move that gave up an advantage the book line keeps. Drilling pattern: studying the book line in that specific opening.

23. Transposition into a bad line

Your sequence of moves transposed into a position known to be inferior, often because the move order gave up a critical defensive resource. Drilling pattern: transposition awareness within your own repertoire.

Skill dimension 5: Endgames (6 motifs)

Endgame motifs are the most technical. Pattern recognition has to come with concrete calculation, and small mistakes here are the likeliest to turn a winning position into a draw.

24. Opposition direction error

In a king-and-pawn endgame you took (or gave up) the opposition in the wrong direction, so the opposing king could either advance with its pawn or block yours. Drilling pattern: technique for direct, distant, and diagonal opposition.

25. King-too-late

Your king didn’t become active in time. It stayed on the back rank while the opposing king walked to the centre and the position simplified into a lost king-and-pawn race. Drilling pattern: recognising the moment in a middlegame when activating the king becomes the most important move.

26. Wrong rook activation

In a rook endgame you put your rook in a passive spot (behind your own pawn, or in front of an opposing passed pawn from the wrong side). Drilling pattern: Tarrasch’s rule, rooks behind passed pawns, both yours and the opponent’s.

27. Drawn-but-played-on

You turned a winning endgame into a draw with a move that simplified into a known drawn structure (often a wrong-color bishop ending, or a fortress). Drilling pattern: recognising drawn endgame structures before you simplify into them.

28. Wrong-color bishop endgame

You traded into an endgame where your remaining bishop is the wrong colour to control your passed pawn’s promotion square. It often comes together with drawn-but-played-on. Drilling pattern: projecting the endgame before the trade.

29. Technique error in K+P endgame

A known winning technique (Lucena, Philidor, square-of-the-pawn, key-square calculation) was available, and you didn’t execute it correctly. Drilling pattern: repeating the specific technique that failed.

30. Technique error in R+P endgame

The rook-endgame version of the K+P motif: you picked the right technique (Lucena bridge, Philidor third-rank defence, short-side defence) and executed it incorrectly. Drilling pattern: repetition of that specific rook-endgame technique.

How the catalogue maps to training

Each motif belongs to exactly one of the five skill buckets (the dimension it’s listed under above). When Chessful flags a motif in one of your games, it flags that skill bucket. The spaced-repetition queue draws from the flagged buckets, most recently flagged first, with Leitner-schedule intervals between repeats.

The bucket layer sits between motif detection and the training queue because patterns generalise better within a skill dimension than across dimensions. If you keep missing forks, more fork puzzles are the right fix. If you alternate between missing forks and misjudging the opposition in endgames, those are two separate failures and need separate drilling, which a generic “tactics-and-endgame practice” queue wouldn’t give you.

So the skill dimensions are where spaced repetition gets scheduled, and grouping the list for display is a side effect.

What’s not in the catalogue (and why)

A few things Chessful deliberately doesn’t detect:

Time-pressure tactics. A blunder with under thirty seconds on the clock is often a time-management problem and not a pattern problem. Chessful flags it as time-on-the-clock-on-the-wrong-move (motif 20) and not as a tactical failure, because drilling tactics doesn’t fix time pressure. Drilling time budgeting does.
Move-order subtleties in deeply theoretical lines. If you play the Najdorf Poisoned Pawn and miss a nuance on move 20, Chessful flags it as repertoire drift, not as a positional or tactical motif. What helps there is opening study, and pattern drilling wouldn’t.
Psychological mistakes. Resigning too early, accepting a draw in a winning position, playing too aggressively when ahead: Chessful doesn’t try to detect these, because engine output alone can’t reliably tell them apart from objective mistakes.

We left these out on purpose. In each case motif drilling is the wrong fix, and Chessful would mislead you by pretending it wasn’t.

How the catalogue evolves

The catalogue changes between app versions in two ways:

New motifs get added when a recurring mistake shows up in user games and the existing rules don’t catch it cleanly. The latest addition (v1.4) was weakening pawn push without compensation. It used to be part of king-safety underestimate and was split out because the two need different drills.
Existing motifs occasionally get split or merged when one category is doing too much work, or when two categories rarely produce different training value. We’re conservative about it and only do it when the resulting training queue would clearly differ.

Every change goes in the app’s changelog with the motif name and the version. The spaced-repetition queue doesn’t reset when the taxonomy changes; flagged positions move to the closest matching motif in the new taxonomy.

This catalogue is what Chessful is checking when it tells you “you played Nxd5; the knight was your only back-rank defender.” That sentence is what you see. Underneath, the motif label is defender-removal blindness, the bucket it flags is Defense, and your next training session draws from that bucket using spaced repetition.

All of it is open to inspection, which is why we published it.

Chessful is available on the App Store. The method behind the catalogue is in How Chessful turns a Stockfish evaluation into adaptive training. The companion design note on the forty AI opponents is Forty chess opponents, and none of them are me.

The Mac already shipped with every media tool, and someone just had to wire them together

2026-05-09T00:00:00+00:00

It’s a Saturday in May. Somewhere on the open web, someone is uploading a four-gigabyte video of a child’s piano recital to a free conversion site, because the format their camera produces is the format their parent cannot open. The site will take the video, run it through a server they cannot see, log the request, possibly cache the file, certainly read the metadata, and hand back something that plays on a Windows laptop. The user will close the tab and assume it’s fine.

It is not fine, and in 2026 it is also unnecessary.

MediaKit is the small Mac app the studio shipped this spring on exactly this premise: every media-conversion operation a normal user needs has, for a decade, been doable locally on a Mac, and CloudConvert, Zamzar, Smallpdf, and the rest still dominate because nobody had bothered to consolidate those local primitives behind a single drag-and-drop interface.

This is the Saturday essay on what MediaKit is, what it isn’t, and why “free conversion website” is one of the worst remaining defaults on the open web.

What media tools does Apple already ship on the Mac?

I want to be precise about this, because MediaKit’s contribution is real but limited.

The actual algorithms (H.264 encoding, HEVC encoding, AAC encoding, PNG quantization, PDF compression, RAR extraction, AES-256 archive encryption, OCR, on-device speech transcription, image upscaling, background removal) all come from first-party Apple frameworks that ship with macOS:

AVFoundation handles every video and audio operation MediaKit performs, including compression, conversion, trimming, merging, and frame-accurate cuts.
CoreImage handles every image transform, color adjustment, and pixel-level filter.
PDFKit handles merge, split, redact, sign, watermark, OCR, header/footer, and vector-preserving edits.
Vision handles OCR, image classification, and background removal.
Speech handles on-device transcription of audio and video.
Compression and AppleArchive handle ZIP, TAR, GZIP, XZ, BZIP2, and RAR extraction, with path-traversal-safe extraction and AES-256 encryption.

None of this is new or proprietary to the studio. The frameworks have been on every Mac for years, they are sandboxed and hardened-runtime-safe, and they have been optimized for Apple Silicon since the M1 launched.

MediaKit wires them together: one app with one drag-and-drop surface, a menu bar item, six Shortcuts actions, and 133 distinct tools mapped against the formats and operations a normal Mac user actually wants. The alternative is five separate utilities, each with its own settings panel, license model, and update cadence.

So the bet is consolidation. Nothing in MediaKit is novel, and I am going to keep saying so, because the marketing temptation to overclaim is real.

Why the cloud converters persist anyway

If the local primitives have been there for years, why does the median user still upload their video to a stranger?

There are four, and they also explain the shape MediaKit had to take:

Discovery. Search “convert HEIC to JPG” and the top results are conversion websites. Search “convert HEIC to JPG on Mac” and the top results are also conversion websites. Apple does not market the existence of CoreImage to end users. They shouldn’t have to.
Format coverage. Mac built-ins handle the common formats; the cloud converters handle the long tail: RAR v5 with encryption, AVIF, ALAC inside an unusual MKV. The user reaches for the website because the website will handle whatever they throw at it. MediaKit’s goal is to cover the same long tail using Apple frameworks plus a handful of permissively-licensed local libraries, with no cloud round-trip.
One-shot UX. The website is one click: paste, drop, download. Native tools historically required you to know which app to open. The drag-and-drop unified surface in MediaKit answers this: drop any file and MediaKit picks the right tool.
Trust by exhaustion. Users are tired, the website is fast and looks professional, and the privacy cost is invisible. It only becomes visible if you imagine that file being indexed somewhere, or showing up in a data-breach disclosure later.

I do not think most users want to upload sensitive files to strangers. I think they have not been given a default that is just as easy not to.

What’s free, and what’s paid

The free tier is five tools: Video Compress, Image Compress, Image Resize, Audio Convert, and PDF Compress. These are the operations the median Mac user actually performs: the email-attachment compress, the iPhone-photo-to-JPG, the audio rip. They stay free for good, with no nag screen, countdown, or upsell modal blocking the export.

The first three days, every one of the 133 tools is unlocked, so you can find out whether the long tail matters to you before you decide. After three days, the five free tools stay free; the remaining 128 require Pro. Pro is sold monthly, yearly, or as a one-time lifetime purchase, so you can skip the subscription entirely.

Pricing the free tier this way is, in the indie Mac segment, slightly unusual. Handbrake, ImageOptim, and Keka are all free. The studio’s argument is that the operations a typical user runs most often should be free in MediaKit too, permanently and not as a trial extension. If you only ever compress videos and convert HEIC, MediaKit costs you nothing, and you still get a sandboxed App Store app instead of a Homebrew install of FFmpeg.

The Pro tier exists for the people who run the long tail. The studio is not trying to convert free users into Pro users; they are different people.

What MediaKit does not do

Some clarifications I have learned to write down:

MediaKit is not a non-linear editor. It does not replace Final Cut Pro or DaVinci Resolve. If you are cutting a film, please do not use MediaKit; the operations available are linear (compress, convert, trim, crop, merge, normalize). The studio is not going to add a timeline.
MediaKit is not a generative AI tool. Vision and Speech are recognition frameworks: OCR, background segmentation, transcription. Image upscaling is real and produces a larger pixel buffer from a smaller one, but the studio is not running diffusion models. If you need image generation, MediaKit is the wrong tool.
MediaKit is not a cloud sync tool. There is no cloud. If you want your edits accessible from another device, save them to iCloud Drive yourself, or wherever you keep your files.
MediaKit is not a fix for the cloud-converter problem at the institutional level. Universities still tell students to upload PDFs to a third-party tool because the IT department has not bothered to install anything. The studio cannot fix that from outside. But on a personal Mac, the answer is now in the App Store.

A note on the holiday weekend

For US, Canadian, Australian, and several European readers, tomorrow is Mother’s Day. There is a non-zero chance you are about to send a family video to a parent in a format they cannot open. If you find yourself reaching for a conversion website to fix it: please don’t.

The file is going to ride through someone else’s data centre on the way back. It is not going to be deleted the moment you close the tab, regardless of what the privacy policy says.

MediaKit is free for the operation you most likely need (Video Compress, Image Compress, Audio Convert, PDF Compress), unlocked for three days for everything else, and it never leaves the machine.

The studio’s broader argument on cloud-vs-local file handling is in the photos elevator essay from March, if you want the longer version. The shorter version is that Apple has been giving us the primitives for years and we should use them.

The day I plan on my phone is not the day I finish at my desk

2026-05-02T00:00:00+00:00

I do not plan my day on a phone in the kitchen and then carry the plan, unchanged, to a desk for eight hours.

Nobody does. The plan I make at the coffee maker has three tasks on it, and the day I’d like to have has nine. The work happens somewhere in between, and until this week my planner didn’t run on the device I do that work on.

Taskful Day shipped on the Mac on Wednesday. This Saturday essay is about why the Mac was the missing piece, and what I did and did not do to make it work.

Why I didn’t use Catalyst

For several years Apple has made it easy to bring an iPad app to the Mac. You click a checkbox in Xcode, set a few capabilities, fix the obvious touch-target sins and ship. A lot of indie planners and to-do apps reach the Mac this way, and structurally they are an iPad window with a menu bar.

Catalyst is fine for an app you open once and dismiss, like a calculator or a unit converter. It is not fine for an app you keep open in a corner of the screen for eight hours, next to Slack, your calendar and the document you’re trying to finish. The pixels look wrong, the keyboard shortcuts feel pasted on, and the window doesn’t behave like a Mac window.

So Taskful Day on Mac is a SwiftUI app built for the Mac first, with AppKit underneath wherever SwiftUI doesn’t yet give a Mac app what it needs. The window resizes the way you expect, the keyboard shortcuts are real Mac shortcuts, and the menu bar is populated. Drag-and-drop works as it should on macOS, including into and out of other apps, and a menu bar item handles quick capture without opening the main window.

It took longer than Catalyst would have, and I think it was the right call.

One Universal Purchase for all three devices

The other decision: Taskful Day is one Universal Purchase across iPhone, iPad, and Mac. If you bought Pro on your iPhone two months ago, the Mac app activates Pro for you the first time you sign into the same Apple ID. You do not pay again, and there is no separate Mac SKU.

Many indie apps charge separately for the Mac version, and they have good reasons: the Mac app is often a lot of extra work for a smaller audience, and a per-platform price pays for it.

For a planner, though, charging twice works against what the app is for. Taskful Day exists because the day you plan on one device is the day you finish on another. Charging once for the device you plan on and again for the one you work on would make the pricing contradict the product.

So it’s one purchase for every device. Universal Purchase has been around since 2020, and here it made the right setup easy.

Sync through your own iCloud

Sync is the other place a planner can fail without anyone noticing. The day plan you make on your phone has to reach the Mac, the focus session you ran on the Mac has to show up in the iPhone widget, and none of it should pass through someone else’s server.

Taskful Day syncs through your personal iCloud account using CloudKit. The studio has no servers involved, so I can’t see your tasks, and I can’t lose them in a database because there is no database. When you delete the app on every device and sign out of iCloud, the data is gone.

Most cross-platform planners work differently: you sign up for an account, your tasks live on the company’s servers, and the apps are clients. The studio doesn’t use that model anywhere in the catalogue, including here. The cost is that you cannot share a task list with a teammate through Taskful Day, because there is no shared cloud to share through. If you need that, Taskful Day is the wrong app for you, and I’d rather you used something else.

What does “now on Mac” change for Taskful Day?

In practice, the Mac app changes three things.

Planning happens at the desk now. The Day Clock and Energy River views, the two ways Taskful Day shows your day, work much better on a 27-inch display than a 6-inch one. You can see the whole day in one glance, and you can drag tasks across the day with a real pointing device.
Focus sessions don’t need the phone. Focus Orbit runs natively on macOS. You start a session at your desk, the rest of the desktop dims, the menu bar shows the countdown, and the iPhone stays a phone instead of a timer.
End-of-day journaling is faster on a keyboard. The daily mood and reflection entry, which felt like a 60-second exercise on phone, becomes closer to two minutes of real writing on a keyboard. You write different things, so the pattern view shows you something different a month later.

The iPhone is still the device for capture: you think of something, tap, talk, and it’s filed. The iPad is still where the morning review happens. The Mac is now where the work happens, and the planner sits next to it.

Where this fits next to Things, TickTick, Sorted³

If you’re comparing:

Things 3. Things is a beautiful GTD-style task manager that assumes you want a project tree that lives forever. Taskful Day isn’t GTD; it assumes you want one day at a time, and unfinished tasks roll forward without ceremony. If you live in the Areas, Projects, Tasks hierarchy, Things is the right choice.
TickTick. TickTick is a cross-platform Swiss-army knife with reminders, calendars, habit tracking and Eisenhower matrices. Taskful Day does less on purpose: it has no habit tracker, no Pomodoro as such (the focus mode is more immersive than Pomodoro), and no team features.
Sorted³. Sorted is a fantastic time-blocked planner. If you want every task to have a start and an end time, Sorted is the better tool. Taskful Day’s Day Clock view does some of this, but its aim is a realistic plan you can finish, where Sorted’s is to schedule every minute.

Taskful Day is one of several good calm-design planners. As of this week it is one of the few that ships natively on iPhone, iPad, and Mac with a single purchase and iCloud as the sync layer.

Get it

The iPhone, iPad, and Mac apps are all available now. The core is free on every platform. Pro, which adds the focus session timer, advanced analytics, widgets, iCloud sync and unlimited follow-ups, is $2.99/month or $39.99 lifetime, applied across every device you sign in with.

Get Taskful Day.

For the studio’s view of streak-based habit apps and why I don’t ship one, the streak counter essay makes the longer argument behind that choice in this app.

Next Saturday’s entry is about the other thing I shipped this season: a Mac app full of local media tools, the kind people usually upload their files to a random website to use. I expect it to be a more pointed post.

LiftLog ships. You pick the price.

2026-04-25T00:00:00+00:00

LiftLog is on the App Store today.

The one thing to know about it: there is no subscription. You get seven days free with no card on file. After that, you choose a one-time tier between $9.99 and $39.99 and you own the app. Nothing auto-renews, there’s no trial trap, and a lapsed subscription can never lock you out of your training history.

The rest of this post covers why I built LiftLog this way and what I’m trying to learn from it.

Subscription pricing is a tax on training history

Strength training is a long-term practice. You keep showing up, week after week, year after year, and the data you build up (the weights you’ve moved, the personal records you’ve broken, the volume you’ve put your body through) gets more valuable the longer you train.

Most workout-tracker apps charge a monthly subscription. Stop paying and you lose the app, and often access to your own history. I find this morally awkward. The user generated the data, and the user’s effort produced the personal records. Charging rent on someone’s own training journal is the wrong arrangement.

I know the economics. Subscriptions smooth revenue, fund support and pay for ongoing development. Services like Strong, Hevy, and Fitbod have good reasons to use them, and I don’t think those teams are doing anything wrong. I wanted to find out whether another model would work for a one-person studio shipping a single, finished product.

So LiftLog is one-time. You pay once, you own it.

What does “pay what you can” actually mean here?

After the seven-day free trial, the app shows you four tiers:

Fair, $9.99. The entry tier. If this is the most you can justify for the app, pick it, with no guilt and no asterisk.
Good, $19.99. The middle. If LiftLog has earned a serious share of your training time and you expect to keep using it, this is where I think most users will land.
Generous, $29.99. A step up for users who want to support the work, or who have benefited from indie software in the past and want to give back.
Patron, $39.99. The top tier. Same app, no extra unlocks. It exists so people who want to back the studio at a level closer to a year of competitor subscriptions can do that openly, without a hidden option or a tip jar.

All four tiers unlock the same product. Nothing is locked behind a higher number. You choose what LiftLog is worth to you; the features are the same either way.

Why four tiers and not a slider

A slider would be more flexible, but every UX paper I’ve read on charitable giving and pay-what-you-want pricing says the same thing: give people too many options and they freeze, and when they freeze, the median amount paid drops. Four tiers give people a real choice without overload.

Four also creates anchoring. If the only options were $9.99 and $19.99, almost everyone would pick $9.99. With $29.99 and $39.99 visible, $19.99 reads as moderate instead of top-end, and some users will choose to pay above the median. That’s the bet.

The labels matter too. Naming the tiers Fair / Good / Generous / Patron (and not Basic / Standard / Plus / Pro) makes clear that more money doesn’t buy more app. It buys the studio more runway, and I want the labels to say so plainly.

What this is not

A few clarifications, because two friends have already asked:

It’s not freeware. The seven-day trial is generous, needs no card and doesn’t nag, but after that the app does ask you to choose a tier. I’m not Strava-ing my way into a freemium grind. The trial is real and so is the purchase.
It’s not a stunt. This isn’t a one-week marketing experiment. Pay-what-you-can is the app’s pricing model. If it doesn’t work, I’ll learn from that and write about it openly. If it does work, it stays.
It doesn’t scale to everyone. It works for a one-person studio shipping a finished, focused product. It almost certainly does not work for a SaaS company with ongoing infrastructure costs and a 50-person team. I’m only arguing that it has a place where it fits, and subscriptions can keep the rest.

Why LiftLog and GymLogger X

Lagerland Apps already has a strength training app: GymLogger X. It has an Apple Watch app for logging sets from the wrist, generated programs and plateau detection, and costs $39.99 lifetime or $17.99/year. That app is staying. People who want a fast logger they can use from Apple Watch should buy GymLogger X; it’s the better tool for that job.

LiftLog is a different bet:

Design-led, iPhone-first. Tabular numerics, a custom haptic numeric keypad during sets, a restrained navy palette, and programs you build yourself, with supersets and giant sets. It’s for lifters who care how their tools feel as well as what they do.
A pricing experiment. GymLogger X is the conventional answer (lifetime plus optional annual). LiftLog is the contrarian one (pay what you can, once). I want both in the catalogue so I can learn from both.

If you can’t decide, it comes down to this. To log from Apple Watch, get GymLogger X. If you live on iPhone and want polish, get LiftLog. To support an indie studio’s pricing experiment, get LiftLog at the Patron tier. Any of these is a fine choice.

What I’ll be watching

I honestly don’t know how this will turn out. The questions I want answered:

What’s the median tier choice? I expect $19.99 (Good). If it’s $9.99 (Fair) by a wide margin, the anchoring isn’t working and I need to rethink the labels or the tier ladder.
What’s the conversion rate from trial to paid tier? Industry benchmarks for paid trials with no card up front sit around 5 to 15%. Dropping the card requirement reduces friction, but it also drops the auto-renew lock-in behind a lot of “subscription” revenue.
Do Patrons cluster geographically or demographically? I don’t track users individually, but the App Store gives me country-level rollups and tier-level revenue. If a lot of Patron purchases come from regions where $39.99 is a serious amount of money, that changes how I think about the model.
Do reviews mention the pricing? This is the qualitative signal I care about most. If users find the tier ladder respectful and unusual, the model is working. If it feels gimmicky or guilt-trippy, it isn’t, and I’ll write a follow-up explaining what I changed.

I’ll publish a follow-up here in three to six months with whatever the data says, including the bad numbers if there are any.

Try it free

If you train, download LiftLog. You get seven days of full access with no card. After that, pick a tier or don’t, and if you don’t, we part on good terms.

If pay-what-you-can pricing isn’t for you, GymLogger X costs $39.99 lifetime. It comes from the same studio with the same privacy principles and a different pricing model.

Either way, your training history stays on your device, with no third-party tracking, no advertising SDKs and no required account. The app is small, the studio is one person, and those principles stay.

LiftLog is available on the App Store. It’s free for seven days with no card required. After the trial you choose a one-time price: $9.99, $19.99, $29.99, or $39.99.

A glanceable dashboard for App Store revenue, on the iPhone

2026-04-18T00:00:00+00:00

Updated September 22, 2026: an earlier version of this post described shareable access tokens, a strictly read-only design and no App Store analytics. AppMeta Pulse never shipped token sharing, can send replies to customer reviews, and reads App Store impressions and page views. The post is corrected below. For current plans and prices, see the AppMeta Pulse page.

Updated October 25, 2026: this post also described a free tier with one app and 30 days of history. Pulse never had one. The free download opens a demo on sample data, and everything else needs a subscription or the lifetime unlock. The widget description is corrected too.

A small post for the third Saturday in April. Tax week is just behind us in the US, the indie iOS calendar is in the lull between Q1 and WWDC, and most studios are reconciling their books.

This one’s about AppMeta Pulse, the iPhone app this studio ships for that moment. It is the smallest, simplest tool in the catalogue, and I am asked surprisingly often why it exists.

The setup problem

Two months ago I wrote about AppMeta, the native Mac client for the write side of App Store Connect, where you edit metadata, respond to reviews and submit versions. AppMeta Pulse is the monitoring counterpart. It looks at App Store revenue and not much else.

There are two apps because of a permissions problem most indies hit eventually.

App Store Connect has one monolithic role model: either someone has access to your developer account, or they don’t. Sub-roles exist (Admin, Developer, Marketing and so on), but they are coarse. Marketing can edit metadata and Finance can read sales reports, but nobody can have just “read-only revenue access without seeing build artefacts or being able to respond to reviews.”

So if you want your accountant to see your revenue, you have to give them an App Store Connect account, configure their role, accept that they can see things you’d rather they didn’t, and trust them to log in to a developer web tool every time they want to check.

In practice most indies send a screenshot of their numbers over Slack or iMessage. That works for a one-off request and is terrible for any regular reporting.

AppMeta Pulse was first pitched as the answer. It turned out narrower, a fast check for the account owner (see the correction below).

What does glanceable revenue look like?

AppMeta Pulse bets that the question people ask most, “how is the app selling this week?”, deserves its own glanceable tool, separate from the editorial side where you change pricing or push a new version.

The app sits on top of the App Store Connect API and reads your sales, subscription and analytics reports. It shows:

Daily, weekly and monthly revenue per app and across the portfolio.
Subscription health: trials, conversions, churn, cancellations.
Country-level revenue rollups.
Comparison views: this week against last week, this month against last month.
Per-app vs. portfolio splits.

Apart from replies to customer reviews, which arrived at the end of April 2026, nothing it shows can be edited. There is no metadata editing, build management or submission, and it is built so that it cannot do those things.

Why the iPhone

The form factor is iPhone, and the design is meant to be read at a glance.

AppMeta does the desk work on the Mac: multi-locale metadata editing, keyword analysis, review replies. AppMeta Pulse does the check-in on the phone, over the morning coffee, in the weekly meeting with a co-founder or at the quarterly review with the accountant.

The use case I designed for: an indie developer in a coffee shop picks up the phone, taps Pulse, sees the last seven days’ proceeds against the seven before, and decides whether to pay attention or get on with the day. That should take three seconds, and it does.

The widget is, predictably, what I look at most. The small Pulse widget shows one figure, its label and how fresh the data is; the medium one adds a sparkline. The 7-Day Dashboard widget shows proceeds, units and new subscriptions, each with its change from the previous seven days, because those are the numbers worth seeing at a glance.

This post originally claimed a use case for AppMeta Pulse that it doesn’t cover: sharing read-only access without granting write access.

A co-founder, a designer on a profit share or an accountant doing quarterly bookkeeping needs to see the numbers, and none of them needs to be able to change your app’s pricing.

Pulse doesn’t solve this. It has no shared access tokens and no way to give another person access to your account’s data, though you can export a CSV of a period’s sales and send it yourself. The clean way to give someone ongoing read access is still an App Store Connect account with a limited role.

The pricing structure

Pulse is free to download, and the free download runs a demo on sample data so you can see what it does. Your own numbers, the portfolio view and the widgets need Pro. At the time of writing, Pro was $0.99/month, $8.99/year, or $17.99 lifetime; the App Store now lists $0.99/month, $1.99/year, or $2.99 lifetime.

The price is low on purpose. A studio doesn’t use this tool for hours a day; it checks it briefly and relies on it. Pricing it like flagship productivity software would misjudge its place in an indie’s toolkit. A one-time lifetime price puts it in the buy-it-and-forget-it tier, which suits what it does.

What it doesn’t do

AppMeta Pulse is not a financial-planning tool. It does not project revenue, model scenarios, or replace your accountant. It does no tax calculations, and it doesn’t read Payments and Financial Reports; for when Apple’s money actually arrives, see when Apple pays developers.

Nor is it a full marketing-analytics tool. From App Store Connect’s analytics reports it uses only App Store impressions and product page views (it keeps a copy of the downloaded report).

Pulse does one thing: it shows your App Store revenue at a glance, on your phone.

A small note on the catalogue

By my count this is the third post this quarter about a tool for indie iOS developers. It’s also the last for a while. I want to get back to the consumer apps that make up most of the catalogue, and the next few weekends will probably go to them.

If you’re an indie who read this far and you keep opening App Store Connect just to see how yesterday went, AppMeta Pulse is a small pay-once tool that answers that faster. Spring is the season of clean books.

TheWait is now Soon. Why we rebuilt and rebranded

2026-04-13T00:00:00+00:00

TheWait started as a simple countdown app. You pinned an event and watched the days tick down, and that was it. Over a year it grew widgets, themes, calendar sync, and photo backgrounds. The name, TheWait, kept holding it back.

In April 2026 I rebuilt the app from scratch and rebranded it as Soon., with a new name, a new icon, and a new home.

Why rename TheWait to Soon.?

TheWait describes the app literally. You wait, and the app counts down.

That framing gets the feeling wrong. People use countdown apps because they’re looking forward to something. Waiting is passive and carries delay, patience, and endurance with it. Anticipation is active: you enjoy the thing a little before it arrives. When you’re counting down to a trip, a wedding, a birth, or a milestone, part of you is already there.

Soon. says that better. The period at the end is deliberate, because it makes the name a full sentence: the thing you’re looking forward to isn’t far off.

What changed under the hood

The whole app was rebuilt from scratch. New additions include:

Plan Mode. Every countdown now comes with a smart timeline and checklist tailored to the event type. Trips get packing lists and transport reminders, and weddings get their own schedule. The app knows what a birthday, wedding, or graduation typically needs and assembles the prep for you, so you don’t have to write the checklist yourself.
StandBy widgets. Every iOS widget size and style: Home Screen, Lock Screen, StandBy, ring, minimal, and timeline. The event you’re most looking forward to can sit on every screen you already use.
Natural language search. Type “trips in July”, “birthdays this month”, or “anniversaries in 2027” and Soon. understands what you mean.
Memories that return. A countdown that ends becomes a memory, and Soon. brings it back on every anniversary.
iOS Calendar sync. Any iOS Calendar event can become a countdown with a single tap.
39 languages. Full localization including Japanese, Chinese, Arabic, Hebrew, Korean, and every major European language.

What stayed the same

Private by default. Soon. has no ads, tracking, or account. Your events stay on your device. Weather requests use approximate location or a place name only, never precise location.
A one-time purchase option. Premium is $12.99 lifetime (or $1.99/month, or $9.99/year if you prefer) with a 7-day free trial. Nothing is charged automatically without your consent.
Built by one person. Same developer, same catalogue, same principles. Soon. is part of the Lagerland Apps family of privacy-first tools.

What existing TheWait users need to know

If you used TheWait, everything carries over. Your events, themes, and data migrate automatically. You’ll see the new name, the new icon, and Plan Mode, and you get every new feature without paying for a second app. The upgrade is free.

Why indie studios should rename when it matters

Renaming an app is frightening. App Store rankings reset, existing users get confused, and some coverage stays attached to the old name. I resisted doing it for a year.

A wrong name costs you every day, though. Everyone who sees the app sees the wrong framing, every conversation starts with an explanation, and every review mentions how odd the name is. Eventually the cost of keeping it is higher than the cost of changing it, and most of the cost of changing it is nerve.

For a countdown app, where the whole point is moments worth waiting for, Soon. is a better name than TheWait. It was worth the pain.

If you’re building something and the name is slightly wrong, take this as permission to change it.

Soon. is available on the App Store. Free with 5 events forever, or Premium for unlimited events, weather intelligence, daily notes, recurring events, and event notifications.

How to find a random Wikipedia article that is worth reading

2026-04-11T00:00:00+00:00

The Random article link in Wikipedia’s sidebar does exactly what it says, and that is its limit. English Wikipedia has more than seven million articles. About 7,000 of them are featured articles, the grade the community gives its best writing: roughly one in a thousand. Pressing Random is a good way to meet the encyclopedia and a slow way to find its best pages.

Wikipedia has better-aimed routes built in, ranging from fully random to hand-picked, and they work well in combination.

Every built-in way to find something to read

Route	Where to find it	What you get	How it is chosen
Random article	Sidebar link, or Special:Random	Any article	A random number matched against an index (below)
Random featured article	Special:RandomInCategory/Featured_articles	One of about 7,000 featured articles	Random within the category
Random good article	Special:RandomInCategory/Good_articles	One of more than 40,000 good articles	Random within the category
Today’s featured article	Main Page	One featured article a day	Scheduled by editors
Did you know	Main Page	One-line hooks to articles that are new, newly expanded or newly promoted	Nominated and reviewed; usually one set a day
On this day	Main Page	Anniversaries for today’s date	Picked from a queue; quality and topic mix count
Unusual articles	Wikipedia:Unusual articles	A long list of odd but verifiable articles, grouped by subject	Collected by editors
Vital articles	Wikipedia:Vital articles	The topics editors think most deserve a strong article, in levels of 10 to 50,000	Agreed by editors

Random article has a keyboard shortcut: Alt+Shift+X in Firefox, Alt+X in Chrome and Edge, as Wikipedia’s Random help page lists them. Special:Random also works in other language editions; on German Wikipedia it redirects to Spezial:Zufällige Seite.

How random is the Random article link?

Random enough to browse, not random enough to sample. Wikipedia’s technical FAQ explains the mechanism. Every page is given a random index, a number between 0 and 1. Special:Random draws its own random number and returns the next article whose index is higher. An article that sits just after a wide gap between indexes gets picked more often than one close behind its neighbour, so every article’s odds differ slightly, and the differences are themselves random. The FAQ’s verdict: good enough for a small sample.

The pool is the main namespace: every article, long or short, reviewed or not. Run the counts from Wikipedia’s own pages and a random click lands like this:

Kind of article	How many (English Wikipedia)	Roughly one click in
Featured article	about 7,000	1,000
Good article	more than 40,000	160
Any article	more than 7 million	1

Counts as Wikipedia:Featured articles and Wikipedia:Good articles gave them in April 2026. Both move every week, so check those pages for live figures.

More than 99 clicks in 100 land on an article that is neither featured nor good. Plenty of those are excellent and simply unreviewed, but if you want the reviewed ones, there is a better button.

How to aim the randomness

Special:RandomInCategory takes a category name and returns a random page from that category (MediaWiki help). Wikipedia files every featured and good article in a maintenance category, which turns it into a quality filter:

A random featured article: Special:RandomInCategory/Featured_articles. Before they are listed, featured articles are reviewed as featured article candidates for accuracy, neutrality, completeness and style. On the desktop site they carry a small bronze star at the top right.
A random good article: Special:RandomInCategory/Good_articles. Good articles meet a core set of editorial standards. They need not be as comprehensive as featured articles, but they should not omit any major facet of the subject. They carry a green plus icon.

Bookmark those two addresses and you have Random buttons that only land on reviewed articles. The address works with other categories too: put a different category name after the slash.

The hand-picked routes

The Main Page is the other way in. Each of its sections has its own selection rules.

Today’s featured article is one featured article a day, so it clears the same bar as the random featured link.

Did you know is where new writing surfaces. An article qualifies if it was created, expanded fivefold or promoted to good article in the seven days before its nomination, and it needs at least 1,500 characters of original prose (the rules). Each entry is a one-sentence hook linking to the article, and the Main Page normally runs one new set a day.

On this day draws on Selected anniversaries, a queue of historical events, holidays and observances for each date. Importance is not the only test: editors also weigh article quality and the mix of topics.

Unusual articles is a long list, kept by editors, of articles that are verifiable and worth having but odd or whimsical. Its sections run from places and infrastructure to food, folklore and death. It is the nearest thing Wikipedia has to a curated collection of the strange.

Vital articles works the other way round. It lists the subjects editors think most deserve a high-quality article, in five levels from the 10 most vital up to 50,000, which makes it a reading list for the central topics rather than the edges.

Combining the routes

Five spare minutes: press Random a few times and stop at the first article you want to finish.
Wanting a sure thing: use the featured or good article links above.
Once a day: read the Did you know hooks and On this day, which change daily.
When something grabs you: follow the categories at the bottom of the article. Each one is a shelf of neighbouring subjects, and any of them can go after the slash in RandomInCategory.

Where WanderWiki fits

WanderWiki puts three of these routes into a card deck on iPhone. Random asks Wikipedia’s REST API for a random article, the API’s version of the Random article link, so almost anything in the encyclopedia can come up; the app skips disambiguation pages, lists, and stubs too short to summarise. For You draws from topics you choose, which narrows the draw the way a category does, without watching what you linger on. Today in History shows what happened on today’s date. Swipe to the next card, or open one to read the full article reformatted for the phone, and save the ones you want to keep.

There is no account and no advertising. The privacy page sets out that saved articles and interests are stored on the device and that articles come from Wikipedia’s public APIs. Why it is a deck you put down rather than a feed you scroll is the subject of an earlier post.

The app doesn.t replace the website. If you specifically want a random featured article, the RandomInCategory address above is the most direct route.

How to organise your bills each month: a bill calendar that matches your paydays

2026-04-04T00:00:00+00:00

A list of bills answers what do I owe this month. The question that produces a short week is a different one: which paycheck is paying for which bill. A month can balance on paper, with income comfortably above bills, and still put $1,690 of bills on one paycheck and $330 on the next, because the rent, the car loan and the insurance all land in the same fortnight.

A bill calendar answers the second question. The Consumer Financial Protection Bureau publishes a printable bill calendar tool in its Your Money, Your Goals toolkit, and the method works even if you never print it.

The bill calendar method, step by step

Step	What to do	The rule that makes it work
1. List every bill	Rent, utilities, loans, insurance, phone, subscriptions	Include autopays; they still need cash in the account
2. Write the pay-by date	The day the money has to leave your account, not the due date	CFPB: 2 to 3 days early for online or in-person payments, at least 7 days early by mail
3. Add your paydays	Every date money arrives, with the amount	Use that month’s real dates, not “twice a month”
4. Total each pay period	Add the bills whose pay-by date falls between one payday and the next	Compare each total with the paycheck that has to cover it
5. Fix the heavy period	Ask to move a due date, or use a bills account	The CFPB tool suggests asking to move due dates when a week’s bills outrun its income
6. Recheck monthly	Look at next month before it starts	Biweekly paydays move, so April’s calendar can fail in May

Step 2 does most of the work. The CFPB’s tool is plain about the cost of treating the due date as the target: pay even a few days late and you will likely be charged a fee, and you risk a negative entry in your credit record.

Why biweekly pay breaks a monthly calendar

Biweekly is the most common pay schedule in the US. In February 2023, 43.0% of private establishments paid every two weeks, according to the Bureau of Labor Statistics. It is also the schedule that fits a monthly calendar worst, because 14 days does not divide into a month. Your paydays land two or three days earlier in the month each month, and twice a year a month gets three of them.

For a worked example, take someone paid every other Friday, with a payday on April 3, 2026, and nine monthly bills totalling $2,080: rent $1,200 on the 1st, car loan $310 on the 6th, phone $55 on the 9th, car insurance $125 on the 12th, internet $60 on the 15th, electricity $90 on the 20th, student loan $160 on the 25th, two streaming services $36 on the 27th, gym $44 on the 28th.

With each pay-by date set three days before the due date, this is what each paycheck has to cover:

Payday	Bills whose pay-by date falls before the next payday	Total
Fri Apr 3	Car loan, phone, car insurance, internet	$550
Fri Apr 17	Electricity, student loan, streaming, gym, May rent	$1,530
Fri May 1	Car loan, phone, car insurance, internet	$550
Fri May 15	Electricity, student loan, streaming, gym	$330
Fri May 29	June rent, car loan, phone, car insurance	$1,690
Fri Jun 12	Internet, electricity, student loan, streaming, gym	$390
Fri Jun 26	July rent, car loan, phone, car insurance	$1,690

Same bills, same pay, and the load on one paycheck swings from $330 to $1,690. Across 2026 on this schedule it runs from $275 (August 7) to $1,750 (August 21).

Three things fall out of the table:

Rent is never paid by its own month’s paycheck. Rent due on the 1st has a pay-by date in the last days of the previous month, so it always comes out of a paycheck from the month before.
The third paycheck is not spare money. May 2026 has three paydays on this schedule. The third, May 29, lands just before June’s rent and ties for the heaviest load in the table.
Which months get three paydays depends on your Fridays. Twenty-six biweekly paydays is 24 plus two extras. On this cadence they fall in May and October; on the alternate Fridays, starting January 2, in January and July. Weekly pay on Fridays gives 52 paydays in 2026, with five in January, May, July and October.

Two ways to fix a lopsided calendar

Move a due date. With semimonthly pay (the 1st and 15th, say) this is the whole fix: paydays never move, so each paycheck covers the same bills every month, and if a lender agrees to move one due date, the balance holds for good. With biweekly pay it helps less, because the paycheck that is overloaded this month is a different one next month.

Smooth it with a fixed transfer. Keep a separate account just for bills, and on every payday move the same amount into it: monthly bills × 12 ÷ 26. Here that is $2,080 × 12 ÷ 26 = $960 per paycheck. Twenty-six transfers of $960 make $24,960, exactly twelve months of $2,080. Pay every bill from that account and the swing disappears from your spending money: each paycheck gives up $960, whatever the calendar does.

The account needs a starting cushion, because the money arrives evenly and the bills do not. For this schedule, seeding it with one $960 transfer in January, after January’s rent, keeps it positive all year. Its lowest point is $320 on April 28, the pay-by date for May’s rent, and it ends the year back at $960.

Credit cards: the one due date that stays put

Card due dates are the most predictable line on the calendar. Under Regulation Z, a card’s due date must fall on the same day of the month in every billing cycle (12 CFR 1026.7(b)(11)). The statement must be mailed or delivered at least 21 days before that date (§ 1026.5(b)(2)(ii)). And the issuer cannot set a payment cut-off earlier than 5 p.m. on the due date (§ 1026.10(b)(2)(ii)). Enter the card once and it will not wander.

If a date slips anyway

The threshold worth knowing is 30 days. The CFPB’s guide to reading your credit report says an account is usually still reported as current if it is paid within 30 days of the due date. A late fee can arrive much sooner, depending on your agreement. Past that point, negative payment history can generally be reported for up to seven years. A payment you notice on day three is a fee problem. On day thirty-one it can become a credit-history problem.

Where AllPaid fits, and where it doesn’t

AllPaid holds the bill side of this calendar. Each bill gets a name, an optional amount, a due date and a repeat, such as monthly or yearly. Type a name it recognises, such as Netflix or rent, and it offers to fill in the cycle and category, plus a typical price for common subscriptions; amounts for rent and utilities are left to you.

The calendar button opens the Monthly Summary: the month as a grid with a dot on every day a bill is due, which changes colour once the bill is paid, and three totals across the top for due, paid and remaining. Reminders arrive at 9:00 local time the day before a bill is due. Pro adds earlier ones, such as three days or a week ahead, and one on the due day itself. To build in the CFPB’s margin, either enter the pay-by date as the due date or use the three-day reminder. From the notification you can mark the bill paid or snooze it for two hours or until tomorrow, and marking a repeating bill paid moves it to its next due date. Ask Siri “What bills are due in AllPaid” and it reads out the next seven days.

Two decisions are deliberate. A bill whose date has gone by is labelled Due date passed, not overdue, because the app’s design brief asks for calm, neutral language and rules out overdue panic states. And AllPaid never asks for a bank login; the reasoning is in I will not ask for your bank login.

That second decision is also its limit here. AllPaid does not know when you are paid and has no income field, so steps 3 to 5 (paydays, pay-period totals, the transfer amount) stay on paper or in a note. It also cannot remind you about a bill you never entered.

TL;DR

A bill calendar shows which paycheck pays which bill. A balanced month can still hide one overloaded fortnight.
Plan around pay-by dates, not due dates. The CFPB suggests 2 to 3 days early online and at least 7 days early by mail.
Biweekly pay drifts. In the example, the same $2,080 of bills puts anywhere from $330 to $1,690 on a single paycheck.
The smoothing formula is monthly bills × 12 ÷ 26. Move that much to a bills account every payday, and seed it with one transfer.
Card due dates are fixed by rule: same day every month, statement 21 days ahead, cut-off no earlier than 5 p.m.
Paid within 30 days, an account is usually still reported current. Fees can start sooner.

Your photos shouldn't ride the elevator to a stranger's data centre

2026-03-28T00:00:00+00:00

Think of the last time this week you needed to convert a media file: a HEIC photo to JPG, a video compressed for Slack, two PDFs merged, a screen recording’s audio extracted to MP3.

Most people use a free online converter for that. You upload the file to cloudconverter.com or ilovepdf.com or tinypng.com or one of a hundred near-identical sites, wait, download the result, and move on. The same reflex reaches documents with your home address printed on them, vet paperwork, for one.

Almost none of those tools needed your file to leave your device. Uploading is convenient, but it sends private files somewhere they never needed to go, and MediaKit is the studio’s argument that the whole category of conversion tools belongs on your Mac.

What does “convert online” actually do to your file?

When you use a free online converter, the file goes through these steps:

It leaves your machine, encrypted in transit.
It lands on the operator’s storage, sometimes encrypted at rest, sometimes not.
Their conversion pipeline processes it, which typically takes seconds.
It is held in storage, often for hours, sometimes for days, depending on the operator’s retention policy.
You download it.
It may or may not be deleted from the operator’s storage according to their stated policy, which you have no way to verify.

You notice the first and last steps. The privacy questions sit in the middle ones. The file you converted contained whatever it contained (a photograph of your kitchen, a screenshot of an email, a PDF of your medical records, a video of your child), and it now lives, briefly or not so briefly, on infrastructure you do not control.

Most online converters are run by small teams, and most try to delete files promptly. The problem is the design: files leave your machine for processing that doesn’t require it, and you have to trust the operator to be careful in the right way.

Apple Silicon changed the math

Cloud converters dominated because local conversion used to be slow. In 2015, compressing a 4K video on a laptop took twenty minutes. Uploading it to a cloud service that compressed it in thirty seconds was simply faster, even counting the upload.

Apple Silicon closed that gap. Modern Macs have hardware video encoders that compress at multiples of real-time speed, with ProRes acceleration, HEIC encoding, and AV1 decoding all on the chip. Local performance is now competitive with the cloud round trip, and sometimes faster.

For images and PDFs, local processing was always faster. Those moved to the cloud because web tools are easier to ship: one runs in any browser, while a desktop tool has to be installed. That is real friction, and we think the privacy you keep is worth it.

What MediaKit specifically does

MediaKit is a Mac app with 133 local conversion tools, organised by media type:

Video: compression for YouTube/Instagram/Slack, format conversion (MP4, HEVC, AV1, ProRes), resolution and bitrate adjustment, frame extraction, audio extraction.
Image: HEIC↔JPG↔PNG↔WebP, bulk operations across folders, resize/crop/rotate, EXIF stripping, format-specific optimisation.
Audio: format conversion, bitrate adjustment, channel mixing, silence trimming.
PDF: merge, split, redact, sign, OCR, page reorder, compress.
Archive: ZIP, TAR, GZIP, and RAR v5 extraction natively on Apple Silicon. That has long been a pain point for people who still get RAR archives in 2026, which happens more often than you’d think, since academic and design workflows use the format heavily.

Every tool runs entirely on the Mac, so nothing is uploaded and there is no operator retention policy to read. For the most common video job, getting a clip under an email attachment limit, the limits and the bitrate arithmetic are in a separate guide.

All the tools support Shortcuts integration, so you can chain them into automated workflows. “Compress all videos in this Downloads folder, output to ~/Compressed, delete originals over 100MB” is one Shortcut; it runs on a schedule and never touches the internet.

The freemium decision

Pricing was the decision we argued about most before launch.

MediaKit shipped with five permanently free tools (Video Compress, Image Compress, Image Resize, Audio Convert, PDF Compress), which between them probably cover 70% of casual use cases, and a single Pro tier that unlocks the remaining 128 tools and batch processing across all of them. There is also a free 3-day trial of all tools, so you can try everything before deciding.

We wanted a free path that people would actually use. Five tools is enough that a casual user could go years without paying, and that’s fine; the app should be useful first.

The long tail of tools is what makes MediaKit worth paying for to a power user, and power users are the ones who fund building it. So power users pay because they get a lot out of the app, and casual users pay nothing for the basics.

In short

If you habitually use online converters, MediaKit is our case that you don’t need to. The Mac in front of you can do the same processing locally, faster than you’d expect, and your files stay on it.

The free tier covers the common cases. The Pro unlock covers everything else, including the obscure jobs (RAR v5 on Apple Silicon, batch HEIC stripping, PDF redaction with verifiable removal) that most online services either don’t support or charge a subscription for.

It’s the last weekend of March. If you have a stack of media files you’ve been meaning to process, this is a way to do it without uploading any of them.

How to sleep after a night shift: the drive home, the dark room, the nap and the days off

2026-03-21T00:00:00+00:00

Night workers usually get less sleep, and lower-quality sleep, than people who sleep at night. That is the starting point of the NIOSH Training for Nurses on Shift Work and Long Work Hours, a free course from the U.S. National Institute for Occupational Safety and Health. It was written for nurses, but its sleep advice does not depend on the job. Unless another source is named, everything below comes from it.

The day after a night shift, in order

NIOSH’s example has the worker home at 8 a.m. Move the times to fit your own shift.

When	What to do
First half of the shift	Spend as much time as you can in bright light. If you use caffeine, have it now.
Second half of the shift	Cut back on bright light unless you are very sleepy. Stop caffeine several hours before the end.
The drive home	Dark sunglasses only if someone else is driving.
Home, around 8 a.m.	Go straight to bed. If you haven’t eaten for hours, have a small meal with protein and carbohydrate first.
Morning to early afternoon	Sleep as long as you can. The more sleep you get before 2 p.m., the better rested you will be.
Afternoon or evening	Nap before the next night shift if you can.
Days off	Stay up until 3 or 4 a.m. and sleep until noon or 1 p.m.

Each row is explained below with its source. The light rows come from the course’s night-shift light page, which calls the body-clock benefit for permanent night workers theoretical; bright light early in the shift is mainly about staying alert.

Make the bedroom dark enough that you can’t see your hand

NIOSH sets the bar for a daytime bedroom at a room “so dark you cannot see your hand in front of your eyes” (sleep after a night shift). Closing the curtains rarely gets there. The bedroom light checklist:

Windows: room-darkening shades or heavy, lined drapes, adjusted so no light leaks around the edges. Blinds let too much through.
Doors and hallways: turn off hall lights or put a draft stopper under the door. If light still gets in, wear an eye mask for the whole sleep.
Inside the room: remove or cover anything that glows, such as a lit clock, a phone or a TV.
The bathroom trip: keep the path dark and clear, with a dim red nightlight if you need one.

Noise is the other half. NIOSH suggests earplugs, a fan or a white-noise machine, asking the household to keep out of the bedroom and keep the noise down, and setting the phone to Do Not Disturb with chosen contacts allowed through for emergencies. Keep the room cool, and turn the clock face away so you are not checking the time.

Caffeine belongs at the start of the shift

NIOSH gives caffeine’s half-life as 5 to 6 hours, longer in some people, and suggests that night workers who use it have it at the start of the shift and stop several hours before the end. The arithmetic explains why: a coffee at 3 a.m. still leaves about half its caffeine in your system when you lie down at 8 or 9.

The same page covers the rest of the run-up to sleep: dim lights for an hour or two before bed, no heavy or spicy meals in the 2 to 3 hours before, not too much to drink, and any alcohol several hours ahead, because it can wake you early.

The drive home is the riskiest part of the morning

NIOSH notes that many nurses feel excessively sleepy after night shifts and have a higher risk of crashing on the way home. It mentions a brief nap at work before driving as something that might help, and says plainly that this has not been tested.

Sunglasses are a trade-off. Blocking bright morning light on the way home may help you sleep longer afterwards, but researchers worry that it also takes away light’s alerting effect from a driver who is already very sleepy. NIOSH’s safest approach is to wear dark sunglasses after a night shift only if someone else is driving, put them on before you step outside, and keep them on until you are back in a dark room.

The nap before the next night

NIOSH recommends napping before you go back to work if you can: it adds to your total sleep and helps you stay alert through the night. This prophylactic nap is usually long, a few hours, enough to reach deeper sleep and ease the sleep pressure of the night ahead. The studies NIOSH cites:

Nap before the night shift	Result
1.5 hours, 3:30 to 5 p.m.	Nurses and nursing aides were more alert in the second half of their first night shift than those who didn’t nap
2.5 hours, 7:30 to 10 p.m.	Better alertness during a simulated night shift than with no nap
3 hours, 2 to 5 p.m.	Higher alertness during the following night shift than with no nap
2.5 hours, plus caffeine at the start of the shift	The combination improved alertness

In 2007, the American Academy of Sleep Medicine’s practice parameters rated planned napping before or during the night shift a “standard”, its highest-certainty category, for improving night workers’ alertness and performance.

Long naps have a cost: grogginess on waking, called sleep inertia. Waking after about 20 or about 90 minutes tends to leave you less groggy than waking after about an hour, in deep sleep, and that grogginess may clear within 15 to 30 minutes. It lasts longer when you are short of sleep, so leave time before you drive or do anything where a mistake matters. If you work on call, where a phone can wake you at any hour, how to sleep on call covers that kind of grogginess in more detail.

Days off: keep part of the window

Switching all the way back to night sleep on every day off keeps your body clock in something close to permanent jet lag. The compromise NIOSH describes: on days off, stay up until 3 or 4 a.m. and sleep until noon or 1 p.m. That way a block such as 8 a.m. to noon is sleep time on work days and days off alike.

The same page warns against the opposite shortcut: staying awake all day before the first night of a run, or after the last one. You end up awake for too many hours, which raises the risk of accidents and, over time, of chronic sleep loss. The course does not cover rotating schedules in detail; rotating workers who struggle to adjust are pointed to a sleep specialist.

When it’s more than a bad week

Persistent sleep problems should not be ignored, NIOSH says, and a sleep disorder such as sleep apnea or insomnia can make enough sleep impossible until it is treated. The American Academy of Sleep Medicine’s page on shift work disorder draws a similar line: a new shift is hard for many people at first, but if after several weeks you still have trouble falling or staying asleep, or feel tired even after 7 to 8 hours, you may have shift work disorder. That is a conversation for your doctor or a sleep specialist, and so is any sleep aid or supplement.

Where AfterShift fits

AfterShift is an iPhone app for people on night, rotating and on-call schedules. It is an informational tracker: it shows what your sleep is doing around your shifts, but it does not diagnose or treat anything, and none of the advice above depends on it. Where it meets that advice:

It reads your sleep and labels it. AfterShift reads sleep from Apple Health (it never writes or shares that data) and tells you where each sleep fell: after a night shift, before one, between shifts or on a recovery day.
It shows whether bedroom changes worked. For each sleep you see time asleep against time in bed, sleep efficiency, the sleep midpoint and whether you slept inside the planned window. If new blackout shades help, that is where it shows.
It plans the next window. Add your next shift and the Today tab shows a planned sleep window, flags one shorter than six hours, and suggests a short 20 to 30 minute nap when recovery time is tight. If you tell it you can’t nap, it stops suggesting nap windows. The long pre-shift naps in the NIOSH table are yours to plan; Log Nap records them and asks how the nap went, including whether you woke up groggy.
It times caffeine against your sleep, not the clock. Setup asks for your one-way commute and your caffeine sensitivity, which sets a cutoff of 4, 6 or 8 hours before sleep. Caffeine you log from the Today tab is marked good, borderline or late over the last 14 days.
The Coach tab has short explainers on light, naps, caffeine timing and the daytime sleep environment.

The Shift Recovery Score is built from sleep length, continuity and the timing of your next shift, and like everything else on the screen it is there to inform you; it doesn’t judge your sleep. There is no account, and your data stays on your device; the privacy page has the details, and the design post explains why the app treats daytime sleep as normal.

The advice itself is free and older than any app: a dark room, early caffeine, a nap before the next night, and a doctor if the sleep still won’t come.

The case for a native App Store screenshot tool

2026-03-14T00:00:00+00:00

App Store screenshots are the most underrated assets in indie iOS marketing. They are the first thing a prospective user sees in a search result, and they convert better than any description, keyword, or rating. Yet most indie developers I know treat them as the worst chore of every release (that’s anecdote, not a survey).

I treated them that way for five years. Mockly is the studio’s attempt at something better, and the rest of this post is what I learned shipping it.

What is the fastlane status quo for App Store screenshots?

In the iOS indie world, most people generate screenshots with fastlane snapshot, a Ruby tool that drives the iOS simulator, takes screenshots in every required device size, and writes them to disk. Add fastlane frameit (device frames) and fastlane deliver (upload to App Store Connect) and you have a complete pipeline.

Fastlane deserves credit. It is genuinely useful, its team has done indie developers a public service for nearly a decade, and the tool is open source. If you already have a heavily customised CI pipeline and your screenshots fit fastlane’s templates, it is a reasonable choice.

It is not comfortable to use, though. The workflow is:

Write Swift UI tests that drive your app to specific screens.
Maintain a YAML config of devices, locales, and target screens.
Run a Ruby command-line tool that takes 30-90 minutes for a multi-locale ship.
Hope that nothing in iOS or Xcode broke the simulator automation since last release.
Manually swap or recompose any screenshot that needs editorial work: text overlays, multiple devices in one image, before/after pairs.
Ship.

Every step adds friction, and it compounds. The Swift UI tests rot. The YAML grows. The simulator changes its rendering between Xcode versions without telling you. The editorial work happens in a separate tool (Pixelmator, Photoshop, or hand-coded SwiftUI), so the editorial assets and the automated assets drift apart. By the third release, half the studios I know have given up on the automated path and are screenshotting the simulator by hand.

The native-app argument

Mockly is built on the bet that most indie screenshot work is a GUI problem, and automation solves the smaller part of it.

A GUI tool lets you manipulate the asset directly. You drag the screenshot from the simulator into the app, pick a device frame from a library, add a text overlay, compose multi-device layouts, and see the final result immediately. The locale switcher swaps the underlying screenshot and keeps the layout. The 3D frames are rendered live instead of laid on as PNG overlays, so a four-degree rotation gets proper perspective and lighting, which a flat composite cannot match.

The output is the same PNG files at the App Store’s required dimensions. The workflow is what changes. Each screenshot becomes a small asset you own, edit and re-export when needed, where a pipeline would regenerate it slightly differently every time the simulator runs.

That workflow fits studios that ship a polished, carefully edited set of screenshots: several devices in one image, overlay copy, motion blur on transition shots.

What Mockly specifically does

The feature set, briefly:

3D Metal-rendered device frames. Every iPhone and iPad model from the last six years, rendered when you compose the screenshot. Rotation, perspective, lighting, and reflections are physically rendered.
Localised composition. A single layout, with text, multiple devices, and overlays, exports across 20+ App Store regions in one click. The locale switcher swaps screenshots and translates copy.
Direct upload to App Store Connect. You skip the fastlane deliver step. The app talks to the ASC API and pushes to the right per-locale slot.
Templates. A library of professionally designed templates for common patterns: the four-screenshot hook, the before-and-after, the device-and-watch pairing.
Editorial workflow. Custom layouts, free positioning, drag-and-drop: the full composition tool that fastlane doesn’t try to be.

Mockly deliberately leaves the automation pipeline alone. If your studio has a deep CI/CD investment and screenshots that regenerate from running tests on every release, keep fastlane in your stack. Mockly covers the editorial step upstream of the pipeline, deciding what the screenshot says, for the studios where that is most of the work.

The pricing follows the AppMeta pricing decision from a few weeks back: a one-time purchase with lifetime access. AppMeta later added a yearly option; Mockly has no subscription at all.

Mockly adds Family Sharing support. A two-developer studio (me and a co-founder, two indie partners, a couple-run studio) can share a single $12.99 license. I chose this on purpose. The alternative was per-seat pricing, which suits SaaS and doesn’t suit a tool that small studios use now and then.

The studio loses some revenue to Family Sharing. In exchange, I think, it gets the right relationship with the user: a small indie tool should treat its small indie users like a household, and not like a contract.

Who should stay with fastlane

Not every iOS developer should switch to Mockly. Fastlane serves the largest, most automated indie pipelines well, and many of them have years of customisation that would be expensive to abandon.

My claim is narrower. A sizeable share of indie developers, the studios where screenshot work is editorial first and pipelined second, would be better served by a GUI tool than a CI script. Almost nobody builds GUI tools for indie iOS workflows, because the audience is “just” tens of thousands of developers worldwide.

This studio happens to be part of that audience, and Mockly is for it: $12.99, lifetime, with Family Sharing. If it doesn’t fit your workflow, fastlane will still be there next release.

If you’ve ever sworn at a Ruby script in the middle of a Friday ship, this might be the weekend to reconsider which parts of the chore you actually need.

Why I shipped a Strong-style logger that nobody asked for

2026-03-07T00:00:00+00:00

It’s the first weekend of March. The clocks shift forward in the US tomorrow night, which, through a quirk of biology, makes this the worst week of the year to start a new training program. More on that later.

This weekend’s post is about why this studio shipped a strength-training logger at all, when the category is one of the best served on the App Store.

Why ship another strength logger into a crowded category?

GymLogger X competes with Strong (the long-running incumbent), Hevy (the design-led upstart), Fitbod (the AI-program one), Caliber (the coach-network one) and a long tail of niche loggers. They are all good apps, and the category is not under-served in any obvious way.

When I started building GymLogger X in late 2025, friends in the indie community asked me, gently, why. Features weren’t the reason. The incumbents had one specific thing structurally wrong.

Logging on the wrist

Most strength loggers on the App Store are designed around the phone. The session is laid out for the phone screen, and the watch app, where there is one, is a smaller version of it that lets you peek at the next set, maybe start a rest timer, and sometimes log a set if you tap through three menus.

That is backwards for how a gym session goes. Your phone sits in a bag or on a bench, while your watch is on your wrist, with you between sets. So the watch is where logging should happen.

Building a logger around the wrist is harder than building a phone-first one. The screen is small, the input options are limited (Digital Crown, taps, voice), the latency budget for syncing back to the phone is tight, and Apple’s WatchKit constraints are real. Most apps skip it because the engineering cost is significant and fewer people will use it than the iPhone audience.

I shipped GymLogger X anyway, with the watch as the interface you log on and the phone as the engine in your bag. You start the session on the iPhone, which keeps the record. After that, set entry and rest timers happen on the wrist, and live heart rate is there at a glance. The phone handles analytics, program editing and history review, which benefit from a bigger screen.

The feedback so far: the people who want this really want it, and the people who don’t want it don’t notice it’s there. I’m fine with both.

Plateau detection that doesn’t lecture

The other half of the bet is the analytics.

Most strength loggers track sets and reps and stop there, and their Pro tiers add some trend lines. In my experience none of them will tell you: your bench press has been stalled at 100kg×5 for nine weeks across three different programs, and the most likely cause is your recovery, not your programming.

GymLogger X Pro tries to make that observation, gently. The plateau detection feature compares the estimated one-rep max across your four most recent sessions of each exercise and flags the exercise when that number has stopped climbing while your training volume holds steady, which means it has stalled despite consistent effort. The output is a flag on the exercise, not a notification. It names the likely cause (too much volume, intensity held too high, too little variation, or too little recovery) and suggests two things to try, such as a deload week or a change of rep range. The progress it measures is each lift’s estimated one-rep max, and how that estimate is calculated, and where the formulas stop being trustworthy, has its own post.

It does not restructure your program for you, change your weights, or send you a coach’s nag. Other apps have those features. I think they are things the user should choose to do, and not the app’s place to impose. Plateau detection in GymLogger X is information, and the next move is yours. If it points toward a lighter week, when to deload covers the signs and what the evidence says.

The lifetime price

GymLogger X ships with the freemium model the studio has stuck to: core logging is free for good, Pro is $17.99/year, and there is a one-time $39.99 lifetime option for users who don’t want a subscription on a tool they intend to use for a decade.

The lifetime tier is the one I get asked about most. For a studio chasing recurring revenue, the math on it is poor. A user who buys lifetime in year one and uses the app for seven years has paid the studio a fraction of what an annual subscriber would have. The tier exists anyway because strength training is a long-term practice, and a user’s training history shouldn’t depend on keeping a subscription going.

About 30% of GymLogger X paid users choose the lifetime tier. They are vocal and loyal, and they are the users I’m proudest to serve.

The daylight-saving note

Back to the calendar. This weekend the US shifts to daylight-saving time. Most US adults will lose an hour of sleep on Sunday night, and most of them won’t realise the loss has measurable consequences for the following week’s training.

The research on this is unambiguous. Acute sleep restriction reduces strength performance by 5-10% the next day, noticeably raises perceived exertion, and depresses recovery markers (HRV, resting heart rate) for several days. In the gym it shows up as a lift that felt easy last Tuesday feeling heavy this Tuesday, with the lifter blaming their effort instead of their sleep. If you rate your sets, how RPE and reps in reserve work explains why the same load can rate harder after a short night.

If you started a new strength program on January 1 and have been progressing well, this is the week the curve will flatten, and the time change is the cause. Take Tuesday’s session at last week’s weights instead of pushing for new ones, and resume normal progression next week. GymLogger X won’t lecture you about it, but I will.

The short version

GymLogger X exists because the category had a structural gap, logging designed for the wrist, and nobody seemed to be filling it. It has a lifetime price because strength training is a long game, and plateau detection because the data needs someone to interpret it.

For the polished iPhone-first side of strength training, the studio also ships LiftLog, a sister app with a completely different pricing experiment. The two serve different lifters.

Forty chess opponents, and none of them are me

2026-02-28T00:00:00+00:00

I learned chess from my grandfather and never got past competent. The reason I built Chessful is precisely that gap: I wanted an app that explained what I’d done wrong in a way my grandfather would have, in plain language, instead of pointing at a centipawn evaluation graph and expecting me to read it.

The app shipped with two features that took disproportionate engineering effort. One was the post-game analysis, which is the feature users actually mention. The other was forty distinct AI opponents, which carry everything else without anyone noticing. This post covers both.

What’s wrong with the slider-based chess opponent?

Most chess apps offer a slider from Level 1 (weak) to Level 20 (engine-strong). The slider feels reasonable until you play it for a week and realise something specific:

The engine plays the same way at every level. It just plays worse on purpose at lower levels, by adding noise to its evaluation function. Level 5 is the same opponent as Level 15, making mathematically random mistakes. After a dozen games you can feel the noise. The mistakes have nothing to do with any style, and no real opponent plays that way.

The result is that improvement against the engine slider doesn’t transfer well to playing humans, because humans have characters. They favour certain openings. They get into trouble in specific structural positions. They have blind spots: the bishop on the long diagonal they always miss, the rook on the seventh rank they always overestimate.

If you’re trying to build a chess app for improvement, the slider isn’t enough. You need opponents that feel like people.

The forty opponents

Chessful ships with forty AI opponents, each with a distinct rating, opening repertoire, structural preferences, and a small set of characteristic blind spots. Every opponent has a name, a portrait, and a one-paragraph backstory. They are explicitly fictional. None of them imitates a specific real grandmaster, which is a line I won’t cross, but each one is recognisable as a type.

There’s the aggressive Sicilian player who attacks the kingside relentlessly and sometimes overcommits. The positional grinder who exchanges pieces to reach better endgames. The fianchetto specialist who handles the long diagonals beautifully but flails in tactics. The student who plays well in opening theory but forgets it after move twelve. The 1700-rated club player who is slightly drunk on a Tuesday night and slightly sober on a Thursday morning.

Each opponent is built from a base engine with a style overlay: modifiers to the evaluation function that nudge it toward characteristic moves, openings, and structural decisions. The implementation is unglamorous, mostly piecewise weighting of evaluation features (mobility vs. king safety vs. pawn structure vs. material) tuned by playing thousands of games against a fixed test set and watching for behavioural drift.

The result is recognisability. After ten games against the aggressive Sicilian player, you start to anticipate her openings and learn where her blind spots are, and you are playing against her instead of an abstract evaluation function. That is what makes the games feel like games, and it is why improvement against Chessful’s opponents transfers to playing humans.

The post-game analysis

The other feature that took disproportionate effort is the post-game analysis, and it is the feature users write to me about.

The standard chess-app analysis flow is: play a game, hit “analyse,” watch the engine annotate every move with a depth-15 evaluation. The output is technically correct and almost completely unreadable for anyone below 1800 rating. “You played 18.Re1, computer prefers 18.Bxh6 with eval +1.4.” Yes, but why?

Chessful’s analysis tries to answer the why in plain language. It finds the move that lost the game and the threat the user missed, then explains in one or two sentences what was happening structurally. Sometimes it suggests the principle the user should remember, such as “Trades that benefit your opponent’s pawn structure are usually bad even if material is even”, or “This is a known weak square for the bishop in the Caro-Kann”.

The implementation is a layered model: the engine identifies critical moments, a smaller language model produces the explanation in natural English, and a hand-curated set of pattern detectors flag known motifs (back-rank weakness, isolated queen pawn, knight on rim). Together they produce something that reads like a chess teacher talking.

What Chessful does not do

Chessful is not a chess.com replacement. It does not have ranked play, leaderboards, or live human matchmaking. The studio’s deliberate position is that those products exist and are excellent at competitive play, with the world’s best chess infrastructure.

Chessful is for the player who wants to improve on their own against varied opponents, with explanations they can actually read, on a flight, in a kitchen, or between meetings. It needs no account and no internet, and there is no ranking attached to your name to be embarrassed by.

A small accidentally-personal note

I’ve never told anyone this in print before, but the reason I made the post-game analysis read like a teacher is that my grandfather was a chess teacher in the Soviet Union before he was anything else. I lost him in 2019. The voice in Chessful’s annotations is, I am told by family who would know, more or less his.

It’s how the prompts ended up calibrated. If you find the explanations unusually patient, that’s why.

Chessful is on the App Store. It is free to try, and premium unlocks unlimited analysis and the full forty-opponent roster. If you’ve been looking for a chess app that explains what you did wrong without making you feel like an idiot, this one might be it.

On building a native Mac client for App Store Connect

2026-02-21T00:00:00+00:00

App Store Connect, Apple’s web tool for shipping apps, is the web app that matters most in an indie iOS developer’s day. It’s where you manage metadata, push builds to TestFlight, respond to reviews, set pricing, file privacy declarations, and submit for review. Almost every studio I know spends an hour a day in it during ship weeks.

Underneath, it is a web app from 2014 that has piled on features for a decade. It works. On a long-haul flight, or in a tab next to fifteen others, it is also miserable.

I built AppMeta, a native Mac client, so I could stop being miserable.

The problem ASC has, specifically

In fairness, App Store Connect’s design constraints are not Apple’s fault. Apple manages the metadata for several million apps across two hundred regions in forty languages, with regulatory edge cases in every market. Building a great web tool on top of all that is hard, and the team behind ASC ships a lot.

What ASC isn’t optimised for is an indie developer with five to fifty apps shipping across twenty locales. The specific problems:

Localised metadata editing is one locale at a time. Editing a description in fourteen languages means switching the locale dropdown fourteen times. There is no side-by-side view.
Keyword fields are 100 characters per locale, with no cross-locale gap analysis. Indies find the same keyword waste again in every language because no tool points it out. (The rules for that field, and the folklore around it, now have their own post.)
Review responses are a per-app web flow with no inbox. If you have ten apps, you have ten places to check.
Version submission requires a multi-step flow with hidden state. “Did I save the export compliance? Did I tick advertising identifier? Did I attach the encryption form?” These have all bitten me. So has forgetting which fields only change with a new version.

None of these is catastrophic on its own. Together they are why I had a recurring “App Store Connect” calendar block on Friday afternoons for two years before I shipped AppMeta.

What does a native App Store Connect client actually change?

At its centre, AppMeta is a Mac client that talks directly to the App Store Connect REST API and shows your apps’ metadata side by side. It signs in with an API key you create yourself in App Store Connect; the key setup guide walks through that. It changes four things.

Side-by-side localised editing. Pick a field and every locale’s version of it is on one screen: the English description, then the German, French, Japanese, and Spanish ones below it, each editable in place. Or pick a locale and edit all of its fields together. Changed fields are marked, and you push when you’re ready. The hour-long localisation pass takes ten minutes.

Diff preview before push. Before anything is pushed, AppMeta shows exactly what will change against the current live metadata. I trust this feature more than I trust myself, because it caught a typo in five different localisations the day before I would have shipped them. After that happens to you once, you don’t ship without a diff preview again.

Cross-locale keyword analysis. AppMeta computes per-character keyword use across every locale and points out wasted space, duplicates, and gaps. I used to keep this in a spreadsheet by hand. Now it’s a panel in the app.

Reviews in a native list. Each app’s reviews, from every storefront, sit in one list you can sort by date or rating, one click away in the sidebar instead of behind ten slow page loads. Pick a review, type a response, send. The response still goes through ASC’s regulated channels, with Apple as the source of truth, but you never leave the Mac.

There’s also version submission, screenshot management, pricing changes, and a few smaller things. What matters more than the checklist is that every minute of friction the web tool adds compounds over a year of shipping.

Why a lifetime price, not a subscription

People ask me about this more than anything else about AppMeta, so here is the plain answer.

App Store Connect tooling is a developer tool, and developer tools have a long history of subscription pricing: JetBrains, Sketch, Figma, Linear. The market would happily pay $19.99 a month for a good ASC client. I considered it.

I shipped AppMeta as a one-time $29.99 purchase because subscriptions give a tool like this a specific bad incentive. Every month you have to ship enough perceived value to justify the next charge, and that pressure pushes the roadmap toward more features when it should go toward the right ones. AppMeta’s job is to be a fast, reliable native client, and features added to get through a renewal cycle would make it worse at that.

A one-time purchase imposes a different discipline. The tool has to be worth $29.99 once, and the next sale has to come from a new user who thinks so, not from a renewal charged to an existing one. Revenue comes in more slowly, and in exchange the design stays honest.

What AppMeta is not

AppMeta is not a build pipeline tool. It does not replace fastlane, Xcode Cloud, or your CI. It does not generate screenshots; that’s Mockly’s job. Revenue on the phone is AppMeta Pulse, the iPhone companion.

It is the native client for the metadata and review side of App Store Connect, the part you spend an hour a day in during ship weeks and the part that needed to stop being miserable.

The short version

If you’re an indie iOS or macOS developer shipping in multiple locales and you’ve spent a Friday afternoon flipping through the locale dropdown, AppMeta is the studio’s answer: $29.99, one time, lifetime. Demo mode is free if you want to look around before you buy.

If you’re not an indie developer, this has been twelve hundred words about a niche tool, and you’ve made it admirably far. Thanks for reading. The next post will be about chess.

How to split a Valentine's dinner without making it weird

2026-02-14T00:00:00+00:00

It is February the 14th. Somewhere in the world right now, a table of four friends is staring at a $312 receipt at the end of a dinner. Three of them had the steak, one had the salad and a glass of wine, and someone is doing math on a napkin.

This is a small post about that moment and the app I built for it.

Why is “split equally” unfair?

Most splitting tools default to dividing the bill into equal shares. That works when everyone ordered roughly the same things and stops being fair as soon as the orders differ.

An equal split makes the lighter eater pay for everyone else. The salad-and-wine person at our imaginary table pays $78 for an order closer to $32. They won’t say anything, because the maths is awkward and asking costs more socially than the $46 is worth. They will resent it a little, the next dinner will feel slightly different, and after a year of small inequalities the friendship has lost some trust without anyone being able to say when it happened.

Item-level splitting fixes this. With the right tool it takes thirty seconds; without one, it takes ten minutes and a calculator.

The Splitwise problem

In the early 2020s most people solved this with Splitwise. It works, but every participant needs an account. The four friends at the table end up signing up for an app that will email them about IOUs for the next eight months because one of them couldn’t be bothered to settle.

For a recurring group (roommates, a partnership, a regular travel circle) that overhead is fine, even useful. For a one-off Valentine’s dinner with friends, it’s a cost nobody asked to pay.

RightSplit starts from the other end: the group should not need to download anything. Only the person doing the math has the app.

The flow

This is how I picture RightSplit doing its job:

The receipt arrives. One person picks up the phone.
They take a picture of the receipt. The app reads the items, prices, and tax.
They tap each item, then tap the names of the people who had it. A bottle of wine shared by two gets split 50/50, a round of beers shared by three works the same way, and a steak goes to the person who ordered it.
The tip is calculated and distributed proportionally (the arithmetic, worked all the way out).
The app writes four short messages, one per person, each with the exact amount, plus a pre-filled pay button if the owner has saved a Venmo, PayPal.me, Revolut or Wise handle. The owner sends them in iMessage or WhatsApp.
That’s it. The app keeps the split in case the owner wants to look at it later.

That’s the whole product. Nobody gets a shared account, a stream of notifications, or an IOU ledger that follows them around for nine months. The group never has to install RightSplit, and all the effort sits with the person who is already holding the phone.

What item-level splitting buys at scale

The design pays off more as groups get bigger.

For two people, item-level versus equal split rarely matters, because the amounts are small.

For four people, item-level splitting recovers an average of $20-40 per dinner over an equal split, in favour of whoever ordered modestly. That’s small, but it adds up over a year of group meals.

For ten people (bachelor parties, family dinners, work outings), the difference between item-level and equal splitting can be $80-150 per person. At that size, an equal split is unfair enough to turn a fun dinner into an awkward Venmo argument the next morning.

RightSplit Pro+ adds unlimited receipt scans, item-level splitting, uneven splits (the person with the bigger appetite explicitly takes a 1.5× share), unlimited history and Spaces, for $3.99 a year or $7.99 lifetime. The free tier covers equal splits, the tip calculator, your last five splits and your first receipt scan, which is enough for most two-person dinners.

A note on small kindnesses

Some software exists only to remove a little friction between people, and I think that kind of software is undervalued. Any single split moves very little money. Skipping the awkward conversation about the bill matters more than the money does. Friends remember small kindnesses, and they remember small inequalities even longer.

If you went out to dinner tonight and someone is staring at a receipt right now, take this as a hint that the math can be easier.

Happy 14th.

Reading without a feed: a quiet year with Wikipedia

2026-02-07T00:00:00+00:00

Sometime in late 2024 I deleted the last social feed off my phone. I’d like to say it felt clean and freeing, but I spent the next few weeks reaching for the phone, swiping to where the app used to be, finding empty space, and not knowing what to do with the hand or the attention.

Withdrawal was the easy part. The hard part was that nothing else had been trained to fit the same hole. The five-minute window between meetings, the queue at the coffee shop and the two minutes waiting for the kettle had been algorithmic-feed time for a decade. Without the feed they were just silence. Silence is fine, but a brain that’s been on dopamine for ten years doesn’t yet know what to do with it.

WanderWiki is the app in this catalogue I built most directly for that hand and that hole.

What did I want from a reading app?

The brief I wrote for myself was small. I wanted an app that:

Loaded fast enough to fill a thirty-second window without a loading spinner.
Showed me something interesting on first launch without asking what I liked.
Got more interesting if I told it what I liked, without tracking what I tapped.
Worked on a flight without an “offline mode” hidden behind three menus.
Didn’t have a feed, or at least didn’t try to be infinite.

Wikipedia was the obvious source. It is the largest collection of well-written, fact-checked, structurally consistent prose in human history, and it’s available under a Creative Commons license. If I couldn’t build a calm reading habit on Wikipedia, the fault would be mine.

“For You” without tracking

Reading apps without a feed run into one problem: pure randomness gets boring quickly. Wikipedia has around seven million English articles, and every language edition is a different encyclopedia. A truly random tap will give you Italian municipality of 800 people, American politician (1820-1888), and insect taxonomy in a row, and the user will close the app.

Most apps solve this by tracking what you read, building a profile, and using it to weight the recommendations. That works, and it’s exactly what I deleted off my phone.

So can you have For-You-style relevance without behavioural tracking? WanderWiki’s answer is yes, if you ask the user what they like instead of inferring it. In a one-screen onboarding the user taps interest topics (Science, History, Space, Architecture, Music, Food, sixteen in all), and the For-You feed draws its articles from the Wikipedia categories behind those declared preferences.

The user can change the topics any time. What you read or skip doesn’t feed back into what For You picks, and none of it leaves the phone. There is no behavioural model. That makes it less personalised than a feed-based reader, but easier for the user to correct: if the recommendations go off, the only thing to fix is the list of topics you can see on screen.

Today in History

The one piece of editorial scaffolding I did keep is the Today in History view. Switch to it and WanderWiki deals out the notable events that happened on the current calendar date. A treaty in 1648. A first ascent in 1953. A scientific paper in 1979. A peaceful transition of power in 1994.

It works for the same reason it always has in newspapers: content tied to a date gives the brain a small handhold. It’s this day, in another year, the same calendar slot occupied by a different version of the world. It’s the feature I get the most direct user feedback on, which is why I kept it.

Reading offline

The other constraint I held to was that the app should be some use on a plane.

Here WanderWiki only partly delivers. A discovery deck is live by nature: Random, For You and Today in History all ask Wikipedia for something new, and on a plane there is no Wikipedia to ask. What WanderWiki does is keep what you save. Save an article on the ground and it is on the phone at cruising altitude, in the same list you use online, with no separate offline mode and no download screen.

If you want the whole encyclopedia offline, that is a different engineering problem, and Kiwix solves it. WanderWiki handles the small reading list you build while wandering, which is still there on a 13-hour flight, when a feed replacement is most welcome.

What it gives up

A reading app with no feed and no behaviour tracking is not going to outcompete Twitter for attention, and it shouldn’t try. WanderWiki sessions are short, two articles or sometimes three, and they end when the user has had enough. That is intentional, and session length is the one metric where I want WanderWiki to come in below the competition.

Daily active users is a noisy number for an app like this anyway. The better test is did I just read something the algorithm would not have shown me, and did I close the app before I lost ten minutes I didn’t mean to lose?

Where this fits in the catalogue

WanderWiki sits alongside a handful of other apps in this privacy-first catalogue that share one idea: the replacement for the feed doesn’t have to be productive, but it should be calm, finite, and yours.

It’s a Saturday in early February, and the internet is doing whatever the internet does. If you’ve been looking for something to fill the small windows that used to be filled by something worse, you could do worse than three Wikipedia articles and a quiet kitchen.

Update, 25 October 2026: WanderWiki has grown since this was written. It now keeps a reading streak, shown on the Profile tab and in a widget, and if you allow notifications it sends one daily reminder, which you can retime or turn off in Settings. The free tier stops at 20 articles a day; WanderWiki Plus swipes without a limit. For You still works from the topics you pick and nothing else.

I will not ask for your bank login

2026-01-31T00:00:00+00:00

It is the last Saturday of January. I have just done my own taxes for the year, which is a job I always do badly and never on time. While doing them I noticed that three of the apps on the Productivity charts of the App Store are bill trackers that connect to your bank. Two of them have grown sharply in the last twelve months. All of them open with the same onboarding flow:

To get started, please log in to your bank.

AllPaid, the bill-tracking and subscription-management app this studio ships, does not have that flow and is not going to. This post explains why.

What does “log in to your bank” actually do?

When a non-bank app asks you to log in to your bank, what happens underneath isn’t quite what most users think. You’re typing your bank password into a third-party screen. That third party is almost always Plaid, occasionally MX or Finicity. The third party stores your credentials or, in newer arrangements, holds an OAuth token issued by your bank. Either way it gets persistent read access to your account: transactions, balances, and often historical statements.

The app you actually wanted to use then connects to the third party, not your bank, and pulls a feed of transactions filtered through that aggregator’s models.

This is the standard architecture of fintech. It’s regulated, and most of the time it works. It also has three properties that users should know about:

Your bank credentials, or a token derived from them, now live somewhere they didn’t live before. That somewhere is a target.
The aggregator can see every transaction in your account, in perpetuity, until you revoke access, including when the app you signed up for doesn’t need that data.
Aggregators are a business. Their growth depends on cross-selling the data they aggregate to other applications, anonymised or otherwise. The anonymisation is sometimes meaningful and sometimes not.

I don’t think aggregators are evil. I do think the convenience tradeoff isn’t priced into the user’s mental model when they tap Continue on the onboarding screen.

What you’re actually buying

The promise of bank-linked bill apps is that they will find your subscriptions and bills automatically. You sign up, give them read access, and a list of recurring charges appears.

This works, and it is genuinely useful. It is also doing two things, and only one of them is what the user asked for.

The first is identifying recurring charges, which is the useful part.

The second is building a picture of every other thing you spend money on, which you never signed up for and which is the asset the company is actually building. The bill tracking is a pretext for the data pipeline. Some of these companies are open about it (for the ones whose business model is “find subscriptions you forgot about and offer to cancel them”, that is the value exchange). Some are quieter.

Either way, the user pays with read access to their entire financial life for a feature that comes down to a list they could have written themselves in twenty minutes.

The manual-first answer

AllPaid starts from a different premise: most people have somewhere between five and forty recurring bills, and entering them once is not a difficult problem.

The app is manual-first. You type in your bills, your subscriptions, the rent, the utilities. The app stores them locally on your device, reminds you when they’re due, supports a calendar view, lets you tick them off, and shares specific bills with a partner if needed. With widgets and Siri integration there is almost no daily friction; “Hey Siri, what’s due this week?” takes one tap. There’s a Pro tier that adds spending analytics and full payment history, also fully on-device.

What the app does not do, and will not do:

It does not connect to your bank.
It does not connect to a third-party aggregator.
It does not have an account system, so there is no login, email collection or profile.
It does not see anything you do not type into it.

On paper this is less convenient than a Plaid-connected app. In practice the gap is smaller than people expect. Entering everything the first time takes about fifteen minutes if you have a long list. After that, the work is tapping a notification to mark a bill paid, which is the same effort a bank-linked app asks for, at a lower cost.

What this trades away

Bank-linked bill apps catch one category of bill that AllPaid will miss: the subscription you signed up for, forgot about, and would not remember to enter into a manual app. The classic “$8.99/month for that streaming service you used twice in 2023.” That is a real benefit, and AllPaid does not offer it.

If finding forgotten charges is the user’s primary need, a bank-linked tool is the better fit, and I’d recommend one. Just know what you are giving up when you connect it.

Manual-first works for everyone else: people who know roughly what they pay for, want a reminder to pay it, want to share rent with a roommate, want a calendar view of the next thirty days, and don’t want a third party reading their checking account in perpetuity.

A note on tax season

This post is going up on the 31st of January, and the timing is deliberate. Tax season is when people look at their finances most carefully and most apprehensively. It is also the season when fintech apps run their biggest advertising spend, because conversion is highest when anxiety is highest.

AllPaid is meant to be the calmer answer in that window. It skips the bank login and the anxious onboarding, keeps everything local, and does the boring job of making sure you don’t miss a bill or pay a late fee. It’s free, with Pro at $1.99 a month, $12.99 a year, or $24.99 lifetime, so no subscription is required.

If this is the year you stop trading read access to your bank for features you could write down yourself, we think you’re right.

Building a sleep app for nurses, pilots, and the people who don't have a 9-to-5

2026-01-24T00:00:00+00:00

A friend who works ICU nights asked me, in 2024, why none of her sleep apps understood what she was doing.

She’d open one of the popular ones, log a five-hour daytime sleep, and the app would politely tell her she’d had a poor night and should try going to bed earlier. The app meant well. Its model of a human was someone who sleeps at night. Her model of a human was a nurse who sleeps when the rotation allows.

That conversation was the start of AfterShift. This is what I learned building it.

Why is the 9-to-5 assumption everywhere in sleep apps?

Open any major consumer sleep app and walk through onboarding. You’ll be asked when you go to bed, when you wake up, and what your weekend pattern is. The app assumes a five-day workweek with weekends free, and it assumes “night” means one uninterrupted block of darkness.

Now take a typical nurse’s twelve-hour rotation: three days on, three days off, a two-week cycle, with days flipping to nights halfway through. Her sleep windows might be 10pm-6am one week and 9am-3pm the next, with a chaotic transition night in between. The sleep app’s model breaks, its recovery scores make no sense, and its caffeine recommendations actively harm her. (Most rosters like hers are variations on a handful of named patterns; rotating shift schedules explained lays out DuPont, 2-2-3 and the rest, and which are hardest on sleep.)

This is a real population. The US has about 4 million registered nurses and several hundred thousand commercial pilots, plus paramedics, firefighters, police, factory workers, refinery operators, and a long tail of other rotating-shift workers. Generic sleep apps serve none of them well.

What “shift-aware” means in practice

The first difference between AfterShift and generic apps is what counts as a sleep session. AfterShift accepts:

A primary sleep block of any length, at any time of day, on any day.
Optional naps before or after the primary block. Pre-shift naps are a recognised fatigue countermeasure for night work, and post-shift “anchor sleeps” before transitioning back to days are another.
Fragmented patterns. A six-hour sleep broken once is structurally different from an unbroken six hours, and the app treats it that way.

The second is the Shift Recovery Score, the metric I’m proudest of. It isn’t a sleep score in the consumer sense. It’s a forward-looking estimate: given the sleep you’ve had since your last shift, the rotation pattern you’re on, and how fragmented your recent sleep has been, how recovered are you for the next block?

It’s calibrated against shift-work fatigue research, not the average iPhone user’s resting heart rate. A 7-hour daytime sleep before a night shift can score higher than an 8-hour night sleep before a day shift, because the first one sets you up for the coming work block and the second is misaligned with it. Generic sleep apps penalise the daytime sleep and reward the night sleep, which is backwards for this user.

Caffeine timing deserves a whole feature

The other surprise in building AfterShift was how much research exists on caffeine timing for shift workers, and how little of it reaches consumer apps.

The short version: caffeine has a half-life of about five hours. A coffee three hours before bed leaves enough in your system to disrupt sleep onset and sleep architecture. A coffee at the start of a night shift keeps you alert when you least want it, at 9am when you finally try to sleep. The right strategy depends on which way your shift is rotating, and most shift workers work it out through years of trial and error.

AfterShift builds the strategy in. Tell the app your upcoming shift block and it gives you the latest sensible caffeine cutoff that still protects your post-shift sleep. It’s not glamorous, but going by user feedback it is the most-mentioned feature. The rest of the routine for the day after a night shift, from blackout shades to the nap before the next one, is in how to sleep after a night shift.

What it takes off the user’s plate

I also underestimated how much administrative load shift workers carry around their own sleep. Knowing when you slept and when your next shift starts, working out recovery in your head, deciding whether you need a nap: all of it runs in the background of their day, on top of the job itself.

AfterShift takes that over. Calendar shift import handles the schedule (most large employers publish rotations to a calendar feed nurses can subscribe to). Sleep windows are planned from the shift times, actual sleep is read from Apple Health, and the caffeine timing updates automatically when shifts change. The user doesn’t have to keep doing the math.

With the math gone, the mental load drops, and with less load, people sleep better. I didn’t predict that second-order effect.

Who it isn’t for

AfterShift isn’t a general sleep tracker. If you have a stable 9-to-5 schedule, Observa is the better fit from the studio: it interprets all your Apple Health data, with sleep as one of the categories. AfterShift is for people whose schedule is the problem.

It is also not a clinical tool. Sleep disorders such as narcolepsy and sleep apnoea need a sleep clinic. AfterShift’s Shift Recovery Score is informational and not a diagnosis. I’d rather lose users to a real doctor than oversell what consumer software can do.

Why we built it

A whole category of work keeps modern infrastructure running (healthcare, transport, public safety, manufacturing), and consumer software has mostly designed around the people who do it. AfterShift was an experiment in designing for them, starting from the assumption that their schedule is the normal life of millions of people and not a deviation from it.

If you work nights, rotations, or anything else that breaks the 9-to-5 mould, the app is on the App Store. And if you know a nurse, pilot, or paramedic who has been putting up with a generic sleep tracker, send them the link.

Your Apple Health data isn't telling you what you think it's telling you

2026-01-17T00:00:00+00:00

I have worn an Apple Watch since 2018. By the time I started building Observa, Apple Health had eight years of my data: sleep, heart rate, HRV, ECG readings, mindfulness minutes, workout sessions, blood oxygen, walking steadiness, the lot.

I had no idea what any of it meant.

I mean that literally. I could open the Health app, watch a number go up and down, look at a chart shaped like a small mountain range, and still not answer the only question that mattered: should I do anything differently this week?

Observa exists to answer that question.

What is Apple Health good at?

Apple Health is excellent at what it’s built for. It collects, normalises, and stores health metrics with privacy guarantees no other consumer system has offered. The charts are well designed, the unit handling is careful, and the data layer is, honestly, the best in the industry.

What Apple Health doesn’t try to do, and in my view shouldn’t, is editorialise. It won’t tell you that your HRV dropped because of last week’s two short nights. It won’t connect your morning resting heart rate to the wine you drank on Saturday. It won’t say, “your training load is twenty percent above your eight-week average and your recovery scores are dropping; consider a deload week.” Apple is right to hold back here. Health data is sensitive, and over-interpretation is a real danger.

For the user, though, that restraint leaves a gap: you have the data and nothing that tells you what it means.

The chart-trance problem

If you’ve ever spent twenty minutes scrolling through a year of HRV measurements looking for a pattern, you know the problem I mean. The brain is bad at spotting patterns in noisy time series. We see trends that aren’t there and miss ones that are. We anchor on the latest measurement. One low reading makes us anxious and one high reading reassures us, and statistically neither means anything.

More willpower won’t fix this, because the problem is the display. A chart with seven hundred data points and no overlay works more like a Rorschach test than a tool.

What Observa does

Observa sits on top of Apple Health and answers a small set of questions directly:

What variable is most correlated with your sleep quality this month? Maybe it’s training volume. Maybe it’s screen time before bed. Maybe it’s the day of the week (don’t underestimate Sunday-night anxiety as a predictor).
What does your HRV trend look like, normalised against your own baseline? Your baseline, not the population’s. A 38 ms HRV reading means nothing until you know whether your personal baseline is 32 or 56.
Which days in the last 90 deviated most from baseline, and what else changed on those days? This is where the interesting stories are, the ones where you say “oh, of course, that was the week I flew through three time zones.”
Is your training load keeping pace with your recovery, or are the two diverging? If they diverge, you are building up fatigue, however the individual workouts felt.

None of this is a medical diagnosis. Observa can’t tell you whether you have a clinical sleep disorder, a cardiac issue, or an autoimmune condition, and it won’t pretend to. What it can do is take a year of your own data and turn it into the three or four sentences a thoughtful coach might give you if they had time to read it carefully, which most coaches don’t.

Why this had to be on-device

The other constraint behind Observa is the obvious one: health data should never leave your device.

That’s a statement of values, and it’s also a technical decision with real consequences for the product. A cloud version of Observa could use better correlation models, larger datasets, and more compute. It would also be a target for breaches, a regulatory minefield in several jurisdictions, and, worst of all, something the user couldn’t verify.

Observa’s correlation analysis runs on the device, using local models small enough to fit in the app bundle. The analyses are simpler than what a cloud service could do. In return, nobody but you ever sees a single data point. There is no cloud account to compromise, no employee with database access, and no future press release about having “accidentally trained a model on your sleep data.”

I think that’s the right tradeoff for health data. I know not everyone agrees, and for some uses, such as clinical research and longitudinal population studies, on-device can’t compete. Observa isn’t built for those. It’s the interpretation layer for one person’s own life, and that person owns it.

What this means in practice

If you keep opening the Health app, scrolling, and coming away with nothing, Observa was made for you. It reads what’s already in your Health database (with your permission, limited to the categories you allow) and gives you a weekly read in place of a panel of charts.

It won’t tell you what to eat or when to sleep. Now and then it will tell you something specific and useful, like “your resting heart rate has been elevated for three weeks and the most likely correlate is training volume,” and leave the decision to you.

That’s the whole product: Apple’s data layer plus a thin layer of honest interpretation. It has no tracking, no upload, and no account, and it gives no medical advice. It does the modest, useful job the Health app leaves undone.

A streak counter is a debt the user owes the app

2026-01-10T00:00:00+00:00

Last Saturday’s post made the polite case against guilt-driven fitness apps. This week’s is the structural one, and it’s a specific argument about Taskful Day, the daily planner this studio ships.

What is a streak counter, actually?

A streak counter looks like a positive number. The app tells you: seven days in a row. Twenty-eight days in a row. One hundred and forty-three days in a row. The number goes up, and it feels like a reward.

The same counter has a second behaviour, and that one drives the engagement loop: on a miss, it resets to zero. Not to N − 1. To zero.

That asymmetry is what makes a streak work as a growth lever, and it’s also what makes it a debt instrument dressed up as a reward.

A 143-day streak on screen doesn’t say “you’ve earned this.” It says “if you don’t open me tomorrow, you owe me 143 days.” The number is denominated in future panic. Each additional day inflates the debt, and the longer the streak, the more painful the reset and the more hostage-y the relationship.

Apps know this and build it on purpose. Every meditation app, language app, and habit tracker shipped a streak counter the moment Snapchat showed it worked. Designers don’t add it because users want it. Users don’t want to lose it, and that reluctance is exactly what gets the app opened.

The ratchet effect

Streaks do something else that might be worse than the obvious cost.

Once a long streak exists, the user starts behaving worse to protect it. They open the app at midnight to log a fake meditation, mark a task complete that they didn’t do, walk circles in the kitchen to hit the daily steps, or train through an injury they should be resting.

The number the app shows as proof of progress makes them do less of the actual progress. This is Goodhart’s Law in two taps. The streak stops measuring consistency and starts measuring “willingness to lie to the app to avoid the pain of resetting.”

If your tool’s headline number rewards users for behaviour they’ll be ashamed of later, you’ve built a dependency, and calling it a tool doesn’t change that.

The Taskful Day alternative

When I designed Taskful Day, I skipped “should we have a streak?” and asked “what does the app show where the streak would normally go?”

Nothing, it turned out.

The home screen shows today’s plan and today only. Yesterday’s incomplete tasks aren’t marked red or scolded. They come back as follow-ups, a small prompt that says, in effect, “this is something you said you wanted to do; tap to bring it to today, or dismiss it.” The user decides. The app doesn’t comment on whether yesterday was a “good day” or a “bad day.”

There’s a reflection view and a focus-session timer if you want them, and neither turns into a punishment system. The app doesn’t know whether you had a productive day, and it shouldn’t pretend to.

The cost is a weaker “open the app every single day or else” loop, so daily-active-user numbers are lower than they would be with a streak. I know because I built a prototype with a streak counter, watched the engagement curve, and turned it off anyway.

What it buys

What the design buys is something I think of as week-three trust.

When a user opens Taskful Day for the first time in five days, the app doesn’t yell at them. There’s no flame, no “you broke your streak,” and no catch-up modal. Today’s plan is there, and they can use it or not.

Most users in that situation mention the same thing in feedback: relief. Every other planner had trained them to expect punishment, and when it doesn’t come, they open the app the next day. Not being a guilt machine turns out to be a retention strategy too, just a slower one.

I don’t think Taskful Day will ever match the daily-active-user numbers of a streak-driven planner, and I’m fine with that. The users it keeps use it the way it’s meant to be used, as a tool that meets them where they are and not a counter they’re chained to.

The position, plainly

Streak counters work for the app. They’re brittle and punishing, they corrupt the metric they claim to measure, and they teach users to lie to their tools. Refusing them has a small craft cost and a real product cost, and both are worth paying.

If you want a planner that doesn’t keep score against you, Taskful Day is what this studio offers.

If you want a streak app that respects you, there isn’t one, because the streak is what stops it from respecting you.

If your fitness app is making you feel guilty in week one, that's the design, not you

2026-01-03T00:00:00+00:00

It’s the third of January and the fitness apps are already doing the thing.

The thing starts with a gentle, well-designed, nicely typeset push notification saying you missed your goal by just a little, which is a shame, but you can still recover if you log in right now. After that comes a streak counter that resets if you don’t open the app for two days, a leaderboard against three friends you haven’t seen since college, a coach character with a frowning face, and a colour change from green to amber to red as the days slip.

I’m not making fun of these apps. Talented people design them, the typography and animations are good, and they convert. They are doing exactly what their growth dashboards reward. They are not helping you train.

The mechanism

If a fitness app has ever turned on you in week two, this is what was happening on the engineering side:

You signed up because you wanted to do something more consistently.
The app measured “consistency” with a streak counter, a single integer that resets to zero on any miss.
Streaks are sticky in the short term. People do open the app to keep them alive.
Streaks are also brittle: miss one day and the counter resets. The app’s growth team knows this, and it’s why streaks work. The fragility keeps you opening the app.
So when you miss day four, the app punishes you, you feel bad, and one of two things happens. You panic-open and log a fake workout to save the streak, or you slide into feeling bad and quietly stop opening the app for the rest of the year.

You didn’t train in either case. One is theatre and the other is a churned user. Both feel like the app’s fault, and they kind of are.

What does a non-hostile fitness app look like?

A handful of design choices reliably mark an app that will still treat you well in week three:

No streak counter on the home screen. If there is one, it doesn’t reset to zero. It counts total days trained over your lifetime and never goes down, so missing Tuesday costs you nothing.
Follow-ups for missed work. Tasks or workouts that didn’t happen yesterday aren’t punished or marked red. The app offers them to you again today. They roll forward and nothing resets.
No comparison with people you didn’t choose. Leaderboards are off by default, and there are no friends whose routines you’re pushed to compete with.
Notifications that explain themselves. “You haven’t logged in three days” is hostile. “Your last lifting session was Thursday. Here’s the program for tomorrow if you want it” uses the same data and treats you like an adult.
A way to leave for a week without losing your data. People go on holiday, get injured, get busy. The app should be where you left it when you come back.

What this studio ships

Taskful Day is a daily planner with no streak counter, flame, or red X. Unfinished tasks roll forward to tomorrow. There is a focus-session timer and a reflective view if you want them, and nothing pretends to know whether you had a “good day” or a “bad day.”

GymLogger X is a strength-training log without a social feed, leaderboard, or streak guilt. It tracks sets, reps, PRs, and 1RM trends. If you skip a week, the app does not turn red.

Fitness apps don’t have to be flat and joyless. Pacing and motivation take real craft, and so does the small celebration when you hit a personal record. My complaint is with a baseline that runs on guilt. A celebration should come from what the user achieved, and the app shouldn’t squeeze it out of them by punishing the rest of their life.

A small ask for the third of January

If you set yourself a fitness target for 2026, the most useful advice I have is to pick the app that treats you well in week three over the one that converts hardest in week one. They are usually different apps, and the second kind will hurt you in February.

That’s the whole post. Go for a walk, lift something, and don’t let the streak counter run your life.

What I'm not doing in 2026

2026-01-01T00:00:00+00:00

It’s the first day of 2026. Developers everywhere have started publishing their roadmaps for the year, a pleasant tradition, and I’m sure most of them are sincere.

I’d like to do the opposite and list what I am not doing this year.

Not adding a single advertising SDK

Lagerland Apps has zero third-party tracking SDKs across the entire catalogue. That means no analytics, no advertising networks, and no “anonymized” telemetry that quietly fingerprints people. It won’t change in 2026, and an attractive revenue share offer won’t change it either. The day I add an ads SDK, the studio’s whole positioning falls apart.

Not chasing a ten-app year

The catalogue today is fourteen apps. I don’t need a fifteenth, sixteenth, or twentieth. The studio is one person, and fourteen apps is already about as many as one person can support properly. If I ship a new app this year, it will be because the idea is good enough to displace something else, and not because the calendar said it was time.

Not turning anything into a daily-engagement product

Several of the apps would look more “successful” by App Store metrics if I added streaks, daily notifications, badges, or social comparison. Taskful Day would convert harder with a streak counter. AfterShift would retain more users with a daily nag. I’m not doing any of that. I’d rather have a smaller userbase that doesn’t resent me.

Not chasing AI features for AI’s sake

I expect the most disagreement on this one. I use language models in my own workflow, and I think they’re useful. Where AI really earns a place in an app, I’ll add it: Observa’s plain-language interpretation of HRV is one example, and Chessful’s mistake explanations are another. But a “tap here to summarize your day with AI” button that changes nothing is noise, and I’d rather ship no AI feature than a fashionable one.

Not raising

There is no funding round in the plans for 2026, and I don’t need one. The studio is small, the apps are profitable, and investors in a one-person operation would bring ambitions that don’t fit. The honest version of “we’re not raising right now” is “we don’t want to.”

Not going dark

I’m also not disappearing. This journal is new, and I plan to write more honestly through 2026 than in any previous year, including when things go wrong, which they will. Expect shipping notes, rebrand stories, post-mortems on pricing experiments, and short essays about why a particular feature exists. I’ll write when there’s something worth saying, not on a content-marketing schedule.

What does this mean for the apps in 2026?

If you already use the apps, what’s coming in 2026 is more of the same: refinements over additions, the same privacy posture, and the same one-time-or-honest-freemium pricing. New apps that ship this year will face a high bar, so there won’t be many of them. I’m fine with that.

If that’s the kind of studio you want software from, you’re in the right place. If you want a studio that ships fifteen new features a quarter and live-streams its OKRs, there are several excellent ones (I mean that), but this isn’t one of them.

Welcome to 2026.

Update, 25 October 2026: two of these didn’t hold. The catalogue grew this year instead of staying at fourteen, and three apps now have a streak of some kind: EarnLock (a step-goal streak with a weekly rest day), Millrace (extra undos at daily-streak milestones), and WanderWiki (a reading streak with an optional daily reminder). Taskful Day and AfterShift still have none.

What this journal is, and what it is not

2025-12-27T00:00:00+00:00

Lagerland Apps is a one-person studio shipping iOS and macOS apps (14 when this post went up, 20 today). Until now, the website has been app-page-first: you land on an app, learn about it, and install it. That’s still the goal, but some stories are too broad for a single app page, and this journal is for those.

What is the Lagerland Apps journal?

Rebrand stories. When an app gets a new identity, a new direction, or a new home, the details matter. Soon. was formerly TheWait. AppMeta started as a side-tool and became a full-time project. I’d like to document these transitions for the people who use the apps and the people who are curious about how indie iOS studios actually work.
Shipping notes. Short changelog entries that go further than an App Store “What’s New” line: design decisions, why a feature exists, why another one was cut, with the actual reasoning behind them.
Principles. Occasional essays on privacy-first design, honest monetization, and what it looks like to build apps without advertising incentives. These appear only when I have something worth saying.

What is this journal not?

A marketing blog. I’m not chasing SEO keywords or publishing on a schedule for algorithmic reasons. Posts arrive when there’s something real to document.
A dev blog full of Swift tips. The apps are built with SwiftUI, HealthKit, StoreKit, and Apple’s frameworks, but if you want Swift tutorials, there are better sources.
An AI-generated content farm. Every post here is written by one independent developer, because the whole point of this studio is that one person makes all the decisions.

How to read along

The journal index lists every post in reverse chronological order. There are no social widgets, comments, or newsletter sign-up wall. If you want to get in touch, email me. If you want to support the work, download an app you’d actually use.

Welcome.

Lagerland Apps — Journal

How long to rest between sets: what the studies found, lift by lift

How long should you rest between sets?

What does the research say about rest between sets?

Why does longer rest help, when it does?

How do you shorten a workout without losing much?

Should you time your rest at all?

How LiftLog times rest

When does Apple pay developers? The App Store fiscal calendar, payment dates and missing months

When will Apple pay me?

How does Apple’s fiscal calendar work?

Why is a month missing?

What is the minimum payment threshold?

What currency are you paid in, and who takes the fees?

Where do you see payments in App Store Connect?

Why doesn’t the payment match Sales and Trends?

Where AppMeta Pulse fits

When to deload: the signs, the common schemes, and how good the evidence really is

What is a deload, by definition?

What are the signs you need a deload?

How do you run a deload?

How often should you deload?

What does the evidence actually show?

How GymLogger X schedules deloads and flags plateaus

Designing a puzzle with no words: how Tare teaches its rules, and what accessibility took

What the first levels teach, and how

Levels with one way forward

No channel leaks a hidden weight

What accessibility took

Where the words went

Decisions that changed late

No ads, no subscription: why Tare is free to start and $2.99 once

What’s free, what’s $2.99, and what’s never sold

Where the offer appears, and where it doesn’t

The plan before this one

Why $2.99, and why it won’t be on sale

Why no ads, subscription or consumables

Family Sharing, restoring, and keeping the unlock

The purchase App Review couldn’t find

Ratings and sharing

How to solve a balance puzzle, and how Tare proves every level has one answer

The one rule: weight × distance

Read the cards before you hang anything

A worked example: Chapter II, level 14

Habits that solve most levels

How a level is built

What the gate proves

The 80-level ramp

Xiangqi openings explained: the Central Cannon, its answers, and the quieter first moves

How to read the moves

The ten openings at a glance

Why the Central Cannon comes first

The main line, move by move

Which openings to learn first

How Xiangqiful teaches openings

Xiangqi rules for chess players: what carries over, and what catches you out

The board

Every piece, next to its chess cousin

The rules that cost chess players games

Stalemate is a loss, not a draw

The generals may never face each other

Perpetual check loses

The cannon needs exactly one screen

The horse can be blocked

Some pieces can never attack

The rest of the list

How Xiangqiful handles the rules

Puzzle games without ads or lives: how free games make money, and what Millrace sells instead

How free puzzle games make money

What Millrace sells: the complete list

Where undo tokens fit, and where they don’t

Why there are no lives or ads

What this model gives up

A checklist for any free puzzle game

902 xiangqi mate problems, eight old books, and the problems I left out

What the genre demands

152 problems was not enough

Eight books, 2,208 positions

The book was not corrected to make a problem fit

Checked twice, by the same code