Skip to content

iOS - SDK Release Notes

v2.1.2.7011 Release Notes — 04.11.2026

[IOS SDK] [CONDITIONAL ACTION] [BACKWARD COMPATIBLE]

1. Release Summary

In this version, audio issues related to phone (GSM) calls during video calls (VideoCall) have been resolved: after a phone call, the call audio automatically resumes, the interruption/pause of the call audio while the SDK sounds are playing is prevented, and when an attempt is made to start a VideoCall during an active phone call, the integrator is informed with a new error code.

2. Customer Impact

Check Status Description
Does it affect implementation? Conditional Integrations using the VideoCall module are affected.
Is customer action required? Yes Integrations that show VideoCall initialization errors (initializeFailed) to the user are advised to handle the new error code (1018).
Is there a parameter or configuration change? No There are no new or removed parameters.
Is it compatible with existing integrations? Yes Backward API compatibility has been maintained.
Is testing required? Yes Scenarios for receiving/rejecting/ending phone calls during VideoCall and attempting to start VideoCall while in an active phone call should be tested.
Is there a deadline for transition? No —

3. Changes

Control for Starting VideoCall While Having an Active Phone Call

Component: iOS SDK (VideoCall / Core) | Type: Improvement

What changed? When attempting to start a VideoCall while there is an active phone (GSM) call on the device, the SDK does not initiate the call and informs the host application of the new InitializationError.activeSystemCall (error code 1018) via the initializeFailed callback.

Does it affect customers? Conditional. Only integrations using the VideoCall module are affected.

What needs to be done: Additionally handle error code 1018 in your initializeFailed callback and inform the user that they need to end the phone call and try again. Additional implementation changes are not mandatory for integrations that do not specifically handle this error code.

If no action is taken: If error code 1018 is not handled, the user may not receive meaningful information on why the VideoCall cannot be initiated.


Automatic Resumption of Call Audio After Phone Calls

Component: iOS SDK (VideoCall) | Type: Bug Fix

What changed? The issue where the call audio would be interrupted and not return when a phone (GSM) call is received or ended during a video call has been resolved. The call audio now automatically resumes when the phone call ends.

Does it affect customers? No. The change is automatically applied on the SDK side.

What needs to be done: No implementation or configuration changes are required. It is recommended to test scenarios for receiving, rejecting, and ending phone calls during VideoCall.


Fix for Call Audio Interruption While SDK Sounds Are Playing

Component: iOS SDK (VideoCall / Core) | Type: Bug Fix

What changed? The issue that allowed call audio to be interrupted or lowered while SDK sounds (e.g., agent waiting sound) were playing during a video call has been resolved.

Does it affect customers? No. The change is automatically applied on the SDK side.

What needs to be done: No implementation or configuration changes are required.

4. Known Issues

There are no known issues.


v2.1.2.7010 Release Notes — 22.10.2026

[IOS SDK] [CONDITIONAL ACTION] [CONDITIONAL COMPATIBILITY]

1. Release Summary

In this version, notifications are sent to the host application when Picture in Picture (PiP) mode cannot be initiated in a video call, and the issue of image freezing when PiP is off is resolved. Additionally, a new TUR_DEFAULT country option has been added which allows reading the Turkish ID and passport in a single stream, Public Key SSL Pinning has been made to work with different certificate types, the NFC reading progress indicator has been updated, and an OCR fix has been made for MRZ first/last name reading.

2. Customer Impact

Check Status Description
Does it affect implementation? Conditional Integrations using VideoCall (PiP), Public Key SSL Pinning, NFC reading, and OCR streams are affected.
Is customer action required? Yes Integrations that end the call in the default branch of the videoCallFailed callback need to additionally handle the new PiP state. The Backend version requirement should also be verified.
Is there a parameter or configuration change? Yes New, optional countryCode value: TUR_DEFAULT. Existing values have not changed.
Is it compatible with existing integrations? Conditional The behavior may change in integrations that end calls in the default branch of the videoCallFailed callback when PiP cannot be initiated. Backend requirement is being verified.
Is testing required? Yes VideoCall PiP transitions (PiP on/off), Public Key SSL Pinning, NFC reading, and OCR streams should be tested.
Is there a deadline for transition? No —

3. Changes

Notification to Host Application When PiP Cannot Be Started

Component: iOS SDK (VideoCall) | Type: Improvement

What changed? When the application is sent to the background during a video call and PiP mode cannot be started (for instance, if PiP is disabled in device settings), the SDK now informs the host application through the videoCallFailed(_:) callback with the new .failedToStartPiPMode value. In this case, the call is not terminated by the SDK.

Does it affect customers? Conditional. Only integrations using PiP support within VideoCall are affected.

What to do: Handle the .failedToStartPiPMode value in your videoCallFailed(_:) callback (for example, show an alert to the user indicating that PiP can be enabled in device settings). If you need the new state to not terminate the call, separate this value from the default case that terminates the call.

If no action is taken: If you are terminating the call in the default case of your videoCallFailed(_:) callback, the call may unexpectedly end when PiP cannot be started.


Fix for Image Freezing When Returning from Background with PiP Disabled

Component: iOS SDK (VideoCall) | Type: Bug Fix

What changed? The issue where the video call screen could freeze when the application is sent to the background and returned while PiP is disabled in device settings has been fixed. Additionally, the case where the full-screen image could overlap with the PiP window after a call was rejected has also been resolved.

Does it affect customers? No. The change is automatically activated on the SDK side.

What to do: No implementation or configuration changes are necessary. Testing the VideoCall flow with backgrounding/returning scenarios while toggling PiP on and off is recommended.


TUR_DEFAULT Country Option: Single Flow for Turkish ID and Passport

