01 / The question
A pin is not permission.
While living in Manila during COVID, I found it difficult to distinguish designated smoking areas from places mentioned by word of mouth. I no longer smoke, but the information problem stayed with me: a confident-looking map can hide a very uncertain claim.
iYosi is an informational guide to designated and community-reported smoking areas in Metro Manila. Its purpose is to make the information current and correctable while supporting smoke-free rules and shared air. The map must distinguish a reviewed designated area from a report that people happen to smoke somewhere.
02 / The decisions
Keep different kinds
of evidence separate.
I separated place type from advisory status, and evidence review from community confirmation. A rating describes someone’s experience. A confirmation says whether a place or access route is still there. Neither turns a place into a verified designated area; that requires evidence review.
Browsing is anonymous after the adult-access prompt. Accounts are required for contributions. Location is requested only when a person chooses Near me, and browsing and search work without it. A separate public entrance pin can make directions more useful without confusing the entrance with the actual area.
03 / What I built
Two clients.
One shared contract.
The shared API supports the map, place details, proposals, confirmations, reviews, reports, and account requests. It includes a PostGIS data model, an OpenAPI contract, and an internal moderation console. Proposed places remain pending until an administrator reviews and publishes them.
The Android pilot uses platform APIs and Java; the iOS client uses SwiftUI and MapKit. Both distinguish review dates from community observations, make status visible, and send contributions to the same API. Shapes and text accompany map colors. Directions are constrained by the record’s status rather than offered indiscriminately.
04 / The proof
Make the correction path
as real as the map.
The API repository includes contract and integration tests, an operations runbook, and a record of implemented backend behavior. The iOS delivery notes record a simulator build and launch against an isolated synthetic demo API with four fictional pins and local address suggestions.
The landing preview explains the product with illustrative places. It is a preview, not a directory of verified locations. Likewise, a successful simulator run is evidence of a working client, not evidence of public adoption or a completed launch. Keeping those distinctions visible is part of the product’s own standard.
05 / Where it stands
A pilot with clear
work still ahead.
Android and iOS clients and the shared API are in development for a pilot. Public release still depends on operational decisions covering moderation, privacy, age assurance, and map and search providers, together with the remaining launch checks. App-store destinations are not available yet.
The next useful step is a carefully operated pilot with reviewed information and a working correction process. The design question stays the same: can someone understand what a pin means, how current it is, and what to do when it is wrong?
Jason Fricano