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 least glamorous setting in a training log and the one that decides session length. 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

Two rules sit under that table. 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 it costs the fewest reps.

What does the research say about rest between sets?

The evidence has shifted from fixed prescriptions toward a looser picture: rest 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 its size and its length. Twenty-one people for eight weeks can show a difference; it 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, but less than effort and total volume, and mostly through its effect on volume.

Why does longer rest help, when it does?

Because 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’ conclusion was that volume load, not the rest interval, drove the growth.

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.

The practical version is simple. 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 are the evidence that this works.

Should you time your rest at all?

I think so, for a reason that 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 the variable fixed. It also stops rest creeping the other way on days when you are in a hurry.

This is training information, 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 – Nov 29, 2025	Fri, Jan 2, 2026
December 2025	Nov 30 – Dec 27, 2025	Thu, Jan 29
January 2026 (5 weeks)	Dec 28, 2025 – Jan 31	Thu, Mar 5
February 2026	Feb 1 – Feb 28	Thu, Apr 2
March 2026	Mar 1 – Mar 28	Thu, Apr 30
April 2026 (5 weeks)	Mar 29 – May 2	Thu, Jun 4
May 2026	May 3 – May 30	Thu, Jul 2
June 2026	May 31 – Jun 27	Thu, Jul 30
July 2026 (5 weeks)	Jun 28 – Aug 1	Thu, Sep 3
August 2026	Aug 2 – Aug 29	Thu, Oct 1
September 2026	Aug 30 – Sep 26	Thu, Oct 29 (expected)
October 2026 (5 weeks)	Sep 27 – 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 the promise is the 45 days, not the Thursday. 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. Here is what the research and the people who coach for a living say.

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

Every level of Tare is a hanging mobile that you balance with numbered weights, and none of the 80 has a word on the playing field. There is no tutorial screen, no hand icon and no arrow. The puzzle had to teach the rule, the hidden weights and the cards that reveal them by itself. 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 all 80 levels:

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. No red, no buzzer, no failure screen. A drop that misses every hook isn’t even that; 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. Instead, 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:

Size: the “?” bubble is one fixed size.
Sound: with Sound on, each weight has its own note, and heavier is lower. A “?” makes an unpitched thud.
Touch: a “?” always gives the same haptic strength.
Speech: 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. 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: same meaning, no 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 hold this to account. 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 isn’t wordless everywhere. Settings, the four chapter names (The Hang, The Secret, The Cascade, The Exhibition), the four world names and the unlock screen use words. The app’s whole string catalog is 108 entries, and about two-thirds of them exist only for VoiceOver.

The canvas is held to its rule by a test that reads the code drawing 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 an English game inside a store listing written in 50 locales was where the wordless argument stopped. 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 60; 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

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, no subscription and nothing else to buy.

Here is the model in full, then why 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 forever. Not a trial, never gated
Chapters II–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	—

The price on the unlock screen comes 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. The app has no price written into it 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–IV;
the same button in Settings, directly above Restore purchases.

It never opens by itself: not at launch, not when you come back, not after a solve, and not 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 is also not a promoted purchase on the App Store page, which 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. VoiceOver says “not purchased” for the same reason, never “locked”. Your star total is not shown on the unlock screen either: 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 from 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, alongside rebuilding the 80-level arc, I made Chapter I free and put Chapters II to IV behind one purchase.

A free chapter removes 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 puts it plainly: the free chapter, not the price tag, is now what does the persuading. The store description also 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 the launch plan considers still reads as something crafted rather than 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. Its judgement is that no price below $2.99 would earn back what it costs in credibility. It also means that, for the first year at least, 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 mean network code and a third-party SDK in 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: not when it is shown, not 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, not money. 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.

Buying once should mean owning it

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. Locking a paying player out of an offline game to re-check a purchase is a failure the design rules out.
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 isn’t a surprise. Within a chapter you can skip past up to three unsolved levels, so no single puzzle walls you off.
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. It is one view used in both places, 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 it, so the prompt 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 and nothing else, 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 all 80 of its levels

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

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 rather than 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, with its own arithmetic rather than 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 60. 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. If a level seems to need a guess, it doesn’t: the cards are 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. These are the ten names worth learning 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 threatens nothing and commits to nothing
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 what to do in them rather than how many moves deep they go. 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. The rules that are different are few, but most of them reverse a chess habit, and those are the ones that cost games. This 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	—
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. 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. It is also 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. Perpetual chasing is not adjudicated, so the app 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. The question worth asking before you install one is who pays, and with what. Here are the common models, what each asks of you, and where each shows up on an App Store page. After that, 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 with a timer, boosters for sale and ads for extra moves are a common bundle in level-based puzzle sagas. Paid-upfront games are 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. This is what the developer declares about data, in 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, no lives and no 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 four packs bought separately cost $7.96, so the Complete Collection is cheaper. 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.

What is free: all 64 campaign levels, Freeplay, the daily board, Hint, the Coach, Game Center and the Classic theme, one of seventeen. A paid theme can be previewed 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 here are their exact rules.

Inside a level, Undo is free and unlimited. It 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 arrives 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 doesn’t interrupt anything. Tapping Undo with no tokens opens a sheet with the three bundles and a “Not now” button. 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 in the most direct way. A lives system makes failure cost time: you lose, and you wait or pay. In Millrace a loss costs one tap on Undo. The comment above that button in the source puts it plainly: 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. A hard level with a lives meter attached rewards waiting, not thinking.

Free Undo needed one guard. When a run fails, the card can say which move made the position unwinnable, but only afterwards, 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 ruled out by design and are now ruled out by construction. 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; 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. That is the whole trade. 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 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; every level can be finished free; hints are never rationed, and undos are free inside levels, with tokens 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, not the first one found.

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 is a win in a real game. 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 had limits. 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. 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 quietly break a problem that used to be sound. If that happens, a player should get a smaller corpus, not 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 rather than a content decision and stores none of it. Mate-in-1 and mate-in-3 problems are checked during launch; the deeper two shards are checked 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, not 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 “Review — due today”, or as “Seen before — no new problems left” once the unseen ones run out. 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 instead of insisting on 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.	—

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. That sounds like a slogan until you check it by machine; then it becomes a list of testable properties. Every one of the 64 levels in Millrace, a tile-delivery puzzle, was found by search, not written by hand, and none ships unless all five 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; the first win it reaches is provably the minimum. That number, not my estimate, is what the game calls the best possible.
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. Its exact odds are computed, not sampled. Above 2%, the level is gone.
It is not another level in disguise — 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 — many roads, no dumb ones. 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

An earlier version looked like puzzles

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.

That was structural, not bad luck. 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 asked only whether a solution existed: a floor with no ceiling.

A goal a greedy player can chase is not a puzzle

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. What beat the clearing goal were 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; and it must 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. That is why Millrace has exactly one kind of goal: a measurement, not a lack of imagination.

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 restores the tension a slide-and-merge board lives on: it fills while you merge.

It does not restore chance. 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 — it depends on tiles nobody has drawn — and a solver can only average over futures. With a visible queue there is nothing to average; breadth-first search is the correct model, not an approximation. The gate knows exactly what you know, and nothing more.

How a candidate level is generated

The generator is simple; the rigour lives 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 — picking it first meant most candidates buried their own inlet on move one. The target is one or two doublings above the biggest starting tile, then comes 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 at the gate’s heart: 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 — keep the inlet clear, keep it clear then score, don’t lose on this move, herd the biggest tile to a corner, chase the target onto the vault — again under all 24 orders. Each is deterministic, so one playthrough is a proof, not a sample. A level ships only if all 280 fail.

The battery’s first version was circular, and it’s worth saying so: 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; it is the skill the levels teach. The gate certifies that the content has depth, not that 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, not simulated. 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; the median sits 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. Those nine identical boards are why.

Why the gate lives in the test suite

None of this is a script I ran once. The sixteen checks live in the test target; 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, naming the property that broke. A search that runs out of budget fails too — unproven is unshippable. And the gate must 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 rather than generated, but they pass the same kind of gate; here is how it proves all 80.

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 stop being a feeling and become a number the tests check.

What you see of it

Almost none of this is on screen, which is the point.

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 tells the truth. “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 — only 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, it isn’t. 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. Here is the product page, field by field.

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 and do different jobs.

	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.

One gap, plainly: AppMeta 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 are a risk of their own.

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 is not the same as a pager on the bedside 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.

That is the on-call problem in a few lines. 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.

The caffeine nap has a well-known study behind it. 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 isn’t the same experiment, but it 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, because the uncertainty is expected.
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. That is the trade: 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). Two more names you will meet early are attacking methods rather than 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–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 setup was built for. 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. What it does is keep those dates and tell 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.

One honest caveat, because the schedules above make it matter: 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.

The schedule belongs to your vet. The dates on the certificates belong to you, and keeping them is what lets you 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. The rest is detail, and the detail is mostly about 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	—
1–2	Little to no effort	—

Two rows break the simple subtraction. 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 older than strength training apps by decades, but the generic ones ask how hard the effort felt, which is a poor fit for a set of squats. 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, which is 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 rather than a flat 10.

How accurate are lifters at judging reps in reserve?

Within about a rep, on average, 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 helps you feel at home under a bar, but it doesn’t automatically make the counting accurate.

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

How do you rate a set honestly?

These are the rules I use, built around what the research above says goes wrong.

Rate the last rep, straight after the set. Not the set as a whole, and not after the rest period, when the memory has already softened.
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, the extra precision is imaginary.
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.

One more: 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 instead 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 honest 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.

What matters more is consistency. 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 to give once a fortnight is just a 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, but 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.

Here is every rule with the arithmetic worked all the way out. The part about why the fair rule is hard to propose comes after the numbers, because the numbers 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 convention rather than rule. 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. Announcing which one you used is what matters. 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

The headline is the last column. An even split charges Alex $20.62 more than the salad actually cost — on one dinner, at a table of only four. Twenty-six dinners a year with the same group and the same ordering habits and that is $536 moving from the salad to the ribeye — not as a grievance, just as arithmetic.

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 its quietest damage, 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 conducting an audit over a wine bottle, and it is a price worth paying.

So the two rules are not the same rule, and conflating them is where tables go wrong. 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, it is completely transparent, 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, invisibly.

Which splitting rule fits which table?

The right rule is a function of the social situation, not the arithmetic. Here 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 quietly 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 rather than 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 not more accurate, only 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 does it. A spreadsheet does 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 not better math. It is to move the itemising off the table: do it privately, on one phone, in under a minute, and present a finished number to each person rather than a process. People do not object to receiving a total. They object to watching one get constructed about them.

That is the whole shape of RightSplit. 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 entire subject of this post — is Pro+, at $3.99 a year or $7.99 once. And the OCR is exactly as good as Apple’s OCR: 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 — 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 deserves an honest mention too: it 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 — not $6.00 each.
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, not to the head count. 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.

The rules are all fine. Picking one before the bill arrives, instead of after, is the entire trick.

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. Almost none of it is decisive. Run two competently written programs, same person, same twelve weeks, and you would struggle to see the difference in your own logbook.

What decides the outcome is 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–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 rather than reduce.
Upper/Lower 4×	4	55–75 min	Double progression, or percentage blocks	2×	Intermediates with four genuinely reliable slots	The fourth day gets dropped. The split silently becomes a lopsided three-day where legs are trained once.
PPL 6×	6	45–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-it-up logic collapses inside a fortnight.
Starting Strength / novice LP	3	45–75 min, growing	Linear: add load every session	3×	Untrained or detrained lifters, roughly the first 3–9 months of barbell work	The linear phase ends and nobody notices. Lifters reset the same 10% three or four times instead of changing model.
5/3/1	3–4	40–60 min plus assistance	Percentage-based off a Training Max, 4-week cycle	1× per main lift, ~2× per muscle with assistance	Intermediates wanting a long runway 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 is not what separates these programs. Full body and PPL sit at three and two, and once weekly volume is held equal the frequency research is not 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, not a law.

The failure modes, by contrast, are specific. PPL does not fail because six days is too much volume; it fails because six fixed slots is too many places for a week to break. Novice linear progression fails because it is designed to end, and almost nobody has a plan for 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–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 simultaneously
Percentage / Training Max (5/3/1)	A fixed increment to the Training Max, not to your 1RM	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	There is no failed session, only a lighter one. 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–6 week cadence

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, 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. That is not a step backwards. The bracket resets and you climb it again, and it 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, and 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 the whole program. That last set is taken for as many quality reps as you have, and its rep count is your progress signal — the fixed sets are 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, run it again. 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 put muscle-strengthening activity at two or more days a week for adults, covering all major muscle groups. That is a health floor, not a strength target.

For building strength, three to five days is where most sustainable programs live. But pick your number backwards, not forwards. 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 not a program, it 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 implementation — 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. What the rule cannot tell you is 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. Not for you, and not for the 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, and 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, divide by eight. That is your days per week — not your intention, not your best month. 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 and 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 becomes a skipped one. Most of any session is rest, and how long you rest between sets is the first thing to trim, starting with the isolation work rather than the heavy lifts.
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: percentage cycles or autoregulation, and expect progress measured per quarter.
What has hurt, and what made it hurt? If flat barbell benching aggravates a shoulder, no split solves that. Pick a structure that lets you swap the movement without deleting a day — organised by movement pattern, not by a fixed list of named exercises.

This is training information, not medical advice; if you are working around an injury or a condition that affects loading, get eyes on it from a clinician or a coach who can see you lift.

Why the log is the part that decides it

Everything above assumes you know what you did last time. That assumption is doing more work than any of the programming.

Linear progression is the only model on 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. This is the unglamorous reason logging apps exist, and why 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, a number you can add to any logged set rather than a field imposed on every one. The honest 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 is 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 rather than buried in an algorithm: 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 the reason your programs die is that choosing one is the friction, Fitbod is genuinely the better tool. Its generated-session model removes the decision: you open it and it tells you what to do today, adjusted for yesterday. No amount of good template design in a manual logger replaces that. The trade is subscription-only pricing and proprietary reasoning.

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 one listed that can change your program when your week changes.

For the category sorted by pricing model, there is 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 twelve weeks the difference is small; between finishing and quitting in week five it is enormous.
Days per week is a measurement, not a decision. 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, which is why the log, not the template, is what finishes the twelve weeks.

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. Here is everything a tool will ask you for, and where it 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 rather than one downloaded from App Store Connect.

Team key or individual key?

Apple offers two kinds. The difference matters more than 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 rather than later.

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 works by asking iOS to do the blocking on its behalf, through three frameworks Apple shipped in 2021 and has extended in small increments since.

That distinction is not pedantry. It decides what your blocker can do, what it will never do no matter how much you pay, and — the part nobody puts in the App Store screenshots — exactly how you get out.

What actually blocks an app on an iPhone?

Three frameworks, collectively 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

The sequence in a real app 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 your DeviceActivityMonitor extension get woken at interval boundaries and usage thresholds to change the store.

Two practical gates are worth knowing before you assume the category is bigger than it is. 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” is really doing it at Apple’s chosen moments.

Why the blocker never learns which apps you picked

This is the single most consequential design decision in the whole API.

The app-selection UI is FamilyActivityPicker, and it is Apple’s, not the developer’s. It renders out of process, it lists your installed apps, and what it returns is 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. It hands that blob back to ManagedSettings to raise a shield. It never receives a bundle identifier or a display name. There is no way to reverse it. A token is also only meaningful 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.

The privacy consequence is real and worth saying plainly: a screen-time app physically cannot log that you blocked Grindr, or Robinhood, or your ex’s favourite app. Not “promises not to” — cannot. That is privacy by construction, and the strongest such guarantee in any category I have shipped into.

The product consequence is a genuine 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, which makes support (“it isn’t blocking anything”) an exercise in guided screenshots.

That trade is Apple’s to make, not the developer’s. I think it is the right one.

Which approach blocks what?

Five approaches get sold as “app blocking”, and they intercept at completely different layers. The column that matters is not price, it is 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 — 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 — state is local and enforced by iOS	People who want a different unlock condition 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) rather than 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, one place — writing sessions, dinners, sleep
Grayscale and friction (Color Filters, Focus modes, apps off the Home Screen)	Nothing — it just makes the phone duller and slower to reach	Anything, if you actually want it	Three taps in Settings, or Spotlight	Yes	Drift rather than compulsion — the person who opens an app for no reason and stays for 40 minutes

Two honest notes on that table. A DNS filter is the only row that touches apps you did not enumerate, which is why it is 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. Then 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 is fixing the wrong half of the loop, and a Focus mode is the better tool — or both 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 is doing it with a different mechanism.

Is there an app blocker that cannot be bypassed?

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

So the useful question is not whether there is a way out — there always is. It is how long the way out takes, and whether the effort lands somewhere useful. Here is the actual 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–2 taps, under 5 seconds	Nothing	Yes — it fired the action
Wait out a timer or a breathing pause	5–60 seconds	Attention, the currency you were defending	Yes
Solve a gate — a math problem, a long typed phrase	20–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, sometimes worth paying	N/A

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

Read down that ladder and “unbypassable” collapses. The only real variable 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 — that a cost you set yourself, inside the software, is a cost your craving can renegotiate from inside the moment of craving. The API reality above is the structural version of the same argument. Since revocation is always about fifteen seconds away, the wall is not the product. The price is.

And the price should be paid somewhere your future self benefits. Time-of-wait 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.

That is not the same as saying the other designs are wrong. Several are good for problems mine does not solve:

one sec interrupts before the app opens — a breath, a pause, a question. If your problem is that your thumb arrives before your intention does, that is a better-shaped intervention than a hard gate, because the reflex is what it targets. A gate you have already earned 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 rather than software you authorised. The cost is that you have 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 free is a real advantage that a $19.99 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. It is not doing anything 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 — and the shield is a ShieldConfiguration extension that paints a live progress ring with the number remaining instead of Apple’s generic restriction screen. 3,412 steps until unlock is a destination. This app has been restricted is a wall. 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; what the step-count studies support covers it. $1.99/month, $9.99/year, or $19.99 once, each price checked in August 2026.

The honest constraints are the same ones on this page. EarnLock cannot see which apps you blocked either. It does not stop notifications. It is iPhone and Apple Watch only, and there is 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 a tool with no exit is a tool people delete. And if you open Settings and revoke its authorisation, every shield drops and there is nothing it can do about that — which is true of every Family Controls app named on this page, and worth knowing before you pay any of us. (The data discipline behind that, and every other Lagerland app, is 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 — and it also cannot pre-fill 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. The only real variable 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. Below are the numbers for each step, then 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 puts it plainly: a message must fit the limits of both sender and recipient. The smallest limit on the route is the one that counts.

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

Compression has a floor, and the five-minute row of the table finds it: 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.

The trade is simple: 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). The rest of this page is detail around that sentence: 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

The trap in the downloadable report is that both money columns are per unit. 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

Treat that as arithmetic, not a quote. 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, differently sourced, with several paragraphs on fishing rights and local place-name history that English never had, and missing the geology section you came for.

The sidebar looks like a language switcher. Every other website on the internet has trained you to read it that way — same page, different words. On Wikipedia it means something else. It is a list of independent encyclopedias that each happen to have an article about the same subject.

Almost every question people have about Wikipedia and languages dissolves once that one 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, its own administrators, its own notability rules, its own sourcing norms, its own deletion process, and its own article set. Articles are written locally by people working in that language. They are not derived from an English master copy, because there is no master copy.

Four consequences:

The languages sidebar is a claim about concepts, not 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, but as a seed rather than a pipeline. 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 the moment a local editor works on it. Which is immediately.
Image policy genuinely 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 no image in another, permanently.
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. None of that is a defect awaiting repair. It is what independent project means.

How big is each Wikipedia language edition?

All figures below are rounded hard and approximate as of 2026. Article counts change every hour; the live table is Wikimedia’s List of Wikipedias, which is the source to check rather than this page.

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, 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 is ranking 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. What follows is the shape of each, not a claim about any specific article, because the specifics 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 is the one worth sitting with. 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 land in different places. Reading both is how you find that out.

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 a threshold, three things follow: 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 different in kind 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 generally. They are a reason to know which edition you are standing in. A small edition is not worse. It is thinner, and thinness is a property you should be able to see.

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

The practical 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. A Japanese rail line, a Finnish municipal reform, 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 frequently the real prize: local newspapers, national archives, ministry publications, regional academic presses.
Treat disagreement as the finding. Where two editions differ on a date, a name, or a cause, you have located 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.

This 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 the reference. What follows is a design argument, and it is the reason WanderWiki is a swipe deck rather than a scroll.

A feed has a specific structure: items ranked by predicted engagement, no bottom, and a design objective where you leaving counts as 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 inverts three of those properties, almost by accident of the form:

