Document toolboxDocument toolbox

App Store Release Checklist

Your Bridge iOS app has gone through development and QA, and now it's time to put it out there for the world to see. Are you really ready?

Production smoke test

Before getting here, you should have already gone through essentially this same process with the QA build pointed at the staging environment. In the future we intend to support client development and testing directly in production without polluting the data pool, but for now everything should be thoroughly vetted in staging before smoke-testing in production to minimize that "contamination."

  1. Make sure any necessary schedules, surveys, documents, etc. have been deployed to the production environment (in such a way as not to interfere with any current or previous app versions' functioning–that might be a whole document on its own). This should be done by a researcher, possibly in conjunction with a Bridge server engineer.
  2. Archive a non-QA, Release build. Make sure DEBUG is not defined as a preprocessor macro and that the app is pointing at the production environment.
  3. Export and upload it to the App Store for a TestFlight beta. This and the previous step will need to be done by an iOS client engineer. The remaining steps can be done by anyone with the time and knowledge of what's supposed to be in the app.
  4. Download the beta as an upgrade and check:
    1. Activity schedules look right
    2. Each activity and each survey works as expected
    3. Results of activities show up in the dashboard
    4. The news feed is pointed at the correct URL
    5. The Learn tab and all the pages depending on it look correct and have no typos
    6. The Profile tab:
      1. has the expected user info items, and they are getting/setting their information from HealthKit or not, as appropriate based on permissions
      2. settings items are all present as designed and each works as it's supposed to
      3. all necessary documents are linked (e.g. privacy policy, license info, copyright info) and correct
  5. Delete the app and re-download the beta as a "fresh install"
  6. Swipe through the study overview and verify that it all looks correct, any videos play all the way through, and there are no typos 
  7. Verify that signing in to an existing account works, and activity schedules still look right
  8. Delete and re-download again
  9. Sign up for a new account
    1. view the "learn more" on each step and verify that it looks right and there are no typos
    2. verify that answering questions incorrectly on the quiz at the end sends you back to the beginning
    3. after answering questions correctly, check that you receive an email verification link in your email. Don't click the link yet.
    4. verify that the "continue" button just tells you your email isn't verified yet and to check your email.
    5. verify that the "share" button takes you to the page to spread the word, and that you can get back from there to the verification page.
    6. click the verification link in the email, and verify the page it takes you to looks correct for this study and not like a placeholder.
    7. go back to the app and click the "continue" button.
    8. verify that the desired HealthKit permissions are requested.
    9. once verified, repeat at least 4.a. and 4.f.i. above

Submit to App Store

You've validated that the app and any necessary server-side resources are ready to go in the production environment. Now it's time to cross the i's and dot the t's. ...or the other one.

  1. You need to supply a full set of metadata in the app’s Versions pane, as described in Creating an iTunes Connect Record for an App. This can (and should) be started before, or at least in parallel with, the Production smoke test steps above. Getting all the required assets ready takes time.
  2. If this is an update to an existing app, notify the support team (currently Amy Truong <amy.truong@sagebase.org>) of the upcoming release and of any significant changes included. If it's a new app, notify them in what ways this app differs from previous apps.
  3. Submitting the app for final review is explained in Submitting the App to App Review. Always submit with the option for us to pull the trigger once approved, not for automatic release upon approval.
  4. Double check the territories in the Availability section. In most cases, the only territory should be the United States.
  5. Once approved by Apple, meet with all parties involved in the app (server team, client team, researchers, support, QA) and get a final go/no-go from each. Only release the app when the response is unanimously "go." Best to do so on a day early in the week when most of the engineering team will be on hand to deal with any unexpected problems that arise.