How We Built the ARKit Sudoku Solver
In this technical retrospective (2017), @anielsen shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Cloud & Mobile Era (2014–2019)
COMMUNITY SCORE ★ 151 points
TOTAL DISCUSSIONS 37 comments
Really enjoyed reading this. The process is really explained well including all the fun rabbit holes and unexpected pitfalls on launch day, and the technical steps to overcome.
Interesting limitations to work around such as vertical planes vs horizontal, and focal length.
Not at all surprised they saw better performance with almost immediate payback by training models on their own $1,200 hardware than running in the cloud.
Very interesting they trained their own character recognition model and not only that but built their own custom crowd-sourced image labeling system complete with accuracy checks and review screens.
Overall, fantastic write-up!
Since the author spent so much time on the optical character recognition step, it's worth mentioning that you don't even really need OCR for this task.
You can just find the squares, group the characters in the squares into visual equivalence classes, assign each class an arbitrary number, solve the puzzle in terms of those numbers, then fill in each empty square with the (average?) image of the equivalence class it matches.
This would allow you to solve a Sudoku puzzle with letters or WingDings instead of numbers, and the output font would naturally match that of the original puzzle.
So, 6 years ago, Google Goggles could solve sudoku puzzles for you from pictures.
It's interesting to compare how far the interface/speed has come in 6 years if you watch the videos of how it was done then: http://googlemobile.blogspot.com/2011/01/google-goggles-gets-faster-smarter-and.html
(Goggles did not do the image handling on device)
Definitely cool, and I like the application of ARKit. But using ML to solve a sudoku seems like overkill. I remember writing a constraint-based solver as the first assignment for an undergrad-level AI course back in uni. Surely this implementation is less efficient? Someone let me know if I am wrong.
If the aim was to simply learn new tech, though, then I get it. I am just wary of ML being a hammer used on anything even remotely resembling a nail.
This is super cool, but I can't help but think that something is missing if it takes hundreds of thousands of examples of digits for a machine learning algorithm to be able to differentiate them. It wouldn't take a human child this many. The available machine learning algos are not using near the amount of information available.