Family Edge Planner

From today's mood to a realistic outing—without the planning back-and-forth.

Comment

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Family Edge Planner

Inspiration

Planning a day off is not only a place-search problem. Every outing creates decision overhead: discovering options, comparing weather, time, cost, accessibility, and travel, then doing enough back-and-forth to choose a plan. This is especially visible in dense cities, where a private outdoor space is not a default leisure venue for many people and “Where should we go today?” returns again and again.

We wanted the first decision to be human and lightweight: “How should today feel?” The app should turn an open-ended discussion into a concrete itinerary people can react to, while remaining honest about what is live data, what is an estimate, and what is generated by AI.

What it does

The user chooses one of four moods and can edit party size, accessibility preferences, budget, outing time, coarse area, and travel mode. The app refreshes the selected day’s forecast, searches Apple Maps automatically, and checks supported municipal event sources. It then builds a timed itinerary with real venue names and addresses, MapKit travel estimates, app-owned cost and stay-duration estimates, concise fit reasons, venue characteristics, per-stop directions, and an all-stop Apple Maps overview.

When the optional Gemma model is installed, inference runs on the iPad. This avoids a hosted language-model request for every planning session, keeps group constraints and generation prompts on the device, and is designed for low marginal AI inference cost so the product can be offered as affordably as possible. Live weather, venue discovery, supported official events, and routes still use network services.

Gemma receives only short candidate IDs and group constraints. Swift—not the model—reconstructs venue facts and totals, rejects malformed or out-of-policy output, retries once with clean feedback, and then uses an explicitly labeled safe plan if necessary. Without a model, a deterministic on-device planner uses the same app-provided candidates and is labeled separately from Gemma output.

How we built it

The app is written in SwiftUI and targets iOS/iPadOS 17 or later. Core Location supplies location only after an explicit tap. WeatherKit is the preferred forecast source, with an Open-Meteo fallback that receives coordinates rounded to roughly one kilometer. MapKit supplies local search and travel estimates. Supported official event feeds are aggregated without allowing one municipality’s outage to block the other sources. User preferences, saved plans, and generated plan data stay in local app storage.

LiteRT-LM 0.12.0 runs the optional on-device Gemma model. The planning pipeline separates generation into PlanDraft, CandidateCatalog, PlanAssembler, and PlanValidator. This lets the model choose IDs and short reasons while app-owned code hydrates names, addresses, costs, durations, travel, and totals.

How Codex and GPT-5.6 were used

I am a non-engineer, and Codex was the implementation partner that made a working native iOS prototype possible. I did not treat its first answer as the finished product. My loop was to define one concrete behavior, have Codex implement it, run it in the Simulator or on a signed iPad, report the bug or friction I actually observed, and then refine the code and tests.

That loop changed the product substantially. Manual venue selection became one-tap discovery. Sample places became real Apple Maps candidates. Current-location handling, weather, travel mode, routes, supported official events, onboarding, localization, and clear model/fallback labels were added after hands-on use exposed what was missing or confusing. Codex supported the SwiftUI implementation, LiteRT-LM integration, constraint debugging, device scripts, and automated tests.

GPT-5.6 performed the final evidence-backed review. It reconciled the four real plan-source states, corrected submission copy that had incorrectly described every no-model result as sample demo data, rechecked the candidate-ID/JSON/cost/time boundary, regenerated the Xcode project, and reran the final build and test suites. The recorded result was 91 passing unit tests, two opt-in network tests skipped, and 14 passing UI tests.

Challenges

  • Running a multi-gigabyte model reliably on a physical iPad while keeping model weights out of Git and the app bundle.
  • Preventing generated text from becoming a source of venue facts, prices, or travel claims.
  • Keeping live Apple Maps, weather, official events, deterministic planning, real Gemma inference, and safe fallback behavior visibly distinct.
  • Testing localization, large Dynamic Type, iPad landscape, onboarding, persistence, live-network boundaries, and a stable public demo without making normal tests depend on the network.

Accomplishments

  • Real on-device Gemma inference was verified offline on a physical iPad, including ten consecutive successful warm runs.
  • The app automatically discovers real venues and can incorporate supported official events without asking the user to choose a shortlist.
  • Model output is reduced to allowlisted IDs and short reasons; Swift reconstructs and validates the final plan.
  • The final simulator review passed 91 unit tests and 14 UI tests.
  • The English public demo is 118 seconds and uses dedicated story slides whenever the app is not on screen. It leaves additional reading time for the generated itinerary, includes narration, explicitly labels the no-model path, and shows live weather and Apple Maps venues.

What we learned

On-device AI is most useful here when it makes a bounded judgment rather than acting as the database. Keeping public venue facts, planning estimates, and model output separate made the product easier to explain, validate, and recover. It also avoids turning every plan into a paid cloud-LLM request, although the live-context services still use the network. We learned that reducing decision overhead is not the same as removing control: the app can propose a concrete itinerary while still letting users change the mood, constraints, travel mode, or individual stops.

What’s next

  • Enable the production WeatherKit capability and verify the signed distribution build.
  • Expand official event coverage beyond the current municipal sources.
  • Add judge-friendly distribution through TestFlight.
  • Continue physical-iPad VoiceOver and Split View validation.
  • Improve route-radius filtering and venue-opening verification without presenting unverified details as facts.

Built With

Share this project:

Updates