AssistiveTouch Menu & On-Screen Assist Button App Store Listing in Simplified Chinese — Custom AssistiveTouch Actions, AssistiveTouch Pointer & 辅助触控菜单 zh-Hans Copy

Who this is for

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

• Already ship an app whose US product page markets the AssistiveTouch menu — on-screen assist button overlays, custom AssistiveTouch action pickers, Top Level Menu walkthroughs, AssistiveTouch pointer demos, or Shortcuts users wire under Settings → Accessibility → Touch → AssistiveTouch
• Show AssistiveTouch, AssistiveTouch menu, on-screen AssistiveTouch button, custom AssistiveTouch actions, AssistiveTouch pointer, or 辅助触控 / 辅助触控菜单 / 屏幕辅助按钮 / 自定义辅助触控操作 on en-US screenshot galleries and description paragraphs
• Finished AssistiveTouch menu or custom-action UX in the binary — not looking for AssistiveTouch API integration, custom action handler engineering, or system settings UI reproduction 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 users press external adaptive switches with auto-scanning rather than tap an on-screen AssistiveTouch button, that is a different listing story — see Switch Control listing (zh-Hans). If users speak numbered overlay commands to tap UI elements, see Voice Control listing. If users double-tap the physical back of iPhone, see Back Tap listing. If your lead feature is a simplified Home Screen for cognitive accessibility, see Assistive Access listing. If users lock the device to one app, 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 AssistiveTouch capability covers storefront language. Xcode, entitlements, and Connect actually separate on-screen assist UX in the app from product-page copy:

• AssistiveTouch menu & on-screen assist button — in-app code or system integration that complements the floating assist button, custom action launcher, or AssistiveTouch-friendly layouts. Controls whether buyers get on-screen shortcuts. Does not generate Chinese listing text.
• Custom AssistiveTouch actions & Top Level Menu — Shortcuts or workflows users assign under Settings → Accessibility → Touch → AssistiveTouch → Customize Top Level Menu. Engineering work for action pickers and menu demos. Listing copy should match what screenshots actually show.
• AssistiveTouch pointer & pointer styles — on iPadOS and macOS, AssistiveTouch can show a customizable on-screen pointer with tracking and click options. Separate from Pointer Control tracking speed settings — listing copy should name the correct surface per frame.
• 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 support in the app.

Working AssistiveTouch 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 menu, on-screen assist button, custom action, and pointer workflows on the product page in zh-Hans, not how you implement AssistiveTouch APIs or reproduce Apple system settings UI.

The AssistiveTouch family on one product page — four related surfaces

Apple groups several AssistiveTouch features under one Accessibility setting. Western indie listings often mention one or more on the same US product page. AppLocale covers all four on this single guide — paste-ready zh-Hans copy for whichever your screenshots and description already claim:

• On-screen AssistiveTouch button (屏幕辅助按钮 / 辅助触控) — the floating assist button buyers drag anywhere on screen under Settings → Accessibility → Touch → AssistiveTouch. Gallery frames may show the button overlay, opacity slider, or "Turn on AssistiveTouch" badge.
• AssistiveTouch menu & Top Level Menu (辅助触控菜单) — the circular menu that expands from the assist button with Home, custom actions, device controls, and gesture shortcuts. Screenshot overlays often show Top Level Menu customization grids or menu walkthrough demos.
• Custom AssistiveTouch actions (自定义辅助触控操作) — user-assigned Shortcuts, gestures, or app actions mapped to menu slots under Customize Top Level Menu. Marketing frames may show action picker sheets, custom action grids, or "Add custom action" walkthroughs.
• AssistiveTouch pointer (辅助触控指针) — on iPadOS and macOS, an on-screen pointer with customizable appearance, tracking, and click behavior under AssistiveTouch pointer settings. Gallery frames may show pointer style pickers, tracking speed sliders, or pointer click demos — distinct from Pointer Control accessibility settings when your English listing shows both.

Your gallery may lead with the on-screen assist button on one frame and custom action grids on the next. zh-Hans caption lines should name the correct surface per frame — a Top Level Menu editor is not a Switch Control scanning highlight, not a Voice Control numbered overlay, and not a Back Tap assignment walkthrough unless that is what the screenshot shows.

AssistiveTouch listing copy is not Switch Control, Voice Control, Back Tap, Assistive Access, or Guided Access

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