Component: iOS SDK (OCR) | Type: New Feature

What changed? A new TUR_DEFAULT country option has been added to the OCR module. With this option, the Turkish Republic identity card (TD1) and any country's passport (TD3) can be read in a single flow, and the document type is automatically determined during reading. This option depends on the relevant type control being enabled on the server side; if disabled, it operates like the TUR option.

Does it affect customers? Conditional. Only integrations wishing to use the TUR_DEFAULT option are affected.

What to do: Teams wishing to use TUR_DEFAULT simply need to pass this value to the countryCode parameter. Integrations using other country codes do not require changes.


Public Key SSL Pinning Compatibility Improvement

Component: iOS SDK (Core) | Type: Bug Fix

What changed? The Public Key SSL Pinning feature has been ensured to work correctly with certificates of different key types and sizes.

Does it affect customers? Conditional. Only integrations using Public Key SSL Pinning are affected.

What to do: No implementation or configuration changes are necessary. Teams using Public Key SSL Pinning are recommended to test their connection authentication.


NFC Reading Progress Indicator Updated

Component: iOS SDK (NFC) | Type: Improvement

What changed? The progress indicator shown during NFC reading has been changed from restarting indicators for each data group to a single and continuous advancing indicator. Progress increases without reversing during reading.

Does it affect customers? No. The change is automatically activated on the SDK side.

What to do: No implementation or configuration changes are necessary.


MRZ Name/Surname Reading Fix

Component: iOS SDK (OCR) | Type: Bug Fix

What changed? The issue where OCR reads some letters as numbers in the name and surname information from the MRZ field has been resolved.

Does it affect customers? No. The change is automatically activated on the SDK side.

What to do: No implementation or configuration changes are necessary.

4. Version and Compatibility

Component Previous Version New Version Minimum Requirement
Backend (OCR model download service) — — Dependency information is being verified

Dependency information is being verified: The new version of the service from which OCR models are downloaded has been started in this release. The minimum Backend version required for this version to work needs to be clarified; it is recommended not to transition until your Backend version's compatibility is verified.

5. Migration Steps

  1. Verify the minimum Backend version required for this SDK release.
  2. Upgrade the SDK version.
  3. If using VideoCall, handle the .failedToStartPiPMode value in your videoCallFailed(_:) callback.
  4. End-to-end test VideoCall PiP transitions, Public Key SSL Pinning, NFC reading, and OCR flows.

6. Known Issues

There are no known issues.


v2.1.0.7012-s Release Notes — 21.10.2026

[IOS SDK] [CONDITIONAL ACTION] [BACKWARD COMPATIBLE]

1. Release Summary

This release is a fix version released to resolve an integration issue occurring when adding the OCR module (EnQualifyOCR) in projects that add the SDK with Swift Package Manager (SPM) while using Xcode 27 and Tuist. There are no changes to the functionalities of the SDK.

2. Customer Impact

Check Status Description
Does it affect implementation? Conditional Only projects that add the SDK with SPM and use Xcode 27 with Tuist are affected.
Does customer action need to be taken? Yes Only projects encountering this issue need to update their SDK package to this version; no action is required for other integrations.
Are there parameter or configuration changes? No There are no new or removed parameters.
Is it compatible with existing integrations? Yes Backward compatibility is maintained.
Does it require testing? Yes It is recommended to verify integration and build processes through SPM with Xcode 27 and Tuist.
Is there a deadline for migration? No —

3. Changes

Fix for Integration Issue with Xcode 27 and Tuist using SPM

Component: iOS SDK (OCR / SPM package) | Type: Bug Fix

What changed? The error caused by case sensitivity in the file path during the addition of the OCR module (EnQualifyOCR) through SPM in projects using Xcode 27 and Tuist has been resolved. EnQualifyOCR can now be integrated seamlessly in Xcode 27.

Does it affect customers? Conditional. Only projects that add the SDK with SPM and use Xcode 27 with Tuist are affected. There are no changes with other integration methods.

What to do: Teams encountering this issue need to update their SDK package dependency to version v2.1.0.7012-s. No implementation or configuration changes are needed for integrations not encountering this issue.

If no action is taken: The same error will continue to occur when adding the OCR module with Xcode 27 and Tuist.

4. Migration Steps

  1. Update your SPM dependency to version v2.1.0.7012-s.
  2. Rebuild your project with Tuist and verify that the OCR module is added without issues in Xcode 27.

5. Known Issues

There are no known issues.


v2.1.0.11 Release Notes — 06.10.2026

[IOS SDK] [NO CUSTOMER ACTION] [BACKWARD COMPATIBLE]

1. Release Summary

In this release, support has been added for the SDK to correctly recognize new iPhone models and for the OCR flow to work with device-specific settings on these devices.

2. Customer Impact

Check Status Description
Does it affect implementation? Conditional Applications running on new iPhone models are affected.
Does customer action need to be taken? No The change is automatically activated on the SDK side.
Are there parameter or configuration changes? No There are no new or removed parameters.
Is it compatible with existing integrations? Yes Backward API compatibility is maintained.
Does it require testing? Yes The OCR flow should be tested on new iPhone models.
Is there a deadline for migration? No —

3. Changes

Support for New iPhone Models

Component: iOS SDK (Core / OCR) | Type: Improvement

What has changed? New iPhone models are now recognized correctly by the SDK; the device-specific behaviors of the SDK (including OCR) are now applied correctly on these devices.

Does it affect customers? Conditional. Only applications running on new iPhone models are affected.

What needs to be done: No implementation or configuration changes are necessary. It is recommended to test the OCR flow on the new iPhone models.

4. Known Issues

No known issues are present.


v2.1.2.7009 Release Notes — 06.10.2026

