AssistiveTouch & Virtual Home Button App Store Listing in Simplified Chinese — Floating Assistive Menu & 辅助触控 zh-Hans Copy

Who this is for

Western indie iOS developers — US, UK, EU, Canada, Australia — who:

• Already ship an app whose US product page markets an on-screen AssistiveTouch companion — a floating home button overlay, custom AssistiveTouch action, floating assistive menu, or Shortcut users wire under Settings → Accessibility → Touch → AssistiveTouch
• Show Virtual Home Button, floating assistive menu, custom AssistiveTouch actions, or Works with AssistiveTouch on en-US screenshot galleries and description paragraphs
• Finished floating-menu or AssistiveTouch-compatible UX in the binary — not looking for UIAccessibility, AssistiveTouch overlay detection, private API, or custom accessibility container engineering help here
• Enabled the China App Store but the zh-Hans row is empty, machine-translated, or still English on AssistiveTouch-themed gallery frames
• Need paste-ready Connect text — not an engineer for Accessibility APIs, not a designer to re-export every screenshot from scratch

If your lead feature is a Back Tap trigger on the physical back of iPhone — not an on-screen floating menu — see Back Tap listing (zh-Hans). If you market VoiceOver screen reader support — not AssistiveTouch menus — see VoiceOver listing. If you sell Guided Access single-app lock — not floating assistive shortcuts — see Guided Access listing. If the entire China page is still English on every field, start with China App Store still shows English or the AppLocale product page.

AssistiveTouch engineering vs zh-Hans listing copy — two different jobs

Teams assume floating-menu capability covers storefront language. Xcode, entitlements, and Connect actually separate on-screen assistive UX in the app from product-page copy:

• AssistiveTouch menu & floating-button logic — in-app code or system integration that shows a floating overlay, custom action grid, or virtual home button companion. Controls whether buyers get on-screen shortcuts. Does not generate Chinese listing text.
• UIAccessibility & custom accessibility containers — system Accessibility plumbing and overlay APIs. Listing copy should explain what buyers configure in Settings — not promise private AssistiveTouch detection your binary does not ship.
• Custom AssistiveTouch action assignment — Shortcuts or workflows users map under Settings → Accessibility → Touch → AssistiveTouch. Engineering work for action pickers and menu demos. Listing copy should match what screenshots actually show.
• Pricing and Availability → China — makes the app downloadable on the China App Store. Separate from language rows.
• App Store tab → Chinese (Simplified) localization — independent row for title, subtitle, keywords, description, promotional text, screenshots, and caption lines. Empty or English here means China buyers see English fallback regardless of AssistiveTouch features in the binary.

Working floating-menu flows in the binary and a localized China listing are both required when you sell on the China storefront — neither replaces the other. AppLocale covers how you describe AssistiveTouch, virtual home button, and custom AssistiveTouch action workflows on the product page in zh-Hans, not how you implement UIAccessibility APIs or overlay detection.

AssistiveTouch listing copy is not Back Tap, VoiceOver, Guided Access, or Control Center

Accessibility marketing apps blur several surfaces indie teams conflate. AppLocale covers listing metadata only — on-screen AssistiveTouch menu marketing on the product page:

• AssistiveTouch & floating assistive menu (this page) — the on-screen assistive menu, floating home button, virtual home button overlay, and custom AssistiveTouch actions under Settings → Accessibility → Touch → AssistiveTouch. Gallery frames often show floating-button demos, custom action grids, or menu walkthrough badges.
• Back Tap & Double Tap Back (different) — double or triple tap on the physical back of iPhone mapped to a Shortcut under Settings → Accessibility → Touch → Back Tap. See Back Tap listing guide — not 辅助触控 floating-menu copy.
• VoiceOver & screen reader (different) — VoiceOver support, Works with VoiceOver, screen reader accessibility badges. See VoiceOver listing guide — not floating home button marketing.
• Guided Access & single-app lock (different) — lock the device to one app with a session passcode. See Guided Access listing guide — not AssistiveTouch menu overlays.
• Custom keyboard & third-party IME (different) — a keyboard extension under Settings → General → Keyboard → Keyboards. Not AssistiveTouch floating-menu copy.
• Control Center (different) — the system tray, custom controls, and toggle tiles as a whole. AssistiveTouch may include a Control Center action, but that is one menu item — not Control Center toggle marketing as the lead. See Control Center listing guide — not virtual home button copy.

