getAvailableBuyProviderTypes() now returns [moonpay] only when moonPayApiKey is
non-empty, so MoonPay's Buy button appears only in builds where the CI secret is
present (and the exchange-helper signer is live). Both build workflows now inject
MOONPAY_API_KEY -> moonPayApiKey and EXCHANGE_HELPER_API_KEY -> exchangeHelperApiKey
alongside Trocador + WalletConnect. moonPaySecretKey is server-side and never injected.
Both build workflows now set walletConnectProjectId in lib/.secrets.g.dart from
the WALLETCONNECT_PROJECT_ID secret (alongside the Trocador keys), so
WalletConnect pairing works in signed builds. Add WALLETCONNECT_PROJECT_ID
(your reown Wallet projectId) to the CI secrets before building.
LibTorch.xcframework ships with each slice's Info.plist claiming
MinimumOSVersion=12.0, but the Mach-O LC_BUILD_VERSION inside the
binaries actually requires 13.0 (device) and 14.0 (simulator). Apple's
validator catches the lie and rejects TestFlight uploads with ITMS-90208
("LibTorch.framework does not support the minimum OS Version specified
in the Info.plist") regardless of the app's deployment target.
Revert the previous 15.0 deployment-target bump (which was based on the
wrong hypothesis) back to 13.0 — that's actually what LibTorch supports.
Add a workflow step that plutil-rewrites both slice Info.plists to match
the value their binary actually requires. Bump build number 1.0.0+2 ->
1.0.0+3 for the re-upload.
First TestFlight upload was accepted and processed all the way through,
then Apple's binary validation kicked back ITMS-90208 Invalid Bundle:
The bundle Runner.app/Frameworks/LibTorch.framework does not support
the minimum OS Version specified in the Info.plist.
torch_dart-v1.0.17 ships a LibTorch.xcframework whose Info.plist
declares a higher MinimumOSVersion than our app's 13.0. Apple's
notarization-style check rejects an app that claims to run on iOS
versions where a bundled framework refuses to load.
Bump the four spots iOS deployment target lives:
- ios/Podfile (was 13.0)
- ios/Flutter/AppFrameworkInfo.plist MinimumOSVersion (was 12.0)
- ios/Runner.xcodeproj/project.pbxproj — 6 IPHONEOS_DEPLOYMENT_TARGET
entries (mixed 12.0 / 13.0)
all → 15.0. iPhone 6s (2015) and newer; very wide 2026 coverage.
Also bump build number 1.0.0+1 → 1.0.0+2 in pubspec_description.yaml.
Apple rejects re-uploads with the same build number (ITMS-90478), so
the next TestFlight upload after this fix needs a fresh +N.
Workflow diagnostic step that dumps LibTorch.xcframework's Info.plist
MinimumOSVersion now lives in the "Fetch prebuilt torch_dart" step. If
15.0 still isn't enough, the log tells us exactly what to bump to next.
altool bailed with "Failed to load AuthKey file. (-39) The file ...
does not contain a valid authentication key." — same shape as the
.p12 truncation we hit earlier. The .p8 stored secret is probably
truncated or has stray characters from the original web-UI paste.
Add fail-fast validation right after decoding the .p8 to disk:
prints the first + last lines (just the PEM markers, no key body)
and runs `openssl pkey -in file -noout` to actually parse it. If
either check fails the step bombs immediately with a clear "re-paste
via Gitea API" instruction, saving 30+ seconds before altool fails
the same way with a less useful error.
One of the Flutter plugins in our dep chain (sp_scanner / payjoin /
something in the cargokit family) compiles its rust component with
+nightly. The archive step ran for 27s then bombed with:
Error (Xcode): Missing manifest in toolchain 'nightly-aarch64-apple-darwin'
We were installing only stable + iOS targets. Add nightly toolchain
(minimal profile) + iOS targets for it alongside the stable ones.
~250 MB extra download once per runner workspace lifetime.
build-ios-sim.yml has the same stable-only setup but never tripped on
this — likely because the failing plugin's release-only build path
isn't exercised in the unsigned sim build. Leaving sim workflow
alone for now; copy the nightly steps over if it ever surfaces there.
Xcode build-setting precedence puts TARGET-LEVEL pbxproj settings
ABOVE the target's xcconfig. So the earlier append to Release.xcconfig
(CODE_SIGN_STYLE = Manual etc.) was being silently overridden by the
pbxproj's CODE_SIGN_STYLE = Automatic. The build did Automatic
signing anyway and bombed with:
Error (Xcode): No Accounts: Add a new account in Accounts settings.
Error (Xcode): No profiles for 'com.suchsoftware.hashwallet' were
found: Xcode couldn't find any iOS App Development provisioning
profiles matching 'com.suchsoftware.hashwallet'.
(Note "App Development" not "App Distribution" — confirming the
project was still asking for a dev profile via Automatic signing.)
sed-patch the Runner target's Release config block in
project.pbxproj directly, scoped by the stable Release config UUID
(97C147071CF9000F007C117D) so we don't touch Debug/Profile configs.
Sets:
CODE_SIGN_IDENTITY = "Apple Distribution"
CODE_SIGN_STYLE = Manual
DEVELOPMENT_TEAM = ${APPLE_TEAM_ID}
PROVISIONING_PROFILE_SPECIFIER = ${PROFILE_NAME}
Patch runs only at CI time; the committed pbxproj stays on Automatic
signing for local Xcode dev. The dumped block at the end of the
step confirms which lines actually changed, so the next failure
mode (if any) is debuggable.
The openssl pkcs12 round-trip step was speculative defense against
"modern macOS Keychain exports incompatible with security import" —
a problem we made up. What was actually happening:
1. The original failure ("SecKeychainItemImport: Unknown format")
was caused by a TRUNCATED base64 secret value. security wasn't
rejecting the format; it was rejecting bytes it couldn't parse
because the file was 29 bytes short.
2. The follow-on failure ("RC2-40-CBC unsupported") was the openssl
conversion step bombing because openssl 3.x has RC2-40-CBC
disabled by default. macOS Keychain Access actually exports
PKCS12 with RC2-40-CBC + PBE-SHA1 — exactly what `security
import` reads natively.
With the truncated-secret fixed (re-pasted via Gitea API), the .p12
on disk is now correct. Import it directly without round-tripping
through openssl. Less code, fewer failure modes, faster.
macOS Keychain Access on Sonoma+ exports .p12 with modern crypto
(AES-256-GCM + PBKDF2 + SHA-256). The `security import` binary on
some macOS releases — including ours apparently — rejects it with:
SecKeychainItemImport: Unknown format in import.
The openssl decode itself was fine (now using openssl base64 -d -A),
but security can't import the resulting PKCS12 envelope.
Pipe the .p12 through openssl: unpack with the user's password, then
re-export using legacy PBE-SHA1-3DES for both certs and keys, plus
SHA1 MAC. The resulting .p12 uses 90s-era crypto for the OUTER
envelope, which is what security import wants — the actual signing
keys + cert inside are unchanged. No security implication; the legacy
format encryption only matters for the few seconds the .p12 lives in
$RUNNER_TEMP before being imported and deleted.
Also added diagnostic output (file size, magic bytes, file(1)) so the
next failure mode (if any) is easier to characterize.
`base64 --decode` also failed on the Mac runner with the same
"(null): error decoding base64 input stream" — so either this macOS
version's BSD base64 doesn't honor --decode (only -D) or it chokes
on the input format. Either way, swap the three secret decodes to
`openssl base64 -d -A`:
- openssl ships with macOS by default; no extra install
- -d = decode (same on BSD and Linux, no platform skew)
- -A treats the input as one continuous line (matches our
`base64 -i x | tr -d '\n'` encoding flow)
If openssl base64 ever bites us we'll fall back to python3's
base64.b64decode, but openssl has been bulletproof for ~25 years.
macOS uses BSD base64 where -d historically means *debug*, not
*decode* like GNU base64. On the Mac runner that bit us — the
first base64 -d invocation ran in debug mode, consumed no stdin,
and produced an empty .p12 file, then the keychain import bombed
with the now-classic "(null): error decoding base64 input stream"
once a downstream tool tried to read the empty file.
Switch all three secret decodes (.p12 cert, .mobileprovision,
.p8 API key) to base64 --decode. Long form is identical between
GNU coreutils and BSD base64.
The Apple secrets themselves were fine — sanity-check step
confirmed all non-zero lengths (TEAM_ID/KEY_ID showed as ***0
in the log, which is the actual literal 10 with the 1 redacted
because some other secret value contains the substring "1").
First TestFlight trigger failed at the .p12 import step with
"base64: stdin: (null): error decoding base64 input stream" — meaning
$APPLE_DIST_CERT_P12_BASE64 was empty when reaching the keychain step.
Add a length-only debug step at the top of the Apple-signing section
that prints the length of every required Apple secret and bails
fast with a clear "set this secret on Builds/hash-wallet" message if
any is zero-length. Same pattern build-android.yml uses for the
Android keystore + Trocador secrets.
The likely cause is the Apple secrets being set on github-such-
software/hash-wallet but not on the Builds fork the workflow runs
in — Gitea secrets are repo-scoped, not org-scoped.
The committed project.pbxproj Release config uses CODE_SIGN_STYLE =
Automatic + CODE_SIGN_IDENTITY = "Apple Development" — both set up for
local Xcode-signed-into-an-Apple-ID development workflow. CI has only
the Distribution cert + provisioning profile we install into a temp
keychain, no Apple ID session, so Automatic signing fails at archive
time.
Append manual-signing overrides to ios/Flutter/Release.xcconfig in CI
(xcconfig values take precedence over pbxproj defaults, so this
overrides without modifying the committed project file):
CODE_SIGN_IDENTITY = Apple Distribution
CODE_SIGN_STYLE = Manual
DEVELOPMENT_TEAM = ${APPLE_TEAM_ID}
PROVISIONING_PROFILE_SPECIFIER = ${PROFILE_NAME}
PROFILE_NAME is parsed earlier from the .mobileprovision Name field.
APPLE_TEAM_ID comes from the existing Gitea secret. Local Debug/Profile
builds remain on Automatic signing — unchanged.
Gitea is on the same Mac mini as the runner, behind NPM in a separate
container. The proper fix is a hosts entry on the Mac that points
git.such.software at NPM's LAN IP so the runner reaches Gitea via
NPM's Let's Encrypt cert.
The env var stays in the workflow as a belt-and-suspenders fallback —
no harm if certs already validate cleanly, saves the workflow from
breaking again if the hosts entry ever gets blown away (system reset,
container migration, etc).
iOS:
- Build itself succeeds (Runner.app sits in build/ios/iphonesimulator/).
- actions/upload-artifact's Node.js HTTP client hits git.such.software
via LAN (NAT hairpin), bypassing the public NPM/Let's Encrypt cert
and landing on Gitea's internal self-signed cert. Node refuses with
DEPTH_ZERO_SELF_SIGNED_CERT.
- Setting NODE_TLS_REJECT_UNAUTHORIZED=0 at job env disables verification
for all Node-based actions in the job. Acceptable here because we're
talking to our own server on our own LAN — no external MITM surface.
- Long-term cleaner fix: install Gitea's CA cert into the runner's
system trust store, or have the runner reach Gitea via the public
hostname so NPM's Let's Encrypt cert is presented.
Android AAB:
- APK built + signed + uploaded fine (~14 min). AAB build then failed
at FinalizeBundleTask$BundleToolRunnable / :app:signReleaseBundle
with no visible error.
- Added --verbose to 'flutter build appbundle' so the next run prints
the actual gradle stacktrace. Once we see WHY signReleaseBundle is
failing, we can target the real fix.
Build was failing with:
component download failed for rust-std-aarch64-apple-ios-sim:
could not rename downloaded file from '.../9362b66...partial' to
'.../9362b66...': No such file or directory
One of the iOS pods (likely reown_walletkit's yttrium FFI or similar)
invokes rustup mid-build to fetch iOS targets. When the pod build runs
multiple targets in parallel, multiple rustup processes race on the
same .partial download file — one finishes/renames, the next looks
for the .partial that's no longer there.
Fix: add a workflow step that runs before pod install + flutter build:
- Install rustup if missing (idempotent — self-hosted runner persists).
- Wipe any stale *.partial files (debris from previous racing).
- rustup target add the three iOS triples serially.
That way the pod's mid-build rustup invocation finds everything already
installed and just no-ops.
Two fixes that together address the 'There is no XCFramework found at...'
build failure:
1) ios/Runner.xcodeproj/project.pbxproj: remove 10 lines referencing
ZanoWallet.xcframework + WarpApiFFI.xcframework (zcash). Those were
stale — both chains were removed in commit 4eb7db0b7 weeks ago, but
the Xcode project still listed them in BuildFile, CopyFiles, FileReference,
and Group sections. xcode error referenced them as missing.
2) Both iOS workflows now run scripts/ios/gen_framework.sh after staging
the monero_c bundle. The script reads
aarch64-apple-ios/lib<wallet>_wallet2_api_c.dylib and
aarch64-apple-ios-simulator/lib<wallet>_wallet2_api_c.dylib from the
bundle, wraps each as a .framework with an Info.plist, then bundles
device + simulator into ios/MoneroWallet.xcframework +
ios/WowneroWallet.xcframework via xcodebuild -create-xcframework.
These are exactly the paths project.pbxproj's CopyFiles phase
references.
The 'Inspect iOS targets' debug step was expanded to print bundle
subdirs + sample target contents, so if the monero_c bundle doesn't
actually ship those exact dirs we'll see it in the log.
Empty action-row buttons (Send/Receive/Swap/Scan) and empty bottom
navbar tabs are the same root cause on Linux + Android (+ likely iOS):
the workflows weren't running Cake's compile_graphics.sh, which is
what converts res/pictures/*.svg sources → assets/new-ui/*.svg.vec
precompiled vector assets that CakeImageWidget loads via
AssetBytesLoader.
History: commit 89e07fbba (Cake upstream, March 2026) moved to
precompiled SVGs, added compile_graphics.sh, and added a 'Compile
graphics' workflow step. Then 980c0278b added \*.svg.vec to .gitignore
(so the artifacts are no longer tracked). End result: CI MUST run
compile_graphics.sh to produce the .vec files, or every CakeImageWidget
silently renders nothing.
Fix:
- Add vector_graphics_compiler: ^1.1.16 to dev_dependencies (the script
invokes 'dart run vector_graphics_compiler ...' which needs the
package in the project's deps for 'dart run' to find it).
- Add a 'Compile SVG assets' step to all four workflows, between
generate_localization and the build/pod-install step.
This will populate assets/new-ui/ with ~82 .svg.vec files at build
time, so every CakeImageWidget reference (action row, navbar, top bar,
settings rows, etc.) resolves to its actual icon.
pod install fails with Encoding::CompatibilityError 'Unicode
Normalization not appropriate for ASCII-8BIT' when the shell locale
isn't UTF-8. CocoaPods' own warning tells you: 'CocoaPods requires
your terminal to be using UTF-8 encoding'.
Gitea Actions runner on macOS launches subprocesses with LANG unset,
which Ruby treats as ASCII-8BIT. Setting env-level LANG=en_US.UTF-8
and LC_ALL=en_US.UTF-8 fixes it for all steps in the job.
build_bindings.sh in bitbox_flutter unconditionally runs
'gomobile bind -target=android -androidapi 24' which produces an
api.aar — needed only for Android. The Mac runner has no Android SDK,
so gomobile fails with 'could not locate Android SDK'.
iOS doesn't need the .aar. BitBox's iOS support is a separate native
plugin under bitbox_flutter/ios/Classes/ + bitbox_flutter.podspec,
linked via flutter pub get + pod install. We just need the directory
present so the path-dep resolves.
Replace the wrapper invocation in iOS workflows with the clone steps
only; skip build_bindings.sh entirely. Android workflow keeps using
the wrapper as-is.
scripts/build_bitbox_flutter.sh invokes build_bindings.sh which calls
gomobile to generate iOS bindings for the Go BitBox client. Without
Go + gomobile on the Mac runner, that step fails with 'gomobile:
command not found'.
Adds an idempotent step: install Go via brew if missing, then 'go
install golang.org/x/mobile/cmd/{gomobile,gobind}@latest' if missing.
Self-hosted runner persists $GOPATH/bin between runs, so steady-state
is zero-cost after the first install.
Same conditional-install pattern as Flutter + CocoaPods.
Android:
- monero_c prebuilt bundle doesn't ship i686-linux-android (32-bit x86
Android — essentially extinct, sim/emulators use x86_64). Was failing
loud on the missing target. Now: missing target = skip + log; only
the truly-modern ABIs (arm64-v8a, x86_64) are REQUIRED. armeabi-v7a
(32-bit ARM) is shipped if available but not required. The resulting
APK is universal across whichever ABIs got staged.
iOS:
- 'sudo gem install cocoapods' was hitting a password prompt because
the Gitea runner user has no passwordless sudo configured (rightly).
Switched to brew-first install (Homebrew lives in its own prefix,
no sudo needed on Mac). Falls back to 'gem install --user-install'
(no sudo) if brew is somehow unavailable. The whole step is still
no-op if 'pod' is already on PATH.
Avoids any confusion / potential trademark friction with HashWallet
(Spanish hardware-wallet company). Hash Bags is a more distinctive
name, harder to collide with, and we can still rank for 'hash wallet'
search via App Store / Play Store subtitle ('Hash Bags - A Wallet
for your Coins').
What changed (all user-visible strings):
- Launcher labels: android/app.properties, scripts/android/app_env.sh,
scripts/ios/app_env.sh, linux window title (CMakeLists +
my_application.cc)
- In-app text: lib/generated/i18n.dart + ARB sources under res/values/
- Brand docs: README.md, CONTRIBUTING.md, PRIVACY.md,
assets/text/Terms_of_Use.txt, assets/text/Release_Notes.txt
- hash.boats website: index.html, og-image.svg + regen og-image.png,
site.webmanifest, styles.css comment, splash/confirm/pulse/mark/
lockup svg titles, report/index.html, server/server.js
- CI workflow display names ("Hash Bags Linux build", etc.)
What did NOT change (deliberate):
- Bundle ID / Package: com.suchsoftware.hashwallet (immutable app
identity on App Store + Play Store — changing == orphaning the app)
- Binary name: hash_wallet (Linux executable)
- Dart import paths: package:hash_wallet/...
- Git repo: hash-wallet (Such-Software/hash-wallet)
- URL scheme: hashwallet:// (internal deep links)
- support@such.software (no domain change yet)
- App Store / Play Store listing names (whatever was registered there
stays; we updated launcher label only)
- hash.boats domain (still the wallet site)
Also kept the '#ash Wallet' wordplay in the nav but updated to
'#ash Bags' so the # mark still serves as the H. Nav reads:
[# mark] #ash Bags
Website hero tagline now matches the App Store sub-title concept:
'A wallet for your coins. Open-source, non-custodial, multi-chain.
Privacy-leaning by default.'
108 files modified, ~674 string replacements.
iOS workflows were broken on the Mac mini runner because Flutter
wasn't installed. Three fixes:
1) Conditional Flutter setup. Check 'flutter --version' first; only
pull subosito/flutter-action@v2 if missing or wrong version. Self-
hosted Mac runner persists SDKs between runs, so steady-state is
zero-cost. First run on the runner triggers a full SDK download
via subosito (with cache: true so subsequent fresh installs are
still fast).
2) wget → curl across all iOS workflow steps. macOS doesn't ship
wget by default; curl is always present and respects -fsSL +
redirect properly.
3) Concurrency groups on all four workflows. A burst of commits no
longer queues N copies of the same build — newer pushes cancel
in-flight runs on the same branch. Groups:
linux-<ref>, android-<ref>, ios-sim-<ref>, ios-testflight-<ref>
This addresses the '6 runs from one merge' issue: each commit in
the merge triggered all 3 push-listening workflows. Concurrency
cancels the earlier 3 the moment the newer commit's runs start.
4) CocoaPods install is also conditional (was already 'if ! command -v
pod' under the hood; just tightened the step name).
Phase 2 of iOS CI. Full signed pipeline that:
1) Decodes secrets:
- APPLE_DIST_CERT_P12_BASE64 + password → temp keychain
- APPLE_PROVISIONING_PROFILE_BASE64 → ~/Library/MobileDevice/...
- APPLE_API_KEY_P8_BASE64 → ~/.appstoreconnect/private_keys/
2) Parses the .mobileprovision for its UUID + Name (used in ExportOptions).
3) Generates ios/ExportOptions.plist dynamically with the right Team ID +
profile name + 'app-store' method.
4) Runs flutter build ipa --release --export-options-plist=...
5) Uploads the .ipa to TestFlight via xcrun altool with the API key.
6) Always cleans up keychain + temp credentials, even on failure.
Trigger: workflow_dispatch ONLY (manual). TestFlight uploads consume a
build number with every push — we don't want auto-trigger spamming
TestFlight. Bump the build number in scripts/ios/app_env.sh before
each TestFlight push (or wire a workflow_dispatch input later).
All Apple secrets (and the Trocador ones reused from Linux/Android) are
already configured in Gitea Actions.
If signing fails on first run: most likely the profile name extracted
from the .mobileprovision doesn't match what Xcode expects, OR the
distribution cert in the .p12 doesn't match what the profile pins. The
keychain identity sanity-check + ExportOptions.plist echo in the logs
will tell us which.
jwinterm