The terminal action leaves the deck. The point of a card is to make you open the article. 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 that is chosen in a menu, not inferred from dwell time. Interest categories work the same way. A declared preference is worse at maximising engagement than a behavioural model, and better at the thing 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 rather than when the 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.

None of this makes a deck automatically virtuous. A swipe deck ranked on dwell time with a streak counter bolted on would be a feed wearing a costume. The form does not save you; it just makes the honest version easy to build and the dishonest version visibly gratuitous.

Where WanderWiki fits, and where it does not

WanderWiki is a discovery client, and it is worth being precise about what that excludes.

It runs on iPhone and iPad, iOS 18.2 and later. It carries 32 Wikipedia language editions — 32 of roughly 340, a real limitation and not a rounding error. 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 instead, is in a guide to finding interesting Wikipedia articles. Ad-free, no account, and the articles you save are kept 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. That is the trade for having no ads and no engagement model to feed.

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 rather than machine-translated English category names. In the other 15, For You and Browse fall back to random articles from that edition instead of pointing English names at a category tree that does not use them. That is the principle from the top of this page implemented in one place: the German Wikipedia’s category structure is the German Wikipedia’s, and pointing English category names at it returns the wrong articles or none. The data side is documented per-app on the transparency page.

What it does not do. It does not translate — if an article does not exist in the edition you selected, WanderWiki cannot conjure 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.

And two genuine competitor advantages, because pretending otherwise would be silly. If you want the encyclopedia itself offline — the whole thing, 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 rather than 32, Wikipedia’s own official app is built for that and is free. WanderWiki sits in the narrow gap between them: a reading surface for the encyclopedia you are not currently searching for.

TL;DR

Wikipedia language editions are written, not translated. Each is an independent project with its own editors, notability rules, sourcing norms, and image policy. There is no English master copy for others to render.
The languages sidebar links concepts, not text. Those links live in Wikidata and assert only that two pages are about the same subject — 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 rather than 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 mine the references list — local sources are the usual payoff.
Small editions are thinner, not worse — but thinness is 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 the answer is instant. No.

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.

The certificate does not belong to the dog. It is filed mentally under the pet and it is, on paper, a document about a household with an animal named in it. That mismatch between how the document feels and what it contains is the whole subject of this post.

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 remarkably 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 microchip code is not a pet-only number. 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, not your details, but it is a useful reminder that the number is an index into a database about you, not 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

The user-facing feature is identical. You point the camera at a page, a moment passes, the fields fill in. Underneath, there are two completely different architectures, and they differ on 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

Read that last cost row carefully, because it explains the rest of the table. Server-side extraction has a marginal cost per page. That cost has to be recovered — through a subscription, through a clinic partnership, or through 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.

The two rows where cloud wins are real, and anyone selling on-device processing should say so out loud. 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. And it 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, 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 rather than hard-code a marketing number.

Here is the part that trips people up. Neither framework tells you anything about privacy on its own. An app can present the VisionKit sheet, get a beautiful deskewed image back, and then POST it straight to a server. The capture UI is not evidence. 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?

Four tests. None of them requires you to read code, and they work on any health app, not just pet apps.

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 is behavioural rather than declarative. A marketing page can say “privacy-first” for free. A scan that completes with the radios off cannot be faked.

The other three are declarations, worth reading rather than skimming. Apple’s app privacy details are self-reported — 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. You should not take my word for that. You should read the page and 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 quietly extend 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.

Nothing on your side of the trade can change. 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 not to trust harder. It 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

This is where I have to be straight about the trade-offs in our own app, because 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. And the free tier limits how many documents you can scan, which is a business constraint, 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.

What we are not willing to do is quietly route the page through a server and describe it as 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. Point camera, fields fill in. The difference is entirely in 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 genuinely wins on hard scans. Bigger models, better on faded and creased pages, and they improve without an app update. That advantage is real and worth naming.
The asymmetry is the argument. 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 that 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?

Because 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. If your roster has a name, write out the next 28 days as D, E, N and off. That list is what your sleep responds to.

How does each pattern move between days and nights?

Two things decide how hard a switch is: which way the clock moves, and 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 arithmetic is unforgiving. 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 rather than 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.

Eleven hours isn’t an arbitrary line. 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

Twelve-hour shifts get a footnote. 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 looks at each window between the end of one shift and 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.

None of this changes your roster. What it gives you is your own record of which changeovers cost 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. It 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 are the ones that renew far away from the decision that created them, and those are exactly the charges a short statement scan is structurally unable to show you.

The better mental model: 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 of them already has a screen showing you its own slice. The audit is a route through those screens, in a sensible order, finishing with the statement rather than starting there.

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

A few notes on the paths, because they move.

Apple. The highest-yield single stop for most iPhone users, and the one people skip 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. This is the step almost everyone skips, and it is where the strangest charges live, 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. Two separate lists, and the second one is the sneaky one. 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 quietly receiving since.

Email and purchase history. Search your inbox for the renewal language rather than for 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. The reason is the next section.

Password manager. Not a billing record, so do it last, but 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?

Not all charges are equally findable. These are the categories that survive a casual audit, ranked roughly by how often I have watched 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 — this is exactly what it is for
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	Typically 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 the honest limit of any app-based audit. A direct debit set up by post is not in Apple’s records, not in PayPal’s, not in your inbox, and on the statement it looks like an ordinary bank transfer rather than 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. That is the whole mechanism, and it is worth making numeric, because the intuition runs the other way — 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. Nothing subtle is happening — we audit in three-month windows out of habit, and three months is the wrong instrument for a twelve-month event.

Now put cost next to it. A $99-per-year subscription and a $8.25-per-month subscription cost you the same amount over a year. One of them you encounter twelve times. The other you encounter once, in a month you were not looking, in an amount large enough that you will assume it was something else. The yearly plan is usually the better deal and it is reliably the harder one to keep track of — which is also why the cheerful annual discount is offered so enthusiastically.

Two consequences. Scan 13 months rather than 12, so a renewal sitting on the boundary cannot fall through the seam. And when you find an annual charge, write the renewal date down on the spot — you will not meet 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 I would rather name them than pretend they do not exist.

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 — a payment processor’s name, a parent company, an eight-character string. That is a real capability and no amount of manual discipline reproduces it.

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. These are the errors a list built from memory reproduces faithfully, because memory is where the error came from.

Rocket Money does all three, and it does them well. If your actual problem is I do not know what I am paying for, an aggregator-connected tool is the right instrument and I will say so. The trade 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, not just the recurring ones, 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 is the answer to how do I get the discovery without the access. It is slower. It is one afternoon rather than one tap. It also terminates — once you have the list, you have it, and the maintenance is a few minutes a quarter.

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

This is where most audits fail. 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 do that. A spreadsheet does, until the third week. AllPaid is the studio’s answer to this specific 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 gentle 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.

The honest limitation is the whole 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 the list. Those are two different jobs and I would rather be clear about which one the app does.

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, Subby is freemium with its own premium unlock — and 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, at the cost of being a web account rather than 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 rather than leave a gap.

One habit beats all of it: the moment you start a free trial, write down the date it converts. That is the one category on the hiding list you can eliminate at signup instead of hunting for a year later.

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 genuinely wins on three things: charges you never knew existed, price rises, and duplicates. The price is aggregator read access to every transaction, forever, not only the recurring ones.
Finding the charges and keeping them are different jobs. The checklist finds them; 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	—	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. They divide by a hundred out of chess habit 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. The position is probably fine too. And 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.

This is the conversion table nobody hands you. Reference first; 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, not a normalised display.

The scale is the engine’s, not the game’s. 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. Note how close that is to a chess centipawn: 90 units per pawn against 100. The reason shogi evals look like four-digit numbers and chess evals like small decimals is display convention — chess front-ends divide by a hundred before drawing anything, shogi front-ends print the integer. Tunings shift these constants, so if you need them exact, read them in the source rather than 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 out of win-rate fitting in the elmo and YaneuraOu learning code — 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, not 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, not the win.
Beyond ±2000	97%+	Decided. The rest is bookkeeping.	Scroll back to where it crossed.
`mate N`	100%	Not a magnitude. A proof.	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, not a forecast.

Why do shogi evaluations swing harder than chess centipawns?

Because a captured shogi piece is not removed from the game. It goes to your hand — the mochigoma (持ち駒), which 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.

So a capture is not a subtraction. It 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 carry 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.

Now put the numbers together. 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. That is not the engine being dramatic. That is the game.

The other half of the answer is what does not happen. Chess evaluations calm down because material leaves and positions simplify toward technically drawn endings. Shogi has no such drain. Trades load both komadai and sharpen the position rather than quieting it. 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 even 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 is already everywhere: it arrives 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 is a live threat against every weak square at once, and your opponent has to answer all of them.

It is not blocking your own pieces, which is no small thing 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 — 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 transformation even though the material table does not.

The 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 is not “very good”, it is “there is a forced mate, and here is the proof, seven moves long”. Three consequences follow.

It is not on 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, not an evaluation.

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. There is also no score at all 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 makes that argument stronger in two specific 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 buys less and costs more. Comparing a shogi “depth 20” with a chess “depth 20” is meaningless: 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: five-move nets starting with a pawn dropped on an empty file to be promoted three moves later. Those are exactly the moves a club player had no chance of finding at the board and no chance of generalising afterwards. The mistakes that actually decided your game — the hanging silver, the knight drop that would have forked king and rook, the reflexive promotion, the edge pawn that opened your mino castle — are visible far shallower.

So no ply number here, the way the chess post gives one 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?

Say the true thing first. Lishogi is free, open source, and genuinely 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 — being open source — lets you read exactly what the analysis did rather than trust a description of it. If what you want is the number, on a board you can send to someone, that is the answer and it is free. PiyoShogi is likewise a fine 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.

An evaluation is a verdict without a reason

Everything above teaches you to read a number that, once read, still does not tell you what to do. -980 is a verdict. It says 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.

Translating verdict into 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 do not exist in that taxonomy: 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 those from scratch rather than adapting a chess list — 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, no account, and no 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 Premium is the tier that raises engine depth and shows multiple candidate lines.

The limitation is the exact flip side of that design. Shogiful leads with the sentence rather than the number, and it has no online human play at all — so if what you wanted was the eval graph itself, deep and shareable, lishogi does it better and 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 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; shogi front-ends just print the integer instead of 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, not physics, and they move with the engine.
Every capture counts twice, because the piece goes to your hand rather than off the board. 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.
A piece in hand beats the same piece on the board in most positions: no travel time, no positional commitment, and a live threat against every weak square at once. This is most extreme for the lance and knight, which cannot turn around.
A mate score is categorical, not numeric. 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 is not 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. Ten thousand is not where the studies point; it is where a slogan pointed. The four studies below are the ones most of the numbers you read come from.

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–8,000 a day in adults 60 and over, and 8,000–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–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. Read the numbers as where the curve bends, not as a dose that guarantees 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?

Not 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–7,499	Low active
7,500–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 the number to get right first is the daily total.

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. A daily total counts every step: the kitchen, the office, 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. That number, not 10,000, is your starting point.
Set the goal one walk above it. A goal you reach on an ordinary day without trying is no goal. A goal you only reach on your best days is a lockout. 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 is cheap. Starting too high and quitting is not.
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 instead of one compromise number.

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 choice of goal decides whether it feels like a 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 instead of showing a stale 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.

A daily threshold isn’t the only design. Some step apps sell screen time by the step instead; 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 a starting point for a much lower baseline, not a destination.

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 almost useless. 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 second wrong model 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 at exactly the moment it is needed, because emergencies do not happen at home.

So before the argument, here is 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 — 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. This is the single most valuable line in an emergency	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 get left out of almost every home record, and they are the three that cost you most when missing. The adverse-reaction line, because nobody writes down the thing that went wrong two years ago. 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 precisely to answer that question, and it will not help if your contact details in that registry are three addresses out of date. And the after-hours hospital, which you look up for the first time in the worst ten minutes of the year.

Which documents does each situation actually need?

Situation	What they actually 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	—	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 window is set by the carrier, 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

The international row is the one to take seriously. Nobody should take pet-travel rules from a blog post, including this one. The requirements are country-pair specific, they change, and the failure mode is your animal being 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: categories, not a schedule

This is a taxonomy, not a dosing plan. 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 rather than by your vet	Rabies, same

Note that “core” is not a permanent list. 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 is regional rather than global. That single change is the argument for checking a live guideline rather than trusting anything, including this table, that was written on a fixed date.

Why does the paper folder fail?

Two reasons, and only one of them is obvious.

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 not a record.

The second is structure, and it is the one that quietly 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, and a source document is not an answer. What a vet wants is the answer, in a form they can scan in seconds while doing four other things.

Photos of documents in a camera roll are the same failure wearing modern clothes. The information is technically present and practically unreachable, filed between thousands of unrelated pictures and a screenshot of a parking receipt.

What does a 20-second record actually require?

The real test is narrow. 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.

It has to work with no signal and no login. Veterinary waiting rooms are frequently concrete boxes with terrible reception, and the moment that ruins the twenty seconds is a login screen followed by a password reset email you cannot receive.

It has to produce one artifact, not fourteen. A single PDF with vaccinations, medications, weight, and history is a thing you can hand over, email ahead, or print. A camera roll is not.

It has to be answerable, not just searchable. “Next due” beats “here is the certificate.”

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 exactly this shape. 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 rather than a number, holds the microchip number, with the insurance policy and pet-passport documents attached alongside the clinical history 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.

The constraints are real. 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.

And here is the honest part, because it matters more than the pitch. PetDesk does something Pawza structurally cannot. It connects to participating veterinary clinics, so it can carry appointment booking and the reminders your clinic itself sends. Pawza cannot do that, and will never be able to, 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 divides along similar honest 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 is twelve categories, not one folder: 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, not a schedule. WSAVA, AAHA and AAFP set the categories; your vet and local rabies law set the intervals — and the categories 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, not a summary you made yourself. 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.

The paper is fine. The problem is that the paper is at home, and your dog is here.

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 quietly close it. Not because the rules were hard. They never reached the rules.

The kanji on the pieces, not the rules, is the wall. So before any of the design story, here is the thing you actually came for: 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 is fourteen distinct things to tell apart by character alone. Chess gives every piece its own shape, which is exactly why “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, four things will trip you up — and they are the same four every time.

The gold is the centre of gravity. The gold general moves one step in any orthogonal direction plus the two forward diagonals: six squares, 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 is the tricky one. One square straight forward, or one square in any diagonal — five squares. 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 precisely 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, forever. Both are commitments. Once advanced, they do not come back.

The pawn captures straight. A shogi pawn moves one square forward and captures one square forward — never the diagonal capture you have wired into your hands from chess. There is no two-square first move and no en passant. There is, instead, the drop.

Drops are the rule that changes everything. When you capture a piece it joins your hand and can later be placed — dropped — onto any empty square as your whole move, fighting 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–9 right-to-left from Black’s side; 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–i for ranks: P-7f is a pawn to the 7th file, 6th rank.
Hosking uses numbers 1–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.

So 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 — and 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 real barrier — and why I didn’t just translate them

Everything above is the 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.

The obvious question is why shogi can’t simply draw a knight as a horse the way chess does. The answer is that the piece design is load-bearing. All forty pieces are one shape and one colour; ownership is shown by which way the wedge points, because that has to survive the drop rule — a captured piece joins your hand and comes back fighting for you. Fixed colours would lie about ownership; the rotating wedge 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 is a state change, not a piece swap. It is a beautifully compact system if you read the characters, and an undifferentiated field of identical wedges if you don’t.

A board you can actually read needs three things, not one:

Identity — a distinct, instantly-parseable symbol per piece. This is the easy part, and where most sets stop.

Movement — the part that matters. A newcomer doesn’t know a lance only goes forward, that a knight has exactly two destination squares, 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 — which pays off most with that gold family, where promoted silver, knight, lance, and pawn all move alike and the icons make the family resemblance visible instead of four arbitrary facts to memorise.

Promotion state — traditional sets flip to red characters; a Western set needs an equally unmissable change, not just a tint, because “did that silver promote?” is exactly the question you can’t afford to get wrong when you’re working out whether it can retreat.

There’s one decision hiding in plain sight: 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 is asking for an informed decision before they’ve seen the board. The locale already answered the question; the toggle in Settings is for when they change their mind.

Learn the pieces first, the kanji second

Here’s the honest trade-off, because it’s real: the broader shogi world runs on kanji. Books, problem collections, Japanese apps, real boards, every diagram on every shogi site — all kanji. A player who stays on Western pieces forever has a ceiling on what they can read.

So the Western set is built to be temporary. The piece guide is one tap from every game, showing both styles side by side; training introduces the characters progressively — you meet 銀 after you already know how a silver behaves, which is dramatically easier than learning symbol and behaviour at once. Behaviour first, symbol second, is the entire thesis. Nobody learns chess by memorising the letters K, Q, R, B, N before their first game; shogi outside Japan has effectively demanded the equivalent for decades, then wondered why the game doesn’t travel.

A board you can read on move one

The readable board is the front door. What’s 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. The piece set isn’t a feature; it’s the precondition for every other feature.

If what you want is ranked play against humans, the online platforms are the right tools — and worth knowing the board there is all kanji, which is the whole 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 — there’s our honest guide to the best shogi apps for iPhone.

Shogiful itself is on the App Store for iPhone, iPad, and Mac — free to try, with the full coaching loop from $1.99/month or $19.99 once. The app page has the methodology, an honest 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?

Here 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

Three things stand out.

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?

Honestly, the 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. Here they are, followed by 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–20% of the bill before tax	$60 of food: $9–$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–15% of the bill; $2–5 for pizza, by size and difficulty	$32 order: $3.20–$4.80
Bartender	$1–2 per drink, or 15–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–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–$10.60
Hair stylist	15–20%, shared among everyone who worked on you	$70 cut: $10.50–$14
Hotel housekeeping	$2–5 per day, left daily	4 nights: $8–$20
Valet	$2–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, 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 15% is where guidance and habit overlap, and 20% is the top of the range rather than the norm.

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. Picking one and using it every time is the useful habit.

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 is expensive. A party of eight, $420 of food, 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. Leaving something extra for exceptional service is still your choice; doing it by accident is the thing to avoid.

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–20% of the tab
6 beers at $7 ($42)	$6 (14%)	$12 (29%)	$6.30–$8.40
6 cocktails at $15 ($90)	$6 (7%)	$12 (13%)	$13.50–$18.00

The rules meet at about $10 a drink, where $1.50–$2 is 15–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.

What it won’t do is choose the percentage. RightSplit doesn’t know whether you are at a buffet or a steakhouse, so the table above is still the part you bring.

TL;DR

Sit-down restaurants: 15–20% of the bill before tax. Buffets 10%. Most Americans tell Pew they would leave 15% or less.
Delivery 10–15%, taxis and haircuts 15–20%, housekeeping $2–5 a day, valets $2–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–2 a drink and 15–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 so far as to ship you a physical NFC tag — lets you unlock with the tag from across the room.

These are not blockers. They are friction. The distinction matters.

A blocker has a cost you cannot pay from inside the moment of craving. Friction has a cost you can pay in two taps, and the design relies on the hope that you won’t.

The reason every app in this category eventually adds a tap-through escape is App Store ratings. The user sets up the blocker on a Sunday afternoon when they are calm, and they encounter the blocker 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 rules the rating distribution ships in the next release.

So the apps end up with a door, and the door gets easier to open 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. They set the timer. They picked the pause length. None of these are obstacles in the moment of craving — they are bookmarks from a previous 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 — that’s the wait-out model. one sec and ScreenZen do this. It does not work, because waiting is itself a tap. The user sets down the phone, picks it back up, ten seconds passed, the lock is gone. The user paid in attention, which is the same currency they were trying to defend in the first place. Nothing about the wait translates into anything the user benefits from later.

The body is the other candidate. If the unlock costs steps, or active minutes, or active calories, the user cannot pay it from the couch. They have to go outside, or get on the floor, or move through the room. And — this is the part that makes the design defensible rather than merely strict — the cost is denominated in something the user’s life also benefits from. 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 on Apple Health. Steps in the free tier. Active minutes or active energy in Premium. The user picks the goal on a calm day. The Thursday version of the user does not get to renegotiate it, because the Thursday version of the user does not have a tap-through.

Why the shield matters

There is a second design choice that follows from the first.

Apple’s Family Controls API will, by default, render a generic restriction screen over any app you block. This app has been restricted by Screen Time. It looks like a system prompt. It teaches the user nothing — no count of what is left, no relationship to the goal, no sense that the cost is reachable.

