Industry
Yes. Supply businesses and cooperatives run B2B complexity that retail tools ignore: account-specific pricing, seasonal demand, deliveries, and members who order from the field. We build ordering portals, inventory visibility across locations, delivery coordination, and member accounts, connected to the accounting or ERP system already in use. A rep should be able to check any promise in the system before making it. Retail platforms rarely stretch this far, so ask hard questions before assuming one will.
Why do app store rejections keep happening after the first launch?
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.
What should I put in the App Review notes?
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.
Does my app need an in-app account deletion feature?
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.
Do I need Sign in with Apple if my app offers Google or Facebook login?
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.
What happens after an app is rejected from the App Store?
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.
Can I choose my own TABA vendor?
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.
How do I request TABA funding from my agency?
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.
Can TABA funds pay for software development work?
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.