[IOS SDK] [NO CUSTOMER ACTION] [BACKWARD COMPATIBLE]

1. Release Summary

In this release, it has been ensured that the reading screen properly closes after the NFC reading time is exceeded (timeout), and the error is reported to the integrator in one go. Additionally, support for correctly recognizing new iPhone models by the SDK has been provided.

2. Customer Impact

Check Status Description
Does it affect implementation? Conditional Integrations using the NFC reading flow (timeout scenario) and applications running on new iPhone models are affected.
Does it require customer action? No Changes are automatically applied on the SDK side.
Is there any parameter or configuration change? No There are no new or removed parameters.
Is it compatible with existing integrations? Yes Backward API compatibility has been maintained.
Does it require testing? Yes The timeout scenario during NFC reading should be tested.
Is there a deadline for migration? No —

3. Changes

Fix for Reading Screen and Error Notification After NFC Timeout

Component: iOS SDK (NFC) | Type: Bug Fix

What has changed? A problem was resolved where the NFC reading screen could remain open in some cases after the NFC reading time was exceeded (timeout), and the timeout error could be processed repeatedly. Now, during a timeout, the reading screen closes, and the error is reported to the integrator in one go.

Does it affect customers? Conditional. Only integrations that use the NFC reading flow and encounter the timeout scenario are affected.

What needs to be done: No implementation or configuration changes are necessary. It is recommended to conduct end-to-end testing of the NFC reading flow in the timeout scenario.


Support for New iPhone Models

Component: iOS SDK (Core / OCR) | Type: Improvement

What has changed? New iPhone models are now recognized correctly by the SDK; the device-specific behaviors of the SDK (including OCR) are now applied correctly on these devices.

Does it affect customers? Conditional. Only applications running on new iPhone models are affected.

What needs to be done: No implementation or configuration changes are necessary.

4. Known Issues

No known issues are present.


v2.1.2.7008 Release Notes — 01.10.2026

[IOS SDK] [CUSTOMER ACTION REQUIRED] [BACKWARD COMPATIBLE]

1. Release Summary

This version is a corrective release published to address a packaging issue that affected the code signing of the package found in v2.1.2.7007. It contains the same changes as v2.1.2.7007; short-term connection interruptions during NFC passport/ID reading are now automatically recovered, the reliability of automatic video quality adjustment during VideoCall has been improved, and a visual correction regarding the initial guide visual on the OCR camera screen has been made.

2. Customer Impact

Check Status Description
Does it affect implementation? Conditional Integrations using v2.1.2.7007 may have been affected by the code signing packaging issue; integrations using NFC, VideoCall, and OCR camera flows are impacted by behavioral changes.
Does it require customer action? Yes Integrations using v2.1.2.7007 need to be updated to v2.1.2.7008.
Is there any parameter or configuration change? No There are no new or removed parameters.
Is it compatible with existing integrations? Yes Backward API compatibility has been maintained.
Does it require testing? Yes Verification of code signing during Build/Archive; NFC reading/connection interruption scenarios; video quality behavior during VideoCall; and guide visuals on the OCR camera screen should be tested.
Is there a deadline for migration? No —

3. Changes

Code Signing Packaging Fix

Component: iOS SDK (Core) | Type: Bug Fix

What has changed? A packaging issue affecting the code signing of the SDK package has been resolved. This issue was only present in version v2.1.2.7007.

Does it affect customers? Yes. Integrations using v2.1.2.7007 may have been affected by this issue.

What needs to be done: If you are using v2.1.2.7007, you need to update the SDK to v2.1.2.7008. If you are migrating from v2.1.2.7006 or an earlier version, you can upgrade directly to v2.1.2.7008.

If no action is taken: If v2.1.2.7007 is continued to be used, errors related to code signing verification may occur during build/archive or distribution.


Automatic Resumption After NFC Connection Interruption

Component: iOS SDK (NFC) | Type: Improvement

What has changed? During NFC passport/ID reading, if the connection temporarily drops before card reading is complete (for example, if the card is slightly moved away from the phone), it was necessary to restart the reading from the beginning. Now, in such short-term connection interruptions, reading automatically continues from where it left off.

Does it affect customers? No. Changes are automatically applied on the SDK side.

What needs to be done: No implementation or configuration changes are necessary. It is recommended to test the NFC reading flow, especially including scenarios of connection interruption during card reading.


Reliability of Automatic Video Quality Adjustment in VideoCall

Component: iOS SDK (VideoCall) | Type: Bug Fix

What has changed? A problem has been resolved where the automatic video quality adjustment, which activates according to network conditions during video calls, did not work in some cases. Furthermore, it has been ensured that while steps utilizing the camera, such as OCR or face verification, are active during the call, this automatic adjustment temporarily pauses and resumes when the step is complete.

Does it affect customers? No. Changes are automatically applied on the SDK side.

What needs to be done: No implementation or configuration changes are necessary. It is recommended to test the VideoCall flow, especially in conjunction with OCR/face verification steps during the call and under different network conditions.


Correction of Initial Guide Visual on OCR Camera Screen

Component: iOS SDK (OCR) | Type: Bug Fix

What has changed? When the OCR camera screen opened, a problem was resolved where, in certain scenarios (for example, when back face reading was initiated), the guide visual in the center was displayed as an inappropriate visual for the relevant step.

Does it affect customers? No. Changes are automatically applied on the SDK side.

What needs to be done: No implementation or configuration changes are necessary.

4. Migration Steps

  1. If you are using v2.1.2.7007, update the SDK to v2.1.2.7008 and refresh your dependencies with pod install.
  2. Run your Build/Archive process to retest code signing verification.
  3. Test the NFC reading, VideoCall, and OCR camera flows end-to-end.

