PocketJev

Not quite. It never generates text. You supply a question and 2 to 26 options, and it reads the next-token logits for A, B, C straight off Qwen3-VL-2B 4-bit through MLX Swift, so there is no JSON parsing or repair step in the decision path. What comes back is a relative score per option.

No. The README says plainly that the displayed numbers are relative scores among the supplied choices, not probabilities that the answer is correct, and nothing is documented about threshold behaviour. If a wrong call would matter, its own advice is to add an explicit UNKNOWN option and verify against your own held-out examples.

The repo gives no way to tell. It publishes no quantitative iPhone latency or accuracy numbers and calls itself a working prototype. Its own guidance is that a broad question like "Is this render acceptable?" is less reliable than narrow observation questions such as "Is any part cut off by the image border?".

Both routes exist. The Releases IPA is a generic Release build for compatible sideloading environments, is not App Store or TestFlight signed, keeps the bundle identifier io.github.nullpojp.PocketJev, and still downloads the model on first setup. A source build wants Xcode 26 or newer, iOS 18, XcodeGen to regenerate the project, and a bundle identifier you change from com.example.PocketJev. Either way the roughly 1.78 GB Qwen3-VL 2B 4-bit weights come from Hugging Face on first use, and the app needs an iPhone with enough memory to hold them.

The mlx-community/Qwen3-VL-2B-Instruct-4bit model. It is downloaded on first use, cached on the iPhone, and the Hugging Face artifact is about 1.78 GB with 4-bit MLX weights under Apache-2.0. The weights are not in the repository.

It reads the next-token logits for A, B, C and up to 26 choices and shows a relative score per supplied option, without generating free-form text, which avoids JSON parsing or repair in the decision path.

It runs at 1, 2, or 5 seconds without queuing stale frames, keeps the live camera visible while the captured frame animates into the result area, and keeps the previous confirmed result visible until the next decision finishes, with light haptics after a decision.