The Walls That Stop A Prototype: Signing, SDK Mismatch And The Review Queue

Mostafa Dhouib·10 min read

The Walls That Stop A Prototype: Signing, SDK Mismatch And The Review Queue

The short answer. A one-week prototype rarely fails because the code was hard. It fails because of three walls that have nothing to do with code: getting a binary signed and notarised so it will run on a machine that is not yours, a mobile SDK version that does not match the runtime inside the client's own application, and a review or approval queue that moves on its own timetable regardless of your deadline. Each of these is typically discovered on day four, when the build is done and someone tries to put it on a real device. Each can cost more than the entire build. Hit all three on day one, with a trivial program, before writing anything that depends on them.

The pattern is consistent enough to plan around. Days one to three go well. The hard technical question gets answered, often earlier than expected. Then the thing has to leave the developer's machine, and the week ends.

What follows is not a complaint about platforms. The gates exist for defensible reasons. The mistake is treating them as deployment steps rather than as feasibility risks, which puts them at the end of the plan instead of the start.

Wall one: the binary will not run on their machine

The first time the prototype runs anywhere other than the machine that built it, it gets stopped. Not by a bug. By the operating system declining to execute an unsigned or unnotarised binary from an unidentified developer.

Signing and notarisation are each straightforward on their own and together they form a chain with several links that can be missing.

An account or membership that someone has to hold. On desktop and mobile platforms, signing identities belong to an enrolled organisation, and enrolment can involve a legal entity check with its own processing time. If the client does not already have one, that is not a half-hour task. If they do, the person who controls it may be on leave.

A certificate that has to be issued, installed and kept available. Issued to a named individual or a team, stored somewhere the build can reach it, and valid. An expired certificate behaves like a missing one.

Notarisation as a separate round trip. On at least one major desktop platform, signing is not sufficient. The binary is submitted to the vendor, scanned, and a ticket returned. It is usually quick and it is not instant, and it can reject for reasons that require a rebuild, such as a dependency that is itself unsigned or a hardened runtime setting that conflicts with something the prototype does.

Entitlements that conflict with what the prototype needs. The exact capability under test, device access, local network access, raw USB or serial, may require an entitlement that triggers extra review or is simply not granted for an ad-hoc build.

The last one is the genuinely dangerous link, because it can turn out that the thing you are prototyping cannot be shipped in the form you prototyped it, no matter how well the code works.

Wall two: the SDK does not match the client's runtime

This one hides better than signing, because everything works in isolation.

You write against a device or service SDK. It builds, it runs, your tests pass. Then it goes into the client's actual application, and the application is on an older platform version, or a different build toolchain, or it already depends on a library that the SDK also depends on at a different version. The prototype now has to live inside a runtime you do not control and did not choose.

The failures are specific and consistent.

Minimum platform version. The SDK requires a newer platform version than the client's application currently targets. Raising that target is not a prototype-sized change, because it affects every other part of their application and their own supported device list.

Toolchain and language runtime mismatch. A binary framework built with one compiler version can refuse to link against a project using another. On some platforms this produces an error that names the compiler rather than the problem.

Transitive dependency conflicts. The SDK pulls in a networking or serialisation library that the host application already has at an incompatible version. There may be no resolution that satisfies both.

Architecture and simulator gaps. A vendor framework that ships without a build for the architecture the client's developers actually use, so it cannot be run on their machines even though it works on a device.

Permissions and background execution. The capability works while the application is in the foreground and stops when it is not, which for a telemetry-style prototype is the difference between a yes and a no.

None of these appear while the SDK is in a project of your own making. All of them appear the first time it goes into theirs.

Wall three: the queue has its own timetable

The third wall is not technical at all, and it is the one that cannot be engineered around.

Distribution to real devices often passes through a review step. A tester build on a mobile platform may need a review pass before external testers can install it. A hardware integration may need a partner's approval. An internal deployment may need a security review, a change advisory board, or a vendor onboarding process at the client's own organisation.

Three properties make these especially bad for a one-week engagement.

The duration is not under your control and is not reliably predictable. It is usually short. It is occasionally not, and the variance is what kills schedules rather than the mean.

Rejections restart it. A rejection for a missing privacy declaration or an incomplete form costs a full cycle, not a few minutes.