Your screenshots may show a floating AssistiveTouch menu beside a custom action grid. Listing copy should name the correct claim per frame — a virtual home button badge is not a Back Tap assignment walkthrough, not a VoiceOver accessibility overlay, not a Guided Access lock screen, and not a Control Center tray overview unless that is what the frame shows.

Apple system AssistiveTouch vs your app's floating-menu marketing — listing honesty

Apple ships AssistiveTouch in iOS Settings → Accessibility → Touch. It shows a floating on-screen menu with Home, custom actions, device controls, and gesture shortcuts. Third-party apps often market "works with AssistiveTouch", virtual home button, floating shortcut launcher, or custom AssistiveTouch action companions. AppLocale rewrites listing copy from what your US page already claims:

• If your app complements iOS AssistiveTouch — zh-Hans copy can describe custom actions or floating shortcut workflows your binary actually supports without claiming to replace Settings → Accessibility → Touch → AssistiveTouch unless your English listing already states that accurately.
• If your app is a dedicated floating-menu or virtual home button product — description and screenshot overlays should name the on-screen model you ship (辅助触控, 助手触控, 虚拟主屏幕按钮, 浮动辅助菜单) in commerce-idiomatic Chinese, not generic "accessibility SDK" overclaims.
• If your US page mentions custom AssistiveTouch actions — AppLocale aligns zh-Hans strings to your English source; we do not invent overlay detection or private API parity beyond what your screenshots and description support.
• If your US page overclaims — AppLocale aligns zh-Hans strings to your English source; we do not broaden floating-menu scope beyond what your listing already claims.

Clear zh-Hans copy helps buyers understand whether your app adds custom AssistiveTouch actions or a floating shortcut launcher before install. It does not replace UIAccessibility implementation, overlay engineering, or Apple's review decisions — and it does not certify AssistiveTouch compatibility on every device model.

What China buyers see when zh-Hans AssistiveTouch copy is missing

Floating-menu and accessibility companion apps often lead marketing screenshots with AssistiveTouch walkthroughs, virtual home button demos, custom action grids, or "Works with AssistiveTouch" badges — surfaces where English marketing text appears beside on-screen menu UI:

• Screenshot overlay badges — "AssistiveTouch", "Assistive Touch", "Virtual Home Button", "Floating assistive menu", "Custom AssistiveTouch actions", "Works with AssistiveTouch" on gallery frames
• Description paragraphs — English value props about one-tap shortcuts, floating home button access, or accessibility workflows that China readers skim past
• Subtitle and keywords — English-only rows miss China Search intent for 辅助触控, 助手触控, 虚拟主屏幕按钮, or 浮动辅助菜单 when buyers filter for floating-menu apps
• Promotional text — 170-character field still pitching AssistiveTouch menus in English above the description
• Mixed page — Chinese description pasted once but AssistiveTouch screenshot captions and subtitle still English — reads unfinished next to localized competitors
• Formal machine translation — stiff 翻译腔 for AssistiveTouch terms (辅助触控 vs 助手触控 vs 虚拟主屏幕按钮) and wrong phrasing that does not match how Chinese buyers describe floating assistive menus on store pages

Better zh-Hans listing copy helps accessibility-conscious and power-user buyers understand your floating-menu story before install. It does not replace UIAccessibility APIs, overlay engineering, or Apple's review decisions — and it does not guarantee AssistiveTouch behavior on every iPhone model.

What AppLocale delivers for AssistiveTouch apps on zh-Hans

This SKU is a listing rewrite scoped to AssistiveTouch and floating-menu marketing — paste-ready fields you copy into App Store Connect:

• Name (title) — zh-Hans app name within Connect character limits when your English title does not signal AssistiveTouch or virtual home button value to China searchers
• Subtitle — concise benefit line that can reference 辅助触控 or floating assistive menu without stuffing raw English badge text
• Keywords — zh-Hans search terms buyers use for 辅助触控, 助手触控, 虚拟主屏幕按钮, and floating shortcut apps in your category
• Description — long listing body with clear zh-Hans paragraphs on AssistiveTouch workflows you already ship — without English-only "Virtual Home Button" jargon
• Promotional text — when you include the 170-character promo field in scope
• Screenshot overlay / caption lines — short zh-Hans text on gallery images that show floating-button demos, custom action grids, menu walkthroughs, or virtual home button badges
• English alignment — matching en-US field notes when both storefronts must stay consistent on AssistiveTouch promises

We map deliverables to the fields you actually use. Send every English overlay line and description paragraph that mentions AssistiveTouch, virtual home button, or floating assistive menu — we deliver counted strings that fit Connect limits. We rewrite what you already claim on the US page; we do not invent overlay detection or private API capabilities your app does not ship.