EarnLock paints its own shield. The shield shows a circular progress ring, the current step count, and the exact number remaining: Earn 2,026 more steps to unlock. When the user attempts to open Instagram, they are not told they are restricted. They are told they are 2,026 steps from Instagram. The unlock is a destination, not a wall.

This is small but it matters. A wall produces resentment. A destination produces motion. 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 does ship two real costs.

The first is that some days the user will not hit the goal. They will not see Instagram that day. The right product response is to make that survivable without being undermineable. 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. It is the door for the genuine emergency, and only that.

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 the user quits the whole thing. EarnLock ships a streak because users ask for it, but a single rest day per week protects the count, and there is no notification shaming the user for missing a day. The streak is allowed to exist; it is not allowed to become the thing the user is actually optimising.

(I wrote a separate essay about why streak counters are a debt instrument. The short version is: any time you ship a streak, you owe the user a rest mechanism, or you are building a guilt loop with a different label.)

The shadow week

There is one more piece worth naming, because it is the part most blockers get wrong on day one.

When a user installs a screen-time app, the app does not know anything about that user yet. It does not know which apps they actually overuse, what time of day the urge spikes, or how much real time they would have spent had nothing blocked them. So the app picks a default — usually generous, sometimes hostile — and the user either bounces because it is too strict or bounces 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, for how long. At the end of the week it shows the user a screen that says, in effect, here is what you would have lost — about 30 minutes a day, 23 separate block events this week — based on your own behaviour. Enable real blocking? The user makes the call with their own data, not with a guess from a stranger who has never seen their phone.

This is, I think, the right default for any tool that proposes to change a user’s behaviour. The first week should not be the tool acting on the user. It should be the tool earning the right to act, by demonstrating that it understands what is actually happening.

Why no account, no server, no SDK

The last piece is structural rather than behavioural.

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. This is, by a wide margin, the most psychologically intimate dataset a phone can produce — more intimate than location, more intimate than messages, more intimate than the photo library.

The only safe thing to do with that data is to never let it leave 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 — even we cannot see which apps the user picked to block. Apple’s App Privacy nutrition label reads “Data Not Collected” for every release.

This is the right default for any app that sits between a user and their own behaviour. There should not be a database that knows the user tried to open Instagram 47 times last Tuesday. There should not be a server that knows they missed their step goal for a week in February. There should not be an account that ties any of this to an email address. The mechanism is private because the mechanism is intimate, and the right response to intimacy is restraint.

What this trades away

The honest 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.) A screen-time app with no analytics SDK cannot run growth experiments on cohorts of strangers. A screen-time app with no tap-through escape will get some one-star reviews from people who wanted a door.

These are the costs. I think they are the right costs to pay.

A screen-time blocker that can be talked out of blocking in the moment is not a blocker — it is decoration. A screen-time blocker that ships behavioural data to a third-party server is not a tool — it is a study you didn’t sign up for.

EarnLock is the version of the category that 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.” Here are its rules in one place, with where each one comes from.

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. That is why the no-spaces rule matters. A field written the way people write lists, with a space after every comma, loses one character at every comma. Ten terms, nine wasted characters.

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?

This is where most of the wasted characters come from. Apple documents more of it 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

Fourteen words, none of them in the name, subtitle or category, no spaces after commas, one form of each word. It only works if the app really does track mood, water and sleep. 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 actually 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. That is the strongest argument for treating the field as a small, planned change each release rather than something you rewrite in a hurry. 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

The App Store screenshot tooling category is, on reflection, a slightly absurd one.

Open the top three results on Google for “App Store screenshot generator” and try the workflow: you drop your pre-release screenshots — by definition material that’s still under embargo — into someone else’s web browser. The browser uploads them to someone else’s servers. The rendering, the device-framing, the AI translation pass all happen on infrastructure the vendor owns. Then you download the finished files and upload them, manually, to App Store Connect.

This is a perfectly normal workflow. It’s also a slightly strange architecture for a tool whose entire input is content that hasn’t been announced yet. And once you notice that strangeness, you start to wonder why almost nobody builds the obvious alternative — a native Mac app that does the same thing, but where every byte stays on your machine until you push it to Apple.

This post is an attempt to explain both halves of that question. Why Mac-native is the better architecture in this category. And why, despite that, almost nobody builds it.

What “Mac-native” actually means here

When this post says “Mac-native”, it means a few specific things, all of which fall out of running the workflow in a real macOS app rather than 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. No upload, no remote render farm, no waiting for someone else’s queue.
Files stay on disk. Your raw screenshots, your localised text, your project files — all of it sits in ~/Documents or wherever you put it. The screenshot tool reads and writes locally; 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, 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. They don’t sit in a SaaS vendor’s database.

This is what “native” buys you. It’s not nostalgia for desktop software — it’s a specific architectural property: 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, in roughly ascending order of how often they actually matter:

NDA exposure. 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 to have. Vendor policies that say “we delete uploads after rendering” are policies — they sit on the wrong side of your trust boundary. Native rendering eliminates the question.

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. For a workflow where you’re submitting to App Store Connect and may need to re-render the same project six months later for a minor update, determinism actually 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-10 seconds per screenshot once you account for upload, queueing, render, download. For a project producing 234 screenshots (6 device sizes × 39 locales), this is the difference between a 5-second render and a 5-minute render. The local version also doesn’t depend on the vendor’s servers staying up tonight.

Lower total cost. Once the rendering happens locally, the natural pricing model is a one-time purchase. The cost structure of a Mac app — distributed via the App Store, no server bills — supports a $20–$50 one-time price comfortably. The cost structure of a SaaS web app — render farms running 24/7 — pretty much requires a subscription. This is why Mockly is $12.99 once and most competitors are $19–$49 per month.

No account or login required. This isn’t an ideological preference — there’s just nothing for an account to authenticate against. The app doesn’t store anything server-side because there’s no server. You don’t need to recover your account if you change machines, because there isn’t one. The friction reduction is real and the privacy reduction is real and they’re both downstream of “the rendering happens here.”

So why doesn’t everyone build it this way?

Because the architecture is downstream of the business model, not upstream of it.

A SaaS subscription needs three things: a recurring infrastructure cost to justify the recurring price, lock-in to keep churn down, and a per-user cost structure that scales sub-linearly with revenue. The web architecture provides all three: the render farm is the recurring cost, the locked-in cloud project files are the switching cost, and the marginal cost of one more user is ~$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 (it’s actually negative lock-in — 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.

In other words: the Mac-native architecture is structurally better for the user and structurally worse for the vendor. Which is roughly the standard pattern for indie software, and the reason the category is dominated by SaaS even when SaaS isn’t the right product shape.

This isn’t a moral critique of the SaaS competitors. AppLaunchpad, Screenshots.pro, Screenshot Studio, and the others are all reasonable products built within a reasonable business constraint. They’re just optimising for a different objective function, and that objective function happens to push 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. The architectural specifics:

Metal rendering pipeline. Real 3D device geometry, GPU-accelerated, deterministic. Project re-renders tomorrow produce bit-for-bit identical output. Every device class from iPhone 6.9” (1290×2868) down to Apple Watch (410×502) and up to visionOS (3840×2160) is handled by the same renderer.
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. There’s no Lagerland server 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. Credentials live in Keychain. The upload is a direct device-and-locale-aware submission to App Store Connect’s API — no manual browser uploads, no third-party intermediary.
One-time $12.99. Family Sharing for up to six people. The cost structure supports this; the architecture supports the cost structure.

The price is the consequence of the architecture, not a marketing decision.

A note on Fastlane

The honest answer to “why use a GUI tool at all” for many indie developers is: because the Fastlane setup cost is real. 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. But the setup curve is steep — Snapfile, Snapshfile, UI tests in Xcode that drive the screenshot states, then frameit to overlay device frames, then deliver to upload. It’s a multi-day investment for first-time setup.

For solo developers and small teams, the ratio of GUI-tool setup time (an hour) to Fastlane setup time (a few days) usually points to the GUI tool, especially if you’re shipping new screenshots a few times a year. Mockly is a GUI alternative for that audience; 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 — drop screenshots into a browser, render on the vendor’s server, download the result.
For a workflow whose input is pre-release content under NDA, that’s a strange architecture: a third party sits 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, App Store Connect auth lives in Keychain. Every byte stays local until you push to Apple.
The reason web apps dominate isn’t user preference — it’s that the SaaS subscription business model only works if rendering happens on the vendor’s infrastructure.
Mac-native is structurally better for the user, structurally worse for the vendor. That’s why it’s rare.
Mockly is the Mac-native version. $12.99 once, no subscription, no server, 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 full of two-plus years of data they have never opened, never queried, and never learned anything useful from.

That’s not their fault. The Health app is a beautiful container with very little interpretation. It shows you yesterday’s resting heart rate. It does not tell you which of your habits is consistently moving that number.

Observa was built to be the interpretation layer. But before getting into how it works, here’s the more important practical question — the one I get asked most often.

How much data do you actually need before any of this matters?

The short answer: it depends entirely on what question you’re asking. The slightly longer answer breaks down 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, enough morning HRV readings, and enough workouts to start seeing single-variable correlations — did this one habit consistently move this one metric? The kind of insights this surfaces:

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 of these is a single cause, a single effect, with enough same-condition observations (n ≥ 10) and enough opposite-condition observations to make a statistical comparison meaningful. The threshold I use in Observa is p ≤ 0.10 — looser than academic research, but appropriate for self-experimentation where the cost of being wrong is “you try something else for two weeks.”

What 14 days can’t give you yet: anything multi-variable, anything seasonal, anything that depends on training cycles. The data is real; the slice is just too thin.

Tier 2: 60 days for multi-variable correlations

At around the 60-day mark, two things become possible. First, your personal baseline (the rolling mean and standard deviation for each metric — HRV (SDNN), RHR, sleep efficiency, deep-sleep share, REM share) stabilises enough that deviations become meaningful. Second, you have enough non-overlapping weekly samples to run multi-variable analysis.

Multi-variable means: not “did caffeine affect my HRV?” but “did caffeine combined with screen time on the same evening affect my HRV more than either alone?” That kind of compound pattern is where most of the actually useful self-knowledge lives. A late workout alone may cost you 4% deep sleep. A late workout plus a caffeinated afternoon may cost you 19%. The compound is the answer.

Sixty days is also, not coincidentally, around two menstrual cycles, two training mesocycles, and enough weekly variation to capture how your body changes through normal life rhythm. This is the window Observa uses for its Pro tier multi-variable engine.

Tier 3: 90 to 365 days for trend analysis

Here is where things like baseline drift become visible. Your resting heart rate is not a constant — it drops as you build aerobic fitness, drifts up during periods of stress, falls during taper weeks, climbs through respiratory infections you don’t always notice. Tracking RHR week-over-week against last quarter teaches you what “normal” actually looks like for your body. The same goes for HRV: seasonal swings of 10–20% are common, and reading a winter dip as “I’m broken” rather than “winter HRV runs lower” is a common interpretation mistake.

Ninety days is enough to see one full mesocycle of training adaptation. Six months is enough to see seasonal swings. A year is enough to detect anything genuinely meaningful about how your physiology evolves.

What no amount of Apple Health data can tell you

Causation. This matters a lot, and consumer health apps routinely paper over it.

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. There may be a confounder — caffeine timing, meeting load, stress, food choice, alcohol — that you happen to do on the same days. Statistical correlation alone never proves cause.

The right way to use correlation insights is as hypotheses worth testing, not verdicts. If Observa flags “your sleep efficiency drops after late workouts” with high confidence, the useful response is: try training earlier for two weeks, and see if your sleep efficiency improves. That’s the only way to convert correlation into something close to causal knowledge.

This 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

A lot of consumer health apps compute a single daily score: WHOOP-style 0–100 recovery, an Apple-Watch-style “Mind & Body Hello”, Athlytic’s recovery percentage, a Bevel-style biological age. These are useful as glanceable summaries. They’re also opaque — you have very little visibility into what’s moving them day to day.

The principle Observa is built on is the opposite: never a single score, always the underlying metric measured against your own 60-day baseline. “Your HRV (SDNN) is 18% below your personal 60-day baseline” tells you something. “Your recovery is 58/100” tells you something averaged — and the moment you ask “why?”, the score can’t answer.

This is also why 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 only meaningful comparison is you, today, vs. you, on average, over the last two months. That comparison is genuinely informative. 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, mostly when you’re still — not RMSSD, the metric most sports-science tools use. The absolute numbers are not directly comparable to chest-strap measurements or to numbers from a different watch. What is comparable is your watch’s reading of you over time. Tracking that SDNN reading against a 60-day mean is the right way to read it; comparing your raw number to a friend’s is not.

Apple Watch also captures ECG sinus-rhythm data on Series 4 and later, which adds genuine recovery signal when interpreted in context. Sleep stage data (deep, REM, core, awake) comes from a combination of motion and heart rate variability — accurate enough for tracking trends, not accurate enough for clinical sleep staging.

For the curious, Observa reads all of this from your Health app, computes a 60-day rolling baseline for every metric, and surfaces single-variable patterns on the free tier and multi-variable patterns on Pro. Everything runs on your device — no upload, no account, no servers. The point is to make Apple Health useful for the thing it’s quietly 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 quietly accumulating in your Health app since you got the watch. The only thing missing has ever been a layer that knew how to 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 is rarely about ambition; it’s about the manual workflow taking 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 any indie developer follow to get from one locale to 39, with the upfront cost compressed to about 90 minutes and the per-release cost reduced to about 15 minutes. The key insight is structural, not technical: 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–2 hours to build the 6 base screenshots in Figma or your design tool of choice. This is the actual creative work and it’s fine.
Localisation prep: 1–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: Here’s where it gets brutal. 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 next locale, do it all again. Plan for 2–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.

This is the implicit reason almost every indie app ships in one or two locales. It’s not the App Store Connect requirements that are unreasonable — Apple is right to want localised screenshots — it’s that the consumer tooling makes the workflow so expensive that nobody actually does it.

The architecture that makes 39 locales cheap

The structural shift is this: keep your text as a separate, editable overlay layer, never baked into the screenshot image. Once you adopt this 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.

The benefit compounds. 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.

This is what makes the 15-minute-per-release cost work. The expensive parts (rendering, layout, upload) are mechanical compute, not human labour.

The 90-minute first-release workflow

Assuming you’ve done the initial design pass already (the 1–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–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 (Japanese typically — the character density is different 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: ~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, not 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–30 hours described above. For an app shipping 3 releases per year that’s 30–90 hours per year — half a developer-week.
Figma + AI translation (BYO API) + manual upload: ~$2–5 of API calls per release. Time cost drops to 4–10 hours.
Subscription SaaS (Screenshots.pro / AppLaunchpad Pro / Screenshot Studio): $19–$49 per month = $228–$588 per year. Time cost drops to 1–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–$2 per release at 2026 API prices).

The cost-of-tool is small compared to the cost-of-time. The decision is mostly about which workflow architecture you adopt, not which logo is on the tool.

TL;DR

39-locale localisation manually costs 10–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, never baked 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 compounding return on the first hour of architecture work is months of reclaimed time per year.
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.

The 39-locale workflow isn’t about ambition. It’s about whether your text layer is editable. Get that architecture right and the rest is mechanical.

How Plan Mode builds a wedding (or trip, or pregnancy) checklist

2026-05-13T00:00:00+00:00

The reason most countdown apps stop at days is that days are easy. A date subtracts from another date and the result is a number. You can render that number large, pin a photo behind it, and ship.

Soon. does that too. But the part that turns Soon. into a planner — Plan Mode — is the layer that comes after the number: a checklist of what to actually do between now and the date, tailored to the event type, scheduled backward from the date, and surfaced one task at a time.

This post is the design note for that engine. What it does, what it deliberately doesn’t do, 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-slate Custom type for anything else.

The templates are authored once, shipped in the app binary, and the same for every user. That is a deliberate choice and worth defending.

The alternative is generation: at event-create time, send the event type and date to a server (or an on-device LLM), get back a personalised checklist. We considered it and decided against it for four reasons.

Generation requires data leaving the device. Even if the model is local, the design pressure pushes toward “give the model more context so the output is better” — and the more context you collect, the more the privacy guarantee erodes. Templates that ship in the binary cannot leak event details.
Generated checklists are inconsistent. A wedding template authored once is the same checklist for every user. Two friends comparing notes get the same baseline. A generated checklist is a roll of the dice — sometimes it includes the rehearsal dinner, sometimes it doesn’t, sometimes it adds a task that doesn’t exist. We optimise for stability.
Authoring is slow and that’s a feature. Writing a good wedding template forces a human to ask “is this the seventh task or the first?” An LLM doesn’t ask that. The friction of authoring is the friction of getting it right.
Templates can be audited. A user can read the entire wedding template before installing the app. There is no hidden layer.

So: every Plan Mode template is a list. A human-authored list. Same list 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 absolute 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 the 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.

The reason for T-minus rather than calendar dates is that the template needs to work for any event date in any year. A trip in seven months and a trip in three weeks both use the same template; only the anchoring offset changes. It also turns out to be the way humans actually think about prep — “two weeks before the wedding” is how you talk to your photographer, not “July 29th.”

There’s a second benefit: T-minus is what widgets render. The Lock Screen, StandBy, and Home Screen widgets all show days-to-go. T-minus is the native unit of the app, so the planning layer speaks the same language.

One notification per task, not a stream

If you opt into event notifications (Premium), Soon. sends one notification per Plan Mode task on the day that task is due. Not one notification per day. Not one notification per event. One per task.

For a trip 30 days out, the notification stream looks like this across the whole month:

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, spread over a month, each one actionable on the day it arrives. Compare that to the failure mode it replaces: a generic countdown app firing “30 days until your trip!” every morning for thirty mornings. That is noise, not signal.

The free tier of Soon. doesn’t notify at all. Plan Mode is visible on the event card and the widget; the notifications layer is a Premium addition for users who want active prompting rather than passive presence.

What Plan Mode deliberately doesn’t do

It doesn’t auto-restructure your checklist. If you hide a task, it stays hidden — Soon. doesn’t quietly re-add it next week. If you reschedule a task from T-14 to T-21, that’s where it lives.

It doesn’t share. Soon. is on-device only. Plan Mode checklists don’t sync between users, and two people planning the same wedding each install Soon. and create the event independently. (Shared events via opt-in iCloud are on the long-term roadmap; the privacy model has to stay intact.)

It doesn’t optimise. There is no algorithm that watches your checklist completions and reweights the template. The template you ship with is the template you get. Personal customisation is your edits, not a model’s drift.

It doesn’t surveille. Soon. has no analytics SDK, no event-completion telemetry, no “did this notification work” feedback loop reporting home. We don’t know — and don’t want to know — which tasks users check off, which they ignore, or which they reschedule.

These are not features we forgot to build. They are features we considered, prototyped, and removed.

The templates, in full

Every Plan Mode template is visible on the Soon. landing page — Trip (30-day), Wedding (90-day), Pregnancy (40-week), Birthday (14-day), Graduation (21-day), Move (45-day). Each one 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 is anchored to weeks (Week 28, Week 32, Week 35) rather than days because that’s how pregnancy is talked about in clinical and personal contexts. The Wedding template runs to T-90 because the long-tail prep — vendor confirmation, save-the-dates, dress fittings — starts further out than other event types. The Trip template tops out at T-30 because most trips simply aren’t planned earlier than that in practice.

Those choices are author judgments, not data-driven optimisations. If they’re wrong for your event, you edit them.

Why this matters beyond Soon.

Most apps that try to do “planning” end up either (a) generic to the point of uselessness, or (b) so configurable that they require setup work users don’t want to do. The middle path is event-type-aware templates that ship with sensible defaults, are editable at the seam, and don’t try to learn anything about you.

For a countdown app specifically, the engineering load of this is low. A template is a list. A T-minus offset is subtraction. The hard part is authoring the lists well — and that’s not a technical problem, it’s a writing problem.

If you build planning features into a vertical app — workout, cooking, study, project — the same shape applies: ship templates, anchor them to a meaningful zero (the date, the deadline, the milestone), schedule backward, fire one prompt per task on its day, and stop there. Don’t AI it. Don’t surveille it. Don’t auto-tune it. Just ship the list.

That’s all Plan Mode is.

Soon. is available on the App Store. Free with 5 events forever; 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

Most chess apps that say “adaptive training” mean one of two things. They either mean “we have a difficulty slider,” or they mean “we have a recommendation algorithm over a fixed puzzle library.” Neither of those is what Chessful does.

Chessful’s adaptive training adapts to your specific games. The training 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 training queue is going to drill back-rank defenders. If you finally stopped doing that and started misjudging king-and-pawn endgames, the queue is going to start drilling opposition technique.

This is the design note for how that works. The post is structured around the five stages between “you played a game” and “tomorrow’s training session is ready,” in order. Nothing here is novel computer science — it’s the application of well-understood techniques (engine analysis, rule-based classification, spaced repetition) glued together with the specific judgement calls that make the difference between a feature that works and one that doesn’t.

Stage 1: Stockfish on-device

Every Chessful game ends with the position passed into a local Stockfish process running on the same device. There is no cloud call. The engine runs at a depth tuned to the device — deeper on Macs and recent iPads, shallower on older iPhones — and produces a centipawn evaluation per move.

This is the part of the pipeline that most directly resembles what Chess.com, Lichess, and every other chess analyser does. It’s a commodity. The difference is that for Chessful, the centipawn output is not the product — it’s the input to the next stage. Showing a user a centipawn graph and calling that “analysis” is what every other app does, and it’s exactly the move Chessful is structured to avoid.

A note on engine depth: there’s a tempting design pressure to crank the engine deeper to find more mistakes. We chose not to. A 13-ply analysis at club level finds the mistakes that actually matter for an 800–1800 rated player; a 25-ply analysis surfaces lines that even good players can’t read. The point is to identify the patterns the user can act on, not to demonstrate engine strength.

Stage 2: Motif classification

This is where Chessful diverges from every other chess analyser. The centipawn evaluation is run through a layered motif classifier: hand-curated rule-based detectors plus a small on-device language model. The job of the classifier is to take a position where the user lost a significant amount of centipawn value and label it with one of about thirty motif categories.

A non-exhaustive list of the categories:

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 your own piece’s only defender), 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. The label is chosen by the strictest matching detector — the rules are ordered and the first match wins, to avoid the failure mode where one position gets classified as five different things and dilutes the training signal.

Why hand-curated rules and not a learned classifier? Two reasons. First, rules are auditable: if the trainer is drilling the wrong pattern, we can read the rule and fix it. A learned classifier on chess motifs would be opaque — and worse, would drift between app updates as the model gets retrained, which means the user’s “improvement” might be the algorithm changing what it considers a mistake rather than the user actually improving. Second, the chess motif catalogue is small enough to be tractable. There are roughly thirty mistake categories that matter for club players. Encoding them as rules over the engine’s output is engineering work, but it’s bounded engineering work. Training a classifier wouldn’t beat rules at a problem this constrained.

The small on-device language model contributes to the explanation layer — turning the motif label and the engine evaluation into the one or two sentences the user actually reads. It doesn’t do the classification.

Stage 3: Skill-bucket flagging

Each of the thirty-ish motif categories maps to one of five skill dimensions: tactics, defense, positional play, openings, endgames. When a mistake is classified, the corresponding skill bucket gets a flag. The flag includes the motif label, the position, the move you played, the move you should have played, and a plain-language explanation.

The buckets are visible inside the app. You can see exactly how many tactical motifs were flagged this week, which specific tactical motifs they were (mostly missed forks? mostly back-rank threats?), and how the count compares to two weeks ago. Premium adds long-term trend graphs (90 / 180 / 365 days) so you can see whether (say) your defense flag count is actually trending down over a quarter, or whether you’re plateauing.

This visibility matters because adaptive training depends on the user trusting the algorithm. If the next training session is drilling “back-rank threats” and the user has no idea why, the user disengages. If the user can see — “right, the algorithm is drilling back-rank threats because I made the same mistake in three of my last five losses” — the user does 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 established memory-encoding tool for pattern recognition. Anki popularised it for languages; SuperMemo formalised the underlying schedule decades ago. The mechanic is simple: positions you’ve seen recently are seen again sooner; positions you’ve solved correctly multiple times in a row drop out of rotation; positions you got wrong recently come back fast.

The reason it works for chess specifically is that chess pattern recognition is a memory task more than a calculation task. The reason a 1600 player beats a 1400 player on the same tactical position is mostly that the 1600 has seen the pattern enough times to recognise it within two seconds. Forcing the 1400 player to see the pattern repeatedly at increasing intervals is the right pedagogic move. It’s not glamorous, but it’s correct.

Chessful uses a Leitner-style schedule (boxes 1 through 5, intervals roughly 1 day, 3 days, 7 days, 14 days, 30 days). A new flagged motif starts in box 1. A correct solve moves it up a box; an incorrect solve drops it back to box 1. After two correct solves at box 5, the motif graduates out of rotation — though it can come back if the same motif gets re-flagged from a new game.

Free tier: three sessions per week. Three sessions is enough to cover the highest-priority bucket flags but forces the user to choose. Premium: unlimited sessions. The Premium upgrade is the right move for serious improvers; the free tier is honest training for casual players.

Stage 5: Skill graphs and the feedback loop

After each session, the per-skill-dimension graphs update. The Free tier shows the current week and the previous week. Premium adds 90 / 180 / 365-day views.

The reason these graphs matter is the feedback loop. If you’re three weeks into drilling defense motifs and the defense bucket count is still rising rather than falling, that’s a signal that the drills aren’t working — you need a different intervention. Maybe the motif you’re missing isn’t actually a defense problem; maybe it’s a calculation problem you’ve been mis-classifying. Maybe you’re tired and rushing on the drills. Maybe you’re playing in time-trouble and the motif is fine but the time management is the real bottleneck. The graphs make those questions answerable.

This is the part of the engine that takes the longest to surface. Most users don’t engage with the trend graphs until they’ve been using the app for a month or two. But once they do, the trend graphs become the thing that keeps them training — because they can see the curve moving, or notice when it’s not, and respond.

What this isn’t

A few things adaptive training in Chessful deliberately is not:

It’s not a replacement for studying. Drilling motifs from your own games closes specific gaps, but it doesn’t replace working through an endgame book or a structured course on the Sicilian Dragon. Many improving players run Chessful alongside Magnus Trainer, Chessable, or printed books. The two layers — structured study and adaptive drilling on your real losses — compound.
It’s not a replacement for playing. You need to play games for the engine to have material to work with. Chessful provides 40 AI opponents to play against, but the training queue depends on having games to draw from. Three games is the minimum useful threshold; ten games is where the queue gets really specific.
It’s not a replacement for live human play. Chessful has no live matchmaking and isn’t planning to add it. The thesis is that the part of improvement that happens between games is under-tooled. Live play is well-tooled by Chess.com and Lichess. They’re complementary categories, not competing ones.
It’s not personalised by an opaque AI. The motif categories are explicit, the skill buckets are explicit, the spaced-repetition schedule is well-known. Nothing about the trainer is a black box — you can read what it’s doing and argue with it.

Why publish this

Most chess apps with adaptive training don’t disclose what the algorithm does. The reason isn’t usually proprietary — it’s that “adaptive training” usually means “we picked a difficulty curve” and saying so would deflate the marketing. Publishing the algorithm is a way of saying: there’s a real mechanism here, it’s based on established techniques (Stockfish + rules + Leitner-style spaced repetition), and you can verify it works on your own games over the course of a month.

It’s also a way of saying that algorithmic transparency is a Lagerland default. 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. The principle is the same across the catalogue: if the algorithm is the product, the algorithm should be readable.

Chessful is available on the App Store. Free tier covers 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 lives at 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 boasts about 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 — and not because it has to, but because, for the players Chessful is built for, deeper analysis makes the training worse.

This post is the argument. It’s a contrarian position to take in chess software, where “depth” is treated as a quality metric the way “horsepower” is in cars. The position is that, below roughly 2000 rating, engine depth above 15 ply produces lines that the user cannot read or apply — correct lines, but unteachable ones. The mistakes that actually decide games at 800-1800 are visible at depth 10-15. Deeper analysis surfaces subtleties that crowd out the actionable signal.

It’s a pedagogic choice with a measurable side-effect (analysis runs fast on-device, which makes the iPhone-iPad-Mac on-device promise possible). But the pedagogy comes 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 is not a doubling of work — it’s something like 10,000-50,000× more work. Modern engines mitigate this with alpha-beta pruning, transposition tables, and aggressive heuristics, but the underlying cost growth is the reason cloud analysis exists at all: most depth-25 analyses are too expensive to run on a phone.

The reason Chess.com and Lichess can offer depth 22-28 is that they run the analysis in the cloud, on rented compute, and return the result. The trade-off is the cloud round-trip (and, in Chess.com’s case, a daily quota gating the deep analyses).

Chessful runs Stockfish on-device. The trade-off is the hardware constraint — an iPhone has roughly 1/50th of the compute of a desktop, and aggressive deep analysis on a phone is slow enough to be unusable.

This is where most people stop the reasoning. The argument tends to be: “Chessful runs shallower because it has to; Chess.com / Lichess run deeper because they can.” Phrased like that, deeper is better and Chessful is making the best of a hardware limitation.

But that argument is wrong, and not just slightly — it’s wrong in a load-bearing way that determines whether the training the app produces actually helps you improve. The real argument runs the other direction.

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. The user can read it: queen to e2 defends, knight comes in, bishop trades, queen recaptures, rook lifts to take on e6. The five-move sequence is within calculation reach for a 1400 player. They can see why Qe2 was right (it stops Nf4 from being effective), they can play through the line on a board, they can 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 whose payoff materialises ten moves later as a queen trade. The 1400 player cannot read this line. They cannot calculate to move 13 in their head; they cannot, by playing through it on a board, see why Re1 is the right move rather than the longer Qe2 line that the depth-12 engine recommended.

Both engine recommendations are correct. The position evaluation differs (-1.4 vs -1.9), but neither evaluation is wrong — they’re both Stockfish reading the position to their respective horizons. The question is which one is useful pedagogically.

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 doesn’t generalise to anything they can carry into the next game.

This is the central pedagogic claim: at club level, engine depth beyond what the user can calculate is noise, not signal.

Why the noise actively harms training

It’s not just that deeper analysis doesn’t help. It’s that deeper analysis actively 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” (since the eval difference is greater than the platform’s blunder threshold). Suppose the depth-12 analysis flags Qe2 as the best move and rates the user’s Bd3 as a “mistake” (smaller eval drop, since the comparison is to a shorter calculation horizon).

The depth-12 verdict is actually more useful. Bd3 was a defensive misjudgement that the user can recognise and drill — they failed to see the importance of getting the queen to e2 before letting Nf4 get in. That’s a defender-placement motif. Drillable. Carry-able.

The depth-22 verdict is technically correct but produces no training. “You should have played Re1 for a 13-move forcing sequence” is not a lesson the player can internalise. It’s a fact about the position that has no behavioural consequence.

If you train a player on depth-22 analyses, they learn to nod at engine output and accept that the engine sees further than they do. They don’t learn to play better moves themselves. The accuracy of the engine becomes a substitute for 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 to be calculable by a careful club player.
The mistakes the engine flags (hung pieces, missed tactics, defender-removal blindness, prophylactic skips, opposition errors) are the mistakes that actually decide games at this level.
The training drills derived from the analysis target patterns the player has any 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 club-level tactical horizon): depth 11-13.
Defensive misjudgements with consequences materialising in 3-5 plies: depth 10-13.

