Two conventions throughout. <server-ip> is the LAN address of the computer running the server, and <device-ip> is the iPad's. Commands are marked as belonging to one machine or the other, because half of every confusing symptom here comes from running the right command on the wrong computer.

Section 01One request, end to end

1. You hold the home button. SpringBoard presents Siri's interface — Apple's, unmodified — and launchd wakes assistantd, the daemon that has always done Siri's actual work. Everything the tweak does happens inside that one process. SpringBoard itself is never hooked.
2. The dead connection is stubbed. Normally assistantd would now open a connection to Apple's assistant service and refuse to go any further without one. That service was switched off years ago. The tweak replaces -[ADAceConnection startWithAceHost:…] so that it marks itself connected and returns, and isConnected so it agrees. The session proceeds as though the far end answered. No packet is sent, and the three ADCommandCenter methods that would push anything outbound are dropped on the floor.
3. The microphone is tapped, not replaced. The tweak has hooked CoreAudio's AudioQueueNewInput, so when Siri opens its input queue the tweak's own callback sits in front of Apple's. Each buffer is copied aside and then handed straight on, which means Apple's recording, level metering and endpointing all continue exactly as before. A refId — a fresh UUID — is minted the moment recording starts, and it is what ties this request together from here on.
4. The utterance is posted. When recording stops, the captured PCM gets a WAV header and is POSTed as multipart form data to <ServerURL>/converse. That is the only network call the device makes for the request, it is plain HTTP, and it stays on your LAN.
5. The server does the thinking. mynah-server hands the audio to mynah-stt and gets a transcript; asks the local model in Ollama what kind of question this is and what the parameters are; fetches the live data from whichever public source that intent needs; and, if the answer has pictures in it, downloads and downsizes each of them first so that the device is only ever given an address on the server itself.
6. One JSON object comes back, always the same shape — a transcript, a line to speak, and zero or more cards.
7. Native objects are built and injected. The tweak turns that JSON into real SA* instances — the same classes iOS 6 builds for itself when Apple's service answers — marks the request outstanding so the session will accept them, and pushes them into the live session through -[ADSession aceConnection:didReceiveAceObject:], the same entry point Apple's own replies came in on.
8. The interface draws them. Apple's card code, in Apple's interface, drawing objects it believes came from Apple.

Section 02What is on the device

The package installs eight files in three places, and creates a ninth at runtime:

/Library/MobileSubstrate/DynamicLibraries/
    SiriRemastered.dylib     the tweak itself (armv7, ~40 KB)
    SiriRemastered.plist     the filter -- see below

/Library/PreferenceBundles/SiriRemastered.bundle/
    Info.plist              NSPrincipalClass = SRRootListController
    Root.plist              the Settings pane's schema
    SiriRemastered           the pane's compiled binary
    icon.png, [email protected]

/Library/PreferenceLoader/Preferences/
    SiriRemastered.plist     puts the row into Settings.app

created on first save, and left behind on uninstall:
/var/mobile/Library/Preferences/
    com.aditya.ios6siriremastered.plist

The filter plist

Substrate reads /Library/MobileSubstrate/DynamicLibraries/SiriRemastered.plist to decide where the library goes. It contains exactly one instruction:

{ Filter = { Executables = ( assistantd ); }; }

So the library is loaded into processes named assistantd and into nothing else. Every other process on the device — SpringBoard included — never sees it. The tweak's constructor then checks the process name a second time and returns immediately if it is anything else, which is belt and braces on the same guarantee.

If this plist is missing, the dylib is never loaded and the tweak is simply absent: no log lines, no Settings behaviour, nothing. That makes it the first thing to check when the tweak seems not to exist.

The preferences plist

Every setting lives in one file, /var/mobile/Library/Preferences/com.aditya.ios6siriremastered.plist. The Settings pane reads and writes that file directly rather than going through CFPreferences, and the tweak reads the same file, so there is exactly one source of truth and no cache to disagree with it.

The pane makes no network calls at all. It does not ask the server what models exist, it does not fetch the effective configuration, and it does not push anything back — earlier builds did, and the cost of a LAN round trip on a 2012 device was visible every time the pane opened. That plist is now the only channel between the pane and the tweak, in both directions. It also means the pane works perfectly well with the server switched off.

When a change takes effect

The tweak reads that plist once, in its constructor — that is, at the moment Substrate loads the library into assistantd, and again at the start of every recording — the hook on -[ADSpeechManager voiceControllerDidStartRecording:successfully:] calls loadPrefs() before anything else it does.

