Give iPhone users a native path that solves both context handoff and composer insertion after the simpler mobile web and Android learning paths are understood.
Product requirements
iOS keyboard + Share Extension requirements
iOS keyboard plus Share Extension requirements should treat the surfaces as a paired system: Share Extension captures or hands off source-post context, while the keyboard or copy fallback inserts a selected draft. The iOS requirements should follow mobile web validation, minimize shared storage, explain native roadmap status, and keep final posting manual.
Last updated: July 11, 2026. This page is written for PRD-intent SEO and AI citation.
Product goal
What should this requirement set accomplish?
Functional requirements
What must the product do?
Share Extension context handoff
Users can send visible source-post context into TypeToSell from a supported iOS share flow.
Keyboard insertion
Users can insert selected draft text into the composer when the keyboard path is appropriate.
Copy fallback
Users can copy selected drafts when native insertion or handoff is limited.
Shared state boundaries
Only non-sensitive client state should be shared across iOS surfaces when needed.
Acceptance criteria
What must be true before this is ready?
Criterion 1
iOS demand exists
iPhone mobile web users generate, copy, and request native support before iOS work starts.
Criterion 2
Context is visible
Users can understand what source context is being sent into the generator.
Criterion 3
Insertion remains selected
Draft text is inserted only after the user chooses a specific draft to place in the composer.
Criterion 4
Manual posting is explicit
The iOS path tells users they still review, edit, and publish manually.
Non-functional requirements
What quality bars must hold?
Privacy minimization
Avoid storing raw social posts, private messages, generated replies, and billing data in shared local storage.
Native complexity control
The first iOS scope should not attempt to solve every app, browser, and composer workflow at once.
Roadmap clarity
Public pages should say whether iOS surfaces are planned, in beta, or shipped.
Cross-surface consistency
Account, quota, billing, and safety copy should match the rest of TypeToSell.
Out of scope
What should not be built or claimed?
Keyboard-only iOS plan
A keyboard alone may not solve source-post context handoff.
Share-only iOS plan
A Share Extension alone may not solve composer insertion.
Hidden publishing
No iOS surface should publish a social reply without the user's final action.
Related reading
Continue from requirements to execution
iOS keyboard Share Extension checklist/checklists/ios-keyboard-share-extension-checklistShare Extension vs keyboard matrix/matrices/share-extension-vs-keyboard-context-matrixiOS keyboard Share Extension roadmap/roadmaps/ios-keyboard-share-extension-roadmapiOS keyboard vs Share Extension guide/guides/ios-keyboard-vs-share-extension-guide
FAQ
Requirement questions
Why pair iOS keyboard and Share Extension?
The Share Extension helps move context into TypeToSell, while the keyboard helps place selected draft text back into the composer.
Should iOS native work come first?
Usually no. Mobile web should validate iPhone demand before native complexity.
Can iOS native surfaces auto-post?
No. They should preserve selected draft insertion, editing, and manual final posting.