How many times a week will people open this entry?
If they silence notifications, does work stop? Is the field network stable?
Order: role → frequency → push and offline → device features → native last. Starting from “we will build an APP” also drags customer membership into a dual listing. Customers who visit a few times a year will not download. See What to do when nobody downloads the APP. Mini program or APP as the main entry. Compare Mini program or APP as the main entry.
Does cross-platform count as “native”?
For the business, listing, push and the device features you need are enough. Flutter, React Native or dual native is an implementation pick, not a kickoff slogan. What belongs in the brief: how many documents cache offline, location accuracy, whether it must run in the background. Full offline discussion is in No network on site—do you need offline. When H5 alone is enough. See Is H5 enough on its own.
The employee side is the easiest place to “look like it needs an APP”
If employees already work in WeCom, a workbench reporting app often gets more use than another store APP. The feature list is in Employee features people will actually use. Cost difference is in Cost and cycle.
A bid that asks for an APP does not mean phase one needs dual store listings
Some RFPs write “own APP” as a qualifier. You can plan a listing, but work should first run in a usable mini program or WeCom so you do not ship a shell to hit a bid date. Listing packets, privacy text and account deletion are extra engineering. Put them in scope. The customer side still does not need a matching download.
Internal distribution is sometimes better than a public store
An employee app can install via enterprise signing or MDM. It does not need a public store. That skips some review and still keeps push and offline. Public stores fit products strangers search for, not internal reporting. Once Bluetooth or continuous location is in the brief, device acceptance includes those devices. Do not substitute a simulator for the floor. Cross-platform covers most work. Only system-level background tasks or deep sensors need a single-platform native patch.
When you write “must be native” into the plan, also write what you will not do: no store-score ops, no splash-animation contest, no second download for customers. If phase one can use enterprise distribution, listing is not a start condition. Store review must not eat the field-trial calendar. DaXi Technology will write why native is unnecessary or required, so dual listing is not the default. To walk this tree against your scenario, go to the mobile service page and say how often it is used and whether you need offline.