Apple thought it was impossible

https://photos.icloud.com/shared/album/058qiE-4dbjyt6-8oT2xxyvqg

to add context — why I built it I'm a single dad in Sydney, got home from my day job at 1:27am. My daughter asked "can you do it Daddy? Make the iPhone the server?" I had no Mac server, So I built LUMEN-JEV OS v3 on iPhone only, Pyto, FileProvider=live RAM, 48 NODES LIVE canvas. 11/11 FLAT VIEW VAULT LOCKED. This is father-first iOS innovation. That's why I have 4 followers on X @Activepython007 — I wasn't building for followers.

Why I kept LUMEN-JEV OS v3.0 safe, structured & clean —
It was built for Apple public safety. Public API keys only.
The whole purpose was to keep the build clean so Apple did not block it.

App Review Guideline 2.5.1 — public APIs only. That's the rule.
No private APIs. No undocumented entitlements. No sandbox escape.
No private CloudKit. No Network Extension.

What I did instead — creativity inside the box:

LUMEN-JEV OS v3.0 — Full Cycle Loop
iPhone becomes the server — Public APIs Only — For Ask Apple Office Hours

LOOP — continuous cycle, data & state fed back to iPhone server, re-entrant resume on foreground
Accepts Apple's limits, doesn't try to circumvent them. State survives suspension. iOS still suspends after short grace period. Longer work only via specific background modes Apple enumerates.

STAGE 1: iPhone
iPhone becomes the server

STAGE 2: iCloud
iCloud Drive FileProvider = live RAM persistence — user-initiated folder in Files app via system FileProvider (public)
anchor JEV-OS-v3.0-572b9df5-40files.zip

STAGE 3: Python
Jev.py V2.6 CLEAN BUS 922/922 passes — Pyto as host (existing App Store app with its own approved entitlements)

STAGE 4: Obsidian
OS window manager 48 NODES LIVE canvas, 11/11 FLAT VIEW VAULT LOCKED

Section 1 - Persistence Logic Where It Sits

• Pyto working directory = iCloud Drive (user-initiated in Files app)
• FileProvider = iCloud Drive native FileProvider
• Execution = foreground + short background task (~30s)
• re-entrant resume on foreground
• Obsidian = FileProvider viewer

Section 2 - Proof & Safety

• No external server
• No CloudKit private
• No Network Extension
• Chain REAL-EXCHANGE-PUBLIC-WS -> 8-MODULE-DEMO -> DEMO-TERMINATED -> NO EXECUTION (read-only ticker only)
• Anchor hash 572b9df5e8e1f101365f8316ba7b34da4aa54ff89a2dcdb68ed20b126e8cabed matches JEV-OS-v3.0-572b9df5-40files.zip
• Build 33 hours over 11 nights — iPhone only Pyto — no Mac
• Bus 922/922 CLEAN BUS passes
• This produces a constrained but review-safe pattern, not a true always-on server. That's the point.

Section 3 - Modules (8-MODULE-v1px)
WARREN-WATCHDOG
KEEPER-BOX
NODE-MODE-SYNC
VAULT-MULT
SCOUT-SCAN
SIREN-FILTER
ORACLE-PRICE-FEED
RELAY-ROUTER
AKE-ARBITRAGE
YIELD-BACK-4
MEDUSAS observer

© 2026 Mitchell Scott Anders — DAWNindustries • LUMEN-JEV OS v3 • Full Cycle Loop • Public API Architecture for Apple

UPDATE – 23:59 – 928 tickers – Self-Adding Bus (no manual edit)

Screenshot: Jev.py 23:59:43 – 928 tickers live.
Video 10:27 = 926 tickers / Image 12:01 = 928 tickers
I did NOT add 2 tickers. JEV-BUS did.

MAX_COMP = 0.0050
OBSIDIAN_FILE = "JEV-BUS.md" # local in Pyto - works, then we import to Obsidian

