-
For the most parts, it is much easier to work with Swift Packages, for instance you can open up the project (the package) in a different IDE or Editor and code there (VS Code for instance), since SourceKit-lsp supports thirds party IDEs and Edirotrs.
-
You get the opportunity to use vim! (YES, that is a pro!!!)
-
You are open to use the built-in terminal in that edirot to do your git commits without leaving your enviornment (yes, I know you can do git stuff inside xcode!).
-
Running the Unit Tests and getting feedback in a much more prettified way (with the help of libraries such as XCPretty or XCBeautify).
-
Plus, you have the possiblity to check your code for fomatting and code conventions with the help of the legendary SwiftFormat (by the way, here you can find my own setup and configuration of this library that I regularly use SwiftFormat & SwiftLint configs).
-
Everything is cool, up until you need to do the UI part and/or have a CoreData model in your project. SourceKit-lsp doesn't support UIKit, since, well obviously, the UIKit isn't open source. Here you need to get back to xcode.
-
Having a CoreData model in your project (oh man 🤦♂️). In this case you need to create the model in a separate project, an xcode supported project, setup the entities, the configurations etc, then import (copy the file over) it to your package. This is not the only headache you'd face. You need to put the model file in a directory at the root of the source code (Resources directory). That's not all (😂), in case of accessing the model, you need to call
Bundle.module, you can find a detailed explanation about here in the doc. This issue is still true for Localization and Assets. (you need to have the assets and localized strings files in the Resources directory.) -
Obviously, you don't have vim, anymore (yeah, you have some sort of a vim in xcode, which I just call it baby-vim, I have posted about it quite a few times on LinkedIn).
-
From xcode 14.3 onward, xcode kinda forces you to use test plans (xctestplan) plus the making-test-run-randomly (instead of the default one which is alphabetically) is now, is in that autogenerated xctestplan that comes with the fresh project that you created.
which you should make that change as soon as you write your second test!
With frameworks, you have the opportunity to create new (or duplicate-and-modify-existing, which is the preferred one) schemes, assign different test plans to them, which doing so in packages, is quite a headache.
Second, doing the UI in code (programmatically per say) in UIKit, instead of Storyboard which was used originally.
The fun part!
For some reason, Swift Package doesn't support storyboard. I mean you do can have a storyboard and setup all your UI components there, but the problem is that you can't call it (or maybe that is what I have experienced.), you do can though setup the UIs in xib files, and just call them the way you'd call a CoreData model or a Localized string file.
For these reasons, and also since I just love to do the UIs in code, I decided to go on with doing the UI in code.
They use a storyboard in the original project as a container-like or generic one (per say) to reuse it for both the Feed as well as the CommentsImage views (storyboards). Both of them are backed by ListViewController as their controller. So, since I am doing the UI in code, I made the ListViewController generic which takes a generic T of type UITableViewCell. And since it (the controller) needs to register the required tableView with a cell, I added an initializer to it, problem solved, two storyboards eliminated. Next, prefetchDataSource was setup in the storyboard before, now you need to configure it in code.
Sometimes, it is pretty hard to replicate UI components, since there are details you might miss, in this case the Snapshot tests did help alot. After finishing up the UI, I copied the taken screenshots from the original project over to mine and ran the Snapshot tests, they all passed (🥳). Like I once said, the importance of UI testing and Snapshot testing, in general, is about to rely on the engine to examine your UI, instead of relying on a human-eye!
Here, you'll find the EssentialFeed, which stands as the Core (or Model, in the 3 layer architecture) Essential Feed as a Swift Package.
Also, here you'll find the EssentialiOS part of the project, as a Swift Package, which stands as the Presentation layer. Essential iOS.
Note, there might be some details that I have forgotten to add, will update this.
Ah, here is the original project, EssentialApp Thank you, Essential Developer for making this project available. 🙏