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