Fetch Simperium via SwiftPM and remove CocoaPods #1716
Conversation
mokagio
force-pushed
the
ainfra-446-migrate-simplenote-ios-pods-to-swiftpm-simperium
branch
from
9be4817 to
f957588
Compare
|
| App Name | Simplenote Prototype Build | |
| Build Number | 1301 | |
| Version | PR #1716 | |
| Bundle ID | com.codality.NotationalFlow.Alpha | |
| Commit | eb0c28d | |
| Installation URL | 3van243a40el0 |
mokagio
force-pushed
the
ainfra-446-migrate-simplenote-ios-pods-to-swiftpm-simperium
branch
2 times, most recently
from
672d8fd to
a8b0d30
Compare
| let presentAsPopover = UIDevice.sp_isPad() && traitCollection.horizontalSizeClass == .regular | ||
| let presentAsPopover = UIDevice.isPad && traitCollection.horizontalSizeClass == .regular |
There was a problem hiding this comment.
When building Simperium via CocaoPods, all headers are accessible. When building with SwiftPM, only those explicitly configured as public in the Xcode project and imported in the umbrella header are.
This resulted in sp_isPad() no longer being available on my first Simperium-via-SwiftPM go. I could have made it public, but I noticed we already have an implementation in the app code base, so I just used that.
mokagio
force-pushed
the
ainfra-446-migrate-simplenote-ios-pods-to-swiftpm-simperium
branch
from
a8b0d30 to
150037b
Compare
mokagio
added
the
tooling
AliSoftware
left a comment
AliSoftware
left a comment
There was a problem hiding this comment.
Apart from docs nits, LGTM.
I also ran the pod deintegrate to validate that there was not trace left of CocoaPods on the project, and confirmed it didn't generate any diff1.
Footnotes
-
well to be fair it did generate one, but only about formatting the line 1337 of the
project.pbxprojfrom a one-liner into multiline without semantic change) ↩
| #### CocoaPods | ||
|
|
||
| Simplenote for iOS uses [CocoaPods](http://cocoapods.org/) to manage third party libraries. | ||
| Third party libraries and resources managed by CocoaPods will be installed by the `rake dependencies` command above. | ||
|
|
There was a problem hiding this comment.
Maybe instead of deleting this completely, replace it with #### SwiftPM section mentioning that's what it uses now?
There was a problem hiding this comment.
Given SwiftPM is now the standard, or at least the recommended way to manage dependencies, would it be fair to expect folks to assume that's what's in use?
It's also apparent once one opens the project:
There was a problem hiding this comment.
Fair enough.
And as long as the README for simperium itself indicates how to integrate it via SwiftPM (which arguably is also the now-standard and could be seen as not useful to document, but I still think it's useful to mention, including given it's known to not be super active/rarely updated so one could still wonder if it has been updated to SPM, and because it's integrated as a binary xcframework not source code and one has to provide the GH release path not just the repo and the checksum etc, right?). Once we have than on simperium then I agree no need to mention SPM specifically in SN client repos like here.
There was a problem hiding this comment.
as long as the README for simperium itself indicates how to integrate it via SwiftPM
Oh, for sure. I haven't had a chance to address your comments on Simplenote macOS and Simperium but I agree that for the library the SwiftPM + XCFramework setup deserves to be documented.
There was a problem hiding this comment.
Begun adding docs for SwiftPM in Simperium via Simperium/simperium-ios@ba86678 and Simperium/simperium-ios@e3a3a1b
| desc 'Open the project in Xcode' | ||
| task xcode: [:dependencies] do | ||
| sh "open #{XCODE_WORKSPACE}" | ||
| sh "open #{XCODE_PROJECT}" |
There was a problem hiding this comment.
I wonder if using xed (command shipped with Xcode Command Line Tools to open a project in Xcode Editor) rather than open wouldn't be more idiomatic there? 🤷
There was a problem hiding this comment.
To be honest, I think we should get rid of this task.
Maybe it's just me, but I always just use xed from the terminal. Never this.
I'd feel differently if we were code generating the Xcode project with Tuist or similar, because we could make the task kill any open Xcode, regenerate, and reopen Xcode—that's what Beeper does. But here, especially now that we don't have CocoaPods in the dependencies task, it seems unnecessary.
Just to keep in sync with macOS, where the version is necessary because of code signing.
mokagio
force-pushed
the
ainfra-446-migrate-simplenote-ios-pods-to-swiftpm-simperium
branch
from
1593adb to
eb0c28d
Compare
mokagio
deleted the
ainfra-446-migrate-simplenote-ios-pods-to-swiftpm-simperium
branch
This is the final part of the CocoaPods removal work. See https://linear.app/a8c/issue/AINFRA-446.
The changes in Simperium/simperium-ios#624 made the Simperium Apple client available via SwiftPM, and this PR switches from the CocoaPods version to it.
While at it, I also removed CocoaPods entirely. In hindsight, I should have saved the removal for a dedicated PR. But the footprint is small enough that I guess we can manage here, too.
Note
UI tests failing because of https://github.com/Automattic/simplenote-ios/issue/1717
Test
I logged into my account from the Simulator and verified that the notes syncing — which is what Simperium is in charge of — still works.
Screen.Recording.2025-06-16.at.11.33.59.AM.mov
Review
Release
These changes do not require release notes.