Depth 13 covers the entire calculation horizon of a typical club player’s actual play. Going deeper finds additional mistakes — but those mistakes are also additional things the player cannot fix.

The trade-off lives at the top of the club-player range. Around 1800-2000, players begin to read longer engine lines reliably, and the right depth starts creeping up. By 2200, deeper analysis is genuinely useful. By 2400, players want depth 30+ because they actually can use it.

Chessful’s audience is below that band. Depth 13-15 is where the mistakes live.

The same idea — depth as the measure of what a player can actually use — runs the other way in puzzle design: 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 will produce the analysis in roughly 0.5-2 seconds per move on a typical mid-game position. A full 50-move game analyses in 30-90 seconds. That’s well within “I closed the app and reopened it; it’s done” budget.

Running Stockfish at depth 22 on the same phone is slow. The same game would take 5-20 minutes — and the phone would be hot at the end of it. Battery cost is non-trivial.

This is the side-effect of the pedagogic choice. Chessful runs analysis 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 — and would probably have to fall back to cloud analysis for older phones, which would compromise the privacy story. The reason that didn’t happen isn’t that the privacy story is more important than the training; it’s that depth 22 doesn’t produce better training. The pedagogic choice and the privacy story both happen to point the same direction.

What deeper analysis is useful for

This isn’t an argument against deep engine analysis in general. Deep analysis is useful for:

Players above 2000 rating, where calculation horizons extend into the 6-12 ply range.
Opening preparation, where you’re trying to identify objectively best moves in book positions you’ll see again.
Correspondence chess, where the time control allows the player to actually work through engine lines.
Engine vs engine games, where the goal is engine accuracy rather than human improvement.
Theoretical exploration, where the question is “what is the truth of this position” rather than “what should this player do next.”

For club-level improvement training, none of these apply. The training goal is to fix the patterns the player gets wrong in actual games. Those patterns are visible at depth 13. Deeper analysis surfaces additional patterns the player cannot act on.

The mainstream chess software industry has settled on “more depth = better app” partly because depth is a metric that’s easy to compete on (just rent more cloud compute), and partly because the most visible chess players (titled players, streamers, content creators) actually can use deeper analysis and praise it accordingly. The metric became a marketing claim before anyone asked whether it served the median user.

Chessful’s bet is that the median user is served better by training they can read.

Chessful is available on the App Store. The full training methodology — including how Stockfish output gets translated into motif classifications and spaced-repetition drilling — is documented in How Chessful turns a Stockfish evaluation into adaptive training. The complete catalogue of the 30 mistake motifs the analyser flags is documented in The 30 chess mistake motifs Chessful detects.

Countdown psychology — why anticipation beats reminders

2026-05-13T00:00:00+00:00

There’s a thing tourism researchers established about a decade and a half ago that everyone in the holiday-planning industry quietly knows but doesn’t talk about much: the happiest part of a vacation is, statistically, the lead-up.

Jeroen Nawijn’s 2010 study “The holiday happiness curve: a preliminary investigation into mood during a holiday abroad” tracked the affective state of holidaymakers across the full arc of a trip — before, during, and after. The chart that came out of it is well-known in the field. Happiness peaks in the pre-trip weeks, sometimes higher than during the trip itself, and reliably higher than after. The post-trip dip is real. The mid-trip happiness is real. But the pre-trip ascent — the anticipation — is where the most reliable, longest-duration positive affect lives.

This isn’t a quirk of holidays. It generalises. Weddings, births, graduations, moves, long-planned reunions, big concerts, retirement: any specific positive future event has the same emotional shape. The lead-up is its own reward, distinct from the event itself, and often longer-lasting.

Countdown apps are a tool for harvesting that.

This post is about why countdown apps work, what the research actually says about anticipation as a motivational and affective state, why anticipation outperforms reminders for this category of event, and what a well-designed countdown should do with the emotional surface it occupies on a phone Home Screen.

What the research actually says

George Loewenstein, an economist at Carnegie Mellon, formalised the concept of anticipatory utility in 1987 with a paper called “Anticipation and the Valuation of Delayed Consumption.” The setup was disarmingly simple: subjects were asked to choose 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 choose “as soon as possible” — delay-discounting, the same logic that makes a dollar today worth more than a dollar in a year.

Loewenstein found something else. A significant fraction of subjects chose to delay the reward — not because they didn’t want it, but because they wanted to savour the anticipation. The act of looking forward to the kiss was, for them, a source of utility in its own right. They were willing to pay (in delayed gratification) to extend the anticipation phase.

This finding has been replicated and extended across many domains:

Van Boven and Gilovich (2003) showed that subjects who reflected on past experiential purchases (trips, concerts, dinners) were more positive than those reflecting on material purchases (electronics, clothes). They proposed that experiences produce three distinct utility phases — anticipation, consumption, memory — and that the anticipation phase is often the strongest.
Nawijn (2010, 2011) showed empirically that holidaymakers report higher subjective well-being in the lead-up to a trip than during or after.
Sevdalis and Harvey (2007) showed that anticipation effects survive even when participants are uncertain whether the future event will happen at all — a kind of pre-emptive enjoyment.
More recent work in positive psychology calls this prospection — the brain’s capacity to mentally simulate future positive states — and treats it as one of the four pillars of well-being (alongside connection, meaning, and engagement).

The takeaway: anticipation isn’t a side-effect of waiting for something. It’s its own form of consumption. The wait is part of the experience.

Why anticipation outperforms reminders

Reminders and countdowns look superficially similar — both surface a future event on your phone — but they operate on fundamentally different psychological frames.

A reminder frames a future task as obligation. The implicit verb is do: “remember to do this thing.” The affective valence is neutral at best, mildly aversive at worst. People often turn reminders off, ignore them, or rage-dismiss them, especially when the volume is high. The reminder is a debt.

A countdown frames a future event as reward. The implicit verb is expect: “this thing is coming.” The affective valence is positive. People keep countdowns visible, photograph them to send to friends, screenshot them when they hit milestones. The countdown is a savings account.

This frame difference matters because the same future event can be delivered through either frame and the psychological response is measurably different. “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 check at coffee in the morning reads as something you’re glad about.

The point isn’t that reminders are bad. They’re the right tool for negative or neutral future obligations — bills, recurring chores, appointments you don’t want but have to keep. Reminders are the right frame for the dentist.

Countdowns are the right tool for positive future events — the kinds where the lead-up is itself the reward. Reminders are the wrong frame for a honeymoon.

Most countdown apps fail because they’re built like reminders. They render the number bigger, they ship widgets, they add a theme picker. But they treat the date as an obligation to be managed rather than an experience to be savoured. The photo is missing. The checklist is generic. The notifications fire daily. They industrialise anticipation into something that feels like work.

The fix is to design for the savouring use case, not the reminder use case.

What a well-designed countdown actually does

Three components, in priority order. Get any one wrong and the app doesn’t work as anticipation infrastructure.

1. A sensory anchor

The countdown needs a photograph. Not a stock image, not a theme background — a photo the user picked, of the specific future state. The venue, the beach, the maternity ward, the new apartment. 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.

This is why the full-bleed photo background isn’t a cosmetic feature in this category. It is the load-bearing affective component. Without it, the countdown is a number; with it, it’s a daily rehearsal of the future event.

2. A sense of agency

The countdown needs a checklist that handles the prep. Not a generic to-do list — a checklist that knows what kind of event this is and what the prep rhythm should look like.

The reason is anxiety. A bare countdown to a wedding is often slightly anxiogenic — the user knows the date, doesn’t know the path, and the gap between those two pieces of information widens as the date approaches. A countdown that ships a plan closes that gap. The number stops being a reproach (“you should be doing something”) and starts being a coordinate (“you are 21 days out — here is what 21-days-out looks like”).

The checklist also unlocks the savouring effect by giving the anticipation a path. You don’t just look forward to the wedding; you cross off “send save-the-dates” and feel, fairly, like you’re already partly in it. Anticipation pairs with progress to produce a much more sustained positive affect than anticipation alone.

3. A notification rhythm calibrated to one prompt per task, not one per day

The third thing a well-designed countdown does is, paradoxically, shut up most of the time.

The failure mode of every reminder-shaped countdown app is daily “X days to go!” notifications. The first one feels good. The second one feels okay. By the seventh one, the user has banner-banned the app. The signal-to-noise ratio of one notification per day, every day, for 90 days, is terrible. You get 90 notifications and one signal.

A well-designed countdown notifies only on the day a Plan Mode task is due. T-30 has a “book transport” prompt; T-14 has a “buy travel adapter, check passport expiry” prompt; T-7 has “refill prescriptions.” The user gets six or seven notifications spread over a trip month, each one actionable on the day it arrives. The rest of the time, the countdown lives on widgets — Home Screen, Lock Screen, StandBy — ambient and visible without being intrusive.

This is the difference between ambient presence (good) and interrupt-driven presence (bad). Anticipation is sustained by the former and corroded by the latter.

What this means for product designers

If you’re building any product that involves a positive future event — a planning app, a booking app, a goal-tracker, a course-completion app — the countdown frame is probably under-used.

A few specific implications:

Anywhere you currently have a “deadline” or “due date” UI, ask whether the user actually wants a deadline frame or an anticipation frame. Course completion, fitness milestones, savings goals, product launches — most of these are positive future events the user is looking forward to, not negative obligations they’re managing. The UI should reflect that. A photo background on a savings goal page (the apartment, the trip, the camera) is not a gimmick. It is the affective infrastructure of the feature.
Distinguish reminder-frame and countdown-frame events at the data layer. They want different defaults, different notification cadences, different visual treatments. Mixing them in one “events” model produces a UI that pleases no one.
Cap notification frequency to “task days only” by default. Most users will not configure this themselves. The default has to be quiet.
Treat the run-up as the product, not as a wait state. The user experience starts the moment they create the event, not the moment the event happens. Design the 30-day or 90-day run-up as a feature, not as a loading bar.

