Implementing a Feedback Form in Mobile Apps
We develop custom feedback forms for iOS and Android turnkey. Proper implementation is not just a text field with a "Send" button. It's about preventing negative reviews in stores and providing real data for the product manager. The task seems trivial only at first glance: lost drafts, send failures, empty messages without context – all of this turns the form into a useless button.
For example, on a fintech startup project, we encountered users massively complaining about bugs in App Store reviews, even though the app had a feedback button. The problem: after screen rotation, the text disappeared, and metadata was lost on send. Developers received messages like "not working" without app version context. After implementing draft saving and automatic device information attachment, the number of useful reports tripled. About 70% of users abandon filling the form when accidentally minimizing the app – losing up to 50 minutes of work on the text. Our implementation prevents such losses.
How to Save Drafts and Not Lose User Text?
The user wrote three paragraphs, got a call, returned to the app – and the text was gone. This kills the desire to write. On iOS, we save the draft in UserDefaults on every change:
textView.delegate = self func textViewDidChange(_ textView: UITextView) { UserDefaults.standard.set(textView.text, forKey: "feedback_draft") } On opening the form, we restore it. We clear it only after successful submission. On Android, we use SharedPreferences – the logic is identical.
Why Is Automatic Metadata Attachment Critical?
An empty message "everything is bad" is useless for the developer. On send, we automatically attach context: app version, OS version, device model, and user ID (if authorized). The user does not fill these in – the data is collected programmatically.
// Android: compose metadata for sending val metadata = mapOf( "app_version" to BuildConfig.VERSION_NAME, "os_version" to Build.VERSION.RELEASE, "device_model" to "${Build.MANUFACTURER} ${Build.MODEL}", "user_id" to userRepository.getCurrentUserId() ) Without this information, a ticket in the tracker is a lottery. In practice, 80% of bugs reproduce only on specific OS versions. Our implementation gives support all the data for quick diagnostics.
Which Delivery Channel to Choose: SMTP, Webhook, or Helpdesk?
Delivery methods depend on infrastructure:
| Channel | Best scenario | Receipt speed | Suitable for |
|---|---|---|---|
| SMTP via backend | Support reads email | 5–15 minutes | Large teams with dedicated support |
| Webhook to Slack/Telegram | Small team, quick reaction | Seconds | Startups and small projects |
| Integration with helpdesk (Zendesk, Freshdesk) | Product with ticket history | Instant / via API | SaaS-level support |
Direct email sending from a mobile app using MFMailComposeViewController (iOS) or Intent.ACTION_SENDTO (Android) is best avoided – it depends on the device having a mail client and does not provide centralized storage.
What to Choose: Basic Form or Full Helpdesk Integration?
| Component | Basic form | Full integration |
|---|---|---|
| Draft saving | + | + |
| Metadata attachment | + | + |
| SMTP send | + | + |
| Webhook/helpdesk | - | + |
| Message history | - | + |
For startups, a basic form suffices. If the number of submissions exceeds 500 per month, helpdesk integration pays off through automation.
Submission Confirmation and Ticketing
After sending – a simple notification: "Message received, we will reply within 24 hours." If the form is used as a support channel, generating a ticket ID and allowing the user to track status is useful. We do this via your tracker or internal logic.
What Is Included in the Work?
- Analytics: determining the form's purpose (feedback collection, bug reporting, support) – this defines the field set and routing.
- UI design: a single text field + category (optional) + send button. Complex forms with 10 fields are not filled by users.
- Implementation: draft saving, auto metadata collection, chosen delivery channel. Code is written in Swift/Kotlin considering your architecture.
- Testing: network loss during send, very long text, special characters, rotation – each scenario is checked. We guarantee stable operation.
- Documentation: integration description, data schema, support instructions.
Work Process
- Analytics – call with your team, define requirements.
- Design – stack selection, form UI design.
- Implementation – coding, UI layout.
- Testing – unit tests and UI tests, failure scenarios.
- Deployment – publish to TestFlight / Google Play Console.
Estimated Timelines
- Simple form with email send – 1–2 days.
- Form with helpdesk integration, categorization, and message history – 3–5 days.
Cost is calculated individually after workload assessment. Get a preliminary estimate within one business day – contact us.
Our team's experience – 5+ years in mobile app development, over 30 projects in stores. We are familiar with App Store Review Guidelines (sections 4.2, 5.1) and Google Play Store requirements. Order a feedback form integration – improve user experience and reduce negative reviews.