The quickest way in

Tap this link on your iPhone or iPad and you are in. There is no waiting on me and no invitation to look for.

Join the beta on TestFlight

1. Install TestFlight from the App Store.It is free and made by Apple. Do this first.
2. Tap the link above on the same device.It opens a page about Brickworks with an Accept button.
3. Tap Accept, then Install.Brickworks lands on your home screen and opens like any other app.
4. Later versions arrive on their own.TestFlight tells you when there is a new one and you tap Update.

Please still fill in the form. Joining by link tells me nothing about who you are, not even your name, so without the form I cannot tell your feedback apart from anybody else's.

iPhone and iPad

Apple runs its testing through an app called TestFlight. You install TestFlight once, and every test version of Brickworks arrives inside it.

• An iPhone or iPad running iOS 17 or later. Anything from the last several years is fine.
• Your Apple Account email address. It used to be called an Apple ID. Open Settings and tap your name at the very top; the address underneath it is the one I need.
• TestFlight. Apple's own free app. You do not need it before you sign up, only once the invitation arrives.

The other way, an emailed invitation

1. You fill in the form.Choose Apple, and give the email attached to your Apple Account.
2. I add you as a tester.Usually the same day. This is the only part that waits on me.
3. Apple emails you.The email comes from TestFlight, not from me, so look for Apple's name rather than mine. Check your spam folder before you assume it did not arrive.
4. Install TestFlight from the App Store.Free, made by Apple, and the email tells you to do this first. Do that part before tapping anything else.
5. Open the email again on your phone and tap the invitation.It opens straight into TestFlight. If that does not work, open TestFlight yourself and type in the redeem code printed in the email.
6. Brickworks appears inside TestFlight. Tap Install.It lands on your home screen and opens like any other app.
7. Later versions arrive on their own.When I put out a new build, TestFlight tells you and you tap Update. You never have to sign up again.

Two things that catch people out

• It has to be the Apple Account address. Not a work address you also use, not an old one. If the invitation is sent to an address your device is not signed in with, it will not open.
• Test builds stop working after 90 days. That is Apple's rule, not a fault. A new one replaces it long before then and TestFlight prompts you.

How to send me feedback

• From inside TestFlight. Take a screenshot while the game is open and it offers to send it to me with a note attached. This is the easiest way and it tells me which build you were on.
• By email. developer@miljarpro.com

Android phones and tablets

Android testing runs through the Play Store you already have. There is nothing extra to install, but the invitation works differently from Apple's, and it is worth knowing how before you start.

• An Android phone or tablet. Any make.
• The Google Account you use on the Play Store on that device. Open the Play Store and tap your picture in the top corner to see which one it is signed in with.
• Nothing to install. Brickworks arrives through the Play Store like any other app.

What happens, start to finish

1. You fill in the form.Choose Android, and give the Google Account email your Play Store is signed in with.
2. I add you to the tester list.Usually the same day.
3. I email you a private Play Store link.This one comes from me, from developer@miljarpro.com, not from Google. That is the main difference from the Apple side, so do not sit waiting for a message from the Play Store.
4. Open that link on your Android device.It has to be the device signed in with the account you gave me, or the page will tell you the app is not available.
5. Accept the invitation on the page that opens.One tap. It is confirming you want to be a tester.
6. The link takes you to Brickworks on the Play Store. Tap Install.From here it behaves exactly like a normal app.
7. Later versions arrive on their own.Updates come through the Play Store the same as everything else on your phone.

Three things that look broken and are not

• The app may be called something odd. During testing the Play Store can show it as com.miljar.brickworks (unreviewed) instead of Brickworks. That is Google's placeholder and it goes away by itself.
• "Item not found" right after a new version. Google takes anywhere from a few minutes to a couple of hours to make a new build visible. Wait and open the link again.
• The wrong account. If your phone has more than one Google Account on it, the Play Store must be on the one you gave me. Everything else looks like the app simply does not exist.

How to send me feedback

Shake the phone. Any time, on any screen, in the middle of anything. That is the whole thing, and it is by far the most useful way to tell me something.

1. Shake it.A panel slides up. It has already taken a picture of whatever was on the screen the moment you shook it, so you do not have to describe what you were looking at.
2. Draw on the picture, if it helps.Circle the thing that looked wrong. It saves us both a paragraph.
3. Choose Bug, Idea or Praise, and say what happened.Putting your name in the box helps me match it up with you.
4. Send.It comes straight to me with the picture attached. If you have no signal it saves itself on the phone and sends when you are back online, though the picture does not survive that.