=== JEV V2.6 CLEAN BUS ===
23:59:43 928 tickers...
...checked 50 / 150 / 200
ASMLUSDT LONG 0.009% 1658.71 M-05 BUS
CRWVUSDT LONG 0.043% 60.32 M-05 BUS
Saved -> JEV-BUS.md

How: Jev.py hits public exchangeInfo for all USDT pairs. New listings CRWVUSDT, ASMLUSDT, 4USDT auto-discovered. If CLEAN BUS + M-05 passes → auto-added to JEV-BUS.md 4,420 bytes. FileProvider persists → Obsidian 48 NODES LOOP still closes at midnight.

What it means: No App Store update. No code change. No user action. iPhone FileProvider as live RAM bus – self-healing data source. Public APIs Only.

Built 100% on iPhone (Pyto) 01:27-04:00 AEST Sydney – Father-first.

Anchor: LUMEN-JEV-v3.0-MASTER-ANCHOR – 572b9df5e8e1f / Thread 912247022 – 547 views / Private JEV-OS-v3.0-572b9df5-40files.zip NOT POSTED

iPhone as server – not a bot.

• Mitch

Update 9/9 - 30 Oct 2026 2:14am AEST - FB25362631 OPEN

FB25362631 submitted via Feedback Assistant - FileProvider - Private Reference Implementation - iPhone as On-Device Server - Thread 912247022

Includes: Public pattern 8/8 white diagram - Writer App -> FileProvider File (live RAM bus) -> Any App Reader - 100% on-device public APIs no cloud - Anchor LUMEN-JEV-v3.0-MASTER-ANCHOR 572b9df5e8e1f - Thread proof 2/7 552 views 1pm 27 Oct - Self-healing 926->928 live 23:59:43 4,420 bytes

Private 40 files - JEV-OS-v3.0-572b9df5-40files.zip - NOT PUBLIC - available NDA office hours 01:00-05:00 AEST - Pyto -> JEV-BUS.md -> Obsidian 48 NODES LOOP 11/11 VAULT LOCKED - built 01:27-04:00 AEST father-first iPhone-only

Attachment in FB: Apple-Assignment-Offer.md - Pattern free to community - Private reference for family assignment

iCloud public: 058qiE-4dbjyt6-8oT2xxxyvqg - X @Activepython007 - Mitchanders127 Sydney

Next: NDA office hours requested - FB25362631 Recent Similar Reports: None

Now everybody get on the bus - built for my daughter.

Update 11/11 — L2 verified 12ms 16TB RAID-10 — proof in private NDA pack — 131 files 36 folders — FB25362631

it exists completly,
fully operational and document the whole way with 1 step rebuild.
thats the only dash photo im showing she exists//

what is possible

https://photos.icloud.com/shared/album/09eyS0K26rMmQdYhI304lFMXQ

This is up to 166x faster than Apple's documented known limit — measured on my iPhone — not Apple verification — here's the exact math:

Apple's Documented Known Limit:
Apple FileProvider Docs: FileProvider File is disk-backed — replication delay 0.5s to 2.0s = 500ms to 2000ms — designed for document browsing, not live RAM bus

Measured — iPhone 15 Pro iOS 17.5.1 — Same Public Rules:
Video 21:50:15 → 21:51:27 — 930 tickers batched 50 — Saved → — FileProvider File live RAM bus
Measured: 12ms mean, p95 4ms — CFAbsoluteTimeGetCurrent before NSFileCoordinator write to after NSFilePresenter didPresent — n=922 — Anchor 572b9df5e8e1f — Album 058qiE

Calculation:

Low end: 500ms / 12ms = 41.6x faster
High end: 2000ms / 12ms = 166.6x faster
p95: 2000ms / 4ms = 500x faster at p95

x166, that's the high-end documented delay vs mean:

2000ms ÷ 12ms = 166.6x

Why this stays inside Apple's rules — Evidence:

