The setup notes described moving the project as a tarball and never mentioned git, because until now there was no repo. They now lead with the clone URL and what a push needs — the credential helper, a token, and the hostname rather than 10.3.8.90, since the stored credential is keyed to the hostname and a remote written against the bare IP prompts every time. server/.gitignore only excluded data/*.json, which was enough for the checklist file and nothing else. Running the server locally creates data/uploads, data/docs and data/backups beside it, so an attached PDF or a backup would have been committed on the next add. The whole directory is ignored now. That data lives on the NAS; a stale copy of it restored over production is the accident worth designing out. Also records that the NAS password is a keychain item rather than a file, so a future machine knows to store it instead of hunting for the line that used to be in build-deploy.sh. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
6.0 KiB
Moving checklist development to another Mac
The project folder is most of it, but three things live outside it, and one thing should deliberately stay on the Mac Studio.
Source control
The project is in git, on the church Gitea:
http://chronicles-ab.waterschurch.org:3000/christian/recurring-checklist (private)
git clone http://chronicles-ab.waterschurch.org:3000/christian/recurring-checklist.git
That replaces the tarball below as the way to move the code — but only the code. Git deliberately carries none of the secrets and none of the live data, so the "Restore the secrets" section further down still applies to every new machine, and always will.
Pushing needs a credential for the Gitea. Store it once per machine and the osxkeychain helper answers every push after that, unattended:
git config --global credential.helper osxkeychain
The first git push then asks for the username (christian) and a personal access token
with write:repository, generated at Settings ▸ Applications in the Gitea web UI. Write
the remote with the hostname, not 10.3.8.90 — the stored credential is keyed to the
hostname, and a remote written against the bare IP will prompt every time.
The forge is LAN-only. Cloning and pushing need the church network or a VPN into it, the same as a web deploy.
What to copy
checklist-app-transfer.tgz — the whole project minus node_modules, build output and
secrets (all of which are either regenerated or restored separately). Unpack it wherever you
like; nothing depends on the path except the two config files noted below.
mkdir -p ~/Documents && tar -xzf checklist-app-transfer.tgz -C ~/Documents
What the laptop needs installed
| How | |
|---|---|
| Xcode | Mac App Store. Then sudo xcodebuild -license accept and open it once. |
| Node 20+ | nodejs.org installer |
| JDK 21 | see below |
| Android SDK | see below |
No Homebrew and no CocoaPods are needed — iOS uses Swift Package Manager deliberately, because the system Ruby is too old for CocoaPods.
# JDK 21
curl -L -o /tmp/jdk.tar.gz 'https://api.adoptium.net/v3/binary/latest/21/ga/mac/aarch64/jdk/hotspot/normal/eclipse'
mkdir -p ~/.jdks && tar -xzf /tmp/jdk.tar.gz -C ~/.jdks && mv ~/.jdks/jdk-21* ~/.jdks/temurin-21
# Android command-line tools + SDK
curl -L -o /tmp/cmdtools.zip 'https://dl.google.com/android/repository/commandlinetools-mac-13114758_latest.zip'
mkdir -p ~/Library/Android/sdk/cmdline-tools && unzip -q /tmp/cmdtools.zip -d /tmp
mv /tmp/cmdline-tools ~/Library/Android/sdk/cmdline-tools/latest
yes | ~/Library/Android/sdk/cmdline-tools/latest/bin/sdkmanager --sdk_root="$HOME/Library/Android/sdk" --licenses
~/Library/Android/sdk/cmdline-tools/latest/bin/sdkmanager --sdk_root="$HOME/Library/Android/sdk" \
"platform-tools" "platforms;android-36" "build-tools;36.0.0"
# Project dependencies
cd ~/Documents/recurring-checklist-app/mobile && npm install
cd ../server && npm install
Then edit mobile/android/local.properties so sdk.dir points at the new machine's home
directory — it is machine-specific and will be wrong after a copy.
Restore the secrets
They are not in the transfer bundle on purpose. They are already in
checklist-signing-backup.dmg (Google Drive → Apps/Backups). Open it and:
| From the DMG | Goes to |
|---|---|
android/upload-keystore.jks |
<project>/mobile/keystore/upload-keystore.jks |
android/keystore.properties |
<project>/mobile/keystore.properties |
ios/AuthKey_NXR7767SYK.p8 |
~/.appstoreconnect/private_keys/ |
ios/ios-signing.config |
<project>/mobile/ios-signing.config |
| — | <project>/server/.env — copy from the Studio; it is not in the DMG |
chmod 600 ~/.appstoreconnect/private_keys/AuthKey_NXR7767SYK.p8
The NAS password is a keychain item, not a file. build-deploy.sh and
backup-to-drive.sh used to carry it in plaintext; they now read it from the login keychain,
so it stays out of the repo and rotating it is one command instead of a history rewrite.
Store it once per machine — omit the value and security prompts for it, so it never reaches
your shell history:
security add-generic-password -U -s checklist-nas -a Christian -w
Both scripts also accept NAS_PASS from the environment, for anywhere without a keychain.
Then fix the absolute path inside keystore.properties:
storeFile=/Users/<you>/Documents/recurring-checklist-app/mobile/keystore/upload-keystore.jks
The iOS distribution certificate is not copied. Sign into Xcode ▸ Settings ▸ Accounts
with the same Apple ID and run ./release.sh --ios; -allowProvisioningUpdates mints a new
certificate for the new machine automatically. Nothing needs exporting from the old keychain.
Check it works
./mobile/scripts/verify-asc-key.sh # authenticates against App Store Connect
cd mobile && node scripts/sync-web.js # rebuilds www/ from server/public
cd android && . ../scripts/env.sh && ./gradlew :app:bundleRelease --no-daemon
A signed .aab means Android is fully restored. ./release.sh --ios proves the Apple side.
What must STAY on the Mac Studio
The nightly off-site backup. backup-to-drive.sh plus the LaunchAgent
org.waterschurch.checklist-drive-backup should keep running here, not on the laptop:
- a LaunchAgent only fires while the machine is awake and logged in — a laptop that sleeps or goes home silently stops backing up, and the failure is invisible
- it needs the LAN to reach the NAS at
10.1.1.5
Leave both in place on the Studio. If the laptop ever becomes the only machine, move the script and reinstall the LaunchAgent there — and check the log afterwards.
The other thing that needs the LAN
build-deploy.sh (and therefore ./release.sh) pushes to the NAS at 10.1.1.5. Web
deploys only work on the church network. Off-site you can still build and upload the iOS
and Android apps — those only need the internet — but ./release.sh --web will fail until
you are back on the LAN or on a VPN into it.