• AssistiveTouch menu & on-screen assist button (this page) — AssistiveTouch, AssistiveTouch menu, on-screen AssistiveTouch button, custom AssistiveTouch actions, AssistiveTouch pointer, 辅助触控, 辅助触控菜单, 屏幕辅助按钮, and 自定义辅助触控操作 on gallery frames and in description paragraphs.
• Switch Control & external switches (different) — adaptive switches, auto-scanning, switch recipes, 切换控制. See Switch Control listing guide — Switch Control uses external switches and scanning; AssistiveTouch shows a touchable on-screen assist button and menu.
• Voice Control & spoken commands (different) — hands-free UI operation with spoken tap and swipe commands. See Voice Control listing guide — Voice Control uses voice; AssistiveTouch uses on-screen button taps and menu selections.
• Back Tap & physical back trigger (different) — double or triple tap on the physical back of iPhone. See Back Tap listing guide — Back Tap uses the device back; AssistiveTouch shows a floating on-screen button.
• Assistive Access & simplified Home Screen (different) — simplified iOS Home Screen for cognitive accessibility. See Assistive Access listing guide — Assistive Access replaces the entire home screen layout; AssistiveTouch adds a floating assist menu overlay.
• Guided Access & single-app lock (different) — lock the device to one app with a session passcode. See Guided Access listing guide — kiosk lock is not AssistiveTouch menu marketing.
• Pointer Control & Dwell Control (different) — mouse and trackpad tracking speed, pointer size, and dwell-to-click timing under Settings → Accessibility → Pointer Control. See Pointer Control listing guide or Dwell Control listing guide — AssistiveTouch pointer is a separate on-screen assist feature; mention Pointer Control only when your English listing already shows both surfaces.
• VoiceOver & screen reader (different) — VoiceOver support, Works with VoiceOver, screen reader navigation badges. See VoiceOver listing guide — VoiceOver explores and reads the UI; AssistiveTouch provides an on-screen assist button and action menu.
• Accessibility hub multi-feature dump (different) — Settings → Accessibility home grids that list many assistive features as one bullet list. See Accessibility hub listing guide — hub marketing covers several surfaces together; this page covers AssistiveTouch menu and on-screen assist button claims in depth.

Your screenshots may show multiple surfaces in one gallery. Listing copy should name the correct one per frame — a custom AssistiveTouch action grid is not an external switch pairing demo, not a Voice Control numbered overlay, not a Back Tap assignment sheet, and not a Guided Access lock screen unless that is what the frame shows.

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

Apple ships AssistiveTouch in iOS, iPadOS, and macOS Settings → Accessibility → Touch → AssistiveTouch. It shows a floating on-screen assist button, Top Level Menu, custom actions, device controls, gesture shortcuts, and pointer options on supported platforms. Third-party apps may market works-with-AssistiveTouch companions, custom action Shortcuts, AssistiveTouch-friendly layouts, or on-screen assist button integrations your binary actually ships. AppLocale rewrites listing copy from what your US page already claims:

• If your app complements iOS AssistiveTouch — zh-Hans copy can describe works-with-AssistiveTouch badges, custom action companions, or AssistiveTouch menu integrations your binary actually ships without claiming to replace Settings → Accessibility → Touch → AssistiveTouch unless your English listing already states that accurately.
• If your app is a dedicated AssistiveTouch menu companion — description and screenshot overlays should name the on-screen model you ship (辅助触控菜单, 屏幕辅助按钮, 自定义辅助触控操作) in commerce-idiomatic Chinese, not generic "accessibility controls everything" overclaims.
• If your US page shows AssistiveTouch pointer demos — zh-Hans copy should distinguish AssistiveTouch pointer from Pointer Control tracking settings when your screenshots show each — matching what buyers will see after install on iPadOS or macOS.
• If your US page overclaims — AppLocale aligns zh-Hans strings to your English source; we do not invent broader AssistiveTouch scope than your screenshots and description support.

Clear zh-Hans copy helps buyers understand whether your app supports custom AssistiveTouch actions, on-screen assist button workflows, or AssistiveTouch pointer customization — before install. It does not replace AssistiveTouch implementation, custom action 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

AssistiveTouch companion apps often lead marketing screenshots with on-screen assist button demos, Top Level Menu walkthroughs, custom action grids, AssistiveTouch pointer customization, or "Works with AssistiveTouch" badges — surfaces where English marketing text appears beside AssistiveTouch UI:

