3 ms·

There are already package managers that have been developed for years (ie: hard problems solved and bugs ironed out), can track dependencies across languages/ru

There are already package managers that have been developed for years (ie: hard problems solved and bugs ironed out), can track dependencies across languages/runtimes, and have large cross-language communities. Cocoapods isn't even cross-platform. It's only for iOS libraries, which means it only works on macs, which means it won't offer much beyond mac package managers. So use macports, or fink, or homebrew, or nyx.

jballanc 15y ago
You're missing the point. This is not a tool for end-users, but rather for developers. iOS/OS X already have a means of distributing third-party libraries with projects (the "./Frameworks" directory), there just has not, until now, been a good way for developers to find and organize these libraries during development. The goal of this project is to give developers that way of sharing, discovering, and resolving dependencies of libraries, but at the end of the day everything will still get packaged up as a "*.app" that is distributed via the App Store. Also, the reason to create a custom tool for this instead of repurposing one of the many existing package managers is that it allows for the tool to be specialized for the specific case of developing App Store apps. Sure, you can install a third-party library via macports, but how do you tell macports to compile the library and place the resulting frameworks into the right directory in your Xcode project?
protomyth 15y ago
That seems to be the whole point is to provide a specialized manger For libraries on a Mac. Some people don't want a general solution to a specific problem.
adamjernst 15y ago
iOS libraries need to be cross-compiled and statically linked. (Dynamic linking is not allowed in apps submitted to the store, IIRC.) I'm sure macports or whatever CAN be forced to do both of these, but it's easiest just to make something new, lean and efficient.

jballanc 15y ago

You're missing the point. This is not a tool for end-users, but rather for developers. iOS/OS X already have a means of distributing third-party libraries with projects (the "./Frameworks" directory), there just has not, until now, been a good way for developers to find and organize these libraries during development. The goal of this project is to give developers that way of sharing, discovering, and resolving dependencies of libraries, but at the end of the day everything will still get packaged up as a "*.app" that is distributed via the App Store. Also, the reason to create a custom tool for this instead of repurposing one of the many existing package managers is that it allows for the tool to be specialized for the specific case of developing App Store apps. Sure, you can install a third-party library via macports, but how do you tell macports to compile the library and place the resulting frameworks into the right directory in your Xcode project?

protomyth 15y ago

That seems to be the whole point is to provide a specialized manger For libraries on a Mac. Some people don't want a general solution to a specific problem.

adamjernst 15y ago

iOS libraries need to be cross-compiled and statically linked. (Dynamic linking is not allowed in apps submitted to the store, IIRC.) I'm sure macports or whatever CAN be forced to do both of these, but it's easiest just to make something new, lean and efficient.