The same panel is in the menu under Send feedback, if shaking your phone in public feels ridiculous.

• Or email me, any time. developer@miljarpro.com Better for anything long, or anything you would rather not type on a phone.

It is drawn, not painted

Most games ship pictures. A tile is a picture file, a background is a picture file, and the app loads them.

Brickworks does not work that way. The tiles, the boards and the backgrounds are drawn by the app while you watch, out of a short list of colour values. Nothing is loaded from a picture.

That is why forty-five themes fit. A version that shipped pictures would need forty-five sets of them, in light and dark, at three screen resolutions. This needs forty-five short lists of colours.

The music is the exception. There are fifty-nine recordings in the app, most of them written for one particular theme.

Two apps that have to agree

Brickworks is two apps, not one app wrapped twice. The iPhone and iPad version is written in Swift. The Android version is written in Kotlin. They share no code at all, and they are built alongside each other rather than one following the other.

They are allowed to look different, and they should. Each phone has its own conventions for how a menu opens, how a button feels and what a back gesture does, and an app that ignores them feels wrong in a way people notice without being able to name.

What they are not allowed to disagree about is the maths. Scoring, combos, difficulty, the hundred Odyssey levels, the daily puzzles, and the format your saved game is stored in.

The checks

There are about 134 automatic checks on the iOS side and another 56 on the Android one. They run against the actual code and read the real numbers out of it.

That sounds obvious and it is the whole point. A check that keeps its own copy of what the answer should be is not checking anything. It is agreeing with itself.

• A check that reads nothing passes. So every one has to prove it found something before it is allowed to conclude anything.
• Every new check gets tested by breaking the thing it guards and making sure it goes red, then putting the file back exactly as it was.
• A check that matches text the fix also contains is comparing the fix with itself. That one has cost real time twice.

Everything gets written down

Every change carries a number and a short record: what it was for, what got tried, what got rejected.

The reasoning goes into the code as a comment rather than into notes somewhere else. Notes get lost. Comments sit next to the thing they explain.

That includes the failures. When a measurement kills an idea I already committed to, it gets withdrawn in writing, with the numbers, instead of quietly dropped.

Where it is up to

Shape of the thing

Two codebases, no shared source. Neither uses a game engine, neither uses a third-party UI framework, and on both sides the only outside dependency is Firebase, which is optional at compile time.

iPhone and iPad

Swift and SwiftUI, targeting iOS 17. No SpriteKit.

Android

Kotlin and Jetpack Compose, running back to Android 8. No Unity, no Godot, no View system.

Both

Engine/ compiles without SwiftUI on purpose, so the rules can be unit tested from the command line without a simulator. Skin colours are stored as raw hex there and converted to Color at the view boundary. It is a small discipline and it is what keeps the engine testable.

The board is two integers

There are two board representations. GridManager is the real one: colour, obstacles, animation payloads, roughly 2.5 KB. It is what the views read.

The solver does not use it. Placement legality and line clears depend on occupancy alone, so search runs on BitBoard, which is occupancy as bits.

index  = y * size + x        // bit 0 is top-left, rows contiguous
collision = a & b           // one AND
placement = a | b           // one OR
copy state = copy two words

Copying 2.5 KB a few thousand times per spawn is the difference between a solver that runs in a millisecond and one that makes the game stutter.

It used to be a single UInt64, which is exactly sixty-four bits and exactly an eight by eight board. Expert is ten by ten, which is a hundred cells, so storage moved to a two-word Bits type. The operations did not change. They just run on both halves.

Board size used to be a static let read from a dozen places, and every one of those reads was silently an assertion that the game has one board size. Now a board carries its own size and looks up cached masks from Geometry.

The solver, and why the hands are not random

Exhaustive search over a hand is three-factorial orderings times up to sixty-four origins each. Over a million leaf states on an open board, and it needs to run about ten times per spawn. That is not free.

So BoardSolver is a beam search: expand every state one ply, keep the best beamWidth by heuristic, repeat. A million-node search becomes a few thousand, and because the heuristic is decent the plans it keeps are close to optimal.

PieceSpawner uses it twice over. It deals several candidate hands, asks the solver how well each one plays out, and picks by skill level. The effect is that a good line of play exists. A clear is reachable. You are not told where it is, and finding it is still your problem.

The engine re-solves after every placement, so the plan is about the board you actually built rather than the one the solver imagined. Put a piece somewhere unexpected and the next hand is chosen for the position you just made.

