Building an iOS app for a research study: a practical guide

A study app is a measurement instrument that happens to run on a phone. Treat it like a questionnaire or a sensor rig: decide what it measures, how you will know it measures that, and what happens to the data. The code comes after those answers, and it is often the smaller part of the work.

Apple's open source ResearchKit framework has been the usual starting point for iPhone studies since 2015. It handles consent screens, surveys and sensor tasks, so you do not have to build them from scratch. What it does not handle is your backend, your ethics paperwork, your recruitment bias or the person who will fix the app when a new iOS version breaks it.

That last point decides more projects than any framework choice. A lab can build a pilot with a PhD student and a template, hire a research software engineer, or bring in an outside iOS app development team when the study needs a production app with a server, security review and support for the full recruitment window. This guide covers each option, and the questions to settle before anyone opens Xcode.

What does ResearchKit give you?

ResearchKit gives you three ready-made modules for the participant side of a study: consent, surveys and active tasks. It is released under a BSD license and lives on GitHub, where the current README lists Xcode 16 and a base SDK of iOS 17 as requirements.

• Consent. Screens that walk a participant through the study, check comprehension and capture a signature.
• Surveys. Questionnaire steps with standard answer formats: scales, multiple choice, dates, free text.
• Active tasks. Short, semi-controlled activities that record phone sensors while the participant does something, such as walking, tapping or speaking.

Three neighbouring Apple frameworks usually appear in the same project. HealthKit reads health data the participant agrees to share, one data type at a time. CareKit is aimed at care plans and symptom tracking over time. SensorKit exposes extra research data types but needs a separate entitlement from Apple and explicit participant consent, according to Apple's research FAQ.

The same FAQ is clear about some limits. Raw ECG data and real-time heartbeat data are not available through HealthKit. Higher-frequency heart rate is available during workouts and ECG sessions, or through SensorKit. If your protocol depends on a signal, check that the platform actually exposes it before you write the grant.

Which route fits your study?

The right route depends on how custom your measures are and how long the app must stay alive. A cross-sectional survey and a two-year cohort with wearable data are very different software projects, even if both start with a consent screen.

Route	Fits when	Watch out for
Apple's Study App Template	Standard tasks, small team, little or no coding capacity	Access is by application; you are limited to what the template supports
In-house ResearchKit app	You have a developer or RSE and custom tasks	Maintenance after the developer leaves; backend still to build
Outside development team	Large recruitment, a server, security review, a fixed deadline	Code ownership, license and handover terms in the contract
Cross-platform app	You must recruit on Android too	ResearchKit is Apple-only; sensor and health access need native modules
Web survey tool	Questionnaires only, no sensors	No access to phone sensors or health data

Many studies combine routes. A common pattern is web surveys for screening and a phone app only for the sensor tasks, which keeps the app small and the review simpler.

What will the ethics board and Apple ask for?

Ethics boards and Apple both ask for the same core things: informed consent, a clear account of data handling and independent ethics approval. Apple writes these into its App Store Review Guidelines. Guideline 5.1.3(iii) says consent for health-related human subject research must cover:

1. the nature, purpose and duration of the research;
2. procedures, risks and benefits to the participant;
3. confidentiality and handling of data, including any sharing with third parties;
4. a point of contact for participant questions;
5. the withdrawal process.

Guideline 5.1.3(iv) adds that such apps must secure approval from an independent ethics review board, with proof provided on request. For minors, consent comes from a parent or guardian.

Write the consent text with your ethics board before the developer builds the screens. Changing an approved consent flow later usually means an amendment, a new app build and another App Store review. Withdrawal also needs real code: a button in the app, a way to stop collection and a defined process for what happens to data already received.

Where does participant data go?

Participant data goes wherever your app sends it, because ResearchKit has no server of its own. The framework produces result objects on the phone; moving them to secure storage, linking them to a pseudonymous participant ID and exporting them for analysis is your job.

Settle these points in the protocol and the data management plan, then build to them:

