A client will ask you this, sooner or later: “So, how long does it take your developer to build the Apple Wallet badge?”
Pause.
That question tells me, in about two seconds, whether I'm talking to someone who's actually tried this or someone who's only watched it happen to somebody else. Because the honest answer is: no time at all, if the developer is working alone. Zero. Not because it's impossible. Development was never the hard part.
Let me walk you through why, because that's the part of this whole topic I actually find interesting.
A ticket and a key look like the same icon. They aren’t.
In Apple Wallet, a movie ticket and the badge that unlocks your office turnstile look more or less the same: a colored rectangle, a logo, a tap. Same family from the outside. Two different worlds underneath.
The ticket is a signed file the phone displays as a barcode. End of story. You open it, someone scans it, an optical reader validates it: the same reader that could just as easily read a printed piece of paper.
The badge can't get away with that. It has to talk to a door, in a response time the user experiences as instant, using a key that nobody, not even whoever wrote the app, can read or copy. That key lives isolated in a dedicated chip on the phone and never leaves it, and the physical reader has to be certified within the Apple program in its own right before it's allowed to talk to that chip. This isn't a minor implementation detail. It's a different product category altogether, with a different kind of certificate and a different approval process, completely separate from the one anyone can get by opening a developer account in ten minutes.
The real bottleneck doesn’t show up in Xcode
Here's the pre-sales part, the bit that's actually my job. When someone puts “Apple Wallet integration” on a timeline as just another line of development, they're underestimating exactly the part that takes the most time: not writing code, but getting through a selective admission process: as Apple itself documents on the program's official page, partners have to complete a due diligence track that is both business and technical, starting from an application form -- after which it's Apple that provides the documentation for the next steps.
And that's not even the end of it. Because there's a second party involved, one that gets left out of proposals more often than it should: whoever manufactures the physical reader on the door. That piece of hardware needs its own certification, independent of whoever issues the software badge. Two tracks, two timelines, two different counterparts that both have to line up.
Anyone who doesn't know both exist inevitably ends up promising a delivery date that won't hold. It's the kind of promise that takes five seconds to write on a slide and months to pay for in a project.
Being the same company doesn’t get you a shortcut
Here's a real, publicly announced case: Zucchetti is today an Apple-approved and certified partner for issuing, managing and reading NFC passes in Apple Wallet, and the first Italian software house to enable digital workplace access via Apple Wallet. It's also why this topic hits closer to home for me than most: Zucchetti Axess, the company I work for, sits on both sides of the table -- the software badge and the readers that scan it. Same company, two roles.
You'd expect that to cut the paperwork in half. Same roof, same commercial contact for the end client. So why would you still need two separate approvals?
Because Apple doesn't certify a company. It certifies a role. The fact that the software and the hardware come out of the same building doesn't merge the two approval processes into one: they stay two separate tracks, with two separate reviews, even when Apple is dealing with the same counterpart on both sides of the table. It's a process choice I honestly find sensible: certification evaluates what that piece of software or that piece of hardware does, not who owns it.
The part I like best, as an engineer on loan to sales
There's a technical detail here I find genuinely elegant: the exact same security principle (a key generated inside an isolated chip, never exportable, never readable even by the operating system) applies both to the badge that opens your office and to the car key you unlock with the same phone. Same architecture, same underlying reasoning, applied to a turnstile or to a car door. Whoever designed this didn't invent a different solution for every use case. They built one solid foundation and put everything else on top of it.
That's the kind of architectural choice that, once you explain it properly to a client, changes the conversation. You're no longer selling “a nice-looking digital badge.” You're selling a security model that someone else has already stress-tested at global scale, one you're simply configuring for the specific case in front of you. That's a massive difference in terms of trust. It's also why these projects, once you set expectations on timing correctly, are easier to sell.
So, how long does it actually take
I don't know exactly, and honestly I don't trust anyone who gives you a confident number off the top of their head. It depends on who manufactures the readers already installed, how close they are to being certified, how long Apple takes to review your specific case. What I do know is that the real clock starts running before anyone opens a code editor.
And if someone asks me that question again in an elevator, with that same “so how long does your developer need” look on their face, at least now I know exactly where to start explaining it.
Small mercies.
The opinions expressed in this article are my own and do not represent official positions of the Zucchetti Group. Information about the Apple Wallet program comes from Apple's public documentation; information about Zucchetti comes from the official press releases linked in the text.