So a change made in Settings takes effect on your next question. No respring, and no killall. That matters while debugging: flip a card off, ask again, and the new setting is already in force.

If you want to be certain the library itself has been reloaded — after replacing the dylib, say, rather than after changing a setting — force the daemon to restart:

# on the device, over SSH
killall assistantd

That is a reload, not an outage. assistantd is a launch-on-demand job: launchd starts it again the next time you hold the home button. Nothing is lost and nothing needs restarting afterwards.

A respring is never required for this tweak. SpringBoard has none of it loaded, so there is nothing in SpringBoard to refresh. If a piece of advice tells you to respring for a settings change here, it is wrong.

Section 03What the tweak hooks

The constructor bails out unless the process is assistantd, loads the preferences, and installs two function hooks and nine method hooks. Every one of the method hooks checks the enabled flag first and calls straight through to the original when it is off — turning the switch off makes the tweak transparent rather than absent.

Function hooks, in CoreAudio

• AudioQueueNewInput — replaced so that the caller's input callback is swapped for the tweak's. That callback appends each buffer to the tweak's own accumulator and then invokes the original callback, so stock recording and endpointing carry on untouched. The sample rate and channel count are read from the format description assistantd passed in rather than assumed — iOS 6's Siri asks for 16 kHz mono, and whatever it actually asked for is what gets stamped into the WAV header. The samples are 16-bit PCM.
• AudioQueueDispose — replaced only so the tweak can forget a queue it was tracking.

Method hooks, in AssistantServices

How the reply is delivered

When the JSON arrives, on the main thread the tweak:

1. finds the live session — [ADCommandCenter sharedCommandCenter], then its _session, then that session's _serverConnection ivar;
2. calls _addOutstandingRequestId: with the refId, which is what makes the interface willing to accept objects for it;
3. injects, in order: an SASSpeechRecognized carrying the transcript — this is what puts your words on the screen — then an SAUIAddViews holding an SAUIAssistantUtteranceView for the spoken line plus one snippet per card, and finally an SARequestCompleted to close the request out.

Each injection is a direct call to -[ADSession aceConnection:didReceiveAceObject:].

Which card type maps to which object, and which switch

The type string on each element of the server's cards array selects a builder. Note that the athlete card is gated by the Sports switch rather than one of its own:

Every object is built by KVC and every step is guarded. A class that does not exist on this firmware is logged as MISSING class <name> and that card is dropped; a value of the wrong type is coerced or skipped; arrays that Apple's own code would dereference unguarded are never emitted empty. The design rule throughout is that a missing card is always better than a crash.

Section 04What the server answers

mynah-server is a FastAPI service on port 8807, published on all interfaces because the device has to reach it. mynah-stt's port 8808 is bound to 127.0.0.1 only — it is a debug port, and the device never touches it.

POST /converse

Multipart form data. The tweak sends codec (pcm_s16le_16k_wav), lang (en-US), session (the refId), location and units when those are set in Settings, and the WAV itself as the audio part. The server additionally accepts lat, lon and client_time, which this tweak does not send.

The reply is always the same envelope, whatever went right or wrong:

{
  "transcript": "what's the weather in london",
  "speak": "It's 14 degrees and cloudy in London.",
  "dialogPhase": "Summary",
  "listenAfterSpeaking": false,
  "cards": [ { "type": "weather", … } ]
}

"dialogPhase": "Error" marks the failure envelopes. An empty cards array is a normal, correct answer for conversation, greetings and honest “no results” replies.

GET /debug?q=…

The most useful thing on the server. It runs the complete pipeline — classify, fetch, build the cards, compose the spoken line — from typed text, skipping only transcription, and returns exactly the envelope /converse would have returned. No device, no microphone, no network between machines.

# on the server machine
curl "http://localhost:8807/debug?q=weather+in+London"
curl "http://localhost:8807/debug?q=AAPL+stock"
curl "http://localhost:8807/debug?q=who+won+the+Yankees+game+last+night"

It also takes units, lat, lon and location. Always try this before blaming the device. If /debug gives the right answer, everything except the microphone and the LAN is working, and the fault is in one of two much smaller places.

GET /healthz

{"status":"ok","stt":"Systran/faster-distil-whisper-small.en",
 "llm":"gemma4:e4b","search":"duckduckgo",
 "movies":"needs TMDB_API_KEY","public_base":"http://<server-ip>:8807"}

"stt":"unreachable" means the speech container is not answering — usually still downloading its model on a first run. Check docker compose logs -f mynah-stt.

GET /config and POST /config

