also looking at this
feat(ios): haptic, whose reason expired when ios_config landed
#134
18 files
+562
-163
| @@ -78,23 +78,30 @@ | ||
| 78 | 78 | //! **false** (`CraftApp.swift:192`, `packages/ios/src/index.ts:120`). When it |
| 79 | 79 | //! is false the `case` falls off the end and replies *nothing at all*, while |
| 80 | 80 | //! `CraftSwiftShim.handleAction` still returns `true` (`:5247`) so Zig |
| 81 | //! believes the hand-off succeeded. The injected promise is the hand-built | |
| 82 | //! kind with no timeout. **In a default-config app, `openCamera` and | |
| 83 | //! `pickImage` hang the page forever today.** The "working Swift shim" is | |
| 84 | //! only working for an app that set `enableCamera: true`. | |
| 81 | //! believes the hand-off succeeded, and the injected promise is the hand-built | |
| 82 | //! kind with no timeout — so on the shim a default-config app hangs the page | |
| 83 | //! forever. `ios_config.gateFor` maps both actions to `.camera` now, so | |
| 84 | //! `ios_dispatch.offerToModules` answers `CAPABILITY_DISABLED` first and that | |
| 85 | //! hang is unreachable while Zig is linked. This paragraph asserted the hang | |
| 86 | //! in the present tense until then, and the next one said `enableCamera` had | |
| 87 | //! no Zig-reachable channel at all. | |
| 85 | 88 | //! |
| 86 | //! `enableCamera` has no Zig-reachable channel, so this module gates on the | |
| 87 | //! Info.plist keys `packages/ios/src/index.ts:185-186` writes: | |
| 89 | //! The Info.plist keys `packages/ios/src/index.ts:185-186` writes are still | |
| 90 | //! read, for two different reasons: | |
| 88 | 91 | //! |
| 89 | 92 | //! - **`NSCameraUsageDescription` is an extra gate on `openCamera` only, and |
| 90 | 93 | //! it is a crash guard rather than a config proxy.** Presenting a `.camera` picker in a |
| 91 | 94 | //! process without that key is a TCC termination, not an error anything |
| 92 | 95 | //! could be told about. It is written for |
| 93 | 96 | //! `enableCamera || enableVideoRecording || enableQRScanner || enableAR`. |
| 94 | //! - **`NSPhotoLibraryUsageDescription` stands in for `config.enableCamera`, | |
| 97 | //! - **`NSPhotoLibraryUsageDescription` stood in for `config.enableCamera`, | |
| 95 | 98 | //! and it is over-broad by `enableVideoRecording`** — it is written for |
| 96 | //! `enableCamera || enableVideoRecording`, which is the closest proxy | |
| 97 | //! available. It is emphatically **not** a photo-library permission gate: | |
| 99 | //! `enableCamera || enableVideoRecording`, which was the closest proxy | |
| 100 | //! available while the flag could not be read. It is now a second, weaker | |
| 101 | //! gate behind the real one, and the only one of these proxies inexact even | |
| 102 | //! in an SDK-generated app. Tracked in issue #131 with three more. | |
| 103 | //! | |
| 104 | //! It is emphatically **not** a photo-library permission gate: | |
| 98 | 105 | //! `UIImagePickerController` with `.photoLibrary` has run out-of-process |
| 99 | 106 | //! since iOS 11 and neither prompts nor requires the key. Refusing on it is |
| 100 | 107 | //! a statement about how the app was configured, never about what the |