Know what your device
is being asked to do.
Compare browser and native document-reading limits, configured local-model requirements and the distinction between implemented software and device validation.
Public implementation guide · Reviewed October 18, 2026 · Native release and device validation remain separate.
Technical specifications and compatibility
A bill review should not require guessing whether a device can run a model. GoldRock separates ordinary account access, deterministic bill tools, document recognition and optional language-model execution. Each has different requirements. The specifications below describe the configured implementation, not an App Store availability announcement or a guarantee that every compatible-looking device will perform well.
Separate the parts that matter.
Browser basics
Use a current browser with a secure context for protected storage and device APIs. The bill forms and researched steps are distinct from the optional model worker. Private browsing, storage restrictions or browser policy can limit persistence.
Model hardware
The configured browser execution paths use WebGPU. Gemma and Qwen require the listed shader-f16 feature; the current Bonsai 1.7B entry has no listed float16 feature requirement, but still uses the WebGPU execution path.
Storage and memory
Download bytes and working-memory estimates describe different resources. A device can have enough disk space but still fail to allocate a model. Browser caches can be evicted, and a downloaded model may need to be loaded again.
Native release status
The Xcode project targets iOS 18 or later for the app. Apple Foundation Models is separately gated at iOS 26 and system availability. The native implementation still needs current Mac/Xcode signing, build and device release checks before publishing.
Follow the data and the decisions.
- 01
Start with the tool you need
A manual bill worksheet and reviewed reference guidance can work without any language model download. Use a clearer local document or manual entry if recognition is unavailable.
The result of this stepA useful path that does not depend on model activation.
- 02
Check the document format and size
The web and native readers have separate format lists and page limits. A supported extension alone does not establish that a native file has valid contents; the native reader checks its byte signature.
The result of this stepA supported source within the relevant reader’s bounds.
- 03
Review the model download separately
The setup shows the configured public model artifact and a planning estimate for working memory. Additional runtime and installation space can be needed. No private case content belongs in a download URL.
The result of this stepA deliberate download decision rather than an automatic multi-gigabyte transfer.
- 04
Wait for actual initialization
A downloaded model, available GPU API and loaded inference engine are different states. Initialization can fail or stop, and successful loading is not a quality certification.
The result of this stepA readiness state based on the actual operation.
- 05
Check the answer, not only the hardware
Use the original evidence and source receipt. Model outputs can invent details, confuse public-reference dates with case dates or generate unsuitable wording. The person must review even an accepted draft.
The result of this stepAn answer whose claims can be checked before use.
Four capabilities with different requirements
Bill tools and reference guidance
Structured fields and the shared review engine. No local language-model download is needed for deterministic calculations.
Document recognition
Supported files, local rendering and OCR. Image clarity, page limits and memory still affect what can be read.
Optional language-model execution
A supported worker, sufficient device resources and a successfully loaded model. This is additional to the first two capabilities.
See the state the app actually shows.
Specifics you can compare.
| Capability | Browser reader | Native iPhone source |
|---|---|---|
| Maximum source size | 20 MiB per reading operation | 20 MiB per reading operation |
| PDF page limit | Up to 12 pages | Up to 20 pages |
| Supported source formats | PDF, JPEG, PNG, WebP, BMP | PDF, JPEG, PNG, HEIC/HEIF with supported signature checks |
| Recognition | Application-served PDF.js and Tesseract English OCR | PDFKit page rendering and Apple Vision en-US text recognition |
| PDF rasterization | Visible page rendering, annotations disabled for analysis; longest side bounded at 2,400 pixels | Bounded page rasterization with a longest side of 2,200 pixels |
| Image handling | Images scaled down to a longest side of 3,200 pixels for OCR | Source dimension/frame checks; bounded scan images; aggregate scan limits |
| Base app operating-system target | Browser capabilities determine individual features | iOS 18 project target; this does not make Apple’s system model available on iOS 18 |
| Optional system-model gate | Not an Apple Foundation Models browser path | iOS 26+ plus SystemLanguageModel availability on an eligible device |
MiB means 1,048,576 bytes. Model-download values on the local-AI page use decimal GB. Reader limits can be lowered for a specific flow; they do not certify file safety or guarantee successful recognition.
Practical controls and reviewable outputs.
Explicit format limits
The reader can refuse unsupported or oversized inputs rather than presenting an unreadable source as a successful review. A clearer page or manual facts can be used instead.
Model status and cache controls
Setup distinguishes not downloaded, cached, preparing and active states. Removal controls concern public model files. Local case saving is managed separately.
Native capability gates
The Swift source checks Apple model availability and Metal for the separate downloaded Gemma path. Unsupported or preparing states remain distinct from an available model.
A realistic compatibility expectation
A trial on one browser or operating system does not validate all phones, hardware or file types. Memory estimates and static feature checks do not establish medical-answer quality.
Keep availability and responsibility clear.
Pinned browser runtimes
The configured LiteRT-LM JavaScript package is 0.18.0. Transformers.js is 4.3.1, with a pinned ONNX Runtime build. The legacy WebLLM metadata uses 0.2.86. These are implementation versions, not a claim that the newest release is always selected.
Native model preparation
The downloaded Gemma path expects the pinned 2.01 GB model file and verifies its size and SHA-256 digest. The native download checks for more than approximately 4.6 GB of installation space and an available Metal device. It does not establish a universal memory requirement.
Bounded model context
Local retrieval uses curated public chunks, scope filters and source currentness. Prompt and output limits prevent unbounded context growth. They are not a guarantee against prompt injection, hallucination or all identifier leakage.
Questions worth answering before you rely on it.
Can I use a HEIC photo in the browser?
The current web reader asks for JPEG conversion or the native iPhone reader for HEIC. The native implementation includes HEIC/HEIF signature handling, but release and device validation are separate from this source-code capability.
Will an old or low-memory phone still have useful tools?
The ordinary bill worksheet, researched steps and manual writing are separate from a language model. Individual browser and storage restrictions still matter. GoldRock does not promise that every device supports every document or model feature.
Does the browser support a CPU fallback for these model choices?
The configured current model workers select WebGPU for their execution path. This page does not promise an automatic CPU fallback. If setup fails, use the model-free tools and review the explicit status.
Are Qwen, Bonsai and Gemma all native iPhone runtimes?
No. The current browser offers the three named setup choices. The native source includes Apple Foundation Models and a separate LiteRT-LM Gemma path. A browser model listing does not mean a matching native Qwen or Bonsai engine is implemented.
Is the iOS app published or validated on my device?
The existence of SwiftUI source and an iOS target is not an App Store release or a device-performance result. Current Xcode, signing, physical-device tests and release review remain separate steps.
Can a feature check certify that the device is secure?
No. GPU availability, file limits and encryption configuration are technical controls with limited purposes. They do not certify the operating system, guarantee data recovery or establish compliance with a healthcare standard.
Understand the process.
Keep your own decisions.
Use the public sample to explore a fictional case, or sign in to review the tools and settings available to your account and device.