Native iOS
application development
in Westwood

Almost no native iOS project is written entirely from scratch. Networking helpers, image loading, analytics wrappers, and dozens of smaller utilities. Most arrive as third party packages. How a project pulls those packages in shapes every future upgrade. The choice sits mainly between two tools: Swift Package Manager, built directly into Xcode, and CocoaPods, an older external tool that still carries the widest coverage of legacy libraries.

Swift Package Manager resolves and caches dependencies on its own. It needs no extra tool beyond Xcode itself. A fresh checkout on a new machine needs nothing else installed. Version ranges are declared per package. Xcode then resolves the whole graph on build, favoring the newest version compatible with every stated range, unless something is pinned deliberately.

CocoaPods works differently. It generates a workspace file and a lock file that records the exact version installed for every dependency. Some teams still prefer this. It is predictable on a larger, older codebase, where dozens of packages already assume that structure. The tradeoff is real, though: an extra command line tool to install, a slower resolution step as a project grows, and a workspace file that needs regenerating whenever the dependency list changes.

Carthage was once a popular third option. It builds each dependency as a separate framework, without touching the project file at all. It has faded from most new work, as package authors moved toward native Swift Package Manager support. A handful of older internal libraries at established companies still rely on it. They are not always worth migrating away from right away.

Migration between these systems is rarely instant. A library that only ships one format forces a choice. Either the whole project adopts that format for every dependency, or the project runs two package managers side by side. That roughly doubles the surface a team has to track during every future upgrade. A project that started years ago on CocoaPods, and slowly gained Swift Package Manager only packages alongside it, ends up in a common, awkward middle state.

Private, internal packages hosted on a company git server raise a separate question. Continuous integration machines need their own authentication: an access token, or an SSH key scoped narrowly to those repositories. It gets configured once, and then forgotten about. Eventually it silently expires. A build starts failing for a reason that has nothing to do with the code that changed.

Binary distributed packages build faster than source only ones. The compiler skips recompiling code that has not changed since the last build. That matters more than it sounds, once a project accumulates a few dozen dependencies and a full build starts eating real time out of every workday. Source only packages remain easier to debug, though, when something inside one behaves unexpectedly, since a developer can step directly into that code.

None of this needs deciding once and then forgotten. Adding a substantial new library is a natural point to revisit the whole setup. That is especially true if the library only supports the format not currently in use, rather than forcing every future dependency into a pattern chosen years earlier for reasons that may no longer apply.

Fewer, more deliberately chosen dependencies keep the eventual privacy paperwork lighter too. Each third party package that collects data of its own now needs its practices documented alongside those of the app. A shorter list is simply less to track down. It is also less to get wrong, when that documentation gets assembled ahead of a submission.

None of these tools is free of upkeep. Every package added is a line item. Someone has to revisit it. Apple ships a new Swift version. A maintainer abandons a library. A security note quietly appears in a changelog nobody read that week. Treating the dependency list as a standing decision, reviewed on a schedule rather than only when something breaks, keeps a project from waking up years later to a wall of outdated packages that all need replacing at once.