From idea to production
Every Mobile SDK module follows the same path on Android and iOS, from getting set up to going live in an FI's app. You build and test the module. Q2 reviews it, builds a test version of the real app with your module inside, and releases it. The FI then asks for it to be included in their app.
Each step below shows what happens on both platforms. Where Android and iOS differ, the details sit in the green Android and blue iOS boxes.
- 1Get set upAccounts, repository, and tools.
- 2Build and testDevelop in the DevApp.
- 3Submit for reviewMerge request and ticket.
- 4Test buildTry it in the real app.
- 5ReleaseQ2 releases a version.
- 6Go liveThe FI adds it to their app.
The steps
1
Get set up
You
Before anyone writes code, your team needs access to Q2's developer tools and a place for your module to live.
- Make sure you have a Q2 Developer Portal account. It is where you open support tickets and submit modules for review.
- Confirm you can sign in to Q2’s GitLab, where the code lives. Access comes with your portal account.
- Open a support ticket in the portal to request your module repository, and a GitLab group if your organization doesn’t have one yet.
- Request a sandbox, your own test environment, through a support ticket. Your Q2 representative gives you its address.
- Set up your computer and the DevApp, a local stand-in for the Q2 Mobile App. You can start this before your repository is ready.
2
Build and test
You
Develop your module and test it in the DevApp until it is complete.
- Create a branch from
master. Any branch name that suits your team works. - Build your module and try it in the DevApp against your sandbox.
- Keep going until every feature works and passes your own testing.
Android
- Test a release-style build with code shrinking (R8/ProGuard) turned on. Modules that skip this can crash in production.
- If your module uses private libraries, submit them to Q2 for hosting.
3
Submit for review
YouQ2
Ask Q2 to review your module by opening a merge request and a support ticket in the Q2 Developer Portal.
- Open a merge request from your branch into
master. - Open a support ticket so Q2 knows your module is ready for review.
- Q2 reviews your code. If changes are needed, Q2 leaves feedback, you fix them in your branch, and Q2 reviews again.
Android
- Open the merge request first, then the ticket.
- Ticket title:
[Android] Review | module-name | MR#. Include the merge request link, a summary of changes, the test environment you want, and any changes to your module’s settings. - The review checks security, safety, and stability. It is not a code quality audit.
iOS
- Open the ticket first, then the merge request.
- Ticket title:
[iOS] Release | module-name | x.y.z. Include the online banking URL to test against, and ask for a minor or major version if you need one. - Merge request title:
[Ticket #123] [iOS] Release | module-name | x.y.z.
4
Test build
Q2You
Once the review is approved, Q2 merges your code into master and builds a test version of the real Q2 Mobile App with your module inside. You test it.
- Test your module in the test build. Issues that didn’t show up in the DevApp can appear here.
- If something needs fixing, fix it in a new branch and submit it for review again.
- When everything works, record a short video of your module’s workflow in the test build and add it to your ticket. See the release criteria.
- Confirm on your ticket that the module is ready for production.
Android
- The test build points at the environment you chose in your ticket: Sandbox, SDX, or PTE.
- It is built the same way as production, with code shrinking turned on.
iOS
- The test build is delivered through TestFlight, and you are notified on your ticket.
- Partners with a brand-new module first set up a test app in their own App Store Connect account and give Q2 access.
- FIs don’t need extra setup. The module is added to their existing TestFlight app.
5
Release
Q2
Q2 merges master into production and tags the release with a version number. You are notified when your module is released.
Android
- After Q2 tags the release, the FI submits a deployment request (next step).
iOS
- Q2 picks the next patch version unless your ticket asked for a minor or major version. Changes that affect how others use your module need a major version.
- Some new versions must be approved (whitelisted) for a Q2 Mobile App release before FIs get them. For new modules on app version 26.5.0 and later, this applies to major versions only.
6
Go live
FI
The FI asks Q2 to include the released module in their app by submitting an SDK Deployment Request in the Q2 Developer Portal.
- Only the FI can submit the deployment request. Partners coordinate with the FI once Q2 confirms the release.
- The module ships in the FI’s next app build on the App Store and Google Play.
- For a partner’s first release, the module is listed in the Q2 developer Application Catalog, where FIs can request it.
Android
- Ticket title:
[Android] Deploy | module-name | version, with your module’s settings.
iOS
- A new partner module is available for the next Q2 Mobile App release.
- A new FI module is available for the FI’s next build once the Q2 Mobile App finishes its release.
Good to know
- Two protected branches.
masteris used for test builds andproductionfor releases. Every change goes throughmasterand a test build first; you can't merge straight to production. - Changes after release follow the same path: a new branch from
master, a new review, and a new test build. - Not sure about something? Open a support ticket in the Q2 Developer Portal, not through standard Q2 technical support.