5. Known Issues

No known issues are present.


v2.1.2.7007 Release Notes — 24.09.2026

[IOS SDK] [NO CUSTOMER ACTION] [BACKWARD COMPATIBLE]

1. Release Summary

In this release, short-term connection interruptions during NFC passport/ID reading are now automatically recovered, allowing the reading to continue without needing to restart. Additionally, the reliability of automatic video quality adjustment during VideoCall has been improved, and a visual correction regarding the initial guide visual on the OCR camera screen has been made.

2. Customer Impact

Control Status Description
Does it affect implementation? Conditional Integrations using NFC reading, VideoCall (automatic video quality), and OCR camera streams are affected by behavioral changes.
Does it require customer action? No Changes are automatically applied on the SDK side.
Is there a parameter or configuration change? No There are no new or removed parameters.
Is it compatible with existing integrations? Yes Backward API compatibility is maintained.
Does it require testing? Yes NFC reading/disconnection scenarios, video quality behavior during VideoCall (especially during a call with OCR/face verification), and OCR camera screen guide visuals should be tested.
Is there a deadline for transition? No —

3. Changes

Automatic Resumption After NFC Disconnection

Component: iOS SDK (NFC) | Type: Improvement

What changed? During passport/ID reading with NFC, if the connection was briefly interrupted before the card reading completed (for example, when the card was slightly moved away from the phone), it was required to restart the reading from the beginning. Now, in such brief disconnection scenarios, the reading continues automatically from where it left off.

Does it affect the customer? No. Changes are automatically applied on the SDK side.

What to do: No implementation or configuration changes are required. It is recommended to test the NFC reading flow, especially including disconnection scenarios during card reading.


Reliability of Automatic Video Quality Adjustment in VideoCall

Component: iOS SDK (VideoCall) | Type: Bug Fix

What changed? A problem was fixed where the automatic video quality adjustment, which is activated according to network conditions during video calls, could fail to work in some cases. It was also ensured that this automatic adjustment is temporarily halted while steps using the camera, such as OCR or face verification, are running and continues from where it left off once the step is completed.

Does it affect the customer? No. Changes are automatically applied on the SDK side.

What to do: No implementation or configuration changes are required. It is recommended to test the VideoCall flow, especially with OCR/face verification steps during the call and under different network conditions.


Correction of Initial Guide Visual on OCR Camera Screen

Component: iOS SDK (OCR) | Type: Bug Fix

What changed? When the OCR camera screen opened, a problem was fixed where the center guide visual was shown as an inappropriate visual for the related step in some scenarios (for example, when back face reading was initiated).

Does it affect the customer? No. Changes are automatically applied on the SDK side.

What to do: No implementation or configuration changes are required.

4. Known Issues

No known issues are present.


v2.1.0.10 Release Notes — 23.09.2026

[IOS SDK] [NO CUSTOMER ACTION] [BACKWARD COMPATIBLE]

1. Release Summary

In this version, brief connection interruptions during passport/ID reading with NFC can now automatically recover, allowing the reading to continue without having to restart from the beginning.

2. Customer Impact

Control Status Description
Does it affect implementation? No Changes are automatically applied on the SDK side.
Does it require customer action? No —
Is there a parameter or configuration change? No —
Is it compatible with existing integrations? Yes —
Does it require testing? Yes Disconnection scenarios during NFC reading should be tested.
Is there a deadline for transition? No —

3. Changes

Automatic Resumption After NFC Disconnection

Component: iOS SDK (NFC) | Type: Improvement

What changed? During passport/ID reading with NFC, if the connection was briefly interrupted before the card reading completed (for example, when the card was slightly moved away from the phone), it was required to restart the reading from the beginning. Now, in such brief disconnection scenarios, the reading continues automatically from where it left off.

Does it affect the customer? No. Changes are automatically applied on the SDK side.

What to do: No implementation or configuration changes are required. It is recommended to test the NFC reading flow, especially including disconnection scenarios during card reading.

4. Known Issues

No known issues are present.


v2.1.2.7006 Release Notes — 18.09.2026

[IOS SDK] [NO CUSTOMER ACTION] [BACKWARD COMPATIBLE]

1. Release Summary

In this version, the response time for face and smile detection during video calls (VideoCall) has been shortened.

2. Customer Impact

Control Status Description
Does it affect implementation? Conditional Integrations using face/smile detection feature during VideoCall are affected.
Does it require customer action? No Changes are automatically applied on the SDK side.
Is there a parameter or configuration change? No There are no new or removed parameters.
Is it compatible with existing integrations? Yes Backward API compatibility is maintained.
Does it require testing? Yes The face/smile detection flow during VideoCall and device performance (CPU/battery consumption) should be tested.
Is there a deadline for transition? No —

3. Changes

Speed Improvement for Face and Smile Detection During VideoCall

Component: iOS SDK (Face / VideoCall) | Type: Improvement

What changed? The response time for face and smile detection during video calls (VideoCall) has been shortened.

Does it affect the customer? Conditional. Only integrations using the face/smile detection feature during VideoCall are affected.

What to do: No implementation or configuration changes are required. It is recommended to test the face/smile detection flow during VideoCall and the device resource usage (CPU/battery) end-to-end.

4. Known Issues

No known issues are present.


v2.1.0.9 Release Notes — 09.09.2026

[IOS SDK] [NO CUSTOMER ACTION] [BACKWARD COMPATIBLE]

1. Release Summary

In this version, the issue of low-quality image capture when TD1 format ID cards used in Turkey are not held parallel to the camera has been resolved, and it has been ensured that sessions are correctly marked as failed when multiple people are detected during face verification (liveness) flow.