There is also a mercy rule, so you are never handed a dead hand out of nowhere. It sets a flag the tests assert on and the interface deliberately never shows. A rescue you are told about is not a rescue.

ShapeQuota keeps a rolling record of which shape families have come up lately and biases the next draw toward what you have not seen.

Difficulty, as a number of blocks

DifficultyDirector turns your history into how full the board is when you arrive. Two axes.

Both axes are bounded, and the ceiling is not arbitrary. A board seeded past roughly a third full stops being a puzzle and starts being a coin flip.

Scoring and the combo

The combo multiplies everything a placement earns, not just the line bonus. Combo five really is five times the points added. That was not always true, and having a number on screen that is not the number being applied is worse than having no number.

The grace window is wider on the ten by ten board because it takes more placements to build a line there. A fixed grace made the combo nearly unreachable in Expert, which the measurement caught and the design did not.

Frenzy

The clock cannot exceed the round length, so banking time is capped and the mode stays ninety seconds of pressure rather than turning into a slow accumulation.

Today's Game, and what is actually guaranteed

This is the part most worth being precise about, because the obvious reading of it is wrong.

The promise is not a hidden answer key. In a block puzzle there is rarely one correct cell. Pieces are symmetrical, whole regions are interchangeable, and a clear erases the evidence of where anything went. A game that graded you against one intended solution would tell you that you were wrong when you were not.

Which is why nothing random may happen during a daily run. No stones, no bombs, no hazards mid-game. The moment something unplanned lands, the guarantee is void. Classic's rules, not Challenge's and not Frenzy's.

The table holds 2,222 days, 1 September 2026 to 30 September 2032. Every day was replayed before it shipped, through a witness replayer that shares no code with the search that found the lines in the first place.

The useful half of that verification is the control. Every day also gets replayed with line clearing disabled, and none of them survive it. A witness that still replays without clears would prove the replayer is not simulating the game at all, only pretending to.

Rollover uses Calendar.autoupdatingCurrent, so the day turns at the player's own midnight. Two players in different time zones are on different days for part of each day, deliberately.

Themes

A skin is an eight-colour palette plus a finish. The finish is how each tile is shaded, and the tile renderer branches on it: gloss is a vertical gradient with a highlight strip, matte is flat and reads as paper, glass is a translucent face with a bright rim and an inner highlight, and so on.

So changing theme changes the character of the board rather than only its hue, which is the reason forty-five of them are worth having instead of forty-five recolours.

Everything is generated at draw time from those values. There are no tile assets, no sprite sheets and no background images anywhere in the project. The only images in the app bundle are the icon, the launch mark and four score emblems.

Cloud save

Firebase Auth owns the provider credentials and issues a UID. Firestore holds two collections.

players/{playerID}        the save document
identities/{authUID}      a pointer to the playerID that UID owns

The pointer collection is what makes multi-provider accounts work. Signing in with Google gives a different Firebase UID than signing in with Apple, and both have to resolve to the same playerID. Without the indirection, linking a second provider gives you a second, empty account and your run is gone.

The whole file is wrapped in #if canImport(FirebaseAuth). Without the SDK installed it builds to a stub that reports the backend as unavailable, so the project keeps compiling and the game keeps working offline.

Keeping two platforms honest

The obvious way to check that iOS and Android agree is to compare their output. That is the wrong way, because two implementations can agree with each other and both be wrong, and because it only catches what you thought to compare.

Instead there is a written specification of the shared engine constants, and each platform has a checker that compares its own source against that document. The document is generated from the iOS source and committed.

That has a failure mode worth naming: if the spec goes stale, the other platform's checker compares itself against a version that no longer exists and reports that everything matches. It has happened, so there is now a checker whose only job is to assert the spec is current.

Things I got wrong, kept in the code

The comments in this project are long on purpose, and a good share of them record approaches that failed. Three examples.

• An overlay cannot serve a surface that travels from near-white to black. Empty cells were drawn as a black overlay, which reads as a soft well on a cream board and as nothing at all on a black one. Frenzy takes the panel to black, so late in a round every empty square stopped existing, and with it every signal saying you can place here.
• The fix for that is forced by arithmetic and cannot be faded away. An empty cell on a pale panel has to be darker than the panel and on a black panel has to be lighter. Ask for a continuous path between those and the algebra answers with zero opacity at both ends. So three inks now hand over at different panel luminances, staggered, and no two are ever weak at the same time.
• Thirty identical failures is the signature of a broken harness, not broken data. A replay check passed the board size where the seed goes and reported every day as unplayable. The data was fine.