• Screenshot overlay badges — "AssistiveTouch", "AssistiveTouch menu", "On-screen assist button", "Custom AssistiveTouch actions", "AssistiveTouch pointer", "Top Level Menu", "Works with AssistiveTouch" on gallery frames
• Description paragraphs — English value props about one-tap assist shortcuts, custom menu actions, or on-screen accessibility workflows that China readers skim past
• Subtitle and keywords — English-only rows miss China Search intent for 辅助触控, 辅助触控菜单, 屏幕辅助按钮, or 自定义辅助触控操作 when buyers filter for AssistiveTouch 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 conflates AssistiveTouch with Switch Control or Voice Control on store pages

Better zh-Hans listing copy helps accessibility-conscious and motor-accessibility buyers understand your AssistiveTouch menu story before install. It does not replace AssistiveTouch API work, custom action implementation, or Apple's review decisions — and it does not guarantee AssistiveTouch behavior on every iPhone, iPad, or Mac model.

What AppLocale delivers for AssistiveTouch apps on zh-Hans

This SKU is a listing rewrite scoped to AssistiveTouch menu and on-screen assist button 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 menu value to China searchers
• Subtitle — concise benefit line that can reference 辅助触控菜单 or on-screen assist button without stuffing raw English badge text
• Keywords — zh-Hans search terms buyers use for 辅助触控, 辅助触控菜单, 屏幕辅助按钮, 自定义辅助触控操作, and AssistiveTouch companion apps in your category
• Description — long listing body with clear zh-Hans paragraphs on AssistiveTouch workflows you already ship — without English-only "AssistiveTouch menu" 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 on-screen assist button demos, Top Level Menu editors, custom action grids, AssistiveTouch pointer settings, or menu walkthrough 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, AssistiveTouch menu, custom actions, or on-screen assist button — we deliver counted strings that fit Connect limits. We rewrite what you already claim on the US page; we do not invent AssistiveTouch features your app does not ship.

AssistiveTouch-specific listing vocabulary — what translates differently

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

AssistiveTouch menu vs on-screen assist button

US pages use "AssistiveTouch menu", "on-screen assist button", or "Top Level Menu." China storefront copy often uses 辅助触控 for Apple's Accessibility feature name, 辅助触控菜单 for the expandable action menu, or 屏幕辅助按钮 for the floating assist button itself — depending on whether you mean the button overlay, the menu contents, or custom action assignment. AppLocale aligns phrasing with your actual AssistiveTouch scope.

Custom AssistiveTouch actions vs Back Tap triggers

Screenshot galleries often label custom action grids under Settings → Accessibility → Touch → AssistiveTouch → Customize Top Level Menu — 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 AssistiveTouch menu actions.

AssistiveTouch pointer vs Pointer Control

On iPadOS and macOS, AssistiveTouch can show a customizable on-screen pointer with its own appearance and click settings — separate from Pointer Control tracking speed and pointer size under Settings → Accessibility → Pointer Control. zh-Hans copy should use 辅助触控指针 when that is your actual claim — not confuse it with 指针控制 (Pointer Control) unless your screenshots show both surfaces.

AssistiveTouch vs Switch Control vs Voice Control

US pages may mention multiple accessibility features. 辅助触控 (AssistiveTouch) covers on-screen assist button and menu workflows. 切换控制 (Switch Control) covers external switch input and scanning. 声音控制 (Voice Control) covers spoken UI commands. AppLocale keeps each surface distinct per screenshot frame — an AssistiveTouch menu demo is not switch-access marketing unless that is what the frame shows.

Subtitle and keyword packing

The 30-character subtitle and 100-character keyword field need AssistiveTouch search terms Chinese buyers type — see Simplified Chinese keywords & subtitle for field mechanics. Terms like 辅助触控, 辅助触控菜单, and 屏幕辅助按钮 each signal different intent from Switch Control, Voice Control, or Back Tap keywords.

Caption lines vs burned-in badges

Marketing screenshot overlays you control — "AssistiveTouch menu" 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.

Promotional text refreshes

AssistiveTouch feature launches and custom action library updates often land in the 170-character promotional text field above the description — updatable without a new binary. See Promotional text in Simplified Chinese when your AssistiveTouch pitch lives in promo text rather than the long description.

What good zh-Hans AssistiveTouch listing copy looks like

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

