ai/byre
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 14 Wiki Activity

Number builds by build time so releases supersede deploys

Browse Source
This commit is contained in:
Ian Gulliver
2026-10-22 19:33:43 -07:00
parent d8ce1cee41
commit 5ed184e975
7 changed files with 315 additions and 315 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/iphone.md
+1 -1
View File
@@ -8,7 +8,7 @@ Left out on the phone: the Server tab and running byre locally, the shell, file,
## Building
`mac/phone.sh` builds the app with `xcodebuild` (a Swift package can't be built for iOS by `swift build`) in the same shared directory and under the same lock as `mac/bundle.sh`, assembles `Byre.app` itself (icon through `actool`, fonts, `Info.plist` from `mac/phone/Info.plist` plus the version, commit and `DT*` keys App Store Connect checks), signs it ad hoc with `mac/phone/byre.entitlements`, and wraps it in `mac/.build/phone/iphoneos/Byre.xcarchive`. Release only, like the Mac app. `xcodebuild -exportArchive -archivePath <archive> -exportOptionsPlist mac/phone/export.plist -exportPath <dir> -allowProvisioningUpdates` re-signs it for the App Store and uploads it to TestFlight, using the Apple account Xcode is signed into: Xcode makes the distribution certificate and profile itself, so none are kept in the repo. Uploading needs the App ID `run.fc.byre.ios` (iCloud with the container `iCloud.run.fc.byre.mac`, and Push Notifications) and its app record in App Store Connect; neither can be made through Apple's API. The version is the last release tag's (App Store Connect takes only numbers) and the build number is the Mac app's (`docs/operations.md`, "Releases"). App Store Connect refuses a build number that isn't higher than every earlier upload, so a second upload of the same commit fails; a commit count wouldn't do, since it can go down when a branch with many commits uploads before its squash merge lands on main.
`mac/phone.sh` builds the app with `xcodebuild` (a Swift package can't be built for iOS by `swift build`) in the same shared directory and under the same lock as `mac/bundle.sh`, assembles `Byre.app` itself (icon through `actool`, fonts, `Info.plist` from `mac/phone/Info.plist` plus the version, commit and `DT*` keys App Store Connect checks), signs it ad hoc with `mac/phone/byre.entitlements`, and wraps it in `mac/.build/phone/iphoneos/Byre.xcarchive`. Release only, like the Mac app. `xcodebuild -exportArchive -archivePath <archive> -exportOptionsPlist mac/phone/export.plist -exportPath <dir> -allowProvisioningUpdates` re-signs it for the App Store and uploads it to TestFlight, using the Apple account Xcode is signed into: Xcode makes the distribution certificate and profile itself, so none are kept in the repo. Uploading needs the App ID `run.fc.byre.ios` (iCloud with the container `iCloud.run.fc.byre.mac`, and Push Notifications) and its app record in App Store Connect; neither can be made through Apple's API. The version is the last release tag's (App Store Connect takes only numbers) and the build number is the Unix time of the build (`docs/operations.md`, "Releases"). App Store Connect refuses a build number that isn't higher than every earlier upload, which a build time always is, so the same commit can be uploaded again; a commit count wouldn't do, since it can go down when a branch with many commits uploads before its squash merge lands on main.
iOS finds the app's App Intents (the Run workflow shortcut the Action button can run) only through `Byre.app/Metadata.appintents`. Xcode makes that bundle for app targets but not for a Swift package's executable, so `mac/phone.sh` runs `appintentsmetadataprocessor` itself, inside the build lock, on the source list and `.swiftconstvalues` the compiler leaves in the derived data. It has to read the sources from the shared copy the build compiled, which the next build of another worktree replaces. The simulator has no Shortcuts app, so an intent can only be tried on a phone.