The entry requirements are discovered on entry. Submission asks for things nobody knew were needed: a privacy manifest, an export declaration, a named contact, a signed agreement between two companies. Each of those can involve a person who is not on the project.

We have seen a prototype finished on time and still miss the deadline, because a vendor onboarding form at the client's own organisation took longer than the build did. The engineering was never the bottleneck.

Front-load all three on day one

The fix is simple, unglamorous, and almost always resisted, because it looks like spending the first day of five on something that is not the product.

Build and ship a trivial program through the entire real path, first. A program that prints its own version number. Sign it, notarise it, submit it, get it onto the actual target device by the actual intended route. You are not testing the product. You are testing the pipeline, with a payload small enough that nothing about the payload can be blamed.

Put the SDK into their project, not yours, on day one. Before writing any feature, add the dependency to a copy of the client's own application and compile it. Everything you need to know about version mismatches surfaces in that first compile, and it surfaces while there is still time to pick a different approach.

Start every queue immediately, with a placeholder. Submit the trivial build for review. Begin the vendor onboarding. Request the entitlement. These run in parallel with the build and cost almost nothing to start early. Starting them late is the only expensive option.

Name the owner of each gate, with a contact. Not a team, a person, with a way to reach them during the week. Half the delay in these gates is waiting for someone to notice a request.

Write each wall into the plan as a risk with a stated fallback. If notarisation is refused, what do we demonstrate instead? If the SDK cannot go into their application, do we test the device link from a standalone harness and accept a narrower verdict? Decide in advance, because deciding on day four under pressure produces the demonstration-instead-of-verdict outcome.

A day spent on this looks expensive on Monday. It is the cheapest day in the week by Friday.

The honest limit

What we are describing is a pattern across engagements, not a measured result. We are not claiming a percentage of prototypes that fail this way or a number of days lost, because we have not instrumented that and would be making it up. The claim is narrower and we are confident in it: on short prototypes the gates have cost us more schedule than the code has, repeatedly.

The specifics also date quickly. Signing requirements, notarisation behaviour, review durations and SDK support matrices all change, sometimes between the quote and the kickoff. Treat the three categories as durable and verify the details yourself each time, on day one, which is the advice anyway.

And front-loading has a real cost that is easy to gloss over. A day spent proving the pipeline is a day not spent on the technical question, and on a genuinely short engagement that is a quarter of the available time. If the technical risk is extreme and the distribution path is one you have used for this client before, spending the day the other way round is defensible. The error is doing it by default rather than by decision.

FAQ

What usually delays a one-week prototype? Not the code. Three gates that have nothing to do with the code: getting the binary signed and notarised so it runs on a machine that is not the one that built it, a mobile SDK that does not match the platform version or toolchain inside the client's own application, and a review or onboarding queue that runs on its own timetable. Each is typically found on day four and each can cost more than the build.

Why is code signing a feasibility risk rather than a deployment step? Because the chain has links that are not under your control and are not quick. An enrolled organisation account, a certificate issued to a named person, a notarisation round trip that can reject, and entitlements for the exact capability under test. That last one can reveal that the thing you prototyped cannot be distributed in the form you built it, which is a feasibility answer, not a packaging detail.

How do I catch an SDK version mismatch early? Add the dependency to a copy of the client's own application and compile it on day one, before writing any feature. Mismatches in minimum platform version, compiler or language runtime, and transitive dependency versions all surface in that first compile. They never surface in a project of your own making, because there you chose every version yourself.

What should I submit to a review queue on day one? A program that prints its own version number, taken through the full real path: signed, notarised, submitted, installed on the actual target device by the actual intended route. The point is to test the pipeline with a payload too small to be blamed for anything. Start the vendor onboarding and entitlement requests at the same time, since they run in parallel for free.

Is spending the first day on gates ever the wrong call? It can be. On a five-day engagement that day is a quarter of the time, so if the technical risk is severe and you have taken this exact client through this exact distribution path before, spending the day on the technical question is defensible. The error is choosing that order by default instead of deliberately, which is how the gates end up on day four.

What if a gate cannot be cleared inside the week? Decide the fallback in advance and write it into the plan. If notarisation is refused, name what you will demonstrate instead. If the SDK will not go into their application, decide whether a standalone harness that tests the device link yields a narrower but still useful verdict. Deciding this on day four under deadline pressure is how a feasibility engagement turns into a demonstration.