also looking at this
feat(packaging): register the URL schemes an app declares
#57
3 files
+177
-7
| @@ -19,11 +19,15 @@ const keyDirectObject: u32 = 0x2D2D2D2D; // '----' | ||
| 19 | 19 | |
| 20 | 20 | /// Register an AppleEvent handler for `kAEGetURL` so the OS routes |
| 21 | 21 | /// `myapp://...` URLs into our process whenever the user opens such a |
| 22 | /// link (including the very first launch). Apps still need to declare | |
| 23 | /// their URL scheme in the bundle's `Info.plist` under | |
| 24 | /// `CFBundleURLTypes` for macOS to dispatch URLs at all — Craft can't | |
| 25 | /// do that for them, but with the handler installed the rest is | |
| 26 | /// automatic. | |
| 22 | /// link (including the very first launch). | |
| 23 | /// | |
| 24 | /// This is only half of it. macOS dispatches a URL to an app because the | |
| 25 | /// app's bundle claims the scheme under `CFBundleURLTypes`, and nothing | |
| 26 | /// craft produced used to write that key — so this handler was complete, | |
| 27 | /// correct, and could never fire. `packageApp` now emits it from the | |
| 28 | /// `urlSchemes` an app declares; a bare binary with no bundle still cannot | |
| 29 | /// be a URL handler, because there is nothing for LaunchServices to | |
| 30 | /// register. | |
| 27 | 31 | /// |
| 28 | 32 | /// macOS-only. Idempotent. |
| 29 | 33 | pub fn install() void { |