crowd-funder-for-time-pwa/doc/ios-share-extension-git-commit-guide.md at ae49c0e9071132e47d3cafe4d063743ccd9c4568

Files

Jose Olarte III ae49c0e907 feat(ios): implement native share target for images

Implement iOS Share Extension to enable native image sharing from Photos
and other apps directly into TimeSafari. Users can now share images from
the iOS share sheet, which will open in SharedPhotoView for use as gifts
or profile pictures.

iOS Native Implementation:
- Add TimeSafariShareExtension target with ShareViewController
- Configure App Groups for data sharing between extension and main app
- Implement ShareViewController to process shared images and convert to base64
- Store shared image data in App Group UserDefaults
- Add ShareImageBridge utility to read shared data from App Group
- Update AppDelegate to handle shared-photo deep link and bridge data to JS

JavaScript Integration:
- Add checkAndStoreNativeSharedImage() in main.capacitor.ts to read shared
  images from native layer via temporary file bridge
- Convert base64 data to data URL format for compatibility with base64ToBlob
- Integrate with existing SharedPhotoView component
- Add "shared-photo" to deep link validation schema

Build System:
- Integrate Xcode 26 / CocoaPods compatibility workaround into build-ios.sh
- Add run_pod_install_with_workaround() for explicit pod install
- Add run_cap_sync_with_workaround() for Capacitor sync (which runs pod
  install internally)
- Automatically detect project format version 70 and apply workaround
- Remove standalone pod-install-workaround.sh script

Code Cleanup:
- Remove verbose debug logs from ShareViewController, AppDelegate, and
  main.capacitor.ts
- Retain essential logger calls for production debugging

Documentation:
- Add ios-share-extension-setup.md with manual Xcode setup instructions
- Add ios-share-extension-git-commit-guide.md for version control best practices
- Add ios-share-implementation-status.md tracking implementation progress
- Add native-share-target-implementation.md with overall architecture
- Add xcode-26-cocoapods-workaround.md documenting the compatibility issue

The implementation uses a temporary file bridge (AppDelegate writes to Documents
directory, JS reads via Capacitor Filesystem plugin) as a workaround for
Capacitor plugin auto-discovery issues. This can be improved in the future by
properly registering ShareImagePlugin in Capacitor's plugin registry.

2025-11-24 20:46:58 +08:00

5.1 KiB

Raw Blame History

Date: 2025-01-27
Purpose: Clarify which Xcode manual changes should be committed to the repository

Quick Answer

YES, most manual Xcode changes SHOULD be committed. The only exceptions are user-specific settings that are already gitignored.

What Gets Modified (and Should Be Committed)

When you create the Share Extension target and configure App Groups in Xcode, the following files are modified:

1. `ios/App/App.xcodeproj/project.pbxproj` ✅ COMMIT THIS

This is the main Xcode project file that tracks:

New targets (Share Extension target)
File references (which files belong to which targets)
Build settings (compiler flags, deployment targets, etc.)
Build phases (compile sources, link frameworks, etc.)
Capabilities (App Groups configuration)
Target dependencies

This file IS tracked in git (not in .gitignore), so changes should be committed.

2. Entitlements Files ✅ COMMIT THESE

When you enable App Groups capability, Xcode creates/modifies:

ios/App/App/App.entitlements (for main app)
ios/App/TimeSafariShareExtension/TimeSafariShareExtension.entitlements (for extension)

These files contain the App Group identifiers and should be committed.

The following files are already in the repo:

ios/App/TimeSafariShareExtension/ShareViewController.swift
ios/App/TimeSafariShareExtension/Info.plist
ios/App/App/ShareImageBridge.swift

These should already be committed (they were created as part of the implementation).

What Should NOT Be Committed

1. User-Specific Settings ❌ ALREADY GITIGNORED

These are in ios/.gitignore:

xcuserdata/ - User-specific scheme selections, breakpoints, etc.
*.xcuserstate - User's current Xcode state

2. Signing Identities ❌ USER-SPECIFIC

While the App Groups capability should be committed (it's in project.pbxproj and entitlements), your personal signing identity/team is user-specific and Xcode handles this automatically per developer.

What Happens When You Commit

When you commit the changes:

Other developers who pull the changes will:
- ✅ Get the new Share Extension target automatically
- ✅ Get the App Groups capability configuration
- ✅ Get file references and build settings
- ✅ See the Share Extension in their Xcode project
They will still need to:
- Configure their own signing team/identity (Xcode prompts for this)
- Build the project (which may trigger CocoaPods updates)
- But they won't need to manually create the target or configure App Groups

Step-by-Step: What to Commit

After completing the Xcode setup steps:

# Check what changed
git status

# You should see:
# - ios/App/App.xcodeproj/project.pbxproj (modified)
# - ios/App/App/App.entitlements (new or modified)
# - ios/App/TimeSafariShareExtension/TimeSafariShareExtension.entitlements (new)
# - Possibly other project-related files

# Review the changes
git diff ios/App/App.xcodeproj/project.pbxproj

# Commit the changes
git add ios/App/App.xcodeproj/project.pbxproj
git add ios/App/App/App.entitlements
git add ios/App/TimeSafariShareExtension/TimeSafariShareExtension.entitlements
git commit -m "Add iOS Share Extension target and App Groups configuration"

Important Notes

Merge Conflicts in project.pbxproj

The project.pbxproj file can have merge conflicts because:

It's auto-generated by Xcode
Multiple developers might modify it
It uses UUIDs that can conflict

If you get merge conflicts:

Open the project in Xcode
Xcode will often auto-resolve conflicts
Or manually resolve by keeping both sets of changes
Test that the project builds

Team/Developer IDs

The DEVELOPMENT_TEAM setting in project.pbxproj might be user-specific:

Some teams commit this (if everyone uses the same team)
Some teams use .xcconfig files to override per developer
Check with your team's practices

If you see DEVELOPMENT_TEAM = GM3FS5JQPH; in the project file, this is already committed, so your team likely commits team IDs.

Verification

After committing, verify that:

The Share Extension target appears in Xcode for other developers
App Groups capability is configured
The project builds successfully
No user-specific files were accidentally committed

Summary

Change Type	Commit?	Reason
New target creation	✅ Yes	Modifies `project.pbxproj`
App Groups capability	✅ Yes	Creates/modifies entitlements files
File target membership	✅ Yes	Modifies `project.pbxproj`
Build settings	✅ Yes	Modifies `project.pbxproj`
Source files (Swift, plist)	✅ Yes	Already in repo
User scheme selections	❌ No	In `xcuserdata/` (gitignored)
Personal signing identity	⚠️ Maybe	Depends on team practice

Bottom line: Commit all the Xcode project configuration changes. Other developers will get the Share Extension target automatically when they pull, and they'll only need to configure their personal signing settings.

5.1 KiB Raw Blame History

iOS Share Extension - Git Commit Guide