A text post is the foundation of any social application. But often we see teams simplifying implementation to "TextField + Send button" and then receive complaints: the user wrote a long text, minimized the app — the draft is lost. Or they sent a post with weak internet — an error, and everything starts over. Our extensive experience in development (over 30 projects with content publication) shows these details are critical for audience retention. Another problem is version conflict: a user edits a post while another client modifies the same draft. Without versioning, data is lost. Below — how we solve these tasks and what is included in the implementation.
How we design the text editor
In the minimal case, we use UITextView on iOS or BasicTextField on Android if no formatting is required. We always include autocorrection, spell check, and automatic height expansion up to 5-6 lines. On iOS, this is configured via NSLayoutConstraint with updates in textViewDidChange. When formatting is needed (bold, italic, lists), the stack choice depends on the platform:
| Platform | Tool | Features |
|---|---|---|
| iOS | UITextView + NSAttributedString or RichTextKit |
RichTextKit — open source, supports insertion, increases binary by ~800 KB |
| Android | SpannableStringBuilder + EditText or Markwon |
Markwon convenient for Markdown preview, lightweight |
| Flutter | flutter_quill |
Delta format, adds ~2 MB, requires server-side conversion |
We recommend storing text on the backend in HTML or Markdown — neutral formats, the client converts on load. This simplifies integration with web versions. More about Markdown.
Why drafts are mandatory
Users often leave the post creation screen unintentionally — a call, notification, app minimization. Without draft saving, content loss reaches up to 40% (our tests on 30 projects). We implement auto-save with a debounce of 1-2 seconds: every text change is written to UserDefaults (iOS) or DataStore (Android). The key is draft_post or draft_post_{channel_id} for multichannel apps. When opening the editor, we check for a draft and offer to restore. After publication or reset, we clear it. On Flutter, we use SharedPreferences or Hive with debounceTime(Duration(seconds: 1)).
Once we implemented publishing in an app for bloggers. Users inserted long formatted texts. We discovered that when saving to UserDefaults on iOS, if the app is unloaded from memory, the draft is not saved. We switched to CoreData with a background context — save reliability increased to 99%.
Draft checklist example
- [ ] Auto-save with debounce 1-2 sec
- [ ] Restoration when opening editor
- [ ] Clear after publication
- [ ] Multichannel support
How to implement publishing with poor internet
The standard approach — optimistic update + retry queue. On pressing "Publish":
- Generate local
client_post_id(UUID). - Immediately add post to feed with
pendingstatus (gray indicator). - Send request to server. On success — replace ID, remove indicator.
- On error — show "Not sent" status with "Retry" button.
On Android, for retries upon network restoration we use WorkManager with NetworkConstraint, on iOS — BGTaskScheduler or NWPathMonitor. This reduces lost publications by 30-50% compared to synchronous sending. Comparison of approaches:
| Criteria | Synchronous publishing | Optimistic update |
|---|---|---|
| Response time for user | 2-5 seconds on weak internet | Instant (local) |
| Data loss on error | 100% | 0% (post remains pending) |
| Retry on network restoration | Manual | Automatic via WorkManager/BGTask |
Before deployment, we conduct offline scenario testing: internet disconnection, mode switching, timeout simulation. This reveals race conditions and improves UX.
Validation and constraints
Character limit is displayed with a counter (Twitter approach: red minus after exceeding). The publish button is active only when text.trimmingCharacters(in: .whitespacesAndNewlines).count > 0. Mentions (@username) and hashtags (#tag) are parsed with regex and highlighted via NSAttributedString/AnnotatedString. We also support link insertion with automatic recognition.
What is included in the work
- Designing post structure and API (GraphQL or REST specification)
- Editor implementation with auto-save drafts
- Publishing logic with optimistic update and retry
- Error handling and retry on network restoration
- Content validation and counter display
- Offline scenario testing on real devices with various OS versions
- API documentation and access transfer (TestFlight, Google Play Console)
- Client team training and 1 month support
Timelines and cost
Cost is calculated individually based on complexity. Approximate timeline: simple editor with draft and retry — 2-3 days, with formatting and mentions — 5-7 days. For an accurate estimate, contact us — we will analyze requirements and offer an optimal solution. Get a consultation: we guarantee quality and extensive experience.