Navly has changed quite a bit. I used Expo for the original app; the iPhone app is now built in Swift. There's a web planner too, where you can create a plan and see it on a map without an account.
I'm trying to turn a trip idea into a plan you can actually use. Tell it you have four days in Paris and like museums and cafés, and it puts together a day-by-day itinerary. You can see where the stops are and how much travel sits between them.
When plans change
You might want a slower day or a different stop. When you ask, Navly shows the proposed change first. It goes into the plan when you accept it. I don't want the assistant quietly changing things without you noticing.
The map helps here. Putting two place names next to each other is easy; seeing the route makes it clearer whether they fit into the same day. Daily routes appear on Apple Maps. You can open a stop's details and use Look Around where it's available.
Moving from Expo to Swift
The iOS app now uses native components. The web and services still use TypeScript. Swift can't share those TypeScript types, so I define what the API sends and what the app expects through shared contracts.
Navly also owns the flow from the assistant's proposal to approval and the applied action. I don't want to rebuild that flow whenever I change model providers.
I'm still building it independently. What I'm working on now is making the app useful after it has created the plan too: looking up a place, changing the day, getting to the next stop. You can have a look at navly.app.
Following one request through the product
“Four days in Paris, with museums and cafés” is an example request. It gives the city, duration and some interests. In the resulting plan, I look at which stops sit in each day and the travel time between them. Liking the place names isn't enough; visiting them in that order needs to make sense too.
I can then ask to make day two lighter. The existing plan gives that request its context. When reviewing the proposal, I can look at which stops change. Seeing the revised day before accepting helps keep the conversation connected to the saved itinerary.
Creating a web plan is one way to try this. In the iPhone app, choosing a day, looking up a place and opening directions stay connected to the same trip. For paid features and web usage terms, I'd refer to the product site rather than freeze those details in a blog post.
On the technical side, a shared contract means being explicit about data. If the API sends a stop's identity and timing, the Swift client needs a defined way to read those fields. Shared example data helps check both sides. Changing a TypeScript field doesn't automatically update Swift code.