These are not radical claims. They are how Loewenstein, Nawijn, Van Boven, and Gilovich’s findings translate into product design, and they apply far beyond the narrow category of countdown apps.

Practical: what Soon. tries to do with this

The reason Soon. exists, in one sentence, is that none of the major countdown apps treat anticipation as a primary product surface. They treat it as a number to be rendered. Soon. is structured around the three components above — photo, plan, calibrated notifications — for the same reason every shipped feature in the app is structured that way: because the research-backed model of what makes a countdown valuable says that’s where the value lives.

Plan Mode — the part of Soon. that ships event-type templates and schedules tasks backward from the event date — is the agency component. The full-bleed photo background is the sensory anchor. The one-notification-per-task notification rule (Premium) is the calibration component.

The point of this post isn’t to sell that app, though. It’s to articulate, for anyone building products in this space, that countdown is a category worth taking seriously — not as a novelty UI element, but as an affective infrastructure for positive future events. The research is decades old. The product space is mostly still rendering numbers.

There is a substantial unmet need for tools that take anticipation seriously as a primary experience. The next generation of planning, productivity, and life-events apps will be built on this premise. It’s worth starting from the psychology.

Soon. is available on the App Store. Free with 5 events forever; 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 quietly measures one of the most informative numbers in consumer physiology — and almost nobody uses it correctly.

Open the Health app and tap on Heart Rate Variability. You’ll see a column of numbers from the last few weeks. Probably some are 25, some are 45, some are 80. You’ll see a “Range” chart that looks vaguely informative. You may, if you’ve fallen into the wrong corner of the internet, have read that HRV “should” be above 50ms or that anything below 30 is “concerning.” This is approximately 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 — heart-rate variability — is the variation in time between consecutive heartbeats. Apple Watch specifically 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. 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. That’s a 10× spread. The factors that move someone’s individual baseline:

Age. HRV declines roughly 0.5–1ms per year after age 30 in most longitudinal studies. 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 sexes.
Fitness level. Endurance-trained individuals routinely show 50–100% higher resting HRV than untrained individuals. This isn’t proportionally informative either — well-conditioned athletes often have HRV in ranges that would look “elevated” in a generic chart.
Body position. HRV is higher when supine than seated, 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.

In other words: 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 reading that’s reliably interpretable is 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 are statements about you against yourself. Both compensate for nearly every confounder above — age doesn’t change in 60 days, sex doesn’t change, your fitness doesn’t change dramatically, your watch is the same watch. What does change is what moved your physiology this week relative to last quarter. That’s the question worth asking.

Sixty days is a useful baseline window for three reasons. First, it’s roughly two menstrual cycles, so cyclical variation averages out. Second, it covers two typical training mesocycles, so transient adaptation doesn’t dominate. Third, it provides enough non-overlapping weekly samples to make a standard deviation actually meaningful — fewer than that, and the SD itself is noisy.

This is the baseline window Observa uses, and it’s the same window most peer-reviewed sports-science HRV studies use for the same reasons.

What a single low reading does and doesn’t mean

A single 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, intense training the day before, or just normal day-to-day biological noise. It does not, by itself, mean you should rest, train hard, panic, or rejoice.

What’s diagnostic is a pattern. Three consecutive days more than one standard deviation below baseline is signal. A single 25% drop after a known stressor is information about that stressor, not your health. A 25% drop with no identifiable cause and no resolution within 72 hours warrants attention — but attention from a clinician, not a consumer app.

The pattern threshold I think is roughly right for self-experimentation is: needs at least 10 same-condition observations across a 60-day window, and at least one standard deviation of separation between conditions, before you should treat a finding as anything other than noise. Most consumer apps surface “insights” with far thinner statistical backing than this. That’s mostly why their 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 a 10–20% drop in your HRV baseline from October to February. The usual suspects: cold exposure, less daylight, less aerobic activity, more indoor time, altered sleep patterns. None of these are pathological. All of them produce the same downward drift.

Reading a winter dip as “I’m broken” is one of the most common interpretation mistakes. Reading it as “winter HRV runs lower for me, here’s the new baseline to measure deviations from” is the correct response. The baseline is supposed to drift — your physiology drifts with the world.

What this means in practice

A few practical rules that fall out of all this:

Never compare your number to anyone else’s, ever. Not a friend’s, not a stranger’s on Reddit, not a “normal range” infographic. The comparison is meaningless. Compare yourself to yourself.
Track trends, not points. A single day’s HRV is mostly noise. The 7-day rolling mean is signal. The 60-day baseline is the frame that makes the signal interpretable.
Read it as a deviation from your own baseline, not a raw number. HRV is roughly log-normally distributed, so the same millisecond gap means more at a low baseline than a high one. Comparing today’s SDNN to your personal rolling mean as a percentage deviation is what makes it interpretable.
Identify your stressors. If your HRV consistently drops after late workouts, after alcohol, after high screen time, that’s actionable. The drop itself isn’t the problem — the unknown cause is.
Expect seasonal drift. Winter lower, summer higher is normal. Pandemic, illness, life stress, a new baby — all expected baseline movers. The baseline is a moving frame, not an absolute 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. That’s the only HRV comparison that’s worth making.

TL;DR

Absolute HRV varies 3–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–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. Pathologising it 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 was always there in your Health app. The only thing that’s been missing is the frame that makes it informative.

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’s not an indictment of Apple Health. It’s an indictment of how consumer health apps display data they don’t actually have a frame for. The trick to using Apple Health well is knowing which numbers are worth tracking against a personal baseline, and which you should stop opening the app to check.

This post is the short list, with the reasoning for each cut.

The 6 that reward interpretation

These are the metrics where 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 stable enough baselines to make deviations meaningful.

1. HRV (SDNN)

Heart-rate variability — which Apple Watch records as SDNN, the standard deviation of the intervals between successive heartbeats — is the single most informative metric it collects. It integrates autonomic nervous system state, recovery, training adaptation, alcohol load, sleep quality, and acute stress into one number — and changes measurably within 24–48 hours of a habit shift.

Caveat: only meaningful against your own 60-day baseline. Absolute HRV (SDNN) varies wildly between people. See the dedicated post on why.

2. Resting heart rate (RHR)

Slower-moving than HRV but more interpretable. Apple Watch reports an averaged RHR that smooths nicely over a week. Useful for spotting:

Aerobic fitness trends (5–10 bpm drops over 3–6 months of consistent cardio)
Pre-illness signals (sustained 5–10 bpm above baseline often precedes a cold by 24–48 hours)
Alcohol load (RHR routinely rises 5–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

The percentage of time in bed actually asleep. Apple Watch sleep tracking is mediocre at staging but very good at total time. Sleep efficiency above 90% is excellent; consistently below 80% often indicates wind-down issues, caffeine timing problems, or anxiety.

This is the sleep number that holds even when you’ve had a short night. It’s also one of the most actionable: small wind-down changes typically move it 3–5 percentage points within two weeks.

The fraction of your night spent in slow-wave sleep. Apple Watch sleep staging is approximate, but the trend is reliable. Deep sleep is where most physical recovery and memory consolidation happen — and it’s the stage most disrupted by alcohol, late workouts, late food, and bedroom temperature.

What moves it (in approximate order of impact): alcohol within 3 hours of bed (-20–40%), late workout after 18:00 (-10–20%), late large meal (-10–15%), high bedroom temperature (-5–15%), high screen exposure within 30 min of sleep onset (-5–25%).

5. Heart-rate dip during sleep

The percentage your heart rate drops from daytime resting average to overnight average. A dip of 15–25% is typical; sustained dips below 10% can indicate poor sleep quality even when the headline “hours slept” looks fine.

This is the metric AutoSleep popularised and almost nobody else surfaces — yet for many people it correlates more strongly with subjective recovery than total sleep duration. Apple Health has the data; you have to compute it yourself or use an app that does.

6. Active energy (weekly)

Active calories on a daily basis are too noisy and too dependent on measurement accuracy. On a weekly basis, the rolling total is one of the cleaner load metrics Apple Health has. Useful for:

Spotting training-load creep (week-over-week increases of >10% predict overuse injury risk)
Identifying recovery weeks (planned drops of 30–40%)
Long-term consistency (which is what actually moves cardiovascular fitness)

Read weekly. Daily active energy is mostly noise.

The 12 worth ignoring (or skimming at best)

These are the metrics that look meaningful but mostly aren’t. Some are perfectly fine adherence prompts but offer no interpretation surface. Others have enough sensor error or definitional ambiguity that you’ll spend more attention on them than they pay back.

7. Daily step count

A near-perfect proxy for “did you wear your watch today.” Sensitive to phone-in-pocket vs watch-on-wrist, location (urban walkers vs suburban drivers), and what counts as a step (treadmill desks generate phantom counts). 8,000 steps mostly-deliberate beats 14,000 of urban drift; the number doesn’t distinguish.

8. Move ring closure

Adherence prompt, not interpretation. Useful for getting started; useless once you’ve internalised the habit.

9. Stand hours

Apple’s algorithm rewards a minute of standing per hour for 12 hours. Generously calibrated. Easy to game. Doesn’t correlate with anything else.

10. Daily exercise minutes

Apple’s “exercise minute” definition counts brisk-walk-or-above heart rate. Adequate for tracking aerobic adherence; unreliable for strength training (low heart-rate-elevation despite high muscular load), gentle yoga, or skill sports.

11. VO2 Max (estimated)

Genuinely useful, but moves quarterly. Don’t track weekly. The day-to-day variation in the estimate is almost entirely noise. Check monthly.

12. Cardio recovery

The 1-minute heart-rate recovery after exercise. Apple Watch’s calculation is sensitive to whether you stop moving at the right moment. Even when measured well, individual variation is high and the recovery-rate baseline shifts with fitness over months. Useful in clinical contexts; mostly noise in consumer use.

13. Daily resting energy

Apple’s estimate of your basal metabolic rate, derived from height/weight/age/sex. It’s a formula, not a measurement. It changes only when you update your profile.

14. Walking heart-rate average

A useful sanity check for fitness trends over 6+ months. Too noisy for week-over-week interpretation. Don’t pay weekly attention to it.

15. Headphone audio exposure

Genuinely useful for hearing protection. Not actionable except as a “turn it down” reminder. No interpretation surface beyond “is the number high or low.”

16. Environmental sound exposure

Same as above — useful for protection, not for self-knowledge.

17. Mindful minutes

If you meditate, log it. The metric is a participation count. There’s no signal-vs-noise question — you either meditated or you didn’t.

18. Daily flights climbed

Adherence number for general activity. Highly dependent on whether you live in a building with stairs. No interpretive frame.

How to tell the difference

The general test for whether an Apple Health metric is worth interpreting:

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; sleep efficiency signal is 5–15 percentage points. Active calories error is ±20–30%; daily active calories signal is often smaller.
Is the baseline stable across seasons / life events? If not, you’re tracking environmental noise.
Can you act on a deviation? If a 20% drop in this metric doesn’t change anything you’d do, don’t track it.

Six metrics pass all five tests. About a dozen pass one or two. The rest are vanity, adherence, or sensor data masquerading as insight.

What an interpretation app actually does

The reason most consumer health apps display 30+ metrics on a dashboard is product, not science — more numbers signal more value. The reason a useful interpretation app surfaces six of them is the opposite: more numbers means more attention spent on noise.

Observa is built around the short list. It computes rolling 60-day baselines for the six metrics that actually reward attention, surfaces correlations between your habits and those metrics, and ignores the rest. Step count, move-ring closure, stand hours — Apple Health collects them; Observa doesn’t make you stare at them. The metrics that don’t reward interpretation don’t get a dashboard tile.

For most people, getting useful self-knowledge out of Apple Health is less a tracking problem than a subtraction problem. The data has been collecting itself for years. The hard part is figuring out which numbers are worth 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 — illness and fitness trend signal
Sleep efficiency — most actionable sleep metric
Deep-sleep share — what most habits actually move
Heart-rate dip during sleep — under-used recovery signal
Active energy (weekly) — 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: probably not worth your weekly attention either, unless you’re a researcher with a specific question.

Getting Apple Health useful is mostly a subtraction problem. Six metrics. Sixty-day baselines. Everything else is noise pretending to be insight.

App Store screenshot guidelines (2026): sizes, requirements, and what gets rejected

2026-05-13T00:00:00+00:00

App Store screenshots get apps held up for two completely different reasons, and most guides only cover one of them. The first is technical: wrong size, wrong format, a missing required device — App Store Connect bounces the upload before a human ever sees it. The second is editorial: the screenshot uploads fine, then a reviewer looks at it and decides the screen isn’t showing the real app, and you get the polite “your screenshots don’t appear to show actual functionality” rejection at 2 AM the night before launch.

This post covers both: the current specifications, then a working developer’s read of Review Guideline §2.3.3 — which patterns reliably pass, and which ones get rejected.

App Store screenshot specifications (2026)

The big change to internalize first: 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. The old ritual of exporting 6.7-inch, 6.5-inch, and 5.5-inch bundles is gone.

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 6.3-inch, 6.1-inch, 5.5-inch, 4.7-inch, and 4-inch are all generated by scaling. You may still upload size-specific screenshots when you want pixel-perfect control on a given device — it’s just no longer required.

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 front-load your strongest screenshots and treat the rest as depth.

Apple revises these as new hardware ships; the numbers above are current as of June 2026. Before any release, confirm against Apple’s official screenshot specifications. Now the half that the specs can’t protect you from.

What §2.3.3 actually says

Apple’s wording on §2.3.3 has been refined a few times since 2017, but the durable spirit is: a screenshot represents the app a user will receive. Not a future version. Not a concept. Not a marketing illustration of what you wish the app did. The actual app, in actual use.

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 actually does.

The rule, in plain language: the content inside the device screen must be the real app. Everything around the device frame is decorative styling and largely up to you.

The five rejection patterns I’ve seen most often

1. The “future-build” screenshot. The most common. A marketing team shipped a previous version’s UI in the screenshot bundle, or used a Figma concept that hasn’t been built yet. Reviewer downloads the app, can’t find the feature, rejects. Always re-render screenshots from the actual build you’re submitting.

2. The “concept-art” screenshot. Especially common in apps with rich graphics — games, drawing apps, AR apps. The screenshot is closer to a hero shot for a website than an in-app capture. Reviewer reads it as misleading. The fix is to find an in-app moment that genuinely looks like the hero shot and capture it.

3. The “deleted-feature” screenshot. Feature existed in version 2.4, was removed in 2.7, screenshots from 2.4 still uploaded for 2.7. Re-uploading old screenshots is one of the easier ways to inherit a rejection from your own past.

4. The “in-app-purchase price mismatch.” Screenshot shows “$0.99 — limited time,” App Store listing shows $4.99. Reviewer flags the inconsistency. Best practice: either show real IAP prices that match the listing, or don’t show prices in screenshots at all.

5. The “fictional metric” screenshot. Common in fitness, finance, and analytics apps. Screenshot shows “247,891 active users this month” or “+42% sleep score” but the demo data in the app shipping today shows different numbers. Reviewer treats this as misrepresentation.

App Preview videos: specs and the same content rule

App Preview videos have their own specifications, then inherit §2.3.3 on top.

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–12 Mbps or ProRes 422 (HQ), 30 fps, AAC audio.

Then the content rule, with teeth: the video must be actual app footage captured from a device — not a screen-recorded mockup, not an animated concept reel, not external camera footage of someone holding a phone. Apple checks this rigorously, 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. It’s tempting to reuse screenshots when only minor UI changes happened. Each time you do this you risk inheriting a rejection from a feature that quietly went away.
Strip IAP prices unless you’re certain. If the prices are dynamic, regional, or change with promotions, leave them out of screenshots entirely. Show feature value rather than price.
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 the visual style that fits your brand — 3D Metal render, flat outline, tilted angle, transparent background, no frame at all. Reviewers don’t care about the frame. They care about what’s on the screen inside it.

The reason a capture-first tool like Mockly is structurally compliant with §2.3.3 by default is that the 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; the frame is just a render placed around it. The reverse — mock up a concept screen in Figma, drop it into a phone outline, export — is the workflow most likely to drift into rejection territory, because it encourages designing screens that aren’t in the app 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–10 screenshots per localization, PNG or JPEG, flattened. First 2–3 show in search — front-load them.
§2.3.3 is about the screen content, not 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–30 seconds, 886 × 1920 on iPhone — same “real footage only” rule.
Capture-first workflows pass cleanly; design-first workflows risk drift.

For the surrounding workflow, the native screenshot tooling argument, shipping screenshots in 39 languages, and the rest of the indie iOS developer tools go deeper. The specs change with each new device; the §2.3.3 spirit has held for nearly a decade. The rejection emails keep arriving because most indie pipelines make compliance an afterthought instead of the default.

The 30 chess mistake motifs Chessful detects (and why each one matters)

2026-05-13T00:00:00+00:00

When the prior post — How Chessful turns a Stockfish evaluation into adaptive training — went up, the most common follow-up question was straightforward: what are the motif categories?

Fair question. The post described the pipeline but treated the motif catalogue as a black box of “about thirty categories.” This post opens that box. Below 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 pedagogy — what’s documented in Aagaard’s Excelling at Chess series, Yusupov’s Build Up Your Chess nine-volume 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 specific to what an analyser running on top of your full game history can detect that a human coach reviewing one game cannot. Most of the rest is standard improvement material wrapped in a name a club player can carry into the next game.

The reason it’s worth publishing the catalogue is that algorithm transparency is the only way to argue with an algorithm. If you don’t know what Chessful’s classifier is looking for, you can’t tell whether it’s flagging the right thing about your game. If you can read the catalogue, you can.

Skill dimension 1: Tactics (10 motifs)

Tactical motifs are the ones where the mistake was a calculation or pattern-recognition failure on a forcing sequence. They tend to be the most actionable category — drillable, fast to recognise, and reliably re-encountered across openings.

1. Hung piece

The classic. You moved a piece (or left a piece) onto a square where it can be captured for nothing, or for less than it’s worth. Drilling pattern: piece-safety scans on the position before committing a move.

2. Missed fork

An enemy piece (often a knight) could have moved to a square attacking two of your pieces simultaneously, winning material. Drilling pattern: knight-radius blindness — recognising where an opposing knight could land next, especially around the king.

3. Missed pin

You moved a piece in a way that left another piece behind it unable to move (or unprotected if it did move). Drilling pattern: file/diagonal awareness around long-range pieces (bishops, rooks, queens).

4. Missed skewer

A piece attacked a more valuable piece in front, forcing it to move and capturing the less valuable piece behind. Drilling pattern: piece-alignment awareness — particularly for back-rank rooks and same-diagonal queens.

5. Missed discovered attack

A piece moved out of the way to reveal an attack from another piece behind it — often combined with check. Drilling pattern: x-ray vision through your own pieces.

6. Missed double attack

A single move attacking two distinct enemy pieces or squares, not necessarily a fork. Drilling pattern: simultaneous-threat detection.

7. Missed deflection

A piece had to be lured off a critical defensive square, and the deflecting move was available but not played. Drilling pattern: identifying which enemy piece is over-loaded (defending multiple squares) and finding the move that exploits it.

8. Missed overload

A defending piece had too many jobs; a single attack forced the choice and won material. Drilling pattern: counting attackers and defenders on every critical square before committing.

9. Back-rank threat

Your king’s escape squares were blocked by your own pieces, and a back-rank mate was available but not seen (in either direction). Drilling pattern: prophylactic h-pawn pushes; recognising rook + back-rank shapes.

10. Smothered mate possibility

A knight on f7 / f2 (or similar) creates a mate when the king’s escape squares are blocked by its own pieces. Less common but reliably decisive when it appears.

Skill dimension 2: Defense (5 motifs)

Defensive motifs are the most under-trained category among club players. Generic puzzle apps drill tactical attacks; defensive recognition is what costs games at the 1200–1800 range.

11. Defender-removal blindness

The piece you just moved was the only defender of a critical square (often the back rank, often a king-adjacent square). Drilling pattern: before any capture or trade, identify whether your piece is currently defending something. This is the single 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) without compensating for the structural weakness. 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 materialised three moves later. Drilling pattern: looking for the opponent’s plan before formulating 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 enough activity in return. Drilling pattern: pawn structural awareness — identifying which pawn moves create permanent weaknesses.

15. Wrong piece exchanged for defender

A trade you initiated removed your own defensive piece and left a critical square undefended. Distinct from defender-removal blindness because the trade was voluntary. Drilling pattern: post-trade defender count.

Skill dimension 3: Positional play (5 motifs)

Positional motifs are the slowest to drill but produce the most durable improvement. They generalise across openings.

16. Wrong piece traded

You exchanged a piece that was structurally important (a good bishop, an active knight) for a less important enemy piece. Drilling pattern: piece-quality assessment before any trade.

