Email for iOS and Android apps
Updated
A mobile app has push, in-app messages and email. Email is the channel that survives a phone change, a deleted app and a muted notification, so use it for the messages that have to be there later.
Email or push
| Message | Channel | Why | |---|---|---| | Receipt or invoice | Email | A record the user can search later | | Verification or OTP | Email (or SMS) | The user may not have the app open yet | | Account recovery | Email | They cannot sign in to see in-app notices | | Terms or privacy change | Email | A durable notice | | Security alert | Email and push | Needs both speed and a record | | "Your order is nearby" | Push | Useless after an hour | | Social activity | Push, with an optional digest | Frequent and ephemeral | | Re-engagement | Campaign, if consented | Marketing, not transactional |
Backend triggers, not app triggers
Your server already knows when a purchase succeeds, an account is created or a password changes. Let it send the email at that moment. The app should not call an "email me" endpoint for events your backend can see itself. This is safer and keeps mail working when the app is closed. See Flutter and Dart for the case where the app does request an email, such as a login code.
Deep links
Links in emails should open the app when it is installed and fall back to a web page when it is not. Use universal links (iOS) and app links (Android) on a domain you control. Test the path where the app is not installed, because it is the one new users hit.
Example: in-app purchase receipt (Python)
import os
from inboxili import Inboxili
client = Inboxili(os.environ["INBOXILI_API_KEY"])
def send_receipt(purchase):
client.emails.send(
to=purchase.user.email,
from_email="receipts@yourapp.example",
from_name="Yourapp",
subject="Your receipt for {{item}}",
html_body='<p>Thanks {{name}}. You bought <strong>{{item}}</strong> for {{amount}} on {{date}}. <a href="{{url}}">View in the app</a></p>',
text_body=f"Receipt: {purchase.item_name}, {purchase.amount_display}, {purchase.date:%Y-%m-%d}",
template_data={
"name": purchase.user.first_name,
"item": purchase.item_name,
"amount": purchase.amount_display,
"date": f"{purchase.date:%Y-%m-%d}",
"url": f"https://yourapp.example/purchases/{purchase.id}",
},
)
App-store purchases have their own store receipts, so say that your email is a record and not the store's invoice.
Things to get right
- Privacy relay addresses. Some sign-in providers give you a relay email. It works as a normal address, but a bounce means the user disabled forwarding.
- Account deletion. Send a confirmation when an account is deleted, and honour unsubscribe and deletion rules.
- Language. Store the user's language and send in it.
- Volume spikes. A promotion that triggers many purchases at once should go through a queue, below the 120 requests per minute key limit.
Frequently asked questions
- When should I use email instead of a push notification?
- Use email for anything the user may need to find later or may not be able to receive on the device: receipts, account recovery, legal changes and verification. Use push for prompts that expire in minutes.
- Can the app send the email directly?
- It should not. The API key would ship inside the app. The backend sends the email.
Start sending app email
Create a workspace, verify a domain, and make your first API call.