Fix iOS device/simulator cache-key collision in build hook

[HamzaZahid29]

When I archived my Flutter app and tried to upload it to App Store Connect, it kept getting rejected with two errors:
"The binary is invalid... this binary does not seem to have been built with Apple's linker" (code 90125)
"references an unsupported platform in the arm64 slice... Simulator platforms aren't permitted" (code 91169)

i created this script that checks for
#!/bin/bash
set -e
IPA=$(ls build/ios/ipa/*.ipa | head -1)
TMPDIR=$(mktemp -d)
unzip -q "$IPA" -d "$TMPDIR"
BINARY="$TMPDIR/Payload/Runner.app/Frameworks/fllama.framework/fllama"
PLATFORM=$(xcrun vtool -show-build "$BINARY" | grep platform | awk '{print $2}')
rm -rf "$TMPDIR"
if [ "$PLATFORM" != "IOS" ]; then
echo "fllama binary is tagged $PLATFORM, not IOS — do not upload!"
exit 1
fi
echo "fllama binary correctly tagged for device (IOS)"
After digging into it, I found that the fllama binary in my final IPA was actually built for the iOS Simulator, not for a real device — even though I ran flutter build ipa specifically for release/device.

I traced it to hook/build.dart. fllama caches its compiled library on disk under ~/.cache/fllama//, and the cache key is based on os + arch. The problem is that on Apple Silicon Macs, iOS Simulator and real iOS devices both report os = ios and arch = arm64 — the Simulator runs arm64 natively now, so there's nothing in the key that tells them apart.I traced it to hook/build.dart. fllama caches its compiled library on disk under ~/.cache/fllama//, and the cache key is based on os + arch. The problem is that on Apple Silicon Macs, iOS Simulator and real iOS devices both report os = ios and arch = arm64 — the Simulator runs arm64 natively now, so there's nothing in the key that tells them apart.

I added the iOS SDK type (iphoneos vs iphonesimulator) into the cache key, so Simulator and device builds get separate cache entries and can never overwrite each other. I also bumped the cache schema version so anyone upgrading gets a clean cache automatically, instead of needing to manually clear it themselves.

I don't know much about this library so i would recommend going through my implementation.