2. Customer Impact

Control Status Description
Does it affect implementation? Conditional Integrations using TUR TD1 ID card OCR flow and face verification (liveness) flow are affected by behavioral changes.
Does it require customer action? No Changes are automatically applied on the SDK side.
Is there a parameter or configuration change? No There are no new or removed parameters; only internal default values have been updated.
Is it compatible with existing integrations? Yes Backward API compatibility is maintained.
Does it require testing? Yes TUR TD1 ID card OCR flow and face verification (especially in multiple person scenarios) should be tested.
Is there a deadline for transition? No —

3. Changes

Quality Fix for Turkish TD1 Identity Card Reading

Component: iOS SDK (OCR) | Type: Bug Fix

What changed? The issue causing low-quality images to be captured when TD1 format identity cards used in Turkey are not held parallel to the camera has been resolved.

Does it affect the customer? Conditional. Only integrations using the TUR TD1 identity card OCR flow are affected.

What to do: No implementation or configuration changes are required. End-to-end testing of the TUR TD1 identity card reading flow is recommended.


Multiple Face Detection and Stability Fix in Face Verification Flow

Component: iOS SDK (Face) | Type: Bug Fix

What changed? When multiple faces are detected in the camera during the face verification (liveness) flow, the session is now explicitly terminated as a failure. Additionally, a logic error that caused unnecessary frames to be processed after verification was completed or failed has been fixed, preventing potential double error triggers.

Does it affect the customer? Yes. If multiple people are present in front of the camera, the integration will now receive the faceDetectFailed error callback.

What to do: It is recommended to ensure that your application's current faceDetectFailed error callback flow is handled correctly; no additional implementation changes are needed.

4. Version and Compatibility

Component Previous Version New Version Minimum Requirement
GoogleMLKit/FaceDetection (CocoaPods dependency) 7.0.0 4.0.0 Dependency information being verified
iOS Minimum Deployment Target iOS 15.5 iOS 14.0 —

Dependency information being verified: The internal CocoaPods dependency (GoogleMLKit/FaceDetection) of the SDK and the minimum iOS deployment target value have changed in this version range. The developer team should confirm whether this change is an intentional version decision or a configuration difference left over from a branch integration during the development process; after verification, it will be clear whether customer action is required.

5. Known Issues

No known issues.


v2.1.2.7005 Release Notes — 09.03.2026

[IOS SDK] [NO CUSTOMER ACTION] [BACKWARD COMPATIBLE]

1. Release Summary

In this release, a stability issue that could occur during consecutive retry scenarios in the passport/identity reading process via NFC has been resolved, and some error scenarios that were previously unreported to the integrator are now reported through the nfcFailed callback.

2. Customer Impact

Check Status Description
Does it affect the implementation? Conditional Integrations using the NFC passport/identity reading flow are affected by behavioral changes.
Is customer action needed? No Changes take effect automatically on the SDK side.
Are there any parameter or configuration changes? No There are no new or removed parameters.
Is it compatible with existing integrations? Yes There is no change in the delegate interface; it is backward compatible.
Does testing need to be done? Yes NFC reading, consecutive retry, and error scenarios should be tested.
Is there a deadline for the transition? No —

3. Changes

NFC Reading Retry Stability Fix

Component: iOS SDK (NFC) | Type: Bug Fix

What changed? The issue of reading failure that could occur when a new reading is started immediately after a previous reading attempt has been resolved in the NFC passport/identity reading process.

Does it affect the customer? Conditional. Only integrations using the NFC reading and retry flow are affected.

What to do: No implementation or configuration changes are required. It is recommended to perform end-to-end testing of NFC reading and consecutive retry scenarios.


Resolution of Unreported Error Scenarios in NFC Reading

Component: iOS SDK (NFC) | Type: Bug Fix

What changed? In the NFC passport/identity reading process, some error scenarios that could previously terminate silently without any error notification to the integrator now trigger the nfcFailed callback.

Does it affect the customer? Yes. Since no callback was previously triggered in these scenarios, the flow could remain ambiguous in the user interface; now these scenarios are reported through nfcFailed(error:).

What to do: It is recommended to ensure that your application's current nfcFailed(error:) callback flow is handled correctly; no additional implementation changes are needed.

4. Known Issues

No known issues.


v2.1.2.7004 Release Notes — 25.08.2026

[IOS SDK] [NO CUSTOMER ACTION] [BACKWARD COMPATIBLE]

1. Release Summary

In this release, an error in parsing the name line in the OCR reading of Turkish Republic identity cards (TD1) has been fixed; the ability to separately access name/surname information from the MRZ and additional personal data fields in the NFC passport/identity reading process has been added.

2. Customer Impact

Check Status Description
Does it affect the implementation? No The existing behavior is preserved
Is customer action needed? No —
Are there any parameter or configuration changes? Yes New, optional public fields were added
Is it compatible with existing integrations? Yes —
Does testing need to be done? No —
Is there a deadline for the transition? No —

3. Changes

Correction in Reading Name Line of Turkish Republic Identity Card (TD1)

Component: iOS SDK (OCR) | Type: Bug Fix

What changed? The issue of the name field not being read in some scenarios (abbreviated/shortened names) in TD1 format identity cards has been resolved.

Does it affect the customer? No.

What to do: No implementation or configuration changes are required.


Source-Based Access to Name/Surname Information Read via NFC

Component: iOS SDK (NFC) | Type: New Feature

What changed? New fields have been added to the customer chip data returned as a result of NFC passport/identity reading, allowing separate access to name/surname information from the MRZ field and additional personal data fields.

Does it affect the customer? Conditional. It only concerns integrations that want to read this information from separate sources.

What to do: Teams wishing to use this can read the fields getDg1Name(), getDg1Surname(), getDg11Name(), getDg11Surname() from the customer chip object returned by NFC. No changes are required for integrations that do not wish to use this.

4. Known Issues

No known issues.


v2.1.0.8 Release Notes — 12.08.2026

[IOS SDK] [NO CUSTOMER ACTION] [BACKWARD COMPATIBLE]

1. Release Summary

In this release, a visual correction related to the progress indicator used in the face verification flow has been made.

2. Customer Impact

Check Status Description
Does it affect the implementation? No The change takes effect automatically on the SDK side
Is customer action needed? No —
Are there any parameter or configuration changes? No —
Is it compatible with existing integrations? Yes —
Does testing need to be done? No —
Is there a deadline for the transition? No —

3. Changes

Progress Indicator Update Correction During Face Positioning

Component: iOS SDK (Face) | Type: Bug Fix

What changed? A bug was fixed where the visual update of the progress indicator did not occur in certain scenarios when the user’s face moved outside the center of the camera, when it should have turned red.

Does it affect the customer? No.

What to do: No implementation or configuration changes are required.

4. Known Issues

No known issues.


Before moving to a new version, check the "Does it affect the implementation?" section.


v2.1.2.7003

Field Value
Version: v2.1.2.7003
Release Date: 2026-07-28
Breaking Change: ❌
Deprecation Plan: ❌

📝 Changes

Core

  • Sectigo Root Certificate Support: An additional verification layer has been added to the SSL certificate verification infrastructure through the embedded Sectigo root certificate on the device. This enhancement complements the Public Key SSL Pinning support added in v2.1.2.0.

OCR

  • Canada AAMVA Driver License Support: A new document processing strategy has been added for reading and verifying Canadian driver's licenses (in accordance with AAMVA standards).
  • Cyprus ID Card Corrections: Issues in some scenarios with errors and the inability to set card numbers on Cyprus identity cards have been addressed.

VideoCall

  • PiP (Picture in Picture) Mode Fix: The bug that caused the PiP mode to remain active when the user returned to the application from PiP mode has been resolved.

Face

  • Stability and Performance Improvements: The bug causing intermittent application crashes in the face verification module has been fixed, memory (RAM) consumption has been reduced by approximately 49%, and false-trigger detection scenarios have been improved.

🔧 Does it affect implementation?

No — All changes in this version are automatically activated on the SDK side; no mandatory changes are required on the implementation side.

However, it is recommended to include regression testing for Canadian driver license reading, SSL connection scenarios, Cyprus ID reading, VideoCall PiP transitions, and face verification flow.

⚠️ Breaking Changes

There are no breaking changes in this version.


v2.1.2.0

Field Value
Version: v2.1.2.0
Release Date: 2026-06-23
Breaking Change: ❌
Deprecation Plan: Versions including Google MLKit v4.0.0

📝 Changes

Core

  • Enhanced SSL Certificate Verification Solutions: In addition to the existing Base64 string and embedded .der certificate verification methods, support for certificate verification (SSL Pinning) with Public Key has been integrated.

OCR

  • Enhanced Alignment Algorithm: With the transition to the new infrastructure, improvements have been made to automatically correct angular distortions of images taken from the camera, allowing identity recognition processes to continue with these optimized visuals.
  • Security Elements and Visual Layer Separation: By separating security elements on the identity from the base identity visuals, the verification and data accuracy control processes have been deepened.
  • Performance and Resource Optimization: Camera frame and thread management have been restructured, minimizing the consumption of device resources (CPU/RAM).
  • Text Recognition (OCR) Accuracy: Improvements have been made in accuracy and speed during the reading process of characters and text fields on the identity.

VideoCall

  • Remote Flash Control Capability: A function that can be triggered by the customer representative during a video call, operating with an end-user approval mechanism for "turning on/off the device flash" has been included.

🔧 Does it affect implementation?

Yes — Some of the new features require action from teams.

  • Core / SSL Pinning: Teams wishing to use Public Key with SSL Pinning must update the certificate verification method in the Core configuration to support Public Key. There is no mandatory change for teams using the existing Base64 string or embedded .der certificate verification methods.
  • OCR alignment and visual security improvements: Teams using the OCR module are not expected to make additional code changes; however, front/rear surface reading, security element verification, error scenarios, and low light/angled shot scenarios should be end-to-end tested.
  • OCR performance optimizations: Since camera frame/thread management has been optimized on the SDK side, no action is required on the implementation side. However, in-app camera permissions, flow transitions, and varying device performances should be included in regression testing.
  • VideoCall remote flash control: Teams using this feature should verify that the flash on/off requests sent by representatives in the VideoCall flow are managed with user approval. On the application side, camera/flash permissions, user approval screen behavior, and correct updating of flash status during the call must be tested.

⚠️ Breaking Changes

There are no breaking changes in this version.

v2.1.0.0

Field Value
Version: v2.1.0.0
Release Date: 2026-01-23
Breaking Change: ❌
Deprecation Plan: ❌

📝 Changes

➕ Added

1) VideoCall – PiP (Picture in Picture) Support

Support has been added for PiP mode to activate when the user minimizes the application during a VideoCall.

Purpose: To sustain the video call experience in the background.

2) ModelV4 Service – Model Management and Backoffice Synchronization

The ModelV4 service has been added.

The model file is now embedded into the device and can be downloaded from the Backoffice when necessary.

Under the Model V4 enhancements:

  • threshold values
  • mandatory checks
  • and enhancements on model behaviors have been strengthened.

Visual security element analyses and threshold values can now be changed through the Backoffice.

3) SDK Sounds – Device Embedding + Backoffice Sync

Sound files used in the SDK have been embedded into the device.

