blob: c63853a3954f103d888b8279835631e179a00d09 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
|
# Hutch Roadmap
## Positioning
Hutch is already beyond a minimal v1. The core SourceHut surfaces are present:
- Authentication with PAT flow
- Git repositories
- Mercurial repositories
- Trackers and tickets
- Builds
- Sharing
- Core settings and app metadata
The main risk now is not lack of scope. The main risk is shipping too late with
an increasingly broad surface area and not enough polish.
This roadmap treats the current app as a real 1.0 candidate and shifts the
focus from feature expansion to launch readiness.
## Version 1.0 Goal
Ship a stable SourceHut mobile client with strong support for the most active
day-to-day workflows:
- Browse and manage repositories
- Browse and manage tickets
- Browse and manage builds
- Support both git and hg repositories
- Provide dependable sharing and navigation
Version 1.0 does not need to cover every sr.ht service.
## Release Strategy
### Phase 1: Ship Readiness
Focus on quality, not new surface area.
#### Core release checklist
- Verify authentication flow on simulator and physical device
- Verify reset/sign-out/reset-app-data flow on simulator and physical device
- Verify all destructive actions have confirmation and correct follow-up state
- Verify all create flows succeed end-to-end:
- Git repository
- Mercurial repository
- Tracker
- Ticket
- Build submission
- Verify build retry and edit/resubmit flows
- Verify repository sharing links for:
- repository
- commit
- file
- Verify sharing links for:
- build
- tracker
- ticket
- profile
- Review empty/loading/error states across all main tabs
- Remove any leftover temporary debug logging
- Audit device-only issues:
- Xcode attach quirks
- on-device auth/cache behavior
- WebView rendering performance
#### UI/UX polish checklist
- Tighten wording and error messages across create/edit flows
- Confirm summary tabs feel consistent across git and hg
- Confirm toolbar actions are visible and non-duplicated
- Confirm README rendering is smooth on large repositories
- Confirm forms behave well on iPhone-sized screens
- Confirm keyboard behavior and dismissal in all creation sheets
#### App Store readiness
- Finalize app icon and screenshots
- Finalize App Store copy
- Finalize privacy details
- Finalize support URL / project URL
- Decide whether TestFlight comes before public launch
### Phase 2: Version 1.1
Add one compact new service surface after launch.
#### Recommended priority
1. Exact repository lookup
2. paste.sr.ht
3. lists.sr.ht
#### Why
- Exact repository lookup solves a real gap created by the lack of public
discovery APIs
- paste.sr.ht is relatively self-contained
- lists.sr.ht is valuable, but broader in UI and data model scope
### Phase 3: Version 1.2+
Expand only after the v1 core is stable in the wild.
- lists.sr.ht tab
- paste.sr.ht creation/editing polish
- pages.sr.ht management
- broader deep-link/share coverage
- workflow refinements for builds and tickets
## What Counts As “Done Enough” For 1.0
Hutch is ready for 1.0 when:
- The main flows work reliably on real devices
- Errors are understandable
- The app does not feel inconsistent across git/hg/builds/tickets
- The missing services feel like roadmap items, not broken gaps
That means `lists.sr.ht`, `paste.sr.ht`, and `pages.sr.ht` are not blockers for
the first release.
## Non-Blockers For 1.0
These should not delay launch:
- Donation page / IAP
- Broad service parity across all SourceHut products
- Public repo discovery equivalent to `sr.ht/projects`
- Advanced creation workflows beyond what the public APIs cleanly support
## Open Product Questions
These are worth deciding before or shortly after launch:
- Should the app be positioned as “SourceHut client” or “SourceHut for git/hg,
tickets, and builds” in App Store messaging?
- Should exact repository lookup live in Repositories search, a dedicated sheet,
or both?
- Should `paste.sr.ht` or `lists.sr.ht` be the first new post-launch tab?
- Is TestFlight feedback needed before calling the first public build 1.0?
## Recommended Next Step
Do not add another major service right away.
Instead:
1. Run a release-focused polish pass
2. Build a strict 1.0 checklist from the current app
3. Ship to TestFlight or release publicly
4. Use `ROADMAP.md` and `TODO.md` separately:
- `ROADMAP.md` for release strategy
- `TODO.md` for concrete implementation backlog
|