Both are refused with 403 unless the caller's address is private, loopback or link-local, because iOS 6 cannot encrypt anything and these carry configuration. GET returns the effective configuration with tmdb_api_key and wolfram_appid redacted to set (…cd5f) or unset, so you can confirm a key was typed correctly without it ever being printed. The overrides_set list tells you which values are coming from a device override rather than from .env.

POST accepts a fixed key list — tmdb_api_key, wolfram_appid, model, ollama_url, searxng_url, public_base, units, default_location, default_city, default_lat, default_lon — and persists them to /data/config/overrides.json inside the container, which is ./config/overrides.json beside the compose file. Precedence is override, then .env, then the built-in default. An empty value clears an override.

GET /models

LAN-only. Returns what Ollama has installed, with the model currently in use first and flagged:

{"models":[{"name":"gemma4:e4b","size":"4.7 GB","current":true},
            {"name":"llama3.2:3b","size":"2.0 GB","current":false}],
 "current":"gemma4:e4b"}

If Ollama cannot be reached the response carries "error": "ollama unreachable" rather than failing, which makes it a quick way to confirm the container can see Ollama at all. The Settings pane used to populate a model picker from this; it no longer does, and this endpoint is now purely for your own use with curl.

The image and link endpoints

• /img/<40 hex characters>.jpg or .png — a pre-staged image, served straight off disk. The filename is the SHA-1 of the upstream URL plus the target width and format, so the same picture at the same size is always the same file and a repeated question does no network at all.
• /img?u=<url>&w=<width> — the lazy path: fetch, downscale, cache, serve. The upstream host must be on the allowlist; anything else gets 403 and an img host refused: line in the log.
• /render?tex=… or /render?plot=…&var=x — maths typeset and functions plotted on the server, then staged like any other image. This is how a maths answer arrives as a picture rather than as a line of text that the answer card would truncate with an ellipsis.
• /go/opentable/<token> — the token is a base64url-encoded search term and the endpoint 302s to the real OpenTable search. It exists because the restaurant card's button has to be a plain-http URL the device can actually open, and OpenTable is https.

Section 05Why every image is plain http

iOS 6 cannot load any https URL at all. Not an image, not a link, not a favicon. It is missing the certificate roots the modern web is signed with, and nothing on the device can supply them.

So the server does the loading. Every poster, team logo, headshot and photograph is fetched by the server, resized to something an A6X decodes quickly, written into its own on-disk cache, and handed to the device as a plain http://<server-ip>:8807/img/<hash>.jpg. The device only ever loads images from your own machine.

Three consequences follow, and between them they explain a good share of everything that goes wrong:

1. The Server URL must be http://. This is not a preference or a security trade-off you are being offered — the image addresses are built from that same base, so an https:// server address fails for the pictures exactly as it fails for everything else.
2. A broken image URL is worse than no image. The tweak refuses outright any image URL that is not plain http, logs photo not plain http -> dropped, and omits the field. The reason is specific: on iOS 6's card code both completion paths of a failed image load call setImage: with nil, which wipes the placeholder artwork that had already been drawn. An omitted image keeps the placeholder; a broken one leaves a hole.
3. The first use of a given image is slower than the rest. MYNAH_STAGE_BUDGET — 3.5 seconds by default — caps how long the server waits for a card's images before sending the card anyway. Anything still downloading finishes in the background and is a cache hit next time.

The same rule is why PUBLIC_BASE should be left blank. The server learns its own address from the Host header on the device's own request, which is by definition an address the device can reach. Hard-coding it can only make that worse, and is worth doing only behind a reverse proxy.

Section 06Reading the logs

On the device

Over USB, from the computer, with libimobiledevice installed. Every line the tweak prints is prefixed [SiriRemastered]:

idevicesyslog | grep SiriRemastered

This needs nothing installed on the device and works whether or not SSH is set up, which makes it the reliable route. Leave it running and then ask Siri something.

A healthy request looks like this — values are illustrative, the sequence is not:

