Services

Because every update goes through review again, and the rules move between updates. A new feature adds a permission that needs a purpose string, an SDK update changes what data the app collects and the privacy declaration falls out of sync, a new login provider triggers the sign-in and account-deletion rules, and Apple and Google revise their policies several times a year. A team that submits once a year meets each change as a rejection. A team that submits every month has already met it, which is why we handle submissions inside a development membership rather than as a one-time launch task.

Everything a stranger needs to reach every feature your description promises: a working demo account on the same environment as the build, with multi-factor turned off; the steps to any feature hidden behind a gesture, setting, or account state; sample data or test instructions for features that depend on a purchase, a paired device, or a region; and a short explanation of anything unusual, like a login exemption you're relying on. Reviewers are strict when they have to hunt and reasonable when they're given a map. Write the notes last, from the final build, and test the demo account on a clean device the morning you submit.

Yes, if users can create an account in the app. Apple requires in-app account deletion under guideline 5.1.1(v), and Google Play has a matching account deletion requirement, including a web link where users can request deletion without reinstalling. An email address for deletion requests doesn't satisfy either store, and neither does a deactivate-only option. Build it into account settings from the first version, make it remove the account and its data (with the usual carve-outs for records you're legally required to keep), and tell the user what happens next if the backend takes time. It's a small feature to design in and a predictable rejection to retrofit.

If a third-party or social login creates or signs in to the user's primary account, Apple's guideline 4.8 requires an equivalent option that limits data collection to name and email, lets users keep their email private, and doesn't track them for advertising without consent. Sign in with Apple meets all three, which is why adding it is the standard fix, though the rule describes conditions rather than mandating Apple's button. Apps using only their own email-and-password system, and enterprise or education apps built on existing organization accounts, are exempt. Decide this before the login screen is designed; adding a provider later means a new build, a new review, and account deletion for the new accounts.

You get a message in App Store Connect's Resolution Center citing the guideline, usually with a screenshot, and you choose between fixing the build and resubmitting, or replying with an explanation if you believe the reviewer missed something. Metadata problems can sometimes be fixed without a new binary; anything that changes the app itself needs a fresh build and a new review. Treat the reply as part of the fix. A clear note that walks the reviewer to the feature they couldn't find clears more resubmissions than code changes do, and if you disagree with a decision you can escalate to the App Review Board.

Usually, yes. There is no federally approved list of TABA vendors; you propose one and the agency reviews the request. Common requirements are that the vendor be a legal U.S. business and not your own company, an employee, or an affiliate or investor of yours, and agencies with a default provider may ask you to justify going outside it. Since your chosen vendor goes into a federal proposal under your name, vet them the way the agency will: fixed price and deliverables in writing, named people doing the work, and everything they produce owned by you.

At most agencies, inside your Phase I or Phase II proposal: a named dollar amount in the budget, a justification describing the services and expected benefits, and usually the identified vendor. The variations matter, so read the TABA section of your agency's current solicitation first. Some agencies route the assistance through a preferred vendor unless you justify your own choice, some have allowed funds to be added to an existing award by administrative supplement, and some won't accept a TABA request after the application is submitted. If you're already past submission, ask your program office what's still possible.

Often, yes, when the software is the commercial expression of the research your agency funded. The statute's stated purposes include developing and commercializing the products that result from the project, and product definition, prototyping, and production development are commercialization work in that plain sense. Agencies interpret eligible uses through their own solicitations, though, so frame the request in commercialization terms and confirm it with your program office before counting on it. Worth knowing: most established TABA vendors deliver reports, and a product real customers can use is often the stronger commercialization evidence.

Up to $6,500 on a Phase I award and up to $50,000 on a Phase II award, generally in addition to the research award itself. The exact amounts, whether the funds come on top of or inside your award, and the request process all vary by agency, so your agency's current solicitation is the authority. One practical effect of the caps: they make fixed-price vendor work easy to justify, because a TABA budget line wants a specific dollar figure and a described deliverable, which is exactly what a fixed-price engagement puts in writing.

TABA stands for Technical and Business Assistance: supplemental federal funding that SBIR and STTR awardees can request to pay outside vendors for help commercializing their funded research. It was created by the fiscal 2019 National Defense Authorization Act and extended by the 2026 SBIR/STTR reauthorization, and it sits on top of the research award rather than inside it. Think of it as the program admitting that funded research doesn't become revenue on its own. The money exists so you can buy the commercial expertise your research team doesn't carry, without spending R&D dollars to get it.

Yes. The standard pattern is to keep the current app running (with critical fixes only) while the new version is built in parallel, then ship the rebuild as an update to the same store listing so you keep your ratings, reviews, and install base. Users download an update, their accounts and data carry over, and nothing resets. The cutover plan deserves as much scrutiny as the build quote: ask for the migration steps, the rollback plan, and who handles store review in writing.

Source code and repository access, app store and developer accounts, backend and database access, third-party service credentials (payments, analytics, push), any documentation, and the contact for whoever built it, if they're reachable. Gaps are normal; a good takeover partner lists what's missing and works around it. Before you hand anything over, confirm you actually own the accounts and the code under your current contract. If the old developer controls the store listing or the repo, recovering access is the real first project.