17. Wrong side castled

You castled queenside or kingside when the opposite would have been safer based on pawn structure or piece placement. Drilling pattern: pre-castling structural review.

18. Weak square allowed

You allowed an enemy piece to reach an outpost square (often c4 / c5 / d4 / d5 / e4 / e5 / f4 / f5) where it couldn’t be challenged. Drilling pattern: identifying outpost squares before your opponent gets there.

19. Wrong pawn break

A pawn break (the move that resolves the central tension or creates an attacking path) was either delayed too long, mistimed, or played in the wrong direction. Drilling pattern: recognising the canonical pawn break for each pawn structure.

20. Time-on-the-clock-on-the-wrong-move

The Chessful-specific motif — you spent disproportionate clock time on a move that didn’t deserve it (often a recapture that was forced, or a routine developing move), leaving you with too little time for a critical decision later. Drilling pattern: time-budgeting per move. Only flagged in games where a clock is on.

Skill dimension 4: Openings (3 motifs)

Opening motifs are the most user-specific category — they depend on what repertoire the user actually plays. Chessful builds a profile of your most-played opening lines over time and flags deviations.

21. Repertoire drift

You deviated from your usual opening setup in a way that lost a tempo, allowed an early piece exchange you don’t normally allow, or transposed into a structure outside your repertoire. Drilling pattern: opening-line review focused on the deviation point.

22. Book-move missed

A widely-known book continuation was available and would have been the principled move; you played a reasonable-looking but non-book alternative that gave up an advantage the book line preserves. Drilling pattern: book-line study on the specific opening.

23. Transposition into a bad line

You played a sequence of moves that, by transposition, reached a position known to be inferior — often because the move order swapped a critical defensive resource. Drilling pattern: transposition-awareness for your own repertoire.

Skill dimension 5: Endgames (6 motifs)

Endgame motifs are the most technically distinct — they’re the ones where pattern recognition has to be paired with concrete calculation, and where small mistakes are most likely to convert a winning position into a draw.

24. Opposition direction error

In a king-and-pawn endgame, you took (or yielded) the opposition in the wrong direction, allowing the opposing king to either advance with its pawn or block your advance. Drilling pattern: opposition technique on direct, distant, and diagonal opposition.

25. King-too-late

Your king didn’t activate in time for the endgame — it sat passively on the back rank while the opposing king moved to the centre and the position simplified into a lost king-and-pawn race. Drilling pattern: identifying the point in a middlegame where king activation becomes the most important move.

26. Wrong rook activation

In a rook endgame, you placed your rook passively (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 converted a winning endgame into a draw by playing a move that simplified to a known-drawn structure (often wrong-color bishop, or a fortress). Drilling pattern: recognising drawn endgame structures before simplifying into them.

28. Wrong-color bishop endgame

You traded into an endgame where your remaining bishop is the wrong colour to control the promotion square of your passed pawn. Often combined with drawn-but-played-on. Drilling pattern: pre-trade endgame projection.

29. Technique error in K+P endgame

A specific technique (Lucena, Philidor, square-of-the-pawn, key-square calculation) was available and known to be winning, but the technique wasn’t executed correctly. Drilling pattern: drilling the specific technique that failed.

30. Technique error in R+P endgame

Same as the K+P version but for rook endgames — the technique (Lucena bridge, Philidor third-rank defence, short-side defence) was the right one but executed incorrectly. Drilling pattern: rook-endgame technique-specific repetition.

How the catalogue maps to training

Each motif maps to exactly one of the five skill buckets (the dimension it appears under above). When Chessful flags a motif in one of your games, the corresponding skill bucket gets a flag. The spaced-repetition queue pulls from the flagged buckets — most-recently-flagged first, with Leitner-schedule intervals between repeats.

The reason the bucket layer exists between motif detection and the training queue is that patterns generalise within a skill dimension better than they generalise across dimensions. If you keep missing forks, drilling more fork puzzles is the right intervention. If you alternate between missing forks and misjudging endgame opposition, those are different cognitive failures and need to be drilled separately — not bundled into a generic “tactics-and-endgame practice” queue.

That’s the whole reason for skill dimensions. They aren’t display categories; they’re the level at which spaced repetition is scheduled.

What’s not in the catalogue (and why)

A few things Chessful explicitly does not detect:

Time-pressure tactics. A blunder under thirty seconds on the clock often isn’t a pattern problem — it’s a time-management problem. Chessful flags it as time-on-the-clock-on-the-wrong-move (motif 20) rather than 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’re playing the Najdorf Poisoned Pawn variation and miss a move-20 nuance, Chessful flags it as repertoire drift rather than as a positional or tactical motif. The correct intervention is opening study, not pattern drilling.
Psychological mistakes. Resigning prematurely, accepting a draw in a winning position, playing too aggressively when ahead — Chessful doesn’t try to detect these because they’re hard to disambiguate from objective mistakes from engine output alone.

These exclusions aren’t oversights; they’re the cases where motif-based drilling isn’t the right intervention, and where Chessful would mislead the user by pretending otherwise.

How the catalogue evolves

The catalogue isn’t frozen. Two things change between app versions:

New motifs get added when a recurring mistake pattern appears in user games that the existing rules don’t catch cleanly. The most recent addition (v1.4) was weakening pawn push without compensation — previously folded into king-safety underestimate, split out because the drilling patterns are genuinely different.
Existing motifs occasionally get split or merged when one category is doing too much work, or when two categories rarely produce distinct training value. Splits and merges are conservative — they only happen when the resulting training queue would meaningfully differ.

All changes are logged in the app’s changelog with the motif name and the version. The spaced-repetition queue doesn’t reset on a taxonomy change — flagged positions migrate to the closest equivalent motif under the new taxonomy.

The catalogue above is what Chessful is currently looking at when it tells you “you played Nxd5; the knight was your only back-rank defender.” That sentence is the surface; the motif label underneath it is defender-removal blindness; the bucket it flags is Defense; the next training session draws from that bucket using spaced repetition.

The whole machine is open to inspection. That’s the point of publishing it.

Chessful is available on the App Store. The methodology behind the catalogue is documented in How Chessful turns a Stockfish evaluation into adaptive training. The companion design note on the forty AI opponents is at Forty chess opponents, and none of them are me.

The Mac already shipped with every media tool — 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. It is also, in 2026, 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 the persistent dominance of CloudConvert, Zamzar, Smallpdf, and the rest exists not because the local primitives are missing but because nobody had bothered to consolidate them 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 the contribution MediaKit makes is real but it is also limited, and it would be dishonest to claim otherwise.

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 of these are first-party Apple frameworks shipped with macOS. Specifically:

AVFoundation handles every video and audio operation MediaKit performs. Compression, conversion, trimming, merging, frame-accurate cuts — all of it.
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. None of it is proprietary to the studio. The frameworks have been on every Mac for years. They are sandboxed, hardened-runtime-safe, and have been optimized for Apple Silicon since the M1 launched.

What MediaKit does is wire them together. One app. One drag-and-drop surface. One menu bar item. Six Shortcuts actions. 133 distinct tools mapped against the formats and operations a normal Mac user actually wants — instead of five separate utilities, each with its own settings panel, license model, and update cadence.

That’s the whole bet. The bet is consolidation, not novelty. I am going to keep saying this honestly 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?

A few reasons, and they are worth being clear about because they are also the reasons MediaKit needs to be a specific shape:

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 — never a 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 is specifically a response to this. Drop any file, MediaKit picks the right tool.
Trust by exhaustion. Users are tired. The website is fast and looks professional. The privacy cost is invisible. The cost only becomes legible 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-forever tier is five tools: Video Compress, Image Compress, Image Resize, Audio Convert, 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, forever, with no nag screen, no countdown, no 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. There is no subscription you can forget to cancel — Pro is a one-time purchase.

Pricing the free tier this way is, in the indie Mac segment, slightly unusual. Handbrake is free. ImageOptim is free. Keka is free. The studio’s argument is that the operations a typical user runs most often should be free in MediaKit too — not as a trial-extension trick, but as the actual long-term offer. If you only ever compress videos and convert HEIC, MediaKit costs you nothing, forever, 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 the free user into a Pro user — those are different users.

What this is not

A few clarifications, because I have learned to write them:

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), not editorial. 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), three days unlocked for everything else, and never leaves the machine. That’s the whole pitch this weekend.

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. The day I’d actually like to have has nine. Somewhere in between is where the work happens — and the device I do the work on has, until this week, not been the device my planner ran on.

Taskful Day shipped on the Mac on Wednesday. This is the small Saturday essay on why that was the missing piece, and what I did and did not do to make it work.

The Catalyst escape hatch I did not take

Apple has been generous, for the last several years, about how easy it is to bring an iPad app to the Mac. Click a checkbox in Xcode, set a few capabilities, fix the obvious touch-target sins, ship. A lot of indie planners and to-do apps live on the Mac this way. They are, structurally, an iPad window with a menu bar.

For an app you open once and dismiss — a calculator, a unit converter, a one-off utility — Catalyst is fine. For an app you keep open in a corner of the screen for eight hours, alongside Slack and your calendar and the document you’re actually trying to finish, it is not. The pixels read wrong. The keyboard shortcuts feel pasted on. The window doesn’t behave the way a Mac window behaves.

So I did not Catalyst this. Taskful Day on Mac is a SwiftUI app built for the Mac first, with AppKit underpinnings where SwiftUI doesn’t yet give us the affordances a real Mac app needs. The window resizes the way you expect. The keyboard shortcuts are real Mac shortcuts. The menu bar is populated. Drag-and-drop works the way macOS drag-and-drop is supposed to, including into and out of other apps. There is a real menu bar item for quick capture without opening the main window.

It took longer than Catalyst would have. It is, I think, the correct shape.

One Universal Purchase, not three

The other decision worth being explicit about: 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. There is no separate Mac SKU.

This is not the default. Many indie apps charge separately for the Mac version, and there are legitimate reasons to — the Mac app is often a substantial chunk of additional work, and the audience is smaller, so a per-platform price compensates. I am not arguing those teams are wrong.

But for a planner specifically, asking the user to pay twice misses what the app is for. The whole point of Taskful Day is that the day you plan on one device is the day you finish on another. Splitting that across two purchases — pay for the planning surface, pay separately for the doing surface — would make the pricing model contradict the product.

So: one purchase, every device. Universal Purchase has been around since 2020; this is one of the cases where it actually makes the right shape easy.

iCloud, not someone else’s server

Sync is the other place a planner can fail quietly. The day plan you make on your phone has to be on the Mac, and the focus session you ran on the Mac has to show up in the iPhone widget, and none of this should happen on someone else’s server.

Taskful Day syncs through your personal iCloud account using CloudKit. The studio has no servers in this loop. I cannot see your tasks. I cannot lose your tasks 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, end of story.

This is structurally different from the way most cross-platform planners work. The typical model is: sign up for an account, your tasks live on the company’s servers, the apps are clients. The studio does not run that model anywhere in the catalogue, and I am not running it here. The trade is that you cannot share a task list with a teammate through Taskful Day, because there is no shared cloud surface to share through. If that’s a workflow you need, the app is the wrong shape for you and I’d rather you use something else.

What does “now on Mac” actually unlock for Taskful Day?

Three things, specifically, that the Mac app changes in practice:

Planning happens at the desk now. The Day Clock and Energy River views — the two ways into the day that Taskful Day offers — 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 drop into a session at your desk, the rest of the desktop dims, the menu bar shows the countdown, and the iPhone is free to be 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, is closer to two minutes of actual writing on a real keyboard. That changes what shows up in it, which changes what the pattern view shows you a month later.

The iPhone app is still the right device for capture — you think of something, you tap, you talk, it’s filed. The iPad is still the right device for the morning review. The Mac is now the right device for the actual work, and the planner sits next to the work.

Where this fits next to Things, TickTick, Sorted³

A quick note for users comparing:

Things 3. Things is a beautiful GTD-style task manager. Taskful Day is not GTD. Things assumes you want a project tree that lives forever. Taskful Day 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 correct and Taskful Day is not.
TickTick. TickTick is a cross-platform Swiss-army knife with reminders, calendars, habit tracking, Eisenhower matrices. Taskful Day deliberately does less. There is no habit tracker, no Pomodoro per se (the focus mode is more immersive than Pomodoro), no team features. Less surface area is the point.
Sorted³. Sorted is a fantastic time-blocked planner. If you live in time-blocks specifically — meaning, every task gets a start and end — Sorted is the better tool. Taskful Day’s Day Clock view does some of this, but the design philosophy is “realistic plan you can finish,” not “schedule every minute.”

There are good calm-design planners in this space and Taskful Day is not the only one. It is, as of this week, 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 — focus session timer, advanced analytics, widgets, iCloud sync, unlimited follow-ups — is $2.99/month or $39.99 lifetime, applied across every device you sign in with.

Get Taskful Day.

If you are looking for the studio’s broader take on streak-based habit apps and why I don’t ship one, the streak counter essay is the long-form argument for the design choice you’re already feeling in this app.

The next entry, on Saturday, is on 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. It will, I expect, 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.

If you only read one thing about it, read this: there is no subscription. Seven days free, no card on file. After that, you choose a one-time tier between $9.99 and $39.99 and you own the app. No auto-renew. No trial trap. Your training history is never held hostage by a lapsed subscription.

The rest of this post is about why I built LiftLog this way, and what I’m trying to learn by doing it.

Subscription pricing is a tax on training history

Strength training is a long-term practice. The whole point is that you keep showing up, week after week, year after year, and the data you accumulate — 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. The implication is straightforward: you stop paying, you lose the app, you often lose access to your own history. I find this morally awkward. The user generated the data. The user’s effort produced the personal records. Charging rent on someone’s own training journal feels like the wrong shape for the relationship.

I’m not naïve about the economics. Subscriptions smooth revenue, they fund support, they pay for ongoing development. There are good reasons services like Strong, Hevy, and Fitbod use them — and I don’t think those teams are doing anything wrong. But I wanted to find out whether a different shape 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 LiftLog is genuinely the cheapest version of the app you can justify, this is the right choice. No guilt, no asterisk.
Good — $19.99. The middle. If LiftLog has earned a serious amount of your training time and feels like the tool you’ll keep using, this is the calibration most users will land on.
Generous — $29.99. A step up for users who want the work supported, or who have benefited from indie software in the past and choose to lean in.
Patron — $39.99. The top tier. Same app, no extra unlocks. This tier exists so people who want to back the studio at a level closer to a year of competitor subscriptions have a way to do that — without it being awkward, hidden, or a tip jar.

All four tiers unlock the same product. No content gating, no “premium” features behind a higher number. The choice is about what LiftLog is worth to you, not about which features you get.

Why four tiers and not a slider

A slider would be more flexible, but every UX paper I’ve ever read on charitable giving and pay-what-you-want pricing says the same thing: when you give people too many options, they freeze, and when they freeze, the median paid amount drops. Four tiers gives people meaningful agency 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 rather than top-end — and a meaningful number of users will choose to support the work above the median. That’s the bet.

The labels matter too. Calling the tiers Fair / Good / Generous / Patron — instead of Basic / Standard / Plus / Pro — does something I want this app to do everywhere: it removes the implication that more money buys you more app. It doesn’t. It buys the studio more runway. That distinction should be honest, not obscured.

What this is not

A few clarifications, because I’ve already had two friends ask:

It’s not freeware. The seven-day trial is generous, no-card, no-pressure — but after that the app does ask you to choose a tier. I am not Strava-ing my way into a freemium grind. The trial is real; the purchase is real.
It’s not a stunt. I’m not running this as a one-week marketing experiment. Pay-what-you-can is the app’s pricing model, full stop. If it doesn’t work, I’ll learn from that and write about it openly. If it does work, it stays.
It’s not infinitely scalable. This 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 not arguing this should replace subscriptions everywhere — only that there’s room for it in places where it fits.

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; the price is $39.99 lifetime or $17.99/year. That app is not going anywhere. 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. This is the app for lifters who care how their tools feel, not just what they do.
A pricing experiment. GymLogger X is the conventional answer (lifetime + 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 between them, the heuristic is simple: want to log from Apple Watch → GymLogger X. Live on iPhone and want polish → LiftLog. Want to support an indie studio’s pricing experiment → LiftLog at the Patron tier. None of these are wrong answers.

What I’ll be watching

I’m going into this honestly uncertain about the outcome. 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, that tells me the anchoring isn’t doing its job 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–15%. Removing the card requirement reduces friction, but it also removes the auto-renew lock-in that drives 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 meaningful Patron volume comes 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 most about. If users find the tier ladder respectful and unusual, the model is working as intended. If it feels gimmicky or guilt-trippy, it’s not — 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. Honest numbers, including the bad ones if they’re bad.

Try it free

If you train, download LiftLog. Seven days, no card, full access. 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 your thing, GymLogger X is right there at $39.99 lifetime. Same studio, same privacy principles, different shape.

Either way, your training history stays on your device, no third-party tracking, no advertising SDKs, no required account. The app is small. The studio is one person. The principles aren’t going anywhere.

That’s the whole thing.

LiftLog is available on the App Store. Free for seven days, no card required. After the trial: $9.99, $19.99, $29.99, or $39.99 — one-time, you choose.

A calm 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 doing the quiet financial reconciliation that the season demands.

This one’s about AppMeta Pulse, the iPhone app this studio ships for that exact moment. It is the smallest, simplest tool in the catalogue. I am, surprisingly often, asked why it exists.

The setup problem

Two months ago I wrote about AppMeta — the native Mac client for App Store Connect’s write surface, the part where you edit metadata and respond to reviews and submit versions. AppMeta Pulse is the monitoring counterpart. It looks at App Store revenue and not much else.

The reason there are two apps, and not one, is a structural permissions problem most indies hit eventually.

App Store Connect has a single, monolithic role model. Either someone has access to your developer account, or they don’t. Sub-roles exist (Admin, Developer, Marketing, etc.) but the specifics are coarse — Marketing can edit metadata; Finance can read sales reports; nobody can have just “read-only revenue access without seeing build artefacts or being able to respond to reviews.”

This means: if you want your accountant to see your revenue numbers, you have to give them an account on App Store Connect, configure their role, accept that they can see things you’d rather they didn’t, and trust them to log in to a developer-account web tool every time they want to check.

In practice, what most indies do is ship a screenshot of their numbers via Slack or iMessage. This is fine for one-off requests. It’s terrible for any kind of regular reporting cadence.

AppMeta Pulse was first pitched as the answer. It turned out narrower: a fast, calm check for the account owner (see the correction below).

What does glanceable revenue look like?

The bet behind AppMeta Pulse is that the most-asked-for thing — “how is the app selling this week?” — should be its own glanceable tool, separate from the editorial surface 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 surfaces:

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.

It does not surface anything you can edit, apart from replies to customer reviews, which arrived at the end of April 2026. There is no metadata editing, no build management, no submission. It cannot do those things, and that’s the whole point.

Why “glanceable” matters

The form factor is iPhone, and the design is glanceable on purpose.

AppMeta does the desk work — the multi-locale metadata editing, the keyword analysis, the review replies — and lives on the Mac. AppMeta Pulse does the check-in — the morning coffee, the weekly meeting with a co-founder, the quarterly review with the accountant — and lives on the phone.

The use case I designed for is: indie developer in a coffee shop, picks up phone, taps Pulse, sees the last seven days’ proceeds against the seven before, decides whether to pay attention or get on with the day. This should take three seconds. It does.

The widget is, predictably, the surface 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 that matter at a glance.

A use case this post originally claimed for AppMeta Pulse is sharing read-only access without granting write access.

A co-founder, a designer working on a profit-share, an accountant doing quarterly bookkeeping — these people need to see numbers. They don’t need to be able to change your app’s pricing.

Pulse doesn’t do this. It has no shared access tokens and no way to give another person access to your account’s data; you can export a CSV of a period’s sales and send it yourself. The clean way to give someone ongoing read access remains 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 pricing is intentionally low. The argument: this is not a tool a studio uses for hours a day; it’s a tool you check briefly and rely on. Pricing it like a productivity-software flagship would mismatch its actual position in the indie’s stack. A one-time lifetime price puts it firmly in the “buy it and forget about it” tier, which is the right tier for what it does.

What this is not

AppMeta Pulse is not a financial-planning tool. It does not project revenue, model scenarios, or replace your accountant. It does not do tax-related calculations, and it doesn’t read Payments and Financial Reports; for when Apple’s money actually arrives, see when Apple pays developers.

It is also not 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).

What Pulse does is one thing: surface your App Store revenue in a glanceable way, on your phone. That’s the whole pitch.

A small note on the catalogue

