On this page 9 sections
Freelancer, agency or in-house?
Each suits different situations:
- An independent developer gives you direct contact with the person writing the code, usually lower overheads and quick decisions. The risk is capacity: one person can only do so much, and you depend on their availability.
- An agency offers a team: design, development for several platforms, project management and testing. It suits larger projects that need several disciplines at once. You’ll usually talk to a project manager rather than the developers.
- Hiring in-house makes sense when the app is central to your business and needs continuous development. It’s a long-term commitment, and you’ll need someone to judge technical candidates.
Many businesses start with an independent developer or agency to build version one, then decide whether to bring the work in-house once the app proves itself.
What to look for
Apps they’ve actually shipped
Ask for apps on the App Store that they built, and download them. Use them. Do they feel solid? Do they handle bad connections, large text and dark mode? Look at the release history on the App Store page: regular updates suggest the developer looks after their work.
Check that they did the work themselves, and which parts. “Worked on” can mean anything from the whole app to a single screen.
Relevant experience
Experience with your type of app matters more than years in the industry. A developer who has built Apple Watch apps understands the constraints of the wrist; one who has built payment flows knows the edge cases of refunds and failed cards. Ask about the parts of your project that worry you most.
How they communicate
During the first conversations, notice whether they:
- ask questions about your users and business before talking about technology;
- explain trade-offs in plain language;
- tell you when something is a bad idea, or not needed yet;
- put things in writing: what’s included, what isn’t, what happens next.
The developer who says yes to everything in the first call is often the one who has the hardest conversations later.
How they work
Ask how they’ll show progress. Good answers include regular TestFlight builds you can install on your own phone, a shared task list and short demos. “You’ll see it at the end” is a warning sign: you want to find problems in week two, not week twelve.
Ask about quality practices: automated tests, accessibility, privacy, code review. You don’t need to judge the technical details, but you should hear that these are part of the plan and in the estimate. The articles on testing, accessibility and privacy and App Review explain what good looks like.
Questions to ask
- Which of your published apps are most like mine, and what was your role in each?
- What would you build first, and what would you leave until after launch?
- What’s included in your estimate, and what isn’t? Design, backend, testing, App Store submission, support after launch?
- How do you handle changes to scope once we’ve started?
- How often will I get a build to try, and how will we communicate?
- Who will actually write the code? Will any of it be subcontracted?
- What happens after launch? How do you handle bugs, iOS updates and maintenance?
- Who owns the code, designs and accounts at the end?
- Native or cross-platform for this project, and why? (See Native iOS or cross-platform?.)
- What do you see as the biggest risk in this project?
The last question is one of the most revealing. A thoughtful answer shows they’ve understood your project; “there are no real risks” shows they haven’t.
Ownership: protect yourself from day one
This is the part most often overlooked, and the hardest to fix later.
- Apple Developer account. Enrol in the Apple Developer Program in your own name or your company’s name, and invite the developer to your team in App Store Connect with an appropriate role. The app should never be published under the developer’s or agency’s account.
- Source code. Insist on access to the code repository throughout the project, in an account you control, such as your own GitHub organisation. Weekly access to the real code is worth more than a promise of a handover at the end.
- Intellectual property. The contract should assign the rights in the code and designs to you on payment. Libraries and tools the developer already owns may be licensed rather than assigned; that’s normal, as long as the licence lets you keep using and changing the app.
- Third-party services. Accounts for hosting, databases, analytics, email, maps and payment providers should be in your name, with the developer invited as a user.
- Credentials. Keep a list of every service the app uses and who has access. Use a password manager to share access, never email.
- Documentation. Ask for a short README covering how to build, test and release the app, so another developer could pick it up.
If you take one thing from this article, take this: you should be able to change developer without losing your app.
Red flags
- Reluctance to show apps they built, or to explain their role.
- A quote with no breakdown, or one that is dramatically lower than others with no explanation of what’s been left out.
- No mention of testing, privacy or App Store submission.
- They want to publish under their own Apple Developer account.
- No access to the code until the final payment.
- Pressure to sign quickly or pay a large proportion up front with nothing to see.
- They can’t explain technical choices in plain language.
Structuring the engagement
A sensible structure for a new app:
- A short paid discovery phase. Requirements, wireframes, a technical plan and an estimate for version one. You own the outputs and could take them to another developer.
- Build in milestones, each ending in a TestFlight build you can try, with payment tied to milestones.
- Launch support through App Review and the first weeks after release.
- An agreed arrangement for maintenance, whether ongoing or as needed. The maintenance guide explains what that should cover.
This keeps risk small on both sides: you see progress continuously, and the developer has a clear scope for each stage.
Reading a proposal
When proposals arrive, read them for what they reveal about how the developer thinks, not just the total:
- Do they restate your problem in their own words? If the summary of your project is copied from your brief, they may not have thought about it.
- Is the scope broken down into features or milestones you recognise, with what’s out of scope listed too?
- Are assumptions written down? For example, “you’ll provide the copy and images” or “the existing booking API supports cancellations”.
- Do they suggest anything you didn’t ask for, or suggest leaving something out? Good developers push back where it saves you money.
- Is there a plan for testing, accessibility, privacy and App Store submission?
- What happens after launch? Warranty period for bugs, maintenance options, response times.
If two proposals differ a lot in price, compare their assumptions line by line. The difference is usually in what’s been left out.
Consider a small paid first step
If you’re unsure between two developers, or about working with someone new, start with something small and paid: a discovery phase, a clickable prototype, or a technical review of an existing app. You’ll learn how they communicate, how they handle feedback and whether they deliver what they said, before committing the whole budget. A developer confident in their work will usually welcome it.
Key takeaways
- Choose on shipped apps you can use, relevant experience and clear communication, not on promises.
- Ask what’s included, how change is handled and what happens after launch.
- Own your Apple Developer account, code repository, service accounts and intellectual property from day one.
- Watch for red flags: no portfolio, vague quotes, no access to code, publishing under their account.
- Start with paid discovery and build in milestones you can test.
I’m an independent developer building Apple Watch, iPhone and Mac apps in Swift and SwiftUI. You can see my own apps on the apps page and the products I build and run on the projects page. If you’d like to see whether we’d be a good fit, start with a short message. I’ll tell you honestly if I’m not the right person for the job.
Written by Lee Johnson. Published 30 October 2026.