Mobile Engineering Lead

The Role

You will own the day-to-day execution of Gruntify’s move to Kotlin Multiplatform, and take release management for both mobile apps in-house.

The migration already has a plan. What it does not have is someone building to the standard everyone else is expected to follow, mentoring the team through it, and holding the line on the rules once they are agreed. That is this job.

Our iOS and Android apps are production systems. Queensland’s Department of Transport and Main Roads uses them for post-disaster infrastructure assessment across more than fifty councils, and has done for eight years. Rangers at the Department of Environment, Tourism, Science and Innovation use the same apps across Queensland’s national parks.

Today the two codebases share design intent but no implementation. Automated test coverage is something you will build rather than inherit. A twelve-month plan sets the technical direction, and this role is what turns it into daily practice.

Responsibilities

Lead by example

• Build the first migrated modules yourself, to the standard the rest of the team is expected to match. Tests written first, the CI coverage threshold met, and the module running in both live apps before it counts as done.
• Treat shared ownership as real rather than aspirational. Whoever builds a shared module owns it, whichever platform they came from, and you model that from week one.
• Show what good looks like in the code and in the release pipeline, rather than describing it afterwards.

Mentor the team

• Pair iOS and Android engineers on shared-module work, so Kotlin fluency builds through shipped work rather than a training course sitting apart from it.
• Bring the mobile team onto the same AI-assisted workflow our web engineers already use daily. Mobile is the one part of engineering without it.
• Give direct, specific code review feedback, and use it to coach rather than to gate.

Enforce the rules, once they are agreed

• Hold the CI coverage gate without exception. Nothing merges into the shared module below the agreed bar, deadline pressure included.
• Keep white-label discipline. Brand and configuration values stay injected from each flavour’s own config, never hardcoded into shared code.
• Run the governance step on any shared-module change that affects both apps, so decisions about shared code do not default to whoever touched it last.
• Keep the parity-gap register honest and shrinking, rather than quietly parked.

Respect that the business still has to run

• Protect reliability for our government customers first. Migration pace never comes ahead of a production record those field crews depend on.
• Keep the day-to-day ticket queue moving. Migration work sits alongside business-as-usual support, not in place of it.
• Treat each phase’s go/no-go checkpoint as a real decision. Slow down or hold a phase when the evidence says so, rather than pushing through on schedule alone.

Own release management for both apps

• Take full ownership of iOS and Android release execution, bringing it in-house under this role.
• Run the existing release pipelines end to end. Azure Pipelines on iOS, Gradle and AGP via Azure Pipelines on Android, including per-flavour signing across every white-label variant.
• Own app store submissions for both platforms. Coordinate release notes and cadence with the backend and web teams rather than setting them alone.

Introduce AI-powered development and testing workflows

• Stand up AI-assisted tooling across both mobile repositories from week one, extending into mobile what web engineering already runs daily.
• Use AI to draft characterization tests for legacy code before it is touched, and to scaffold new shared modules, so engineers spend their time on judgement calls rather than plumbing.
• Mine the two codebases for recurring patterns and turn them into deterministic, reviewed migration rules. That is the discipline Uber applies to its own large-scale Kotlin migration, and it beats letting AI rewrite production code freely.
• Keep AI-generated code inside the same review and coverage gate as everything else. A fast draft, never a merge-ready deliverable on its own.

Requirements

• Hands-on experience across both Kotlin/Android and Swift/iOS, or deep strength in one with working fluency in the other.
• Experience owning a mobile release pipeline end to end rather than contributing code into one. Azure Pipelines, Gradle and AGP, App Store Connect, Google Play Console.
• Comfortable mentoring engineers through day-to-day work, not only through pull request review.
• Kotlin Multiplatform experience, an equivalent shared-codebase migration, or a fast and demonstrated aptitude for it.
• AI-assisted development tooling as part of your daily workflow, not an occasional extra.
• You know what production-critical means in a government, offline-first, safety-relevant setting, where field crews depend on the app when conditions are bad.

What success looks like

• The CI coverage gate holds on every merge into the shared module, with no undocumented exceptions.
• Release cadence for both apps is maintained or improved once the handover to this role is complete.
• Business-as-usual defects stay at or below the current baseline through the migration.
• The parity-gap register shows differences between iOS and Android closing, not growing, as modules move into the shared layer.
• Phase one finishes with domain models, pure functions and permissions logic shared and running in production on both live apps.

Who you will work with

You will report to our DevOps Lead and sit at the centre of the cross-platform working group set up for this migration. Day to day you will work with our iOS, Android and QA engineers, and with the backend team on APIs, UI/UX, module design, testing and review. Risks and critical issues escalate to our Founder and CEO.

The technology is the easier part of this migration. Making the team part work is what this role is for.