[SiriRemastered] loading (server=http://<server-ip>:8807 enabled=YES cards: answer=1 weather=1 sports=1 stocks=1 movies=1 restaurants=1)
[SiriRemastered] v2 hooks installed
[SiriRemastered] AudioQueue tap: rate=16000 ch=1 fmt=0x6c70636d
[SiriRemastered] record START (ok=1) minted refId=1D4F…
[SiriRemastered] record STOP (reason=1): 51200 bytes ch=1 rate=16000 (~1.6s) -> POST flux
[SiriRemastered] flux reply: transcript="what's the weather" speak="It's 14 and cloudy." cards=1
[SiriRemastered] delivered reply for refId=1D4F… (1 card(s))

The diagnosis is in which line you do not see:

On the server

docker compose logs -f mynah-server           # follow live, Ctrl-C to stop
docker compose logs --tail 200 mynah-server   # the last 200 lines
docker compose logs -f mynah-stt              # the speech container
docker compose ps                             # running? or restarting in a loop?

Lines from the service are prefixed [mynah], and two of them carry most of the diagnostic weight:

[mynah] transcript: "what's the weather in london"
[mynah] intent: weather plan: {…}

The first is what it heard, the second is what it decided that meant. Between them they separate mishearing from misunderstanding, which are different problems with different fixes. Everything else in the log is a named failure of one data source — espn failed:, tmdb failed:, overpass failed:, wolfram failed:, ollama tags unreachable:, stage failed: — and reads plainly.

A container that docker compose ps reports as restarting is crashing and coming back; the error sits just above each restart in the log.

The order to work in

This sequence localises almost any fault in four commands, and it matters that it is in this order — each step rules out everything before it:

1. curl "http://localhost:8807/debug?q=…" on the server machine. If this is wrong, stop: the device is irrelevant and the problem is server-side.
2. curl http://<server-ip>:8807/healthz from a different computer on the same Wi-Fi. If step 1 worked and this does not, it is the network or the firewall — the same trip the device makes.
3. curl http://<server-ip>:8807/config — confirm the server is using the model, keys and location you believe it is.
4. Only now involve the iPad, with idevicesyslog | grep SiriRemastered already running.

Section 07Failure modes and their causes

Section 08When a card takes SpringBoard down

This is the worst thing that can happen, and it is entirely survivable. Nothing is bricked, nothing is lost, and no data is at risk.

The cards are drawn by Apple's card code, which lives in SpringBoard. The tweak does not run there — but the objects it builds are handed across, and a malformed one can crash the process that draws it. When SpringBoard crashes repeatedly, Substrate steps in and boots the device into safe mode: SpringBoard comes up with no tweaks loaded at all, a banner says so, and the device is otherwise completely usable.

What to do

1. Get out of safe mode first. Tweaks are disabled in safe mode, and PreferenceLoader is a tweak — so the tweak's row will not be in Settings while you are still in it. Respring out: tap the safe-mode banner, or from a computer, ssh root@<device-ip> then killall SpringBoard.
2. Turn that card off immediately, before asking anything of the same kind again: Settings → iOS 6 Siri Remastered → Cards. Then killall assistantd so the change is picked up for certain.
3. If you cannot get to Settings, or it crashes again before you can, disable the whole tweak from a computer:

   # on the device, over SSH
   mv /Library/MobileSubstrate/DynamicLibraries/SiriRemastered.dylib /var/root/
   killall assistantd

   Siri reverts to stock — which is to say silent — iOS 6 Siri, the device is entirely normal, and putting the file back is one mv whenever you want it again. The .plist beside it can stay: with no library to point at, Substrate loads nothing.
4. If you have no computer at all, use iFile on the device to move that same file aside, or simply uninstall the package in Cydia.

The mildest version of all of this, and the right first move if the device is usable: Settings → iOS 6 Siri Remastered → Enabled, off. Every hook then calls straight through to Apple's original and the tweak is transparent, without anything being removed.

If you do hit this, it is worth reporting. The server's [mynah] log records the intent and the card it built, and the device's [SiriRemastered] log records what was delivered immediately before the crash — between them they identify exactly which card and which question did it.

Section 09Removing it cleanly

In Cydia: Installed → iOS 6 Siri Remastered → Modify → Remove, then respring when it offers. That takes away all eight installed files — the library and its filter, the preference bundle, and the PreferenceLoader entry.

One thing is left behind, deliberately:

/var/mobile/Library/Preferences/com.aditya.ios6siriremastered.plist

That is your server address, location, units and card switches, kept so that reinstalling picks up exactly where you left off. Delete it by hand if you want a genuinely clean slate:

rm /var/mobile/Library/Preferences/com.aditya.ios6siriremastered.plist

MobileSubstrate and PreferenceLoader stay, because other tweaks on the device use them. Removing MobileSubstrate is not something to do casually on a jailbroken device.

Nothing on the server is touched by uninstalling on the device. To take that down too, in the server folder on the server machine:

docker compose down          # stop the containers
docker compose down -v       # and throw away the speech model and image cache

Then delete the folder. Ollama and its models are separate again, and ollama rm <model> reclaims that disk space.