This is a post for every iPhone\/iPad developer. Every day, we try to use “best practices” when writing code, and building apps.
\n
\nWe make apps that:<\/p>\n
There’s a lot of great stuff in iOS to help with this. The standard-libraries Apple wrote for iOS 2 \/ iOS 3 are exceptional in quality and design.<\/p>\n
And yet … while Apple’s library team has bent over backwards to help developers, it feels like the Xcode team sneaks up behind developers and stabs them in the back. They do it in low-level tools and changes that most ObjectiveC programmers don’t understand or care about. These seem far removed from normal coding. But they influence everything we do – right up to the recent “Xcode won’t allow you to submit your App to the App Store” bug. These are the silent quality-destroyer that slows down development every day.<\/p>\n
Developers suck it down – Apple provides no channel for acknowledging or reporting on this stuff (even their bug system is locked-down and private). It’s time to shine some light on Apple’s shamefully bad tools…<\/p>\n
Apple does not allow developers to re-use or share their code via dynamic libraries<\/strong> – most of what you see in code-re-use is due to hacks\u00a0using Static libs that developers have built to workaround Apple.<\/p>\n To be clear: Dynamic libraries have been Best Practice for decades; even Apple has been telling developers for years to use Dynamic libs across the board<\/strong> (read the OS X documentation).<\/p>\n When iOS came out, no apps were allowed to run “dynamic” code. This was a well-intentioned (but perhaps short-sighted) decision that Apple was later forced to reverse. But they kept the (now meaningless) ban on developers using the core language features of dynamic linking.<\/p>\n Thanks to Apple, we can more easily write virus\/trojan code that sidesteps Apple’s security checks<\/strong> (by running scripted code, which is now “allowed”) than we can write legitimate code that does not<\/strong> (Apple screens it when you upload to the App Store).<\/p>\n Apple has consistently told developers to use “Frameworks”, Apple’s proprietary system for managing libraries that abstracts the Dynamic\/Static difference. Frameworks are hugely valuable and speed up development while reducing bugs<\/strong>. I love Frameworks. They visibly reduce the stress of your team – it’s hard to exaggerate what a positive difference they can make.<\/p>\n But from day one, Apple blocked iOS developers<\/strong> from using this feature, and have never allowed us to use it. Anecdotally, the reason given was “frameworks can (optionally) be Dynamic, and dynamic linking isn’t allowed”.<\/p>\n This is (cow)(excrement)<\/strong>. The community has already proved there is no reason for Apple to ban Frameworks from iOS<\/a>. Instead of a trivial change on Apple’s side, developers have to jump through hoops and hacks to un-break Xcode.<\/p>\n Continuing in this vein, Apple won’t allow iOS developers to use Bundles – which are nothing more than ZIPped folders of ordinary files!<\/strong>. Frameworks made Bundles “optional”; without Frameworks, Bundles are “required”<\/strong>, but for the last 3 years, Apple has actively prevented iOS developers from using them.<\/p>\n Again, if you doubt this, you can use the commmunity-authored workarounds that work (after you jump through all the hoops)<\/a>. Apple won’t explain their actions, but again: this appears to show there’s no reason for Apple to block developers from this feature.<\/p>\n 25 years ago (this is how behind the curve Apple is!), before dynamic libraries were viable, there was a solution with Static Libraries. The toolchain is supposed to be “intelligent” (all of them except Apple’s) and only link static libs where necessary.<\/p>\n Apple is different; Xcode cannot detect that 1==1, even when its own tools tell it this is the case<\/strong>. Xcode then blocks your code from building, for no reason at all<\/strong>, pushing developers through more obscure hoops – or to just give up, stop re-using code, and instead copy\/paste duplicate it. Causing many, many bugs in the process.<\/p>\nWorkaround1: Static linking of static libraries<\/h2>\n
…Corollary: Bundles<\/h3>\n
Workaround2: Dynamic linking of Static Libraries<\/h2>\n