iOS - Module Whitelisting

When releasing or updating your iOS module for Q2MobileApp, understanding the whitelisting process is essential for ensuring compatibility and controlled deployment across Financial Institution (FI) app builds.

📋 Quick Reference

Version Update	Whitelisting Required	Action
Patch (1.0.0 → 1.0.1)	❌ No	Auto-picked if base version whitelisted
Minor (1.0.0 → 1.1.0)	✅ Yes	Must be explicitly whitelisted
Major (1.0.0 → 2.0.0)	✅ Yes	Must be explicitly whitelisted

Key Point: Only major and minor updates require explicit whitelisting. Patch updates are automatically included if the base version is already whitelisted.

Why whitelisting is required

1. Controlled Release Management

Whitelisting allows Q2MobileApp to control which module versions are available in each app release. This prevents unintended updates and ensures only tested and approved versions are distributed to FIs.

2. Compatibility Assurance

Major and minor version updates often introduce new features or changes that may affect app behavior. Explicit whitelisting ensures these updates are only included in app versions validated for compatibility, reducing integration risks.

3. Patch Version Handling

Patch updates (e.g., 1.0.0 to 1.0.1) are typically backward-compatible and contain minor fixes. If a base version (e.g., 1.0.0) is whitelisted, the app will automatically pick up the latest patch version without requiring explicit whitelisting for each patch.

4. FI Build Consistency

When an FI rebuilds their app targeting a specific Q2MobileApp version, only the module versions whitelisted for that app release will be included. This ensures consistency and prevents unexpected module upgrades in production environments.

Version Flow Diagram

Whitelisting Matrix

Update Type	Whitelisting Required	Auto-Picked by App	Notes
Major/Minor	Yes	No	Must be explicitly whitelisted per release
Patch	No	Yes	Auto-picked if base version is whitelisted

Decision Guide

Use this flowchart to determine if your module update requires whitelisting:

Version Timeline Example

Here's how different version updates flow through the whitelisting process:

Real-World Scenarios

1. Patch Update Scenario:

   • ✅ Module 1.0.0 whitelisted in Q2MobileApp 25.8.0
   • ✅ You release 1.0.1 (bug fixes)
   • ✅ FI builds targeting 25.8.0 automatically get 1.0.1

2. Minor Update Scenario:

   • ❌ You release 1.1.0 (new features)
   • ❌ Must be explicitly whitelisted in Q2MobileApp 25.9.0
   • ✅ Only available after Q2 team approval and inclusion in next release

3. Major Update Scenario:

   • ❌ You release 2.0.0 (breaking changes)
   • ❌ Requires explicit whitelisting and extensive testing
   • ✅ Available only in future Q2MobileApp releases after approval

---

Key Takeaways

Quick Summary

• Patch updates (1.0.0 → 1.0.1): ✅ Auto-picked, no whitelisting needed
• Minor/Major updates (1.0.0 → 1.1.0 or 2.0.0): ❌ Requires explicit whitelisting
• FI consistency: Builds always use the same module versions for a given Q2MobileApp release

Next Steps

1. Planning an update? Use the Decision Guide above
2. Need whitelisting? Contact the Q2 team with your module version details
3. Questions? Review the Version Timeline Example for scenarios

Benefits of this process:

• 🔒 Controlled deployments across all Financial Institution apps
• 🔄 Automatic patch updates for critical bug fixes
• 🧪 Thorough testing for feature and breaking changes
• 📈 Predictable release cycles aligned with Q2MobileApp schedule