Define an interface using secure storage as a reference
Inspect the UTS interface and platform implementations of ak-secure-storage. It provides availability, set, get, remove, and clearNamespace. Callers handle stable outcomes without manipulating Keychain or Keystore native objects.
For your module, define inputs, results, and failure types first. Missing storage values must differ from underlying read or write failures. Unsupported devices need an explicit result; silently writing credentials to ordinary storage would alter the security conditions. Limit the module to an independently callable capability, leaving account screens and project business logic in the application.
Check archive paths and dependencies
Review the version, minimum tools, platform limits, and dependencies in the catalog before downloading. Archives retain repository paths, with the actual module under apps/ak-mobile/uni_modules/<module-name>. The outer archive folder is not the folder to copy into uni_modules.
The push package also contains ak-permissions. Compare same-named files already present in the target project and preserve its business patches. Record the public commit and adopted version so a later upgrade has an identifiable baseline.
The private official repository uses this existing script to prepare its four catalog archives:
bash -n scripts/official/package-plugins.sh
scripts/official/package-plugins.sh
The script archives a fixed public commit into apps/ak-web/public/plugins, retaining licenses and declared dependencies. It is an official-catalog packaging step. Local source edits do not change the pinned commit, and it does not publish arbitrary third-party packages. Catalog users do not need this private-repository script to adopt a module.
Provide a repeatable example
A storage example should save, read, delete, and read after deletion, distinguishing absence from failure. Use temporary test values without real passwords or tokens. Repeat the sequence to check that leftover state cannot make a later run appear successful.
Other modules need failures appropriate to their behavior. The interface must remain usable after push permission denial. OAuth cancellation must end loading. CAPTCHA expiry must clear the answer and obtain a new challenge. When a provider is involved, document account and setup steps while retaining credentials in controlled environments.
Separate tested behavior from work waiting on a real channel or device. A simulated authorization result can exercise a page branch, but cannot establish correct provider callbacks, signing, or domain association.
Record compatibility at the device and tool level
| Item | Record |
|---|---|
| Build tools | HBuilderX/compiler versions and actual command |
| Platform | Separate Android, iOS, and HarmonyOS outcomes |
| Environment | System version, signing, simulator or physical device |
| Normal behavior | Inputs, observable result, and state after repeated calls |
| Failure behavior | Denial, cancellation, expiry, offline state, or missing resources |
| Data handling | Credential location, sanitized logs, and logout cleanup |
Use labels such as build passed, simulator tested, device tested, or unverified, with the corresponding environment. One successful device does not cover other targets. Secure storage also needs checks for unlock conditions, value limits, and deletion behavior.
Release and handover
Include source, licenses, dependencies, README, an example, and a changelog. Interface changes need caller migration instructions. New permissions need request timing and denial behavior. List dropped platforms directly in the version notes.
Follow the README once in a clean example project, then ask a developer unfamiliar with the implementation to do the same. Missing directories, configuration, and commands identify documentation gaps. Publish a traceable version in your own repository and discuss reusable changes through the public contribution process.
Source references: uni_modules and the secure-storage README. These mobile modules follow the application build process. Backend runtime plugins have separate interfaces and deployment rules; this ZIP integration process does not replace them.