SMF·MIMESTREAM
Un prompt peut-il remplacer Mimestream ?
Email — email clients and hosted mail
Bordereau de suivi des pièces
Verdict
Un client email macOS natif construit spécifiquement contre l’API Gmail, utilisant nativement le propre système d’étiquettes de Gmail plutôt que de le traduire via des dossiers IMAP génériques, c’est un vrai projet de week-end à une semaine, et une approche technique vraiment différente des fiches Superhuman et Fastmail basées sur IMAP de ce catalogue. Ce qui ne survit pas : des années de bizarreries de l’API Gmail et le poli macOS natif spécifique de Mimestream, ses widgets, panneau de partage, et intégration Spotlight.
Pièce A — Le prompt
Reçu le31.07.2026Construis un client email macOS natif contre l’API Gmail spécifiquement — pas IMAP générique, ce qui est l’approche que prennent déjà les fiches Superhuman et Fastmail de ce catalogue. Utilise Swift et SwiftUI avec l’API Gmail de Google (OAuth) directement, rendant le propre système d’étiquettes de Gmail, pas des dossiers, puisque les messages Gmail peuvent avoir plusieurs étiquettes que IMAP traduit maladroitement en dossiers, nativement dans l’interface : un message peut montrer plusieurs badges d’étiquette, et le filtrage par étiquette fonctionne comme le fait la propre interface web de Gmail. Mets en cache les métadonnées et corps de message en local dans SQLite pour une recherche rapide et une lecture hors ligne, en synchronisant de façon incrémentale via les tokens d’historique et de synchro de l’API Gmail plutôt que de tout re-récupérer à chaque fois. Implémente la rédaction, la réponse, l’archivage, la gestion d’étiquettes, et les opérateurs de recherche façon Gmail (from:, subject:, has:attachment) analysés et traduits en requêtes de recherche de l’API Gmail. Ne construis pas de prise en charge des comptes non-Gmail, de prise en charge multi-comptes, ni de notifications push natives via l’API push de Gmail — c’est hors périmètre ; c’est un client mono-compte Gmail utilisant le modèle de données spécifique de l’API Gmail, pas un client email générique. Nécessite une application Google OAuth (gratuite à enregistrer) avec accès à l’API Gmail ; aucun autre service externe requis.
L’ouverture pré-remplit le prompt — il ne reste qu’à appuyer sur entrée.
Pièce B — Ce que tu perds
- B.1 des années de bizarreries de l’API Gmail et de gestion de limite de débit
- B.2 le poli macOS natif comme les widgets, Spotlight, et le panneau de partage
- B.3 la prise en charge multi-comptes
- B.4 les notifications push via l’API push de Gmail
Alternatives existantes
Pièce C — Pourquoi certains continuent de payer : mail infrastructure, integrations, and client polish
Lire l’API Gmail est documenté et accessible ; garder un client natif fonctionnant sans accroc à travers les limites de débit de Gmail, les changements de quota, et la propre évolution de l’API de macOS, pendant des années, c’est le travail de maintenance en dessous.
Questions
Pourquoi construire contre l’API Gmail plutôt qu’IMAP, comme les autres fiches de client email de ce catalogue ?
Parce que le système d’étiquettes de Gmail ne se mappe pas proprement sur des dossiers IMAP — construire directement contre l’API Gmail laisse les étiquettes fonctionner comme elles le font vraiment dans la propre interface de Gmail, ce qui est une approche vraiment différente et plus native.
Puis-je connecter un compte non-Gmail ?
Non — cette construction est spécifiquement pour Gmail, en utilisant le propre modèle de données de l’API Gmail. Un compte non-Gmail aurait besoin de l’approche IMAP générique que décrit plutôt la fiche Fastmail de ce catalogue.
Ça prend en charge plusieurs comptes Gmail ?
Pas dans cette construction — elle est bornée à un compte, exprès, pour garder la logique de synchro gérable.
Combien ça coûte à faire tourner ?
Rien au-delà du compte Gmail que tu as déjà — c’est une application locale sans backend, et le palier gratuit de l’API Gmail couvre facilement un usage perso.
Outils proches
Récépissé