also looking at this
feat(ios): haptic, whose reason expired when ios_config landed
#134
18 files
+562
-163
| @@ -74,11 +74,12 @@ | ||
| 74 | 74 | //! Info.plist key to read instead: `renderUsageDescriptions` |
| 75 | 75 | //! (`packages/ios/src/index.ts:183-199`) writes nothing from either flag. |
| 76 | 76 | //! |
| 77 | //! Both are therefore served unconditionally, and an app that set | |
| 78 | //! `enableFilePicker: false` or `enableFileDownload: false` now gets the | |
| 79 | //! behaviour anyway. Restoring the gate means adding the fields to | |
| 80 | //! `AppConfig`, not adding a guess here — the same trade | |
| 81 | //! `bridge_mobile_system.zig` records word for word for `share`. | |
| 77 | //! Both flags are read directly now: `ios_config.gateFor` maps `pickFile` to | |
| 78 | //! `.file_picker` and `saveFile` to `.file_download`, so | |
| 79 | //! `ios_dispatch.offerToModules` answers `CAPABILITY_DISABLED` before this | |
| 80 | //! module is asked. This used to say both were served unconditionally and that | |
| 81 | //! restoring the gate meant adding fields to `AppConfig` — true when written, | |
| 82 | //! and answered by `ios_config.zig` reading `craft.config.json` instead. | |
| 82 | 83 | //! |
| 83 | 84 | //! Falling through to the shim is not the safe option it was for |
| 84 | 85 | //! `takeScreenshot`, because the shim does not answer these correctly today: |