What does a path to staff look like in a coding-heavy environment?

There are definitely paths to Staff that are more technical, and given the top-down nature of Apple, it seems like there's a bias toward that archetype. Check out the archetypes from the StaffEng book. Perhaps the "solver" archetype is what Apple values from software engineers.

One thing that may be instructive is to look at existing Staff engineers in your team and org (I imagine you probably only have 1 staff eng on your immediate team). How do they spend their time, and what's the 1-liner for why they got promoted to that level?

You mention you spend 90% of your time coding, which is not inherently a bad thing, but I'd want to make sure that you also spend enough time ensuring that people within/outside your team are aware of your technical expertise in whatever it is you're doing. Similar to the other Staff engineers, would people be able to describe a 1-liner for what your most impactful work is?

Do you feel confident in being able to do that with the remaining 10%? It's possible, but I'm a bit skeptical given that you probably have team meetings, 1:1s, and general overhead around task management + reporting.

I recommend checking out this write-up of Meta's staff engineer archetypes.

There are 3 more technical archetypes that could fit here:

• Fixer - This is "solver" as Rahul mentioned. The idea is that you fix the bugs few others can, and what this means for staff is that the fixes you put out would have been extremely difficult or impossible for an ICT2, ICT3, or ICT4. How I saw this play out at Meta is that these engineers would vacuum up those complex bugs people couldn't figure out + ignored and be extremely active in the oncall process and SEVs (production events). I spent a lot of time developing fixer behavior a lot at Meta and found it to be fun - It's like playing detective! I shared a lot of thoughts in this Q&A around my thought process when it comes to debugging: "How can I root cause bugs faster?"
• Specialist - This means going deep on a technically complex and niche area and becoming an organization renowned (I define "organization" as everyone under your director at the very least) expert on it. There's generally some areas of every tech stack that are inherently more difficult and finicky than others. For Android, an example was video infra. It is so hard to get video to play properly and with low latency/decent quality, especially when you're working with bad network connections like Meta does across its family of apps. Try to find the equivalent of video infra for Android in your space and make it your goal to become a master there. You can leverage your manager and other senior/staff engineers in your org to get an understanding of what this area may be.
• Code machine - This one's the most straightforward to understand: You simply write a ton of code. However, it's more than just volume - The code should be good quality and working within very technically complex areas. From my experience, a staff-level code machine has the same code output as 3-4 strong senior engineers at least. I had a reputation as a code machine back at Meta, and I shared a bunch of my techniques/learning around how I did that here: "How can I write great code faster?"

Lastly, I highly recommend watching the following video from Airbnb's Head of Search Engineering, Rachel Zhao: What's the Difference Between A Senior And Staff Engineer?

There's also a bunch of great senior->staff resources linked in the description of that video, and those should help further clarify what Big Tech Staff Engineer behavior really looks like.