This is, by my count, the third post this quarter about a tool aimed at indie iOS developers. It’s also the last for a while — I want to come back to the consumer apps that occupy most of the catalogue, and the next few weekends will probably do that.

But for the indies who read this far, AppMeta Pulse might be the small, useful, pay-once tool you didn’t know you wanted. If you keep opening App Store Connect just to see how yesterday went, this is the better answer.

Spring is the season of clean books. Use it.

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, you watched the days tick down, and that was the whole deal. Over a year, it grew: widgets, themes, calendar sync, photo backgrounds. But the name — TheWait — kept holding it back.

In April 2026, I fully rebuilt and rebranded the app as Soon.. New name, new icon, new home. Here’s why.

Why rename TheWait to Soon.?

TheWait tells you what the app is about in a literal sense. You’re waiting. The app counts down.

But that framing gets the emotional point exactly wrong.

Countdown apps aren’t really about waiting. They’re about anticipating. There’s a difference. Waiting is passive — it’s a word associated with delay, patience, endurance. Anticipating is active — it’s a feeling you cultivate, a joy you borrow from the future. When you’re counting down to a trip, a wedding, a birth, or a milestone, you’re not stuck in the wait. You’re already partly there.

Soon. captures that better. The period at the end is deliberate — it’s a full sentence, a quiet statement. The thing you’re looking forward to isn’t far. It’s Soon.

What changed under the hood

This wasn’t a simple name swap. The entire app was rebuilt from scratch. New additions include:

Plan Mode. Every countdown now ships with a smart timeline and checklist tailored to the event type. Trips get packing lists and transport reminders. Weddings get their own rhythm. You don’t have to build your own checklist — the app knows what a birthday, wedding, or graduation typically needs, and it assembles the prep automatically.
StandBy widgets. Every iOS widget size and style — Home Screen, Lock Screen, StandBy, ring, minimal, timeline. Your most anticipated moment can now be visible 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. When a countdown ends, it doesn’t disappear. It becomes a memory, and Soon. quietly brings it back on every anniversary. The moment never fades — it just cycles.
iOS Calendar sync. Any iOS Calendar event can become a countdown with a single tap. The dates you already track become the moments you can feel.
39 languages. Full localization including Japanese, Chinese, Arabic, Hebrew, Korean, and every major European language.

What stayed the same

The philosophy didn’t change. Soon. is still:

Private by default. No ads, no tracking, no 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. No auto-charging without consent.
Built by one person. Same developer, same catalogue, same principles. Soon. is part of the broader Lagerland Apps family of privacy-first tools.

What existing TheWait users need to know

If you used TheWait, everything carries over. Your events, your themes, your data — it all migrates automatically. You’ll see the new name, the new icon, the new Plan Mode, and you’ll have access to every new feature without paying for a second app. The upgrade is free.

Why indie studios should rename when it matters

I’ll be honest: renaming an app is terrifying. App Store rankings reset. Existing users get confused. Some coverage dies on the old name. For a year I resisted doing it.

But a wrong name is a daily tax. Every person who sees your app sees the wrong framing. Every conversation starts with explaining. Every review mentions the oddness. Eventually, you realise the cost of keeping it outweighs the cost of changing it — and the cost of changing it is mostly just courage.

For apps in this category — countdown, anticipation, 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 quietly wrong, this is 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. Here they are, from fully random to hand-picked, followed by how to combine them.

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, and each of its sections runs on rules worth knowing.

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.

A routine that uses all of it

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.

What the app does not try to replace is the website. If what you want is specifically a random featured article, the RandomInCategory address above is the most direct route there is.

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.

A worked example. 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

Pick the most recent moment in the last week when you needed to convert a media file. A HEIC photo to JPG, a video compressed for Slack, a PDF merged with another PDF, a screen recording’s audio extracted to MP3.

If you’re like most users, you used a free online converter. You uploaded the file to cloudconverter.com or ilovepdf.com or tinypng.com or one of a hundred near-identical sites. You waited. You downloaded the result. You moved 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. The convenience is real, but the privacy posture is structurally wrong, and MediaKit is the studio’s argument that the entire category of conversion tools belongs on your Mac instead.

What does “convert online” actually do to your file?

When you use a free online converter, here is what the file does, in sequence:

Leaves your machine, encrypted in transit.
Lands on the operator’s storage, sometimes encrypted at rest, sometimes not.
Is processed by their conversion pipeline. The processing typically takes seconds.
Is held in storage, often for hours, sometimes for days, depending on the operator’s retention policy.
Is downloaded back to you.
May or may not be deleted from the operator’s storage according to their stated policy, which you have no way to verify.

The first and last steps are the ones the user notices. The middle ones are the ones with privacy implications. 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.

I’m not suggesting any particular online converter is malicious. Most are run by small teams and most try to delete files promptly. I am suggesting that the architecture — files leaving your machine for processing tasks that don’t require it to leave — is wrong by default, and the user should not have to trust the operator to be the right kind of careful.

Apple Silicon changed the math

The honest historical reason cloud converters dominated is that local conversion was 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 just faster, even with the upload time.

Apple Silicon erased that gap. Modern Macs have hardware video encoders that compress at multiples of real-time speed. ProRes acceleration, HEIC encoding, AV1 decoding, all of it on-die. The local performance is now competitive with — and sometimes faster than — the cloud round-trip.

For images and PDFs, local processing was always faster. The cloud era for those was driven by deployment convenience, not performance. A web tool runs in any browser; a desktop tool needs to be installed. That’s a real friction. But it’s a friction worth paying for the privacy it preserves.

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 crucially, RAR v5 extraction natively on Apple Silicon, which has been a long-standing pain point for users who get RAR archives in 2026 (more often than you’d think — academic and design workflows still use it heavily).

Every tool runs entirely on the Mac. No file leaves the device. No upload, no cloud round-trip, 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.

The tools all support Shortcuts integration, which means they can be composed into automated workflows. “Compress all videos in this Downloads folder, output to ~/Compressed, delete originals over 100MB.” That’s a Shortcut, runs on a schedule, never touches the internet.

The freemium decision

MediaKit’s pricing was the most-debated decision internally before launch.

