Conversation
That's for the value `CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER`, but it's useless to set `$(inherited)` for a Yes or No value because removing the value from the target will automatically make Xcode read it from the project, achieving the same result.
Was giving errors in Yoga: > Double-quoted include "YGEnums.h" in framework header, expected angle-bracketed instead
It resulted in a build failure: > React.framework/Headers/RCTAppearance.h:16:60: > A function declaration without a prototype is deprecated in all versions of C
Generated by 🚫 Danger |
Strange that `pod deintegrate` did not remove it. Maybe it was some custom piece of setup...
As we start removing CocoaPods from some of our projects, we can no longer assume pods exist locally to install. See wordpress-mobile/WordPress-iOS#23951 which prompted this change.
We don't have pods anymore
|
| App Name | WordPress Alpha |
|
| Configuration | Release-Alpha | |
| Build Number | pr23951-c61cb2d | |
| Version | 25.6 | |
| Bundle ID | org.wordpress.alpha | |
| Commit | c61cb2d | |
| App Center Build | WPiOS - One-Offs #11289 |
| /// WordPressKit, now imported via CocoaPods, has the `AppExtension Safe API Only` flag set to *true*. Meaning that | ||
| /// the host app is, effectively as of now, responsible for presenting any alert onscreen (whenever a HTTP Challenge is | ||
| /// received). Capicci? | ||
| /// |
There was a problem hiding this comment.
This was a very old comment. It didn't seem to explain much to me, so I got rid of it.
| #import "WordPressAuthenticator-Swift.h" | ||
| #else | ||
| #import <WordPressAuthenticator/WordPressAuthenticator-Swift.h> | ||
| #endif |
There was a problem hiding this comment.
This was only useful for the CocoaPods setup. I noticed it grepping for CocoaPods and removed it. There were only two usages anyway, which I updated to the generated header, see below.
|
| App Name | Jetpack Alpha |
|
| Configuration | Release-Alpha | |
| Build Number | pr23951-c61cb2d | |
| Version | 25.6 | |
| Bundle ID | com.jetpack.alpha | |
| Commit | c61cb2d | |
| App Center Build | jetpack-installable-builds #10323 |
As we start removing CocoaPods from some of our projects, we can no longer assume pods exist locally to install. See wordpress-mobile/WordPress-iOS#23951 which prompted this change.
Love the I'll try moving the changes there today. |
|
@kean seems like everything worked fine. See #23958 — There are CI failures, but look unrelated to the changes, as they match what's in the base branch, example https://buildkite.com/automattic/wordpress-ios/builds/25312 |
|
|
Closing in favor of #23958 |
As we start removing CocoaPods from some of our projects, we can no longer assume pods exist locally to install. See wordpress-mobile/WordPress-iOS#23951 which prompted this change.


Picks up where #23750, but starting from scratch because of too many project file changes since then, and completes the migration away from CocoaPods as the mean of linking the Gutenberg XCFramework.
The sequence of changes is roughly:
xcframeworksApp.jsfile from the XCFramework to the build products as ajsbundleto use the new locationTwo things noteworthy:
CLANG_WARN_STRICT_PROTOTYPESandCLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER, because of build failures in the XCFramework imports. It doesn't seem ideal, but also we have increasingly less Objective-C so it should be acceptable. Open to suggestions.make dependenciesbefore building the app. It felt a build phase was a bit too much, but it also feels like a line in theREADMEto call attention to this is not enough. Open to suggestions.Testing
I published this from the Simulator: https://giotestdotsite.wordpress.com/2025/01/07/via-gutenbegkit-without-cocoapods/ — Not sure if the HTML source can show it, but I did check locally that the experimental editor toggle was disabled. Besides, the UI being a bit different between the two helps being aware of it.
Apart from that, I'd say run the prototype build on device and see if the Gutenber-via-XCFramework editor works as expected.
Regression Notes
It's possible that some behavior in the Gutenber-XCFramework editor will be compromised. However, I don't see why, once the editor loads, all the code should be the same.
Had a go at publishing a post from the Simulator.
N.A.
PR submission checklist:
RELEASE-NOTES.txtif necessary. - N.A.Testing checklist: