Mobile Payments SDK 2.6.0 — SQLite Database Unlink Warnings During Initialization

[tomortiz25]

Mobile Payments SDK 2.6.0 — SQLite Database Unlink Warnings During Initialization

Hello Square Developer Support,

We are developing an iPad-based point-of-sale application integrating Square Mobile Payments SDK 2.6.0.

During application initialization, we consistently encounter SQLite database lifecycle warnings involving Square’s internal RegisterAccounts.sqlite database and its associated WAL and SHM files.

OBSERVED SQLITE WARNINGS

The warnings include:

BUG IN CLIENT OF libsqlite3.dylib:
database integrity compromised by API violation:
vnode unlinked while in use

RegisterAccounts.sqlite
RegisterAccounts.sqlite-wal
RegisterAccounts.sqlite-shm

invalidated open fd

We conducted a targeted physical-device debugging investigation and captured the following execution sequence:

Application launch
→ Square Mobile Payments SDK initialization
→ Square SDK internal execution
→ Foundation.removeItem(atPath:)
→ removefile
→ unlink
→ SQLite reports invalidated open file descriptors

The file-removal operation originates within Square’s SDK during initialization.

We have not identified any application-level code deleting or modifying these files.

Importantly, we have observed the warnings under two configurations:

1. An iPad authorized with our own Square merchant account.
2. The same iPad running without active Square authorization.

The SDK has continued initializing, and we have successfully processed payments during authorized testing. However, we are concerned about the implications of removing SQLite database files while active file descriptors remain open.

We also located an older Square Developer Forum discussion reporting nearly identical warnings in Reader SDK 1.3.8:

Issue initializing the Square Reader SDK in iOS / Swift project

Hi Folks, hoping someone might be able to point me in the right direction with an issue. I was able to successfully clone the ReaderSDKSample project, go through the configuration and setup of the project locally (get repo password, download and install the SDK, etc.) and take a live credit card payment via the card reader on an iPad Mini. I’m subsequently trying to create a new project from scratch, to get to the same point, however I am running into an error when trying to initialize the SDK…

We understand that Reader SDK and Mobile Payments SDK are different SDK generations, so we are not assuming the underlying causes are identical.

QUESTIONS FOR SQUARE ENGINEERING

Could your engineering team clarify the following?

1. Is this a known behavior or defect in Mobile Payments SDK 2.6.0?

2. What causes the SDK to remove RegisterAccounts.sqlite and its WAL/SHM files during initialization?

3. Is this cleanup expected when existing SQLite connections remain open?

4. Could this affect merchant authorization persistence, reader restoration, or interrupted-payment recovery?

5. Has this behavior been corrected in a newer SDK release?

6. Are there recommended initialization or lifecycle changes we should implement?

7. If this is an SDK-internal issue, is there an existing engineering ticket or planned correction?

We can provide sanitized debugger backtraces and additional diagnostic information if needed.

We would appreciate guidance before expanding our Production deployment.

ADDENDUM — SDK DEPENDENCY AND INITIALIZATION AUDIT FINDINGS

Following our original investigation, we completed an additional source-level and binary dependency audit of our Square Mobile Payments SDK integration.

We would like to share these findings to help your engineering team narrow the investigation.

1. SDK VERSION AND DEPENDENCY VERIFICATION

Our application uses a single Square Mobile Payments SDK package, pinned to version 2.6.0.

We confirmed:

• No separately installed legacy Square Reader SDK.
• No duplicate Mobile Payments SDK package or product linkage.
• No competing CocoaPods or Carthage installation.
• No independent initialization of Square’s bundled supporting frameworks.
• One application-owned SDK initialization coordinator.

The application includes the following frameworks as dependencies supplied by Mobile Payments SDK 2.6.0:

• SquareReader.framework
• LCRCore.framework
• CorePaymentCard.framework

These are not separately installed legacy SDKs.

2. INITIALIZATION LIFECYCLE

Our application initializes Mobile Payments SDK during application launch through a single coordinator.

The initialization path includes guards against repeated initialization and environment mismatches.

Source inspection indicates that an ordinary successful application launch invokes MobilePaymentsSDK.initialize once.

We found no evidence of concurrent initialization, duplicate SDK instances, or application-triggered deauthorization during the captured SQLite warnings.

Our reviewed initialization sequence appears consistent with Square’s documented integration requirements.

3. CONFIRMED FILE-REMOVAL CALL STACK

Using temporary LLDB instrumentation on a physical iPad, we captured file-removal operations involving all three database files:

• RegisterAccounts.sqlite
• RegisterAccounts.sqlite-wal
• RegisterAccounts.sqlite-shm

The observed execution path was:

Application launch
→ MobilePaymentsSDK.initialize
→ Square SDK internal frames
→ Foundation.removeItem(atPath:)
→ removefile
→ unlink

The removal operations originated inside Square’s SDK during initialization.

SQLite subsequently reported invalidated open file descriptors.

No application-level file deletion targeting these databases was identified.

Because Square’s internal functions are not fully symbolicated, we cannot determine which internal component retains the open SQLite connections or why the files are being removed.

4. AUTHORIZATION STATE IS NOT THE TRIGGER BY ITSELF

We have reproduced the warning under two configurations on the same physical iPad:

• With a Square merchant account authorized and payment processing operational.
• Without an active Square merchant authorization.

Therefore, missing authorization is not a necessary condition for the warning.

The warning also occurred before restoring a different merchant’s historical data, ruling out that backup as a necessary cause.

5. SDK VERSION AND HISTORICAL BEHAVIOR

Our dependency audit found no newer iOS Mobile Payments SDK release documented as correcting this behavior.

We also identified a historical Square Developer Forum report from 2020 describing the same SQLite filenames and unlink warnings in Reader SDK 1.3.8.

We recognize that Reader SDK and Mobile Payments SDK are different generations and are not assuming the underlying implementation or root cause is identical.

6. ADDITIONAL ENGINEERING QUESTIONS

Based on these findings, we would particularly appreciate clarification on:

1. Whether Mobile Payments SDK 2.6.0 intentionally removes or replaces RegisterAccounts.sqlite during initialization.

2. Whether this operation is part of database migration, legacy storage cleanup, or another internal lifecycle process.

3. Why SQLite connections appear to remain open when the files are unlinked.

4. Whether this behavior can affect merchant authorization persistence, reader reconnection, or interrupted-payment recovery.

5. Whether Square has an internal engineering issue tracking this behavior.

6. Whether any supported mitigation or future SDK correction is available.

CURRENT OPERATIONAL OBSERVATIONS

SDK initialization and authorized payment processing have succeeded during our testing.

We have not established any financial-record corruption or payment failure attributable to these warnings.

We are deliberately avoiding undocumented workarounds, direct manipulation of SDK database files, or changes to our authorization lifecycle while awaiting clarification.

Thank you for reviewing these findings and for any guidance your engineering team can provide.

POS Application Development Team