AssistiveTouch-specific listing vocabulary — what translates differently

Floating-menu marketing on App Store pages uses vocabulary general utility guides rarely cover. zh-Hans copy should reflect how Chinese buyers describe on-screen assistive shortcuts — not a literal paste of US marketing:

AssistiveTouch vs generic floating button

US pages use "AssistiveTouch", "Assistive Touch", "Virtual Home Button", or "Floating assistive menu." China storefront copy often uses 辅助触控 when referencing Apple's Accessibility feature, 助手触控 as an alternate commerce phrasing, or 虚拟主屏幕按钮 for virtual home button overlays — depending on whether you mean system AssistiveTouch compatibility, in-app floating shortcuts, or a dedicated virtual home button product. AppLocale aligns phrasing with your actual menu scope.

Custom AssistiveTouch actions vs Back Tap triggers

Screenshot galleries often label custom action grids under Settings → Accessibility → Touch → AssistiveTouch — distinct from Back Tap assignment under the same Touch menu. Match the trigger model your English listing and screenshots actually show; do not lead with 轻点背面 vocabulary when your US page markets floating menus.

Virtual home button vs physical Home button

Face ID iPhones removed the physical Home button, so "Virtual Home Button" marketing resonates with buyers who want on-screen Home access. zh-Hans copy should use 虚拟主屏幕按钮 when that is your actual claim — not confuse it with AssistiveTouch's full action menu or Guided Access session lock.

Subtitle and keyword packing

The 30-character subtitle and 100-character keyword field need floating-menu search terms Chinese buyers type — see Simplified Chinese keywords & subtitle for field mechanics. Terms like 辅助触控, 助手触控, and 虚拟主屏幕按钮 each signal different intent from Back Tap or VoiceOver keywords.

Caption lines vs burned-in badges

Marketing screenshot overlays you control — "Virtual Home Button" headlines on gallery frames — are separate caption fields or burned-in PNG text. See Screenshot captions in Simplified Chinese for caption-field mechanics when overlays are editable in Connect.

What good zh-Hans AssistiveTouch listing copy looks like

AssistiveTouch and floating-menu copy appears on screenshot galleries and in description skims. Strong Chinese strings lead with the on-screen shortcut benefit and state scope plainly — paste-ready examples for Connect fields:

• Subtitle (example) — 自定义辅助触控，一键浮动快捷 — custom AssistiveTouch benefit within the ~30-character cap
• Keywords (example) — 辅助触控,助手触控,虚拟主屏幕按钮,浮动菜单 — only when accurate to your feature set
• Screenshot overlay (example) — 浮动辅助菜单，自定义快捷操作 — floating-menu frame with clear custom-action line
• Description paragraph (example) — plain zh-Hans list of AssistiveTouch workflows you ship — custom action grids, virtual home button companion, works with AssistiveTouch badges — matching what you actually implemented
• Honest scope — do not claim "replaces iOS AssistiveTouch" in Chinese if your app only markets works-with-AssistiveTouch compatibility

zh-Hans and en-US strings can differ in length and structure when the underlying floating-menu story is the same — avoid mirroring English comma-heavy promo lines character-for-character.

Why machine-translated AssistiveTouch copy fails

• Literal "Assistive Touch" → awkward 辅助触摸 as a product subtitle instead of commerce-idiomatic 辅助触控
• Generic "Virtual Home Button" → 虚拟主页按钮 (web homepage sense) instead of 虚拟主屏幕按钮 (iOS Home button sense buyers expect)
• English badge headlines preserved on zh-Hans screenshots — "Floating assistive menu" with no Chinese benefit line beside it
• Overlay text overflow — long English AssistiveTouch captions pasted into short screenshot callout zones truncate on device
• Conflating 辅助触控 with Back Tap 轻点背面 — buyers searching for floating menus may not match back-tap keywords
• Inconsistent vocabulary between listing description, promotional text, and screenshot captions when all three mention AssistiveTouch

Machine translation is fine for internal drafts. Finished AssistiveTouch strings need idiomatic zh-Hans that states what floating-menu workflows you ship — while keeping accurate scope. AppLocale rewrites by hand; we do not deliver raw Google Translate or LLM output as finished copy.

What you send