• Subtitle (example) — 自定义辅助触控菜单，屏幕一键操作 — AssistiveTouch menu benefit within the ~30-character cap
• Keywords (example) — 辅助触控,辅助触控菜单,屏幕辅助按钮,自定义操作 — only when accurate to your feature set
• Screenshot overlay (example) — 屏幕辅助按钮，自定义快捷菜单 — on-screen assist button frame with clear menu benefit line
• Description paragraph (example) — plain zh-Hans list of AssistiveTouch workflows you ship — Top Level Menu customization, custom action grids, AssistiveTouch pointer options, 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 AssistiveTouch 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 "AssistiveTouch menu" → 辅助触摸菜单 (wrong character) instead of buyer-friendly 辅助触控菜单
• English badge headlines preserved on zh-Hans screenshots — "Custom AssistiveTouch actions" 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 切换控制 — AssistiveTouch shows an on-screen assist button and menu; Switch Control uses external switches and scanning — different buyer intent and keywords
• Conflating 辅助触控菜单 with 声音控制 — AssistiveTouch uses on-screen button taps; Voice Control speaks numbered overlay commands — opposite input method
• Conflating 屏幕辅助按钮 with Back Tap 轻点背面 — AssistiveTouch shows a floating on-screen button; Back Tap uses physical back-of-phone taps — different screenshot vocabulary
• Conflating 辅助触控指针 with Pointer Control 指针控制 — AssistiveTouch pointer is an on-screen assist feature; Pointer Control tunes mouse and trackpad tracking — different settings path
• Inconsistent vocabulary between listing description, promotional text, and screenshot captions when all three mention AssistiveTouch menu or custom actions

Machine translation is fine for internal drafts. Finished AssistiveTouch strings need idiomatic zh-Hans that states what menu and on-screen assist 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", "AssistiveTouch menu", "On-screen assist button", "Custom AssistiveTouch actions", "AssistiveTouch pointer", "Top Level Menu", "Works with AssistiveTouch", menu walkthrough captions)
• Brief note on which AssistiveTouch workflows your app supports today — works with AssistiveTouch, custom action companion, on-screen assist button layout, AssistiveTouch pointer integration — so zh-Hans copy stays accurate
• Target locales (e.g. zh-Hans for China storefront)
• Your deadline if aligning with an AssistiveTouch 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 menu and on-screen assist button 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 AssistiveTouch menu reliability or custom action execution improves — listing rewrite describes what you already ship
• No AssistiveTouch API, custom action handler, AssistiveTouch pointer overlay, or system settings UI 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, or Connect configuration on your behalf
• No screenshot design, PNG re-export, Apple Search Ads, or review-reply retainers
• Not QuantRadar · not investment advice · not legal review

AppLocale FAQ

Does AppLocale implement AssistiveTouch APIs or custom action handlers?

No. We deliver Connect listing metadata copy only — name, subtitle, keywords, description, promotional text when included, and screenshot caption lines. AssistiveTouch API integration, custom action handler engineering, AssistiveTouch pointer overlay implementation, and system settings UI reproduction are outside scope.

How is AssistiveTouch listing copy different from Switch Control or Voice Control?

AssistiveTouch listing copy covers the on-screen assist button, AssistiveTouch menu, custom AssistiveTouch actions, and AssistiveTouch pointer under Settings → Accessibility → Touch → AssistiveTouch. Switch Control covers external switch input and scanning. Voice Control covers hands-free UI operation with spoken commands. Those are different buyer stories with different screenshot vocabulary.

How is this different from Back Tap, Assistive Access, Guided Access, or Pointer Control?

Back Tap covers double or triple tap on the physical back of iPhone. Assistive Access covers simplified Home Screen mode. Guided Access covers single-app lock and kiosk mode. Pointer Control covers mouse and trackpad tracking settings. AssistiveTouch covers the on-screen assist button and action menu — a different buyer story on each surface.

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, AssistiveTouch menu, custom actions, or on-screen assist button (with frame order noted), which AssistiveTouch workflows your app ships, 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 AssistiveTouch menu behavior?

No. AssistiveTouch menu logic, custom action assignments, pointer styles, and on-screen button positioning come from your binary and the operating system — not Connect listing fields. AppLocale covers product-page marketing copy only; we do not configure AssistiveTouch on the buyer's device.

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 AssistiveTouch menu and on-screen assist button 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 AssistiveTouch or custom action engineering, not Switch Control or Voice Control listing copy, not Back Tap or Guided Access listing copy, not Assistive Access or Pointer Control listing copy, not VoiceOver or Accessibility hub listing copy, 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 menu & on-screen assist button 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