로드맵

iOS 키보드 + 공유 확장 roadmap

TypeToSell은 자동 게시하지 않습니다. 마지막 버튼은 사용자가 누릅니다.

마지막 업데이트: 2026-07-11. 로드맵 페이지는 명확한 증거 없이는 네이티브 앱스토어 제공을 주장하지 않습니다.

전략적 적합성

이 로드맵이 중요한 시점

초안 3개를 만들고 하나를 선택해 수정한 뒤 수동으로 게시합니다.

단계

로드맵 단계와 성공 게이트

단계 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 모바일 웹 tracking

Share intent research

Keyboard friction notes

Roadmap disclosure

성공 지표: 초안 3개를 만들고 하나를 선택해 수정한 뒤 수동으로 게시합니다.

단계 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개를 만들고 하나를 선택해 수정한 뒤 수동으로 게시합니다.

단계 3

Phase 3: keyboard insertion path

Composer prototype

초안 3개를 만들고 하나를 선택해 수정한 뒤 수동으로 게시합니다.

Keyboard insert action

Copy fallback

수동 게시 reminder

Beta analytics

성공 지표: 초안 3개를 만들고 하나를 선택해 수정한 뒤 수동으로 게시합니다.

위험

로드맵 위험과 완화책

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 모바일 웹 and Android learning first.

의사결정 게이트

다음 단계가 준비되었음을 증명하는 것

Start iOS discovery

iOS users show 모바일 웹 usage and ask for native support.

Build 공유 확장

Context capture is the main iOS friction.

Build keyboard

초안 3개를 만들고 하나를 선택해 수정한 뒤 수동으로 게시합니다.

FAQ

로드맵 질문

왜 combine iOS 키보드 and 공유 확장?

초안 3개를 만들고 하나를 선택해 수정한 뒤 수동으로 게시합니다.

해야 하나요 iOS native work come first?

Usually no. It should follow 모바일 웹 and Android validation unless iOS demand is clearly stronger.

할 수 있나요 iOS native workflows auto-post?

아니요. The user should still review, edit, and manually publish.