• Your live App Store listing URL
• Current English listing copy — name, subtitle, keywords, description, promotional text if used
• Screenshot overlay text that mentions AssistiveTouch features ("AssistiveTouch", "Assistive Touch", "Virtual Home Button", "Floating assistive menu", "Custom AssistiveTouch actions", "Works with AssistiveTouch", menu walkthrough captions)
• Brief note on which AssistiveTouch workflows your app supports today — works with AssistiveTouch, custom action companion, virtual home button overlay, floating shortcut launcher — so zh-Hans copy stays accurate
• Target locales (e.g. zh-Hans for China storefront)
• Your deadline if aligning with a floating-menu feature launch or App Store update
• Reply from the email address on your Stripe receipt after checkout

What you get

• Simplified Chinese (zh-Hans) — listing fields and screenshot overlay lines scoped to AssistiveTouch and floating-menu marketing, paste-ready for Connect
• English (en-US) — aligned listing strings when both locales need the same promise in native phrasing
• Character-count notes — which strings fit Connect limits and what to trim
• Paste-ready delivery — formatted copy mapped to each field you sent
• 24-hour turnaround — delivered to the email on your Stripe receipt

What we do not promise

• No guarantee that floating-menu reliability or AssistiveTouch action execution improves — listing rewrite describes what you already ship
• No UIAccessibility, AssistiveTouch overlay detection, private API, custom accessibility container, or floating-button engineering
• No claim that your app replaces Apple Accessibility AssistiveTouch or detects the system overlay via private API unless your English listing already states that accurately — and even then, AppLocale does not certify Accessibility review parity
• No guaranteed App Store ranking, keyword position, download growth, or Accessibility certification outcomes
• No fabricated social proof, review quotes, ratings, or traffic numbers
• No binary localization, in-app string translation, screenshot design, PNG re-export, or Connect configuration on your behalf
• No Apple Search Ads management or review-reply retainers
• Not QuantRadar · not investment advice · not legal review

AppLocale FAQ

Does AppLocale implement AssistiveTouch overlays or UIAccessibility?

No. We deliver Connect listing metadata copy only — name, subtitle, keywords, description, promotional text when included, and screenshot caption lines. UIAccessibility API integration, AssistiveTouch menu overlay engineering, private API detection, custom accessibility container work, and floating-button implementation are outside scope.

How is AssistiveTouch listing copy different from Back Tap, VoiceOver, or Guided Access?

AssistiveTouch listing copy covers the on-screen assistive menu, floating home button, virtual home button, and custom AssistiveTouch actions under Settings → Accessibility → Touch → AssistiveTouch. Back Tap listing copy covers double or triple tap on the physical back of iPhone. VoiceOver listing copy covers screen reader accessibility. Guided Access listing copy covers single-app lock and kiosk mode. Control Center listing copy covers the system tray. Those are separate scopes with different screenshot vocabulary.

Should my zh-Hans listing claim to replace iOS AssistiveTouch in Settings?

Only if your app actually provides that capability and your English listing already states it accurately. AppLocale rewrites from your source claims — we do not invent system-replacement promises, private overlay detection, or certify parity with Apple's Accessibility AssistiveTouch feature.

What do I send after AppLocale payment?

Your live App Store listing URL, current English listing copy, screenshot overlay lines that mention AssistiveTouch or floating-menu features (with frame order noted), which AssistiveTouch workflows your app supports, and target locale (zh-Hans). Reply from the email address on your Stripe receipt — we deliver to that Stripe email within 24 hours.

Does localizing my listing change in-app floating-menu behavior?

No. Floating menu logic, custom action assignments, and overlay positioning come from your binary and iOS — not Connect listing fields. AppLocale covers product-page marketing copy only.

Will zh-Hans AssistiveTouch copy improve China rankings?

We do not guarantee ranking, browse placement, or download lift. Complete zh-Hans metadata helps users who already find your page understand floating assistive menu value in their language — it is not a placement hack.

How much does AppLocale cost?

$79 one-time via Stripe checkout. No subscription. Seller is Fortune Insight, LLC.

What is AppLocale not?

Not UIAccessibility or AssistiveTouch overlay engineering, not Back Tap or VoiceOver listing copy, not Guided Access or Control Center listing copy as the lead, not screenshot design, not binary localization, not Connect configuration, not ranking guarantees, not review-reply retainers, not QuantRadar, and not investment advice. We do not invent reviews, ratings, or traffic numbers.

AppLocale — zh-Hans listing copy for AssistiveTouch & floating assistive menu apps

$79 one-time

Buy on Stripe

Delivered within 24 hours after Stripe payment. After checkout, reply from your Stripe receipt email with your App Store URL and English listing copy.
No ranking guarantees. Sold by Fortune Insight, LLC.

AppLocale product page