iOS Static Libraries Are, Like, Really Bad

Re:iOS Static Libraries Are, Like, Really Bad by CoolGuySteve on Sunday January 12, 2014 @07:14PM (#7048091)

It's a two sided coin, if you update a dynamically loaded library that subtly breaks backwards compatibility, you end up with apps that mysteriously stop working because of some other update in the system.

Really, it's up to the app maintainer to update their program, and if it has a vulnerability, in theory the sandbox will prevent it from doing damage to others.

[ Parent | on HN ]

Re:iOS Static Libraries Are, Like, Really Bad by binarycrusader on Monday January 13, 2014 @02:02PM (#7052567)

If someone updates a library incompatibility, they deserve what they get. That's why shared libraries have versioning.

In the mobile space, it would be even more beneficial if platform holders and ISVs actually followed this; the memory and space usage savings could be substantial.

[ Parent | on HN ]

Re:iOS Static Libraries Are, Like, Really Bad by binarycrusader on Monday January 13, 2014 @06:23PM (#7054302)

I'm uncertain why someone would downvote my comment above, but shared library versioning is a real thing, and it is a best practice:

http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries...

https://www.usenix.org/legacy/publications/library/proceedin...

Linux distributions heavily depend on this for the GCC runtime libraries (such as libgcc_s); it's how they provide backwards compatibility.

Many operating system distributors also rely on symbol versioning for their shared libraries as well so they can compatibly evolve interfaces for consumers.

So my original point stands, if someone incompatibly updates a shared library without accounting for versioning, they're doing it wrong.

[ Parent | on HN ]