Missito
Core iOS & Android engineer - chat UI and client messaging layer (not the encryption core) · ~May 2017 – Jan 2018
A phone-number-based, end-to-end-encrypted mobile messenger for iOS and Android - Signal-Protocol encryption over a hybrid MQTT + REST transport, with text, voice-note, photo, video, location, and contact-card chat. Built in 2017–2018, never publicly released.
Missito is a secure instant-messaging app for consumers, in the same category as Signal, WhatsApp, and Telegram. People register with a phone number verified by an SMS code, the app finds which of their existing contacts are already on Missito (and lets them invite the rest), and every one-to-one conversation is end-to-end encrypted - only the two people talking can read what is sent, not the servers in between.
Conversations are rich, not just text: alongside typed messages with typing indicators and delivery/read receipts, people can send voice notes recorded in-app with a live waveform, photos and video captured or picked from the gallery, a location on a map, and contact cards - plus forward messages, see who is online, and block contacts. It shipped as a native iOS app (Swift) and a native Android app (Java), backed by a separate internal admin console for user lookup and moderation that was not part of my work.
A design decision shared across both apps: the transport is a hybrid of two protocols. Outgoing messages are sent over ordinary HTTPS/REST, while everything arriving in real time - incoming messages, status and typing events, and encryption-key top-up signals - comes down over MQTT, a lightweight always-on messaging channel. MQTT is the downlink, REST is the uplink, and anything that failed to send while offline is automatically re-sent from the local on-device database once the connection returns.
I was one of the two primary iOS engineers and a core Android contributor, and my area was the chat UI and the client-side messaging layer on both platforms: the chat screens, the rendering of each message type, the voice-message recorder and player, media attachments with upload and download progress, typing indicators, delivery and read receipts, opening a chat from a push notification, message forwarding, and the resend-and-dedupe logic for failed messages. I did not build the Signal-Protocol encryption core itself - that layer was owned by other engineers; I integrated the chat against its encrypt/decrypt API.
An honest note: the app reached a working end-to-end-encrypted state during 2017–2018 but was never publicly released as the project got cancelled by the client.
Architecture & engineering highlights
- Hybrid MQTT + REST messaging transport - a real-time downlink over MQTT (Paho on Android, MQTTClient on iOS) paired with an HTTPS send path, with connection lifecycle tied to app foreground/background state and automatic resend of undelivered messages from the local database on reconnect. (My area: the client wiring - send, receive, status, resend.)
- Full media chat pipeline - text, voice notes, images, video, location, and contact cards, each with its own incoming and outgoing rendering: per-type XIB cells on iOS and 14 distinct ViewHolders in a date-sectioned list on Android. (My area.)
- Custom voice-message subsystem on iOS - an in-app recorder with a live audio waveform, a custom scrubber and playback UI, and a swipe-to-cancel gesture. (My area - much of the audio cell layout, download state, and playback.)
- Client-side encrypted attachments with progress UI - media is AES-256 encrypted on the device before upload and decrypted after download, with combined upload/download progress; on Android uploads go to presigned form URLs and downloads run through a dedicated download manager. (My area on the UI and transfer side.)
- Notification intelligence - suppresses notifications for the chat that is currently open and during the burst of messages delivered right after a reconnect, so a returning user is not spammed.
- End-to-end encryption via the Signal Protocol - the classic prekey model with on-device key stores for identity, sessions, and one-time keys, replenished on demand. Built by other engineers, not me; I integrated the chat against its encrypt/decrypt/build-session API.
- Encryption at rest on Android - the local database is itself encrypted with a 64-byte key on top of the end-to-end encryption, so messages are protected both in transit and on the device.
Tech stack
iOS
Android
Shared
All rights belong to their respective owners.