Add IFTTT support for iOS - #2091
Merged
Merged
Conversation
Four artifacts from com.ifttt.ifttt, readable now that the vendored parser handles Realm's pre-Cluster layout: - Account (class_UserRecord): login, email, account id, time zone - Applets (class_LiveConnectionRecord): the connected applets, with the service joined through the row's own primaryService link and the publisher as the service supplied it - Connected Services (class_LiveServiceRecord) - Detected Apps: the service ids under the app-detector.my-apps key of Library/Preferences/com.ifttt.ifttt.plist The connected applets are in class_LiveConnectionRecord, not in class_AppletRecord, which held no rows. class_ActivityItemRecord, class_WidgetRunRecord and class_RegionEvent were also empty, so no applet run, widget run or geofence event was recovered; the notes say so rather than leaving the absence to be read as an omission. An iOS data container is GUID-named, so the Realm path pattern cannot carry the bundle id. Every candidate Documents/default.realm is required to hold an IFTTT class before it is read. Verified in both directions: on the tested extraction it returns rows, and on one holding three other apps' Documents/default.realm it returns none. Detected Apps is reported as stored and does not assert that an entry means the app was installed; only one extraction holding IFTTT was available, so the list could not be compared against a second device. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds IFTTT support for iOS. Four artifacts from
com.ifttt.ifttt, readable now that the vendored parser handles Realm's pre-Cluster layout:class_UserRecord): login, email, account id, time zone.class_LiveConnectionRecord): the connected applets, with the service joined through the row's ownprimaryServicelink and the publisher as the service supplied it.class_LiveServiceRecord).app-detector.my-appskey ofLibrary/Preferences/com.ifttt.ifttt.plist.The connected applets live in
class_LiveConnectionRecord, notclass_AppletRecord, which held no rows.class_ActivityItemRecord,class_WidgetRunRecordandclass_RegionEventwere empty too, so no applet run, widget run or geofence event was recovered; the notes state that rather than leaving the absence to read as an omission.An iOS data container is GUID-named, so the Realm path pattern cannot carry the bundle id. Every candidate
Documents/default.realmmust hold an IFTTT class before it is read. Verified both ways: rows on the tested extraction, and none on one holding three other apps'Documents/default.realm.Detected Apps is reported as stored and does not assert that an entry means the app was installed. Only one extraction holding IFTTT was available across 28 Android and 24 iOS corpora, so the list could not be compared against a second device.
🤖 Generated with Claude Code