Capability Details

Apps & clients

Android, PC client and mini program, integrated with the back-end systems.

01 / Technology decisions

Three trade-offs you cannot avoid

Each has its own cost; here is which side we chose and why.

Native or cross-platform: performance versus reach

Common practiceA separate native codebase for iOS / Android

AlternativeOne cross-platform codebase (Flutter / RN)

Our approachCross-platform first, with native plugins for performance-critical modules

Full native means two codebases and two teams, doubling maintenance cost. Cross-platform performance is sufficient for the vast majority of business scenarios; native is genuinely required only for high-frequency animation, heavy image processing and complex sensor fusion. Build those as native plugins and keep the rest cross-platform.

How to support offline: partial caching or full functionality

Common practiceNo offline mode; internet connection required

AlternativeCache common data so it can be viewed offline

Our approachCore processes fully available offline, synced once connected

Showrooms, workshops and underground workings often have no network. If core processes depend on connectivity, the whole system dies when the device goes offline. So critical flows (exam answering, equipment inspection) must work fully offline: write to a local database first, then sync incrementally by timestamp when connectivity returns.

How to ship updates: app store or self-update

Common practicePublish through app store review

AlternativeCheck for updates in-app and download the installer

Our approachDual distribution: app stores plus internal

App store review timelines are out of your control, and an urgent fix can take days. For internal apps (inspections, assessments), MDM or internal distribution is more practical; only public-facing apps need the store.

02 / Option comparison

One problem, three approaches

There is no optimal solution, only solutions that fit the scenario.

Solution	Development cost	Performance	Offline Capability	Best suited to
Native on both platforms	Highest	Best	Strong	Interaction-heavy, graphics-heavy
Cross-platform (Flutter/RN)	Medium	Good (sufficient for most scenarios)	Strong	Business app
PWA / mini program	Lowest	Medium	Weak (limited by browser)	Lightweight tools, campaign pages

Start the selection with 'is offline a hard requirement?', not with the technology stack.

What we do

Android apps (delivered in several projects)
PC clients and desktop tools
Works offline and supports intranet deployment
Integration with training/assessment systems

Discuss requirements

Delivery format

Deployment modelOn-Premise / Private Cloud / Intranet

Scope of deliverySystem + Documentation + Training

Maintenance supportRemote + on-site

Source Code DeliveryNegotiable

Related Cases

Proven systems

Client names are anonymized per confidentiality requirements.

Port / Agent + Consortium Chain + App

Large Container Port · Smart Safety Training Centre

Background: A container port ranked among the top in China by annual throughput. Its existing training was mostly classroom lectures and could not cover hands-on practice for high-risk operations.
Solution: Comprehensive safety training centre + training and assessment platform + mobile learning. 7 assessment systems, 9 software modules, a 3-node consortium chain.
Technology: FISCO BCOS consortium chain (PBFT) · transcripts anchored on-chain via SHA-256 · node.js back end · Android client · 3D model interaction
Outcomes: Training records verifiable on chain and tamper-proof transcripts; covers 55 equipment categories and 66 equipment ledger entries.

Overseas / Digital Exhibits

Museum in a Central Asian Country · Digital Exhibition

Background: A national museum in Central Asia needing digital exhibitions and multilingual guides.
Solution: Digital exhibition system + multilingual guide + 3D display + interactive installations.
Technology: 3D modelling and display · multilingual content · touch guide · large-screen sync
Outcomes: Multilingual digital exhibition delivery with 3D content that runs smoothly on ordinary devices.

View all case studies

03 / Implementation path

How many steps from zero to launch

The order cannot be reversed: starting with write operations or multi-step orchestration makes errors very hard to trace.

Confirm the offline boundary

Which functions must work offline? That is the first architectural decision — more important than choosing a framework.

Define the data sync strategy

How does the local database reconcile with the server: incremental by timestamp or replay by operation log? How are conflicts resolved? This decides whether data corruption appears later.

Build the skeleton

Get navigation, sign-in, permissions and local storage working first; add business features afterwards.

Cover the core flows

Take the single most critical process (inspection or assessment, say) and complete it fully, including offline mode and sync. Once that process works, the others are a copy job.

Packaging & distribution

For internal distribution use MDM or hand out the installer directly; the public version goes through the app stores. Also build in a forced-upgrade mechanism, or old versions will linger forever.

04 / Key metrics

Verifiable Numbers

No adjectives; write the specifications.

Offline CoverageCore processes 100%　Non-core processes can degrade gracefully

Sync strategyIncremental + timestamp　Conflicts resolved server-first or by human intervention

Supported platformsAndroid / iOS / mini program　Trim as needed

Installer size20–60 MB　Depends on whether the model and resources are included

05 / FAQ

What technical leads ask most often

These are questions we have actually been asked, answered without marketing spin.

Can we build only a mini program and skip the app?

If you do not need offline operation or hardware access, a mini program is enough and cheaper. But any requirement involving offline use or barcode scanners, serial ports or Bluetooth forces a native app.

Will cross-platform be too slow?

A business app is usually enough. What really strains performance is high-frequency animation and image processing; that is solved with native plugins, without rewriting the whole app natively.

Will offline data be lost?

It will, if sync is done badly. Our approach: local writes are committed to the local database first and flagged as unsynced, then uploaded one by one from a queue once the network returns; failures are kept and surfaced to the user rather than silently dropped.

Will adding features later require a new release?

Yes. That is the inherent cost of a native app. So the architecture must leave room for configuration-driven behaviour — anything that can change should live in configuration or on the server, not be hard-coded in the client.

How do you handle Android fragmentation?

Set a minimum supported version and force upgrades below it; at the same time avoid APIs that are too new. This has to be decided at project kick-off — changing it mid-way is expensive.