3つの下書きを生成し、1つを選び、編集して手動投稿します。
ロードマップ
iOSキーボード + 共有拡張 roadmap
TypeToSellは自動投稿しません。最後のボタンはユーザーが押します。
最終更新: 2026-07-11. 明確な証拠がない限り、ネイティブアプリストアでの提供を主張しません。
戦略的適合
このロードマップが重要になる場面
フェーズ
ロードマップのフェーズと成功ゲート
フェーズ 1
Phase 1: iOS demand proof
Before native build
Confirm iOS users are a strong enough segment to justify native review and permission complexity.
iOS モバイルWeb tracking
Share intent research
Keyboard friction notes
Roadmap disclosure
成功指標: 3つの下書きを生成し、1つを選び、編集して手動投稿します。
フェーズ 2
Phase 2: 共有拡張 context path
Native context prototype
Make passing source-post context into TypeToSell easier than manual copy/paste.
共有拡張 prototype
Context preview
Draft generation handoff
Privacy explanation
成功指標: 3つの下書きを生成し、1つを選び、編集して手動投稿します。
フェーズ 3
Phase 3: keyboard insertion path
Composer prototype
3つの下書きを生成し、1つを選び、編集して手動投稿します。
Keyboard insert action
Copy fallback
手動投稿 reminder
Beta analytics
成功指標: 3つの下書きを生成し、1つを選び、編集して手動投稿します。
リスク
ロードマップのリスクと軽減策
Keyboard-only build
リスク: It may not solve post-context capture.
軽減策: Pair keyboard with 共有拡張.
Share-only build
リスク: It may not solve composer insertion.
軽減策: Keep keyboard or copy fallback.
iOS too early
リスク: Native complexity can arrive before demand.
軽減策: Require モバイルWeb and Android learning first.
意思決定ゲート
次のフェーズの準備完了を示すもの
Start iOS discovery
iOS users show モバイルWeb usage and ask for native support.
Build 共有拡張
Context capture is the main iOS friction.
Build keyboard
3つの下書きを生成し、1つを選び、編集して手動投稿します。
FAQ
ロードマップの質問
なぜ combine iOSキーボード and 共有拡張?
3つの下書きを生成し、1つを選び、編集して手動投稿します。
すべきか iOS native work come first?
Usually no. It should follow モバイルWeb and Android validation unless iOS demand is clearly stronger.
できますか iOS native workflows auto-post?
いいえ。 The user should still review, edit, and manually publish.