If the relevant sound is updated on the Backoffice side, a mechanism has been added to ensure the device synchronizes with the Backoffice.

4) NFC Certificate – Device Embedding + Backoffice Sync

The NFC certificate has been added to the device.

Code managing the device's sync status with the updates from the Backoffice has been added.

5) Base Model – useEmbeddedLocalSound Parameter (Global Sound Management)

The useEmbeddedLocalSound: NSNumber parameter has been added to the Base Model for use by all modules.

With this parameter:

  • If there are embedded sound files in the project, priority usage of these files is ensured.
  • Unnecessary requests for downloading sound files over the Backoffice / network are prevented.

6) Hold Video

Through the Agent Request delegate, the status of the representative opening and closing the camera can now be tracked.

When the representative opens the camera, the .camOpen event is sent, and when they close it, the .camClose event is communicated through the delegate.

With this mechanism, a hold video can be shown to the customer while the representative's camera is off. When the representative opens the camera again, the hold video will automatically stop, allowing the call to continue live.

🔁 Changed

  • Visual analysis behaviors (especially security elements and threshold controls) have become more dynamic; management has been moved to the Backoffice side (with the ModelV4 infrastructure).

🛠 Fixed

  • UI corrections and improvements have been made for the Verbal Consent screen.
  • In the NFC flow, when the application is minimized, the process is stopped for security reasons.
  • Various performance improvements and bug fixes have been made.

❌ Removed

There are no public APIs/functions removed in this version.

⚠️ Breaking Changes

There are no breaking changes in this version.

🔧 Does it affect implementation?

Yes — Action is required for teams wishing to utilize the new features.

  • PiP: PiP delegates need to be added to the VideoCall module. For details, refer to the VideoCall Module → PiP page.
  • useEmbeddedLocalSound: Teams wishing to use this should add the parameter to the Base Model. It is not mandatory; if not added, the existing behavior remains unchanged.
  • Hold video: Teams wanting to use the .camOpen / .camClose events should update the Agent Request delegate. This is not mandatory.
  • ModelV4, sounds, NFC certificate: No changes are required on the implementation side; the SDK manages it automatically.

v2.0.6.4

Field Value
Version: v2.0.6.4(-s,.5)
Release Date: 2026-01-08
Type: PATH
Breaking Change: ❌
Deprecation Plan: ❌

📝 Changes

1️⃣ VideoCall Within OCR & Face Retry Flow

1.1 General Flow

During the VideoCall process, the Agent may request the retry of OCR or Face verification steps.

In this case, the relevant retry flow is automatically initiated by the SDK.

1.2 Fail State

If the OCR or Face retry process falls into a Fail state:

  • The user is given the option to manually restart the verification process.

1.3 Retry Functions

Two new functions have been added to the SDK:

Text Only
EnQualifyVideoCall.ocrRetry()\nEnQualifyVideoCall.faceRetry()\nEnQualifyVideoCall.nfcRetry()

📌 Usage Rules

  • These functions can only be called during an active VideoCall session.
  • They are not supported outside of the VideoCall.

1.4 Delegate Flow

After the retry function is called, the following delegate methods are triggered by the SDK:

Text Only
ocrRetryRequested()\nfaceRetryRequested()\nnfcRetryRequested()

➡️ Implementation of these delegates is mandatory.

2️⃣ Other Improvements & Fixes

  • When the Rotate / Cancel buttons are set to false in the BackOffice, the issue causing the buttons to disappear completely when the Rotate button is pressed has been resolved.
  • Missing logs sent by the BackOffice have been identified and added to the SDK.
  • Timer issues occurring during WiFi ↔ Cellular network transitions have been resolved.
  • The CallBusinessUID and businessReference values have been ensured to be set correctly.

🔧 Does it Affect Implementation?

Yes — Action is required for teams that will use the retry flow within the VideoCall.

After calling the retry functions, the following delegates must be implemented mandatory:

swift

Text Only
ocrRetryRequested()\nfaceRetryRequested()\nnfcRetryRequested()

If you are not going to use the retry feature, you do not need to change your existing implementation.


v2.0.6.2

Field Value
Version: v2.0.6.2
Release Date: 2025-12-08
Type: PATH
Breaking Change: ❌
Deprecation Plan: ❌

📝 Changes

🔁 Changed

The agentRequest(event: VideoCallMoudule.AgentRequestEvent) delegate has been modified as follows:

Text Only
agentRequest(\n    event: VideoCallMoudule.AgentRequestEvent,\n    lastEvent: VideoCallMoudule.AgentRequestEvent\n)

➕ Added

A new stop function has been added to the NFC module:

Text Only
EnQualifyNFC.nfcStopForBacktoVideoCall()

❌ Removed

The following function has been completely removed from the VideoCall module:

Text Only
setupCallLayout(\n    showRotateButton: Bool,\n    showCancelButton: Bool\n)

🔧 Does it Affect Implementation?

Yes — You must make the following two changes before migrating to this version.

1. VideoCall Module Updates

1.1. Removed Function

The following function has been completely removed from the VideoCall module:

Text Only
setupCallLayout(\n    showRotateButton: Bool,\n    showCancelButton: Bool\n)

Reason:
The visibility of buttons on the VideoCall screen will now be managed dynamically by the Back Office. Therefore, the manual visibility control on the SDK side has been removed.


1.2. Updated Delegate Structure

Old delegate:

Text Only
agentRequest(event: VideoCallMoudule.AgentRequestEvent)

New delegate:

Text Only
agentRequest(\n    event: VideoCallMoudule.AgentRequestEvent,\n    lastEvent: VideoCallMoudule.AgentRequestEvent\n)

Description:
The new delegate structure allows access to the previous event.

