I don't think so. The problem seems to be related with branch switches causing all package dependencies to be invalidated, refetched, and (I think) rebuilt.Sounds like a project that could benefit from either perforce or Git LFS?
Making the mobile team co-owners is actually a great idea. I don't know why we aren't doing that. I think API versioning is not necessary at the moment because we work on launching startup products, so we can freely break the previous API. Thankfully that also means I can make changes to CoreData models without designing a migration.Especially if the back end isn’t yours and doesn’t offer a schema or GraphQL.
That said, I’d probably seriously consider something like Apollo for a project where I could. Maintaining a hierarchy of types that can be generated from a schema is overhead that I’d rather spend elsewhere. Make the mobile team co-owners of the schema file so PRs against it require both sides to be aware and sign off. At least catch some of the brittleness by that. Even better would be proper API versioning.
Doesn’t mean you can’t autogenerate Codables from a schema as a build step, though. I’m just not sure I’d be wanting to write one myself.
I was favoring Apollo at first when we discussed whether to use that or a custom client, but I'm unsure if it's going to limit our flexibility. For example, if a query returns a URL, I'd prefer having our Swift model store it as Foundation's
String. Similarly, if a model has a stable unique identifier shared with backend, maybe I'd prefer to use the
UUIDtype than a regular
Well, since it's doable, that's another point towards using Apollo. The process is a bit verbose, but we'd only need to do it once for each custom type. I think I'm sold now.