iOS Engineer, Applied AI

We need to output HTML fragment with sections for headings present in posting: About Citizen, How We Work, What You Will Own, Your First 90 Days, How Success is Measured, Who You Are, Compensation? The rules: use

for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). Use

• for any list of duties/requirements/benefits, and

  for prose. Do NOT repeat the job title as a heading. Do NOT put Job ID / requisition numbers as headings — fold minor metadata into a short

  or drop it. Preserve ALL substantive information; do NOT invent or summarize away detail. Remove cookie/navigation/legal/EEO/equal-opportunity/scam-warning boilerplate, duplicated lines, and application instructions. IMPORTANT: include a section ONLY when the posting has real, specific content for it — never emit a heading followed by filler/placeholder text (e.g. "commensurate with experience", "not specified", "N/A", "varies", "TBD") and never create Pay/Schedule/Benefits sections unless the posting actually states them. Prefer a few substantive sections over many thin ones. Output ONLY the HTML fragment — no /, no markdown code fences. We need to extract substantive content and format accordingly. We have sections: "A Note From the Founder" (maybe not a standard heading but we can treat as a section? The instruction says use

  for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). It doesn't forbid other headings? It says use

  for section headings (e.g. About the role, Responsibilities...). Likely we should use

  for each section heading we include. The posting includes headings: "About Citizen", "How We Work", "What You Will Own", "Your First 90 Days", "How Success is Measured", "Who You Are", "Compensation". Also there is "A Note From the Founder" at top, maybe treat as intro paragraph. We need to preserve all substantive info, but we can combine some sections if thin? The instruction: Prefer a few substantive sections over many thin ones. But we have many sections with content. We'll keep them. We need to use

  • for any list of duties/requirements/benefits. So where there are bullet-like lists, we need to convert to
    • . Many sections have bullet-like lines. We need to use

      for prose. We must not include boilerplate like "A Note From the Founder" maybe it's okay as a heading? It's not in the list but we can still use

      . Probably okay. We need to drop duplicated lines, navigation, legal, EEO, etc. There's none obvious. We need to not repeat job title as heading. The job title is not explicitly given; maybe "iOS Engineer"? Not present. So fine. We need to not put Job ID/requisition numbers as headings. None. We need to include compensation section because posting states base salary range and equity. So we can include a Compensation section with

      containing that. We need to avoid filler like "commensurate with experience". Not present. Now let's extract content. We'll go through the posting and capture substantive paragraphs. I'll rewrite in my own words? No, must preserve ALL substantive information; do NOT invent or summarize away detail. So we need to keep the exact wording? Probably we can keep the same sentences but we can reformat into HTML. We should not change meaning. It's okay to keep same text. We'll produce something like:

      A Note From the Founder

      I wrote the first version of this app in Swift and I still open Xcode most weeks. For years the gap between an idea and a build on my phone was measured in sprints. Now I build with agents and it is measured in hours, and the engineers here who work the same way ship more in a week than a squad used to ship in a quarter. The iOS app is where millions of people find out what is happening around them, in the moment it matters. I want the person who owns it to be an exceptional iOS engineer first, to run agents like a second pair of hands, and to care that it works on one bar of signal in a crowd. If that is you, I want to build the next version with you, next to me.

      Then About Citizen:

      About Citizen

      Citizen is the #1 safety app in the U.S. Every day, thousands of videos are captured live at the scene of real incidents and distributed in real time to people in every major American city. No other consumer product has this. It is a live network, a newsroom, and a safety tool at once, and it is growing again. The iOS app is where all of it lands: the alert that arrives in seconds, the map, the live video from the scene, the broadcast a user starts with one tap, the Premium and Protect experiences that fund the mission. You will own real pieces of that app, and you will ship them with a small team of engineers, human and agent, holding the bar for what a real-time safety product on iOS should feel like. Some of what you build is for the people inside Citizen who run the city. Our Mission Control and real-time operations team uses Citizen Live, the operator tool that lives in the iOS repo, alongside their web tools all day. They are exacting users and they will tell you the truth.

      Then Why now Citizen is about to reinvent the product... Actually that's part of About Citizen? The posting includes a paragraph "Why now Citizen is about to reinvent the product, not redesign it....". That is substantive. Should we include it under About Citizen or separate? Could be part of About Citizen. We'll keep it in same section. Continue: "Eight years of shipping have left an app that does a great deal and hangs together less well than it should. The next version is live, ambient, and personal: the system watches the city so the user does not have to. That gets built on iOS first, in New York, by a very small number of engineers using agents to do the production work. The base and the distribution are earned. The rebuild is yours to ship." We'll include that in About Citizen. Now How We Work:

      How We Work

      Every role at Citizen is two things: the craft, and the operation of AI to multiply it. You are an iOS engineer first. Swift fluency, taste in architecture, a feel for performance on a real phone in a real crowd, and the judgment to know what a live safety product must never do. You are also the person who runs agents to write, review, test, and instrument the code alongside you. You propose where agents run alone; production gates are policy, because this is a safety product. You hold the bar on quality and you keep the hard calls for yourself. If in month three you are still hand-writing boilerplate, reducers, or test scaffolding, something has gone wrong.

      Then "How work is organized." paragraph:

      Engineering runs on a driver and builder model. Every initiative is a drive with one accountable driver who owns scope, sequencing, and tradeoffs, and a small set of builders who ship it with them. Drivers are not assigned by seniority; they are the people who want the decision and the responsibility that comes with it. You will build on other people's drives and you will drive your own, early.

      Then "Release Captain." paragraph:

      Release Captain. iOS ships weekly. Release Captain is a rotational program: when it is your week, you run the release end to end and land high-priority bug fixes on a severity-based timeline, typically within one to two days. Everyone on the team takes the rotation.

      Then "The stack, so you can self-select now." paragraph with list of tech: We need to convert list to
      • . The text: "Swift 6 with strict concurrency, The Composable Architecture (TCA), a modular Swift Package Manager codebase. Bitrise and fastlane for CI, TestFlight, phased rollout, crash triage in Sentry and Crashlytics, a defined hotfix path. Paywall and onboarding experiments run on GrowthBook. Analytics through Segment into BigQuery." We can make a list: Swift 6 with strict concurrency; The Composable Architecture (TCA); a modular Swift Package Manager codebase; Bitrise and fastlane for CI; TestFlight; phased rollout; crash triage in Sentry and Crashlytics; a defined hotfix path; Paywall and onboarding experiments run on GrowthBook; Analytics through Segment into BigQuery. We'll output
        • each. Now What You Will Own:

          What You Will Own

          We Are Not Hiring a Sole Authority Over The App. We Are Hiring Someone Dedicated, Who Wants Ownership And Can Carry It, Over a Real Piece Of The Core Product, Chosen By The Team's Need First And Your Interest Second, And Who Is Equally Willing To Own New Features And New Surfaces Where They Move The Company's Growth And Current Focus.

          Then "The Pieces On The Table Today" list: - Live video and broadcast. Capture, upload, and playback of live video from the scene, including the one-tap path from "something is happening" to "I am live." Latency and reliability under real network conditions. - Real-time alerts and the map. Push notifications that arrive in seconds, location and geofencing that are accurate and battery-aware, and a map that stays fast with thousands of live incidents on it. - The paid experience. Premium, Protect, onboarding, the paywall, and the GrowthBook experiments that run on them, in partnership with Design and Product. Every consumer dollar has an iOS decision behind it. - Citizen Live. The operator tool in the iOS repo that Mission Control uses. When it is slow, the city hears about it late. - App health and release. Cold start, battery, memory, crash-free sessions, behavior on one bar of signal, and the weekly train, phased rollout, crash triage, and hotfix path in the Release Captain rotation. - Whichever Piece You Take, Two Things Come With It - Instrumentation. Registering Segment events with the data team, checking they land in BigQuery, and making sure the funnel leadership reads is the funnel the app produced. - The agent loop. The agents that draft, review, test, and instrument iOS code at Citizen. Skills are already wired into the iOS repo; you take them over, extend them, propose where they run alone, and raise the output bar. You work daily with backend on the real-time contracts, with Design on what ships, with Product on what to build, with Data on events, and with Mission Control as an internal user. We need to convert each bullet to
        • . Some have sub-bullets; we can keep as part of same
        • text. Now Your First 90 Days:

          Your First 90 Days

          Days 1–30. Use the app every day in New York. Go live. Read the codebase. Ship to production in week one. Shadow a Release Captain week. Identify the three things that hurt users most and start on the first.

          Days 31–60. Run your first Release Captain week solo. Drive your first initiative end to end. Land one measurable improvement in performance or reliability. Take over one of the agent loops already in the repo, extend it, and propose the first one to run without a human, in test generation or code review.

          Days 61–90. Ship the first piece of the reinvented product to real users. Present the roadmap for the pieces you own, with the numbers behind it.

          Now How Success