2. NFC Module Updates

2.1. NFC Stop Function

A new stop function has been added to the NFC module:

Text Only
EnQualifyNFC.nfcStopForBacktoVideoCall()

Purpose of the Function

Ensures the secure termination of an ongoing NFC session during certain transition scenarios.

Usage Scenario (Important)

This function should be used when the following situation occurs:

  1. During the VideoCall, the Agent sends a request to the user for an NFC retry.
  2. While the NFC process is still ongoing, the BackToVideoCall operation is triggered.
  3. Control is performed via the agentRequest(event:lastEvent:) delegate:
Text Only
event == .BackToVideoCall\nlastEvent == .NFC
  1. If NFC is still active, the following function should be called:
Text Only
EnQualifyNFC.nfcStopForBacktoVideoCall()

v2.0.2.5

Field Value
Version: v2.0.2.5
Release Date: 2025-08-26
Type: PATH
Breaking Change: ❌
Deprecation Plan: ❌

📝 Changes

🔁 Changed

  • Compiled as GoogleMLKitFaceDetection v7.0.0.

➕ Added

No new features have been added in this release.

❌ Removed

No structures have been removed in this release.

⚠️ Breaking Changes

No breaking changes exist in this release.

🔀 Migration Guide

What Changed

In this version, the GoogleMLKitFaceDetection v7.0.0 update has been made.

🔧 Does it Affect Implementation?

No — No changes are required on the implementation side.


v2.0.2.3

Field Value
Version: v2.0.2.3
Release Date: 2025-08-21
Type: PATH
Breaking Change: ❌
Deprecation Plan: ❌

📝 Changes

🔁 Changed

  • The garbage layer remaining from the Camera Preview View has been removed at the end of the process.

➕ Added

No new features have been added in this release.

❌ Removed

No structures have been removed in this release.

⚠️ Breaking Changes

No breaking changes exist in this release.

🔀 Migration Guide

What Changed

A layer affecting cross-platform customers related to the Camera Preview screen has been removed.

🔧 Does it Affect Implementation?

No — No changes are required on the implementation side. It is recommended that you test user interactions during process terminations and screen transitions.


v2.0.2.2

Field Value
Version: v2.0.2.2
Release Date: 2025-08-18
Type: PATH
Breaking Change: ❌
Deprecation Plan: ❌

📝 Changes

🔁 Changed

  • The source of the "Gender" information within CustomerIdentityDoc has been updated to be retrieved from the backend instead of the frontend.

➕ Added

No new features have been added in this release.

❌ Removed

No structures have been removed in this release.

⚠️ Breaking Changes

No breaking changes exist in this release.

🔀 Migration Guide

What Changed

The source for reading the "Gender" information in CustomerIdentityDoc has been updated.

🔧 Does it Affect Implementation?

No — The change is on the SDK side. There is nothing to be done on the implementation side.


v2.0.2.1

Field Value
Version: v2.0.2.1
Release Date: 2025-08-12
Type: PATH
Breaking Change: ❌
Deprecation Plan: ❌

📝 Changes

🔁 Changed

OCR & IDVerification

  • The OCR and IDVerification definition structure was created entirely based on the config configuration obtained from the database.
  • Improvements and additional verifications were made specifically for the Turkish Republic TD1 IDs.
  • Improvements were provided for the analysis of visual elements and the photos taken.

Near Field Communication (NFC)

  • Thermal Heat Detection was added, and the device temperature was monitored at 4-second intervals before and during the NFC process.
  • Logging details were enhanced during the process, in case of errors, and before.

Face Detection & Liveness Verification

  • Errors arising from minimizing and maximizing the application during the liveness check were resolved.
  • Voice guidance was synchronized with movements during the liveness check.
  • The progress visual seen by the user during the liveness check was optimized.
  • Prevented the error page from being triggered multiple times after being sent to the background and brought to the foreground.
  • States held during the liveness check were made more detailed and ensured to be reset after an error.
  • Data recorded for repeated operations after an error during the liveness check were cleared.
  • Data recorded for repeated processes after a successful operation following the liveness step were cleared.

VideoCall

  • Improvements were made regarding the live logging after connecting to the video call.

Core

  • Improvements were made on the logs on the network side.
  • A State Manager for performing Thermal Heat Detection was added.

➕ Added

OCR & IDVerification

  • Country and region-specific configuration was introduced along with the config file.

Face Detection & Liveness Verification

  • A video recording structure during face recognition and liveness for self-service customers was added.

Utility Module

  • The EnQualify Utility Module was added, and EnQualify v2.0 features planned to be implemented before and after the flows outside the core flows will be managed through this module.
  • Functions such as Appointment, CallType, DocumentAdd, etc. that have been written so far were moved to this module, and communication was established via the completion structure.
  • The Document Signing feature was added to this module.

❌ Removed

  • Functions and accompanying delegate methods that were within the EnQualify OCR & NFC & Face & VideoCall modules and transferred to the Utility Module were removed.

⚠️ Breaking Changes

  • Changes made in the idDocTypeCheckVerified delegate
  • Changes made in the idDocFrontVerified delegate

🔧 Does it Affect the Implementation?

Yes — An update is required in current implementations due to the addition of the Utility Module.

Functions and delegates removed from the OCR, NFC, Face, and VideoCall modules have been moved to the Utility Module. The primary areas affected are:

  • The idDocTypeCheckVerified delegate has changed
  • The idDocFrontVerified delegate has changed
  • Functions such as Appointment, CallType, DocumentAdd, etc. must now be called through EnQualifyUtility

For detailed usage, refer to the Utility Module page.

🧪 Important Considerations During Testing

  • The flow should be tested end-to-end.