Score 5
iPhone mobile web proof
iPhone users should repeatedly use mobile web before native iOS scope starts.
Benchmark scorecard
iOS keyboard + Share Extension readiness benchmark
The iOS keyboard plus Share Extension readiness benchmark should pass only when iPhone demand is proven and the team can support both context handoff and selected draft placement. A keyboard alone helps insertion; a Share Extension helps source context. The benchmark should require storage minimization, copy fallback, shared entitlement, and manual final posting.
Last updated: July 11, 2026. These are planning benchmarks, not customer outcome claims.
Benchmark method
How this scorecard should be read
This benchmark scores iOS native readiness across iPhone mobile web proof, source-context handoff, selected placement, App Group storage safety, copy fallback reliability, and roadmap honesty.
Benchmark scores
Scorecard
Score 5
Share context handoff
Share Extension should pass enough visible source context for useful drafts.
Score 4
Keyboard placement
Keyboard insertion or copy fallback should place only the selected draft, leaving review and final posting to the user.
Score 5
Storage minimization
Raw posts, generated replies, private messages, and profile URLs should not persist in shared storage.
Score 5
Manual approval safety
The user edits the selected draft and posts manually in the destination app rather than delegating publishing to TypeToSell.
Evidence to collect
What data should prove readiness?
iPhone repeat sessions
Measure iPhone mobile web generation and copied-draft behavior.
Context-handoff failures
Track cases where source post context is missing or too thin.
Placement fallback usage
Measure selected copy fallback before assuming keyboard insertion is required.
Storage review
Audit whether shared state avoids sensitive social content and keeps raw posts out of persistent storage.
Interpretation rules
How should the benchmark guide the roadmap?
Pair surfaces
Treat iOS keyboard and Share Extension as complementary, not interchangeable.
Delay if context is weak
If source context is unreliable, improve share/copy before keyboard scope.
Use copy fallback
Keep selected copy available when native placement is limited.
Keep App Store status clear
Do not imply current App Store availability unless a shipped native surface has been verified.
Risk controls
Keep benchmark pages honest
Fake performance proof
Benchmark pages can sound like measured customer outcomes even when they are a planning scorecard.
Label scores as TypeToSell decision benchmarks, not user results, revenue lift, rankings, ratings, or conversion claims.
Native availability drift
A high benchmark score can make roadmap surfaces sound like shipped native products instead of readiness planning.
Keep Android keyboard, iOS keyboard, Share Extension, Safari iOS, and Firefox Android claims framed as roadmap or planning until verified.
Automation pressure
Scorecards can reward speed so much that manual approval gets treated as optional.
Keep manual final posting, selected draft action, and editable text as pass-fail criteria.
Related reading
Connect benchmark evidence to execution
iOS ReplyPilot Keyboard + Share Extension/mobile/ios-replypilot-keyboard-share-extensioniOS platform constraints/platforms/ios-keyboard-platform-constraintsiOS Share Extension platform constraints/platforms/ios-share-extension-platform-constraintsiOS technical spec/specs/ios-keyboard-share-extension-technical-spec
FAQ
Benchmark questions
When is iOS keyboard plus Share Extension ready?
When iPhone mobile web usage is proven and both context handoff and selected draft placement have safe fallbacks.
Why not build only an iOS keyboard?
A keyboard helps insertion, but reply quality also needs source-post context.
Is the iOS native path available today?
This benchmark is roadmap planning and should not be treated as current App Store availability.