• Destination. Name the server or service, its location and who administers it. Institutional infrastructure is often easier to get approved than a new commercial account.
• Identifiers. Keep names and contact details apart from measurement data, linked only through a study ID.
• Encryption. In transit and at rest, with keys kept out of the app's source code.
• Versioning. Store the app version and task version with every record. When a survey item changes mid-study, you need to know which answers came from which wording.
• Export format. Agree on a flat, documented format for analysts on day one, not after the first data lock.

Apple's FAQ also describes a HealthKit Research Entitlement that removes a 30-day access limit and reduces repeated permission reminders for approved research apps. It does not gate access, but long studies that read historical health data should look at it early.

How should you plan the build?

Plan it in the same order as the study, so that the software follows the protocol rather than the other way round.

1. Fix the protocol first. List every measure, its schedule and its validated source. A survey you translate or shorten is a new instrument, and reviewers will ask about it.
2. Map each measure to a step. Survey item, active task, HealthKit type or passive sensor. Anything that maps to none of these is custom development.
3. Prototype with the catalog app. ResearchKit ships an ORKCatalog sample app that shows every built-in step. Clicking through it with your team is the quickest way to see what is free and what is not.
4. Build the backend alongside the app. A phone app that cannot deliver data is not a pilot.
5. Test with real people. Run a small pilot through TestFlight with colleagues and a few participants, and log every point where someone hesitates.
6. Choose distribution. Apple allows unlisted App Store distribution, reachable only by direct link, which suits studies with a defined recruitment channel.
7. Plan for iOS updates. Apple releases a major iOS version every year. Budget time to retest the app each autumn for as long as recruitment runs.

Automated tests are worth writing for the parts that compute anything: scoring a questionnaire, deriving a step count, converting units. Our guide to testing research code covers the habits that carry over directly to app code.

Does iPhone-only recruitment bias your sample?

Recruiting only through an iPhone app can bias your sample, and reviewers may well ask about it. iPhone owners are not a random slice of the population, so a study that recruits only through an iPhone app inherits whatever differences that group has in age, income and health.

The scale of app-based studies makes this easy to overlook. The mPower Parkinson disease study, built with ResearchKit and published in Scientific Data in 2016, enrolled more than 15,000 participants within weeks of launching in March 2015. The Apple Heart Study, led by Stanford researchers and reported in the New England Journal of Medicine, enrolled 419,297 people with an iPhone and Apple Watch. Large numbers do not remove selection effects; the Catalogue of Bias discussed exactly this point for the Apple Heart Study.

If your research question needs a representative sample, plan an Android or web arm, loan devices to participants who do not own one, or state the limitation plainly in the analysis plan.

When should you bring in outside developers?

Bring in outside developers when the study app has to behave like a product: thousands of participants, a server that must stay up, security review by your institution and a fixed launch date tied to a grant. A pilot with twenty participants is a reasonable job for a student. A multi-site cohort is not.

There are three common staffing models, and they can be mixed:

• A research software engineer inside the group or a central RSE team. Best continuity and domain knowledge. See our piece on research software engineers for how those roles work.
• An outside team for the build, with the research group owning requirements and data. Faster for a fixed scope, but the contract must cover handover.
• A hybrid, where an external team builds the first release and an RSE maintains it through the study.

Whoever writes the code, put these terms in writing before work starts: the institution owns the source code; the code can be released under an open license; credentials and infrastructure sit in institutional accounts; and the handover includes build instructions, tests and a short architecture note. Software costs belong in the grant budget from the start; our post on funding research software covers how to argue for them.

How do you keep the app reviewable and citable?

Treat the app's code as part of the methods. The tasks in it define how symptoms, movement or mood were measured, so readers need to see them in the same way they would want to see a questionnaire.

Keep secrets and participant data out of the repository from the first commit. Add a license, using our primer on choosing a license for research code if you are unsure which one fits. When the study launches, tag the release that participants installed and archive it with a DOI, so the paper can cite the exact version that produced the data.

What to do this week

Write a one-page table with every measure in your protocol, the step type it maps to and the data it produces. Mark each row as built-in, template-supported or custom. Then show it to your ethics contact and whoever will build the app. The custom rows are your real scope, and the conversation about who maintains them is the one to have first.