Post

Replies

Boosts

Views

Activity

Reply to Apple thought it was impossible
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.
Topic: Community SubTopic: Apple Developers Tags:
2d
Reply to Apple thought it was impossible
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.
Topic: Community SubTopic: Apple Developers Tags:
2d
Reply to Apple thought it was impossible
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."
Topic: Community SubTopic: Apple Developers Tags:
5d
Reply to Apple thought it was impossible
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.
Topic: Community SubTopic: Apple Developers Tags:
1w
Reply to Apple thought it was impossible
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
Topic: Community SubTopic: Apple Developers Tags:
1w
Reply to Apple thought it was impossible
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
Topic: Community SubTopic: Apple Developers Tags:
1w
Reply to Apple thought it was impossible
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.
Topic: Community SubTopic: Apple Developers Tags:
Replies
Boosts
Views
Activity
2d
Reply to Apple thought it was impossible
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.
Topic: Community SubTopic: Apple Developers Tags:
Replies
Boosts
Views
Activity
2d
Reply to Apple thought it was impossible
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."
Topic: Community SubTopic: Apple Developers Tags:
Replies
Boosts
Views
Activity
5d
Reply to Apple thought it was impossible
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.
Topic: Community SubTopic: Apple Developers Tags:
Replies
Boosts
Views
Activity
1w
Reply to Apple thought it was impossible
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
Topic: Community SubTopic: Apple Developers Tags:
Replies
Boosts
Views
Activity
1w
Reply to Apple thought it was impossible
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
Topic: Community SubTopic: Apple Developers Tags:
Replies
Boosts
Views
Activity
1w