Mobile Development: SFIA levels and developer seniority
Fennec team · 15 Jun 2026 · 3 min read
Mobile development carries constraints web engineering mostly doesn't: app store review, device fragmentation, offline behaviour, battery life, and two platforms that don't agree on much. Shipping a feature well means handling all of that, not just the screen the user sees.
SFIA levels here move from making simple UI changes to an existing pattern, to owning cross-platform architecture and mobile strategy for an organisation.
1
Level 1: Follow
“I understand mobile development concepts and can make simple UI changes following existing patterns.”
Evidence here is about hitting real constraints: simple UI changes you made following an existing pattern, a completed course in iOS, Android, or React Native fundamentals, or notes from shadowing an app store submission to see what actually happens.
Build a small app from scratch, not a tutorial clone, since that's when the platform's real constraints show up. Learn the basics of the iOS and Android lifecycle differences, and ask to shadow an app store submission if you haven't seen one yet.
2
Level 2: Assist
“I build basic screens and fix bugs with some guidance. I understand the difference between iOS and Android constraints.”
The evidence shifts toward guided independence: screens you built with guidance from a more senior engineer, a bug you fixed that involved understanding a platform constraint, or a design spec you turned into a working screen without much back-and-forth.
Fix a bug involving a platform-specific quirk, permissions or lifecycle are common ones, yourself rather than escalating it. Build a screen from a design spec unaided, and learn what actually happens during app store review rather than just knowing it exists as a step.
3
Level 3: Apply
“I build and ship mobile features independently. I handle platform-specific concerns like permissions, lifecycle, and performance without guidance. I write tests and I know the app store submission process.”
This is where full features become the evidence: a mobile feature you shipped independently with permissions, lifecycle, and performance handled properly, tests you wrote for it, or an app store submission you handled yourself from start to finish.
Own a feature all the way through app store submission and release. Write tests for a screen or flow you built, and investigate one performance issue, startup time or jank are good places to start, and actually fix it rather than noting it for later.
4
Level 4: Enable
“I own the mobile architecture: I decide on framework, patterns, and cross-platform strategy. I lead performance work and help other mobile engineers solve the hard problems.”
By now the evidence is architectural: a cross-platform or architecture decision you made and documented, performance work you led across the app, or a mobile engineer you helped solve a genuinely hard problem.
Decide and document your team's approach to a hard mobile problem, cross-platform strategy or offline sync are common ones, rather than letting it stay ambiguous. Lead a performance investigation across the app, and mentor another mobile engineer, since that's usually the clearest external signal of this level.
5
Level 5: Ensure & Advise
“I set mobile engineering strategy and standards across the organisation. I evaluate cross-platform approaches and lead major mobile programmes.”
The evidence spans the organisation: a mobile engineering standard you set across teams, a cross-platform framework evaluation you led with evidence behind the recommendation, or a major mobile programme you led rather than a single feature within one.
Write a mobile engineering standard spanning teams, and evaluate and recommend a cross-platform approach with real evidence behind it, not just a preference. Leading a programme, not just a feature, is what tends to define this level from the outside.
6
Level 6: Initiate & Influence
“I define mobile engineering direction and platform strategy at an organisational or industry level.”
At the top, the evidence is strategic: organisation or industry-level mobile strategy you set, external recognition for mobile engineering work, or platform strategy that shaped decisions well beyond your own team.
From here, publish your mobile engineering thinking externally, set platform strategy at the organisation level, and expect to represent mobile engineering at the leadership table more often than you write a screen yourself.
Go deeper
A weekly roundup of iOS development news and articles.
The Android equivalent, a weekly digest of the ecosystem.
Apple's developer conference sessions, most freely available afterward.
Knowing where you sit is one thing, proving it later is another. Fennec lets you log mobile development evidence as you go, a shipped feature, a decision, a review, tagged to the level it demonstrates, so the case for your next step is already made when you need it.