Packaging and troubleshooting

Use the exact source/native candidate and pinned engine/toolchain. The local distribution includes iOS arm64 GraffityVps.framework and Android arm64-v8a libGraffityVps.so, ABI/dependency manifests and third-party notices. Rebuilding native bindings requires the repository’s pinned private schema inputs; generated internals are not a public API.

Use a C++ host/toolchain for source installation. The sample contains C++ and a compiled Blueprint integration graph. Mac Editor and Shipping, plus local iOS/Android build/package checks, are recorded separately. Windows, physical device support, backend deployment and store approval are not advertised.

Keep raw PLY and caches outside Content; preview components are transient/editor-only. Default shipping manifests must retain runtime modules, authored Actor/root content and platform-native libraries while excluding Editor preview data and credentials. Add the engine provider’s camera permission/usage metadata and the host’s location permission UX. Do not embed signing material or live SDK tokens in config, Blueprint literals or sample assets.

Common recovery: invalid configuration → check token/location/config; unsupported platform/provider → use the selected mobile providers; camera in use → stop the competing SDK session; permission denied → recover in system settings; tracking lost → restore provider and Start explicitly; authentication → replace the host credential; missing/duplicate root → fix the place/section binding; unavailable route → verify graph/POI/path/transition data.

Before an upgrade, save the current candidate ZIP/checksum, project/plugin sources and authored level. Replace the complete plugin/native pair, rebuild the host and run local tests. Roll back by restoring that pair and the prior project revision. Release preparation creates local artifacts only; publishing, tagging, deploying and store uploading require a later instruction.