Inspiration
Travel planning rarely fails because information is missing. It fails because the useful pieces are split across maps, review apps, long-form guides, weather searches, and expense trackers. At the destination, the traveler still has to decide what comes next, why that order makes sense, how to get there, and whether the plan still fits the day.
Suixing means “travel together.” We built it as a native iOS travel decision console: a focused place where a traveler can turn selected attractions into an explainable route, launch navigation, check weather, record real spending, and keep a visual replay of the trip.
What it does
Suixing starts from the current location or a custom origin and orders multiple attractions using distance, travel time, opening constraints, available time, transport mode, and preferences. It shows every route leg and lets the traveler launch an installed map app without rebuilding a navigation engine.
The app also handles the practical details around a route. City weather opens directly, while attraction weather uses a district-level forecast query. Each saved route has a multi-currency budget and expense ledger. An iOS Shortcut can capture a payment-completion page or historical bill detail, pass it to Suixing, and open the app with an editable confirmation. Vision OCR runs on device and suggests the amount, merchant, payment source, time, and category. Nothing is recorded until the traveler confirms it.
After the trip, Suixing can render the route as an animated GIF. The GIF can be saved or shared from the result page and exported again from trip history.
How we built it
The app is written in Swift 6 and native SwiftUI. MapKit renders the planning and playback surfaces. AMap supplies live China POI and route data when the user provides a key. App Intents exposes payment recognition to Shortcuts, Vision performs local OCR, and a small pure-Swift parser converts OCR lines into a reviewable expense candidate. Trip, route, GIF, and finance models live in SuixingCore so they can be exercised without launching the UI.
The route planner deliberately combines rules and heuristics instead of asking an LLM to invent an itinerary. Opening constraints and travel cost stay explicit; the UI explains the resulting order.
How Codex and GPT-5.6 helped
The product owner drove the scenarios and acceptance decisions. Codex and GPT-5.6 accelerated the engineering loop: exploring an unfamiliar SwiftUI codebase, turning feedback into focused design options, implementing domain models and native views, creating regression fixtures from real payment screenshots, debugging App Intent foreground behavior, automating Simulator checks, and validating release builds.
The most useful collaboration pattern was evidence first. When a phone recording showed that Shortcuts completed OCR but did not open Suixing, Codex inspected the exact frames, isolated the deferred foreground mode, added a regression check, changed the intent to immediate foreground mode, and replayed the same screenshot in Simulator. When the merchant was recognized as “Phone,” Codex used the OCR output to prioritize Merchant Full Name, reject contact labels, recognize Tenpay as WeChat, and categorize China Railway/12306 as transportation.
Human decisions remained central. We chose a one-tap weather interaction, public transport as one understandable mode, confirmation before every OCR import, local-only screenshot recognition, and neutral visual treatment for external-app launchers.
Challenges
The hardest problems were the seams between apps and imperfect real-world location/payment data. Shortcuts may execute while another app is visible; opening Suixing only after background OCR was unreliable, so the intent now enters the foreground before processing and refreshes the pending import when recognition completes. Payment apps also change labels and layouts, so the parser ranks field semantics instead of relying on one screenshot template.
At the shoreline, reverse geocoding can return a sea region instead of a city. Suixing detects marine results and resolves the nearest supported administrative city before requesting attractions, while still telling the traveler that the location is near the coast.
Accomplishments
- A coherent native iOS experience rather than a disconnected prototype.
- Explainable multi-stop routing with six transport choices.
- Private on-device OCR and a user-confirmed multi-currency travel ledger.
- A Shortcut workflow that works for both new payments and historical bill details.
- Animated route replay with repeat export from history.
- Regression checks built from real device failures and verified in Simulator.
What we learned
Travel software must be tolerant of ambiguity but conservative with user data. Location labels, map availability, OCR fields, and installed apps all vary. The best experience is not to hide that uncertainty; it is to resolve what can be resolved, present editable suggestions, and keep the final action under the traveler’s control.
What’s next
Next we would add weather-aware route replanning, better accessibility constraints for older travelers and families, exchange-rate refresh with saved rate snapshots, and optional collaborative voting for groups. The same decision-console model can then support more cities without turning Suixing into a heavy booking or social platform.
Log in or sign up for Devpost to join the conversation.