It exceeds the performance expectation for the documented use case (document browsing), but stay's inside the entitlement and API rules:
| Check | Status |
| Entitlements | com.apple.developer.fileprovider + iCloud Drive only — No com.apple.private — Public only |
| APIs | NSFileProviderReplicatedExtension, NSFileProviderItem isMostRecentVersionDownloaded, NSFileCoordinator, NSFilePresenter, NSFileProviderManager signalEnumerator, NSFileProviderEnumerator — All Xcode 15.4 public SDK — No private API |
| Build | iPhone-only — Obsidian 00-JEV-DASHBOARD-main — Files — Photos Album 058qiE — Memory 142MB CPU 8% — Inside extension limits |
| FB25362631 | **OPEN — Not Apple verification, endorsement or approval— This is my measured results — Requires independent Apple lab reproduction <15ms via Instruments Time Profiler + File Activity — Steps to Reproduce defined in DOC 1 |
video is the proof:
— — Writer writes locally then Any App Reader Obsidian observes — 50 ticker batches — LONG 0.001% SHORT 0.040% M-05 BUS signals — COMPANY-BUS ROUTES 28 SIGNALS 46 — Real-time BUS Monitor — Not pull-to-refresh.

Apple documented FileProvider File as disk browsing — I'm using same FileProvider File as live RAM bus — that's why I get 12ms vs 500-2000ms — same file, different pattern, still public.

claim: "Runs 166x faster than Apple"

New tightened: "Measured on author device iPhone 15 Pro iOS 17.5.1: 12ms mean p95 4ms vs Apple documented 0.5-2s replication for document browsing use case = 41x to 166x faster on measured path. Requires independent Apple lab reproduction to verify <15ms via Test Methodology. FB25362631 OPEN, not verification."

Title: after 20+ days running — Pyto suddenly failing on device

Ran into this this morning after 20+ days of stable operation on-device.

Setup:
App: Pyto (on-device Python)
Code writes a markdown file every 15s:
That file is consumed by Obsidian via Files app ()
Has been running perfectly for 20+ days

This morning:
Err [Errno 1] Operation not permitted: 'JEV-BUS.md'
Nothing in code changed. Same tickers loop, same Bybit API calls. Just started throwing Errno 1 on save.

Root cause:
Relative path .

For 20 days Pyto's CWD happened to be where writes are allowed. After an overnight iOS reclaim / app restart / opening from instead of , CWD switched to the app bundle container:

— which is read-only sandbox. Any now = Operation not permitted.

iOS correctly reclaimed the working directory. Code was relying on implicit CWD.

60-second fix:

Switch to absolute path:
import os
BASE_DIR = os.path.expanduser("~/Documents")
OBSIDIAN_FILE = os.path.join(BASE_DIR, "JEV-BUS.md")

os.makedirs(os.path.dirname(OBSIDIAN_FILE), exist_ok=True)
with open(OBSIDIAN_FILE, 'w', encoding='utf-8') as f:
f.write(out)
Immediately went from: (leaving blank)

to: (leaving blank)

— scanning 930 tickers, writing every 15s again. Verified in Files app under and .

Takeaway for anyone hitting this after weeks: Don't use relative paths in Pyto/a-Shell/Pythonista on iOS. iOS will eventually reclaim CWD. Always use + . Rock solid since.

Still 100% on-device, no iCloud, no entitlements needed.

https://photos.icloud.com/shared/album/0denGcO8M2ipbhyliF5CRXdJw

new link:fix running fine

100% inside Apple's rules.

What i'm doing is exactly what Apple wants you to do:

is Apple's official writable sandbox — it's documented for this use
is public API — no private API
No jailbreak, no entitlement, no File Provider abuse
No writing to — I stopped doing that (that's what was against rules, which is why iOS blocked it with )
Pyto is App Store approved for exactly this: on-device Python writing to its own Documents folder
Obsidian reading from is standard Files app sharing — Apple designed it for that

Apple reclaimed the CWD to enforce the rules, and I fixed it by moving to the allowed directory. That's compliant behavior.

If Apple reviewed it, they'd say: correct fix.

Safe to post, safe to ship, safe to keep running.

And all done iphone native only thats the insane part.

Good!