Showing
5 changed files
with
199 additions
and
1 deletions
No preview for this file type
MODULE_NAME_ANALYSIS.md
0 → 100644
| 1 | +# Module Name Analysis - SPM vs XIB Configuration | ||
| 2 | + | ||
| 3 | +## The Configuration Mystery Solved | ||
| 4 | + | ||
| 5 | +After examining the Package.swift file, I can now explain exactly what's happening with the module names. | ||
| 6 | + | ||
| 7 | +## Package.swift Configuration | ||
| 8 | + | ||
| 9 | +```swift | ||
| 10 | +let package = Package( | ||
| 11 | + name: "SwiftWarplyFramework", // Package name | ||
| 12 | + products: [ | ||
| 13 | + .library( | ||
| 14 | + name: "SwiftWarplyFramework", // Library name | ||
| 15 | + targets: ["SwiftWarplyFramework"] // Target name | ||
| 16 | + ), | ||
| 17 | + ], | ||
| 18 | + targets: [ | ||
| 19 | + .target( | ||
| 20 | + name: "SwiftWarplyFramework", // Target name | ||
| 21 | + path: "SwiftWarplyFramework/SwiftWarplyFramework", // Path to source | ||
| 22 | + // ... resources and dependencies | ||
| 23 | + ), | ||
| 24 | + ] | ||
| 25 | +) | ||
| 26 | +``` | ||
| 27 | + | ||
| 28 | +## The Root Cause | ||
| 29 | + | ||
| 30 | +The issue is **NOT** with our Package.swift configuration. Everything is correctly named `SwiftWarplyFramework`. The problem is elsewhere. | ||
| 31 | + | ||
| 32 | +## Evidence Analysis | ||
| 33 | + | ||
| 34 | +### 1. Package Configuration ✅ | ||
| 35 | +- **Package name**: `SwiftWarplyFramework` | ||
| 36 | +- **Library name**: `SwiftWarplyFramework` | ||
| 37 | +- **Target name**: `SwiftWarplyFramework` | ||
| 38 | +- **All consistent and correct** | ||
| 39 | + | ||
| 40 | +### 2. XIB Configuration ✅ | ||
| 41 | +- **customModule**: `SwiftWarplyFramework` | ||
| 42 | +- **Matches the package/target name perfectly** | ||
| 43 | + | ||
| 44 | +### 3. Runtime Behavior ❌ | ||
| 45 | +- **Error shows**: `_TtC41SwiftWarplyFramework_SwiftWarplyFramework40MyRewardsBannerOffersScrollTableViewCell` | ||
| 46 | +- **Bundle path**: `SwiftWarplyFramework_SwiftWarplyFramework.bundle` | ||
| 47 | + | ||
| 48 | +## The Real Issue | ||
| 49 | + | ||
| 50 | +The mangled name `SwiftWarplyFramework_SwiftWarplyFramework` suggests that **SPM is somehow duplicating the module name** during the build process, even though our configuration is correct. | ||
| 51 | + | ||
| 52 | +## Possible Causes | ||
| 53 | + | ||
| 54 | +### 1. SPM Build System Bug | ||
| 55 | +SPM might be generating incorrect module names due to the directory structure: | ||
| 56 | +``` | ||
| 57 | +SwiftWarplyFramework/ # Root directory | ||
| 58 | +└── SwiftWarplyFramework/ # Target directory | ||
| 59 | + └── SwiftWarplyFramework/ # Source files | ||
| 60 | +``` | ||
| 61 | + | ||
| 62 | +### 2. Client Integration Issue | ||
| 63 | +The way the client app is integrating the SPM package might be causing module name duplication. | ||
| 64 | + | ||
| 65 | +### 3. Xcode/SPM Version Issue | ||
| 66 | +This could be a known issue with certain versions of Xcode or SPM. | ||
| 67 | + | ||
| 68 | +## Debugging Steps | ||
| 69 | + | ||
| 70 | +### 1. Check Client's Package.resolved | ||
| 71 | +The client's `Package.resolved` file might show how SPM is resolving the module name. | ||
| 72 | + | ||
| 73 | +### 2. Check Build Logs | ||
| 74 | +The actual build logs would show what module name SPM is using during compilation. | ||
| 75 | + | ||
| 76 | +### 3. Test with Simplified Structure | ||
| 77 | +We could test if flattening the directory structure resolves the issue. | ||
| 78 | + | ||
| 79 | +## Immediate Solutions to Try | ||
| 80 | + | ||
| 81 | +### Option 1: Update XIB Module Name | ||
| 82 | +Change XIB files to use `SwiftWarplyFramework_SwiftWarplyFramework` as the module name. | ||
| 83 | + | ||
| 84 | +### Option 2: Remove Module Specification | ||
| 85 | +Remove `customModule` and `customModuleProvider` from XIB files entirely. | ||
| 86 | + | ||
| 87 | +### Option 3: Add Explicit Module Name | ||
| 88 | +Add an explicit `swiftSettings` to the target to force the module name. | ||
| 89 | + | ||
| 90 | +## Recommendation | ||
| 91 | + | ||
| 92 | +I recommend trying **Option 2 first** (removing module specification from XIB files) as this is the least invasive and most likely to work across different SPM configurations. | ||
| 93 | + | ||
| 94 | +## Next Steps | ||
| 95 | + | ||
| 96 | +1. Test removing module specification from one XIB file | ||
| 97 | +2. If that works, apply to all XIB files | ||
| 98 | +3. If that doesn't work, try updating to the duplicated module name | ||
| 99 | +4. Document the final solution for future reference | ||
| 100 | + | ||
| 101 | +The key insight is that our Package.swift is correct, but SPM is somehow generating a different module name than expected during the build process. |
No preview for this file type
| ... | @@ -9,7 +9,7 @@ | ... | @@ -9,7 +9,7 @@ |
| 9 | <objects> | 9 | <objects> |
| 10 | <placeholder placeholderIdentifier="IBFilesOwner" id="-1" userLabel="File's Owner"/> | 10 | <placeholder placeholderIdentifier="IBFilesOwner" id="-1" userLabel="File's Owner"/> |
| 11 | <placeholder placeholderIdentifier="IBFirstResponder" id="-2" customClass="UIResponder"/> | 11 | <placeholder placeholderIdentifier="IBFirstResponder" id="-2" customClass="UIResponder"/> |
| 12 | - <tableViewCell contentMode="scaleToFill" selectionStyle="none" indentationWidth="10" reuseIdentifier="MyRewardsBannerOffersScrollTableViewCell" rowHeight="349" id="KGk-i7-Jjw" customClass="MyRewardsBannerOffersScrollTableViewCell" customModule="SwiftWarplyFramework" customModuleProvider="target"> | 12 | + <tableViewCell contentMode="scaleToFill" selectionStyle="none" indentationWidth="10" reuseIdentifier="MyRewardsBannerOffersScrollTableViewCell" rowHeight="349" id="KGk-i7-Jjw" customClass="MyRewardsBannerOffersScrollTableViewCell"> |
| 13 | <rect key="frame" x="0.0" y="0.0" width="413" height="349"/> | 13 | <rect key="frame" x="0.0" y="0.0" width="413" height="349"/> |
| 14 | <autoresizingMask key="autoresizingMask" flexibleMaxX="YES" flexibleMaxY="YES"/> | 14 | <autoresizingMask key="autoresizingMask" flexibleMaxX="YES" flexibleMaxY="YES"/> |
| 15 | <tableViewCellContentView key="contentView" opaque="NO" clipsSubviews="YES" multipleTouchEnabled="YES" contentMode="center" insetsLayoutMarginsFromSafeArea="NO" tableViewCell="KGk-i7-Jjw" id="H2p-sc-9uM"> | 15 | <tableViewCellContentView key="contentView" opaque="NO" clipsSubviews="YES" multipleTouchEnabled="YES" contentMode="center" insetsLayoutMarginsFromSafeArea="NO" tableViewCell="KGk-i7-Jjw" id="H2p-sc-9uM"> | ... | ... |
XIB_INVESTIGATION_REPORT.md
0 → 100644
| 1 | +# XIB Investigation Report - SPM Class Resolution Issue | ||
| 2 | + | ||
| 3 | +## Investigation Summary | ||
| 4 | + | ||
| 5 | +I have thoroughly investigated the XIB bundling and class resolution issue. Here are my findings: | ||
| 6 | + | ||
| 7 | +## ✅ What's Working Correctly | ||
| 8 | + | ||
| 9 | +### 1. XIB File Configuration | ||
| 10 | +**GOOD NEWS**: The XIB files are configured correctly! | ||
| 11 | + | ||
| 12 | +**MyRewardsBannerOffersScrollTableViewCell.xib**: | ||
| 13 | +```xml | ||
| 14 | +<tableViewCell ... customClass="MyRewardsBannerOffersScrollTableViewCell" customModule="SwiftWarplyFramework" customModuleProvider="target"> | ||
| 15 | +``` | ||
| 16 | + | ||
| 17 | +**ProfileHeaderTableViewCell.xib**: | ||
| 18 | +```xml | ||
| 19 | +<tableViewCell ... customClass="ProfileHeaderTableViewCell" customModule="SwiftWarplyFramework" customModuleProvider="target"> | ||
| 20 | +``` | ||
| 21 | + | ||
| 22 | +- ✅ **Class names are clean** (not mangled) | ||
| 23 | +- ✅ **Module is correctly set** to "SwiftWarplyFramework" | ||
| 24 | +- ✅ **Module provider is "target"** (correct for SPM) | ||
| 25 | + | ||
| 26 | +### 2. Swift Class Configuration | ||
| 27 | +**ALSO GOOD**: Our @objc attributes are correctly applied: | ||
| 28 | + | ||
| 29 | +```swift | ||
| 30 | +@objc(MyRewardsBannerOffersScrollTableViewCell) | ||
| 31 | +public class MyRewardsBannerOffersScrollTableViewCell: UITableViewCell { | ||
| 32 | +``` | ||
| 33 | + | ||
| 34 | +### 3. XIB Bundling | ||
| 35 | +**WORKING**: Our debug output shows XIB files are found and loaded: | ||
| 36 | +``` | ||
| 37 | +✅ [WarplySDK] Found XIB: MyRewardsBannerOffersScrollTableViewCell at .../MyRewardsBannerOffersScrollTableViewCell.nib | ||
| 38 | +``` | ||
| 39 | + | ||
| 40 | +## ❌ The Real Problem | ||
| 41 | + | ||
| 42 | +### Root Cause Analysis | ||
| 43 | +The issue is **NOT** with our XIB configuration or @objc attributes. The problem is more fundamental: | ||
| 44 | + | ||
| 45 | +**The error shows the mangled name**: `_TtC41SwiftWarplyFramework_SwiftWarplyFramework40MyRewardsBannerOffersScrollTableViewCell` | ||
| 46 | + | ||
| 47 | +This suggests that **somewhere in the runtime**, the system is still trying to resolve the class using the mangled Swift name instead of our clean @objc name. | ||
| 48 | + | ||
| 49 | +## 🔍 Key Findings | ||
| 50 | + | ||
| 51 | +### 1. XIB Files Are Correctly Configured | ||
| 52 | +- Class names: `MyRewardsBannerOffersScrollTableViewCell` (clean) | ||
| 53 | +- Module: `SwiftWarplyFramework` | ||
| 54 | +- Module provider: `target` | ||
| 55 | + | ||
| 56 | +### 2. Swift Classes Have Correct @objc Attributes | ||
| 57 | +- `@objc(MyRewardsBannerOffersScrollTableViewCell)` is properly applied | ||
| 58 | + | ||
| 59 | +### 3. The Disconnect | ||
| 60 | +- XIB expects: `MyRewardsBannerOffersScrollTableViewCell` | ||
| 61 | +- Runtime is looking for: `_TtC41SwiftWarplyFramework_SwiftWarplyFramework40MyRewardsBannerOffersScrollTableViewCell` | ||
| 62 | + | ||
| 63 | +## 🤔 Possible Causes | ||
| 64 | + | ||
| 65 | +### 1. Module Name Mismatch in SPM | ||
| 66 | +The XIB file specifies `customModule="SwiftWarplyFramework"`, but in SPM, the actual module name might be different (like `SwiftWarplyFramework_SwiftWarplyFramework`). | ||
| 67 | + | ||
| 68 | +### 2. Build System Issue | ||
| 69 | +The @objc attributes might not be taking effect during the SPM build process. | ||
| 70 | + | ||
| 71 | +### 3. Runtime Class Registration | ||
| 72 | +The class might not be properly registered with the Objective-C runtime under the @objc name. | ||
| 73 | + | ||
| 74 | +## 📋 Recommended Next Steps | ||
| 75 | + | ||
| 76 | +### Option 1: Module Name Investigation | ||
| 77 | +Check what the actual module name is in SPM vs what's in the XIB files. | ||
| 78 | + | ||
| 79 | +### Option 2: XIB Module Configuration | ||
| 80 | +Try changing the XIB files to use the actual SPM module name or remove the module specification entirely. | ||
| 81 | + | ||
| 82 | +### Option 3: Alternative @objc Approach | ||
| 83 | +Try using just `@objc` without the explicit name, or use `@objc` with the full module-qualified name. | ||
| 84 | + | ||
| 85 | +### Option 4: Bundle vs Module Issue | ||
| 86 | +The problem might be that we're using `customModuleProvider="target"` when we should be using something else for SPM. | ||
| 87 | + | ||
| 88 | +## 🎯 Immediate Action Items | ||
| 89 | + | ||
| 90 | +1. **Verify the actual module name** being used in SPM | ||
| 91 | +2. **Test XIB without module specification** (remove `customModule` and `customModuleProvider`) | ||
| 92 | +3. **Check if other XIB files have the same issue** or if it's specific to this one | ||
| 93 | +4. **Consider using programmatic cell creation** as a fallback if XIB issues persist | ||
| 94 | + | ||
| 95 | +## Conclusion | ||
| 96 | + | ||
| 97 | +The XIB files and Swift classes are configured correctly. The issue appears to be a deeper SPM module name resolution problem where the runtime is still using mangled names despite our @objc attributes. |
-
Please register or login to post a comment