The shape it shipped with: five tools free forever (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. Pro also includes a free 3-day trial of all tools, so users can evaluate before deciding.

The argument for the freemium structure was that the user should have a non-trivial path to actually using the app for free, not a teaser. Five tools is enough that a casual user could go years without paying, and that’s fine — the app’s job is to be useful first.

The argument for putting the long tail behind Pro is that the long tail is what makes MediaKit valuable to the power user, and the power user is who funds the development of the long tail. The two-tier structure aligns the studio’s incentives with the user’s: power users pay because they get disproportionate value; casual users pay nothing because they get the basic value for free.

The plain version

If you’re reading this and you have a habit of using online converters, MediaKit is the studio’s argument that the habit is unnecessary. The Mac in front of you can do the same processing locally, faster than you’d expect, without your files leaving the device.

The free tier covers the common cases. The Pro unlock covers everything else, including the obscure cases (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 calmer way to do it.

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 information, not a verdict. 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 the indie iOS marketing stack. They are the first thing a prospective user sees in a search result. They convert better than any description, any keyword, any rating. And most indie developers, in my own anecdotal sampling, treat them as the worst chore of every release.

I treated them that way for five years. Mockly is the studio’s argument that there is a better way, and the rest of this post is what I learned shipping it.

What is the fastlane status quo for App Store screenshots?

The dominant solution for screenshot generation in the iOS indie world is fastlane snapshot — a Ruby tool that drives the iOS simulator, takes screenshots in every required device size, and writes them to disk. Combined with fastlane frameit (which adds device frames) and fastlane deliver (which uploads to App Store Connect), it constitutes a complete pipeline.

I am not going to dunk on fastlane. It is genuinely useful, the team behind it has done a public service for indie developers for nearly a decade, and the tool is open source. If you have a deeply customised CI pipeline already and your screenshots fit within the templates fastlane provides, it is a reasonable choice.

What it isn’t, structurally, is comfortable. 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.

The friction is everywhere in this list and it compounds. The Swift UI tests rot. The YAML grows. The simulator silently changes its rendering between Xcode versions. The editorial work happens in a separate tool — Pixelmator, Photoshop, or hand-coded SwiftUI — which means the editorial assets and the automated assets diverge over time. 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

The core bet behind Mockly is that most indie screenshot needs are a GUI problem, not an automation problem.

A GUI tool gives you direct manipulation of the asset. You drag the screenshot from the simulator into the app. You pick a device frame from a library. You add text overlay, you compose multi-device layouts, you preview the final result instantly. The locale switcher swaps the underlying screenshot but keeps the layout. The 3D frames are rendered live, not as PNG overlays — meaning a four-degree rotation looks correct, with proper perspective and lighting, in a way a flat composite cannot match.

The output is the same — PNG files at the App Store’s required dimensions — but the workflow is fundamentally different. Each screenshot becomes a small, owned asset that can be edited and re-exported as needed, instead of a regenerated artefact that is slightly different every time the simulator rolls.

For studios that ship a polished, editorially-considered set of screenshots — the ones with multiple devices in one image, with overlay copy, with motion blur on transition shots — this is the workflow that fits.

What Mockly specifically does

The feature set, briefly:

3D Metal-rendered device frames. Every iPhone and iPad model from the last six years, rendered at the screenshot composition time. Rotation, perspective, lighting, and reflections are real, not faked.
Localised composition. A single layout, with text, multiple devices, and overlays, can be exported across 20+ App Store regions in one click. The locale switcher swaps screenshots and translates copy.
Direct upload to App Store Connect. No 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.

It does not, deliberately, replace the automation pipeline. If your studio has a deep CI/CD investment and screenshots that need to regenerate from running tests on every release, fastlane stays in your stack. Mockly is for the editorial moment that lives upstream of the pipeline — the deciding what the screenshot says part — and for the studios for whom that’s the bulk of the work.

The pricing decision here is the most aligned with the AppMeta pricing decision from a few weeks back: a one-time purchase, lifetime access, no subscription required.

The specific addition for Mockly is 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. This was a deliberate choice — the alternative would have been per-seat pricing, which is the right call for SaaS but the wrong call for a tool that small studios use intermittently.

The studio loses some revenue to Family Sharing. The studio gains, I think, the right shape of relationship with the user. A small indie tool should treat its small indie users as a household, not a contract.

What this post does not argue

I’m not arguing every iOS developer should switch to Mockly. The largest, most automated indie pipelines are well-served by fastlane — and many of them have invested years in customisations that would be expensive to abandon.

What I’m arguing is that a meaningful fraction 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, and that almost no one builds GUI tools for indie iOS workflows because the audience is “just” tens of thousands of developers globally.

That audience is the audience this studio happens to be in. Mockly is for them. $12.99, lifetime, Family Sharing supported. 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 what part of the chore is actually necessary.

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 makes this — by quirk of biology rather than calendar — the worst week of the year to start a new training program. More on that in a moment.

I want to use this weekend’s post to explain something specific: why this studio shipped a strength-training logger at all, when the category is one of the most well-served on the App Store.

Why ship another strength logger into a crowded category?

GymLogger X competes against Strong (the long-running incumbent), Hevy (the rising design-led upstart), Fitbod (the AI-program one), Caliber (the coach-network one), and a long tail of niche loggers. All of them are good apps. The category is not under-served in the obvious sense.

When I started building GymLogger X in late 2025, friends in the indie community asked me, gently, why. The honest answer was: not because of features. It was because of one specific thing the incumbents got 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, sometimes log a set if you tap through three menus.

That is backwards for the actual gym experience. In the gym, your phone is in a bag or on a bench, somewhere not on your body. Your watch is on your body. The watch is the device that’s with you between sets. The watch is where logging should happen.

Building a logger around the wrist is technically harder than building a phone-first logger. The screen is small, the input vocabulary is constrained (Digital Crown, taps, voice), the latency budget for syncing back to the phone is tight, and Apple’s WatchKit constraints are real. The reason most apps don’t do it is that the engineering cost is significant and the user-base willing to use it is narrower 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 happens on the wrist. Rest timers happen on the wrist. Live heart rate is glanceable on the wrist. The phone is for analytics, program editing, and history review — the things that benefit from a bigger screen.

The user feedback has been clear: the people who want this really want it. The people who don’t want this don’t notice it’s there. Both outcomes are fine.

Plateau detection that doesn’t lecture

The other piece of the bet is the analytics layer.

Most strength loggers track sets and reps and stop there. The Pro tiers add some trend lines. None of them, in my experience, will quietly 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 does try 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 it when that number has stopped climbing while your training volume holds steady — 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.

What it does not do is automatically restructure your program for you, change your weights, or send you a coach’s nag. Those are real features in other apps. They are also things I think the user should choose to do, not the app’s place to impose. Plateau detection in GymLogger X is informational. The next move is yours, and 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 a freemium model that the studio has stuck to: core logging is free forever, 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 most often get asked about. The math on it is, candidly, not great for a studio chasing recurring revenue. A user who buys lifetime in year one and uses the app for seven years has paid the studio about a third of what an annual subscriber would have paid. The lifetime tier exists anyway because strength training is a long-term practice and a user’s training history should not be conditional on continuing a subscription.

About 30% of GymLogger X paid users choose the lifetime tier. They are vocal, they are loyal, and they are the user-base I’m most personally proud 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 will not realise that 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% on the day after, raises perceived exertion noticeably, and depresses recovery markers (HRV, resting heart rate) for several days. In the gym, this presents as: a lift that felt easy last Tuesday feels heavy this Tuesday, and the user blames their effort rather than 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 you’ve been progressing well, this is the week the curve will flatten. It is not your training. It is the time change. Take Tuesday’s session at last week’s weights instead of pushing for new ones. Resume normal progression next week. GymLogger X will not lecture you, but I will.

The plain take

GymLogger X exists because the category had a structural gap — logging designed for the wrist rather than the phone screen — and because nobody seemed to be building it. The lifetime price exists because strength training is a long game. The plateau detection exists because the data deserves an interpreter.

For the polished iPhone-first design tier of strength training, the studio also ships LiftLog, a sister app with a completely different pricing experiment. They serve different lifters. Both are honest about what they’re for.

Don’t lift heavy on Tuesday. Lift heavy next Tuesday.

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 is the feature that quietly carries everything else. This is the post about both.

What’s wrong with the slider-based chess opponent?

Most chess apps offer a slider. 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 isn’t a different opponent than Level 15. It’s the same opponent making mathematically random mistakes. After a dozen games you can feel the noise. The mistakes aren’t wrong — they’re uncorrelated with style. No real opponent plays that way.

The result is that improvement against the engine slider doesn’t transfer well to playing humans, because humans are not noisy engines. 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. The app needs opponents that feel like people.

The forty

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 are designed to imitate any specific real grandmaster — that line is one 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 not glamorous. It is 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.

What it produces is recognisability. After ten games against the aggressive Sicilian player, you start to anticipate her openings. You start to know where her blind spots are. You start to play against her, not against an abstract evaluation function. That recognisability is what makes the games feel like games, and it’s what makes improvement against Chessful’s opponents transfer to playing humans.

The post-game thing

The other feature that took disproportionate effort is the post-game analysis, and it is genuinely 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 identifies the move that lost the game. It identifies the threat the user missed. It explains, in one or two sentences, what was happening structurally. Sometimes it suggests the principle the user should remember — “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). The combination produces something that reads like a chess teacher rather than a chess engine.

This was disproportionately hard. It is also the thing users mention most.

What this is not

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 what they do — competitive play with the world’s best chess infrastructure.

What Chessful is for: the player who wants to improve quietly, against varied opponents, with explanations they can actually read, on a flight, in a kitchen, between meetings. No account required. No internet required. No ranking attached to your name that you’ll 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.

That isn’t a marketing claim. It’s just how the prompts ended up calibrated. If you find the explanations unusually patient, that’s why.

Chessful is on the App Store. Free to try, premium for 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 single most consequential web app in the indie iOS developer’s day. It’s how 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.

It is also, structurally, a web app from 2014 that has accreted features for a decade. It works. It is also, on a long-haul flight or in a tab adjacent to fifteen others, miserable.

AppMeta is the native Mac client I built to stop being miserable.

The problem ASC has, specifically

App Store Connect’s design constraints are not Apple’s fault, in fairness. They are managing 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 against that surface area is a hard problem, and the team that ships ASC ships a lot.

What ASC isn’t optimised for is the workflow of an indie developer with five-to-fifty apps shipping across twenty locales. Specifically:

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 rediscover the same keyword waste in every language because there’s no tool to surface it. (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.

Every one of these is a real friction. None of them are catastrophic individually. Together they are why I had a recurring “App Store Connect” calendar block on my Friday afternoons for two years before I shipped AppMeta.

What does a native App Store Connect client actually change?

The core of AppMeta is a Mac client that talks directly to the App Store Connect REST API and gives you a side-by-side view of your apps’ metadata. It signs in with an API key you create yourself in App Store Connect; the key setup guide walks through that. The four things it changes:

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 collapses into ten minutes.

Diff preview before push. AppMeta shows you exactly what will change against the current live metadata before the push happens. This is the feature I trust more than I trust myself, because it caught a typo in five different localisations on the day before I would have shipped them. Once that happens to you once, you do not ship without a diff preview again.

Cross-locale keyword analysis. AppMeta computes per-character keyword utilisation across every locale and surfaces wasted space, duplicates, and gaps. This used to be a spreadsheet I maintained by hand. It is now 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, a click away in the sidebar instead of behind ten slow page loads. Pick a review, type a response, send. The response goes through ASC’s regulated channels — Apple is the source of truth — but the workflow stays on the Mac.

There’s also version submission, screenshot management, pricing changes, and a few smaller things. The point isn’t the feature checklist. The point is that every minute of friction the web tool adds compounds over a year of shipping.

Why a lifetime price, not a subscription

This is the question I get most about AppMeta, and I want to be plain about it.

App Store Connect tooling is a developer tool. Developer tools have a long history of subscription-priced services — JetBrains, Sketch, Figma, Linear. The market would absolutely pay $19.99 a month for a good ASC client. I considered it.

The reason I shipped AppMeta as a one-time $29.99 purchase is that subscriptions create a specific bad incentive for a tool like this: every month, you have to ship enough perceived value to justify the recurring charge. That pressure pushes the roadmap toward more features, not toward the right features. AppMeta’s job is to be a fast, reliable native client. Adding features for the sake of a renewal cycle would compromise that.

A one-time purchase forces a different discipline: ship a tool that’s worth $29.99 once, and let the work earn the next purchase from a new user, not extract a renewal from an existing one. The tradeoff is slower revenue. The advantage is honest design.

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-side companion.

It is, specifically, the native client for the metadata-and-review portion of App Store Connect. The thing you spend an hour a day in during ship weeks. The thing that needed to stop being miserable.

The plain version

If you’re an indie iOS or macOS developer shipping in multiple locales and you’ve ever spent a Friday afternoon doing the locale-dropdown dance, 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 post 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. Someone is doing math on a napkin.

This is a small post about that exact moment, and the app I built for it.

Why is “split equally” unfair?

The default in most splitting tools is to divide the bill into equal shares. This works when the table ordered roughly the same things. It is unfair the moment the orders diverge.

Equal-splitting punishes the lighter eater. The salad-and-wine person at our hypothetical table pays $78, when their actual order was closer to $32. They will not say anything because the maths is awkward and the social cost of asking exceeds the $46 in question. They will quietly resent it, the next dinner will feel slightly different, and over a year of small inequalities the friendship loses a little bit of trust without anyone being able to point at the moment it happened.

The fix is item-level splitting. It takes thirty seconds with the right tool. Without one, it takes ten minutes and a calculator.

The Splitwise problem

The dominant solution to this problem in the early 2020s was Splitwise. It works, with one structural friction: every participant has to have an account. The four friends at the table are now 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 valuable. For a one-off Valentine’s dinner with friends, it’s a tax on the relationship that nobody asked for.

RightSplit is built around the opposite premise: the group should not need to download anything. Only the person doing the math has the app.

The flow

The version that lives in my head when I think about RightSplit’s 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. Bottle of wine? Tap two people, and the app splits it 50/50. Round of beers shared by three? Same. Steak? Tap the person who ordered it.
Tip is calculated and distributed proportionally — the arithmetic, worked all the way out.
The app produces four small messages — one per person — 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.
Done. The app remembers the split for future reference if the owner cares to look.

That’s the whole product. There’s no shared account, no notification storm, no IOU ledger that follows you around for nine months. The group never has to install RightSplit. The friction lives entirely with the person who’s already holding the phone.

What item-level splitting buys at scale

The interesting thing about this design is what happens when groups get bigger.

For two people, item-level vs. equal split rarely matters. The amounts are small.

For four people, item-level splitting recovers an average of $20-40 per dinner over equal-split, in the favour of whoever ordered modestly. That’s small, but it’s the kind of small that compounds across a year of group meals.

For ten people — bachelor parties, family dinners, work outings — item-level vs. equal-split can be a $80-150 swing per person. At that point, equal-splitting isn’t just unfair; it’s the thing that turns 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. $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 scenarios.

A note on small kindnesses

There’s a category of software that exists specifically to remove a tiny amount of friction from human relationships, and I’d argue this category is undervalued. The financial impact of any individual split is small. The relational impact of not having the awkward conversation about the bill is non-trivial. Friends remember small kindnesses; they remember small inequalities even more.

If you went out to dinner tonight and someone is staring at a receipt right now, consider this the offhand suggestion that there’s a calmer way to handle the math.

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 want to say it was clean and freeing, but the honest version is that 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.

The hard part wasn’t withdrawal. The hard part was that there was nothing else trained to fit the same hole. The five-minute window between meetings, the queue at the coffee shop, the two minutes waiting for the tea kettle. These had been algorithmic-feed time for a decade. Without the feed, they were just silence — which is fine, except the brain that’s been on dopamine for ten years doesn’t know what to do with silence yet.

WanderWiki is, more than anything else in this catalogue, the app I built 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. Specifically: didn’t try to be infinite.

The substrate was obvious. Wikipedia 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 make a calm reading habit out of Wikipedia, the problem wasn’t the substrate.

“For You” without surveillance

The unsolved problem in non-feed reading apps is that 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 that profile to weight the recommendations. This works, and it’s also exactly the thing I deleted off my phone.

The interesting question is whether you can have For-You-style relevance without behavioural tracking. The WanderWiki answer is: yes, if you ask the user what they like instead of inferring it. The app has a one-screen onboarding where 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. This is less personalised than a feed-based reader. It is also accountable to the user in a way the feed-based version cannot be — 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.

This works for the same reason it has always worked in newspapers: time-anchored content gives the brain a small handhold. Today, specifically. This day, in another year. The same calendar slot, occupied by a different version of the world. It’s a small thing, but it’s the feature I get the most direct user feedback on, and it’s why I kept it.

Offline as a first-class state

The other constraint I held to was that the app should be some use on a plane.

This is the part that needs the most honesty. 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’s job is the small reading list you build while wandering, which is still there on a 13-hour flight, the moment the value of a feed-replacement is highest.

What it gives up

A reading app that doesn’t have a feed and doesn’t track behaviour is not going to outcompete Twitter for attention, and it shouldn’t try. WanderWiki sessions are short. Two articles, sometimes three. The session ends when the user is satisfied, not when the app runs out of things to show. This is intentional and it is the metric I most want to be lower than the competitors’ metric.

Daily active users is a noisy number for an app like this anyway. The right number 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? That’s the bar.

Where this fits in a privacy-first catalogue

WanderWiki sits alongside a small handful of other apps in this catalogue that all share a posture: 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. 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 is the post explaining why.

What does “log in to your bank” actually do?

When a non-bank app asks you to log in to your bank, what’s happening 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 credentials or — in newer arrangements — holds an OAuth token issued by your bank. Either way, the third party 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 isn’t shady. It’s the standard architecture of fintech, it’s regulated, and most of the time it works. But it has three properties worth being honest 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. Even 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! It is genuinely useful! It is also doing two specific things, and one of them is unrelated to the user’s stated goal.

The first thing it does is identify recurring charges. Useful.

The second thing it does is build a picture of every other thing you spend money on, which is not what you signed up for and is the actual asset the company is building. The bill-tracking is a pretext for the data pipeline. Some of these companies are open about it (the ones whose business model is “find subscriptions you forgot about and offer to cancel them” — that’s the value exchange). Some are quieter.

Either way, the user is paying with read access to their entire financial life for a feature that, in the end, is a list of things they could have written down themselves in twenty minutes.

The manual-first answer

AllPaid is built around the opposite 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. Widgets and Siri integration mean the daily friction is essentially zero — “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. There is no login, no email collection, no profile.
It does not see anything you do not type into it.

This is, on paper, less convenient than a Plaid-connected app. In practice, the convenience gap is smaller than people expect. The first-time entry takes about fifteen minutes if you have a long list. After that, the friction is a notification you tap to mark a bill paid — same friction, lower cost.

What this trades away

I want to be precise about the tradeoff, because hand-waving it is dishonest.

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.” This is a real value proposition, and AllPaid does not solve it.

If finding forgotten charges is the user’s primary need, a bank-linked tool is the better fit, and I’d recommend one honestly. The user just needs to walk in with their eyes open about what they are giving up.

For everyone else — the user who knows roughly what they pay for, wants to be reminded to actually pay, wants to share rent with a roommate, wants a calendar view of the next thirty days, and does not want a third party reading their checking account in perpetuity — manual-first works.

A note on tax season

This post is going up on the 31st of January, and I am aware the timing is not accidental. 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.

The point of AllPaid is to be the calmer answer in that window. No bank login. No surveillance. No anxiety-driven onboarding. Just the boring, useful, local thing that helps you not miss a bill and not pay a late fee. Free, with Pro at $1.99 a month, $12.99 a year, or $24.99 lifetime — no subscription required.

If this is the year you stop handing over read-access to your bank in exchange for features you could write yourself, this is the studio that thinks 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. The app’s model of a human was that humans sleep at night. Her model of a human was that nurses sleep when the rotation lets them.

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 implicit model is a five-day workweek with weekends free, plus the assumption that “night” means a single uninterrupted block of darkness.

Now imagine a typical nurse’s twelve-hour rotation: three days on, three days off, two-week cycle, with the days flipping to nights halfway through. Her sleep windows might be 10pm-6am one week, 9am-3pm the next, with a chaotic transition night in between. The sleep app’s model breaks. The recovery scores are nonsensical. The 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, 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 don’t serve any of them well.

What “shift-aware” actually means

The first thing AfterShift does that generic apps don’t is take a different view of what counts as a sleep session. It 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. 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, which is 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, given the rotation pattern you’re on, given how fragmented your recent sleep has been, how recovered are you for the next block?

It’s calibrated against shift-work fatigue research, not against the average iPhone user’s resting heart rate. A 7-hour daytime sleep before a night shift can produce a higher Shift Recovery Score than an 8-hour night sleep before a day shift, because the former is set up to support the upcoming work block and the latter is misaligned. Generic sleep apps reverse that — daytime sleep gets penalised, night sleep rewarded — which is exactly backwards for this user.

Caffeine timing is a feature, not a footnote

The other surprise in building AfterShift was how much research exists on caffeine timing for shift workers, and how little of it makes it into consumer apps.

The simplified version: caffeine has a half-life of about five hours. Drinking it three hours before bed leaves enough in your system to disrupt sleep onset and architecture. Drinking it at the start of a night shift will keep you alert at the worst possible time — when you finally try to sleep at 9am. The right strategy depends on which way your shift is rotating, and most shift workers reverse-engineer it through years of trial and error.

AfterShift bakes the strategy in. Tell the app your upcoming shift block, and it will tell you the latest sensible caffeine cutoff to protect your post-shift sleep. It’s not glamorous. It is, by user feedback, the single 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

The other thing I underestimated when I started was how much administrative load shift workers carry around their own sleep. Knowing when you slept, knowing when your next shift starts, calculating recovery in your head, deciding whether you need a nap — all of this lives as background processing in their day, on top of the actual job.

AfterShift takes that load. Calendar shift import handles the schedule input (most large employers publish rotations to a calendar feed nurses can subscribe to). The sleep windows are planned from the shift times, and actual sleep is read from Apple Health. The caffeine timing updates automatically when shifts change. The user doesn’t have to keep doing math.

When the math goes away, the cognitive load goes down. When the cognitive load goes down, the actual sleep gets better. This is the second-order effect I didn’t predict.

Who it isn’t for

AfterShift isn’t a generalist sleep tracker. If you have a stable 9-to-5 schedule, Observa is the studio’s better fit — it does interpretation across all your Apple Health data, with sleep as one of the categories. AfterShift narrows the lens specifically to people whose schedule is the problem.

It is also not a clinical tool. Sleep disorders, narcolepsy, sleep apnoea — these need a sleep clinic, not an app. AfterShift’s Shift Recovery Score is informational; it is not a diagnosis. I’d rather lose users to a real doctor than oversell what consumer software can do.

The point

There’s a category of human work that powers most of modern infrastructure — healthcare, transport, public safety, manufacturing — and the consumer software industry has mostly designed around them. Building AfterShift was an experiment in designing for them, with the explicit assumption that their schedule isn’t a deviation from normal but the actual normal of millions of people.

If you work nights, rotations, or anything that breaks the 9-to-5 mould, the app is on the App Store. And if you know a nurse, pilot, or paramedic who’s been quietly suffering 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 don’t mean that in a glib way. I mean: I could open the Health app, watch a number go up and down, see a chart that resembled a small mountain range, and not be able to answer the only question that mattered — should I do anything differently this week?

That gap is what Observa was built to close.

What is Apple Health good at?

Before anything else: Apple Health is excellent at the thing it’s built for. It collects, normalises, and persists health metrics with privacy guarantees no consumer system has ever offered. The charts are well-designed. The unit handling is meticulous. The data layer is honestly the best in the industry.

What Apple Health isn’t trying to do — and shouldn’t, in my view — is editorialise. It will not tell you that your HRV dropped because of last week’s two short nights. It will not connect your morning resting heart rate to the wine you drank on Saturday. It will not say, “your training load is twenty percent above your eight-week average and your recovery scores are dropping; consider a deload week.” Apple’s deliberate restraint here is correct. Health data is sensitive, and over-interpretation is a real danger.

But for the user, that restraint leaves a gap. You have data. You don’t have meaning.

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 failure mode I’m describing. The brain is bad at pattern-matching across noisy time-series data. We see trends that aren’t there and miss trends that are. We anchor on the last measurement. We feel anxious about a single low reading and reassured by a single high one, neither of which means anything statistically.

This isn’t a willpower problem. It’s a display problem. A chart with seven hundred datapoints and no overlay is not a tool — it’s a Rorschach test.

What Observa does

Observa sits on top of Apple Health and answers a small set of questions explicitly:

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 day-of-week (don’t underestimate Sunday-night anxiety as a predictor).
What does your HRV trend actually look like, normalised against your own baseline? Not the population’s. Yours. A 38 ms HRV reading is meaningless without knowing whether your personal baseline is 32 or 56.
Which days in the last 90 had the largest deviation from baseline, and what else changed on those days? This is where the interesting stories live. The ones where you say “oh, of course, that was the week I flew through three time zones.”
Is your training load consistent with your recovery, or is it diverging? If both lines diverge, you are accumulating fatigue, regardless of how the individual workouts felt.

These aren’t medical diagnostics. They’re explicitly not. Observa cannot tell you whether you have a clinical sleep disorder, a cardiac issue, or an autoimmune condition. It will not pretend to. What it can do is take a year of your own data and turn it into three or four sentences a thoughtful coach might tell you if they had time to read it carefully — which most coaches don’t.

Why this had to be on-device

The other constraint that shaped Observa is the obvious one: health data should never leave your device.

This sounds like a statement of values, and it is, but it’s also a technical decision with real product consequences. A cloud-based version of Observa would have access to better correlation models, larger datasets, and more compute. It would also be a target for breaches, a regulatory minefield in multiple jurisdictions, and — most importantly — a thing the user could not verify.

Observa’s correlation analysis runs on the device using local models small enough to fit in the app bundle. The tradeoff is that the analyses are simpler than what a cloud service could do. The advantage is that no one but you ever sees a single data point. There’s no cloud account to compromise. There’s no employee with database access. There’s no “we accidentally trained a model on your sleep data” press release in the future.

I think that’s the right tradeoff for health data. I’m aware not everyone agrees, and there are use cases — clinical research, longitudinal population studies — where on-device cannot compete. Observa is not that product. It’s the interpretation layer for one person’s own life, owned by them.

What this means in practice

If you’ve been opening the Health app, scrolling, and feeling vaguely unproductive about it, Observa is built for that exact moment. It reads what’s already in your Health database (with your permission, scoped to the categories you allow) and produces a calm weekly read instead of a panel of charts.

It won’t tell you what to eat. It won’t tell you when to sleep. It will, occasionally, 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 let you decide what to do with that.

That’s the whole product. Apple’s data layer plus a thin layer of honest interpretation. No tracking, no upload, no account, no medical advice — just the modest, useful thing that’s missing.

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, the structural one — and it’s a particular 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. It feels like a reward.

But the same counter has a second behaviour, and the second behaviour is the one that drives the engagement loop: it resets to zero on a miss. Not to N − 1. To zero.

That asymmetry is what makes a streak work as a growth lever. It’s also what makes it a debt instrument disguised as a reward.

When the app shows you a 143-day streak, it isn’t telling you “you’ve earned this.” It’s saying “if you don’t open me tomorrow, you owe me 143 days.” The number on screen is denominated in future panic, not past achievement. Each additional day inflates the debt. The longer the streak, the more painful the reset, the more hostage-y the relationship.

Apps know this. They build it deliberately. There’s a reason every meditation app, language app, and habit tracker shipped a streak counter the moment Snapchat showed it worked. It’s not that the designers think users want it. It’s that users don’t want it, and the not-wanting is precisely what produces the open.

The ratchet effect

There’s another quiet thing streaks do, and it 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. They mark a task complete that they didn’t actually do. They walk in circles in the kitchen to hit the daily steps. They train through an injury they should be resting.

The metric the app shows them as proof of progress causes them to do less of the actual progress. This is Goodhart’s Law in two-tap form. The streak ceases to measure consistency and starts measuring “willingness to lie to the app to avoid the pain of resetting.”

If your tool’s headline number actively rewards your users for behaviour they will be ashamed of in a quiet moment, you are not building a tool. You are building a dependency.

The Taskful Day alternative

When I designed Taskful Day, the question wasn’t “should we have a streak?” It was “what does the app show in the place where the streak would normally go?”

The answer was: nothing.

The home screen shows today’s plan and today only. Yesterday’s incomplete tasks aren’t red-marked or scolded. They’re offered as follow-ups — a small affordance that says, in effect, “this is something you said you wanted to do; tap to bring it to today, or dismiss it.” The user retains agency. The app doesn’t editorialise about whether yesterday was a “good day” or a “bad day.”

There’s a reflection view if you want to use it, and a focus-session timer if you want to use it, and neither of them turns into a punishment system. The app doesn’t know whether you had a productive day, and it shouldn’t pretend to.

What this gives up is a strong “open the app every single day or else” loop. Daily-active-user numbers are lower than they would be with a streak. I know this 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, instead, is what 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 is no flame. No “you broke your streak.” No catch-up modal. The plan is just there, and it’s today’s plan, and they can use it or not.

Most users in that situation report something specific in feedback: relief. They expected to be punished — every other planner has trained them to expect it — and the absence of punishment makes them open the app the next day. It turns out not being a guilt machine is itself a retention strategy, just a slower one.

I don’t think Taskful Day will ever have the daily-active-user numbers of a streak-driven planner. That’s fine. The users it does keep are using it the way it’s meant to be used: as a tool that meets them where they are, not a counter they’re chained to.

The position, plainly

Streak counters work — for the app. They’re brittle, they’re punishing, they corrupt the metric they pretend to measure, and they teach users to lie to their tools. There is a small craft cost to refusing them and a real product cost to refusing them. 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, the answer is none of them — by design.

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 is the gentle, well-designed, beautifully-typeset push notification that you missed your goal — by just a little, isn’t that a shame, but you can still recover if you log in right now. Then a streak counter that resets if you don’t open the app for two days. Then a leaderboard against three friends you haven’t seen since college. Then a coach character with a frowning face. Then a colour change from green to amber to red as the days slip.

I’m not making fun of these apps. They are designed by talented people, the typography is excellent, the animations are crisp, and they convert. They are doing exactly what their growth dashboards reward them for doing.

What they are not doing is helping you train.

The mechanism

If you’ve ever felt like a fitness app turned on you in week two, here is what was happening on the engineering side:

You signed up because you wanted to do a thing more consistently.
The app instrumented “consistency” as 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.
But streaks are mathematically brittle. Miss one day, the counter resets. The app’s growth team knows this — it’s why streaks work. The fragility is the engagement loop.
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 get the bad-feeling spiral and quietly stop opening the app for the rest of the year.

Neither outcome is “you trained.” One is theatre. 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 respects you in week three:

No streak counter on the home screen. Or, if there is one, it doesn’t reset to zero — it accumulates total days trained, lifetime, irreversibly. The progress is yours; you don’t lose it for missing Tuesday.
A “follow-up” mechanic instead of a “miss” mechanic. Tasks or workouts that didn’t happen yesterday are not punished or red-marked — they’re offered to you, gently, today. Roll forward, don’t reset.
Goals that don’t compare you to other people you didn’t choose to compare to. No leaderboards by default. No friends whose routines you don’t actually want 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” is supportive. Same data, different relationship.
A way to leave for a week without losing your data. Vacations exist. Injuries exist. Lives happen. The app should still be there at the same level you left it.

What this studio ships

Taskful Day is a daily planner with no streak counter, no flame, no red X. Unfinished tasks roll forward to tomorrow. There is a focus-session timer if you want one and a reflective view if you want one, 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.

I am not arguing every fitness app should be flat and joyless. There is real craft in pacing, in motivation, in the small celebration when you hit a personal record. I am arguing that the baseline shouldn’t be a guilt machine. The celebration should be earned by the user’s actual achievement, not extracted by punishing the user’s actual life.

A small ask for the third of January

If you set yourself a fitness target for 2026, the most useful thing I can offer is this: pick the app that respects you in week three, not the one that converts hardest in week one. The two are usually different apps, and the second category will hurt you in February.

That’s the whole post. Go for a walk. Lift something. 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. The pleasant tradition of writing public roadmaps has already begun on every developer corner of the internet, and I’m sure most of them are sincere.

I’d like to do the opposite. Here is 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. No analytics. No advertising networks. No “anonymized” telemetry that quietly fingerprints. That isn’t going to change in 2026, and it isn’t going to change because someone offers an attractive revenue share, either. The first time I add an ads SDK is the first time the studio’s whole positioning collapses.

Not chasing a ten-app year

The catalogue today is fourteen apps. I don’t need a fifteenth, sixteenth, twentieth. The studio is one person, and the surface area is already at the limit of what one person can support thoughtfully. If I ship a new app this year, it will be because the idea is good enough to displace something else — not because the calendar said it was time.

Not turning anything into a daily-engagement product

Several of the apps would be more “successful” by App Store metrics if I added streaks, daily notifications, badges, or social comparison. Taskful Day would convert harder if I shipped a streak counter. AfterShift would have a higher retention curve with a daily nag. I am 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

This is the one I expect the most disagreement on. I use language models in my own workflow. I think they’re useful. I will absolutely add genuine AI capability to apps where it earns a place — Observa’s plain-language interpretation of HRV is one example, Chessful’s mistake explanation is another. But “tap here to summarize your day with AI” buttons that don’t change anything are 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. I don’t need one. The studio is small, the apps are profitable, and adding investors to a one-person operation would mean adding ambitions that don’t fit. The honest version of “we’re not raising right now” is “we don’t want to.”

Not going dark

The other thing I’m not doing is disappearing. This journal is new, and I plan to write more honestly through 2026 than I have in any previous year — including when things go wrong, which they will. There will be shipping notes, rebrand stories, post-mortems on pricing experiments, and quiet essays about why a particular feature exists. None of it on a content-marketing schedule. All of it because there’s something worth saying.

What does this mean for the apps in 2026?

For the apps you might already use, the practical answer to “what’s coming in 2026” is more of the same: better refinements, fewer additions, the same privacy posture, the same one-time-or-honest-freemium pricing. For new apps that ship this year, the bar will be high and the count will be low. Good.

If that’s the kind of studio you want to use 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 — and I mean that — but it isn’t this one.

Welcome to 2026.

Update, 25 October 2026: two of these didn’t hold. The catalogue grew this year rather than 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 14 iOS and macOS apps. Until now, the website has been app-page-first — you land on an app, you learn about it, you install it. That’s still the goal. But some stories are too broad for a single app page.

This journal is for those stories.

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 are more than a App Store “What’s New” line. Design decisions, why a feature exists, why another one was cut. Not marketing — the actual reasoning.
Principles. Occasional essays on privacy-first design, honest monetization, and what it looks like to build apps without advertising incentives. When I have something worth saying rather than a point to prove.

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. Nothing social, no comments, no 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.

That’s the whole thing. 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

Buying once should mean owning it

The purchase App Review couldn’t find

Ratings and sharing

How to solve a balance puzzle, and how Tare proves all 80 of its levels

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