The Stack Overflow podcast is back! Listen to an interview with our new CEO.
4 Updated data
source | link

Clearly Apple has the ability to create dynamically loaded libraries (known as frameworks) for iOS, as they ship several with XCode (such as UIKit). App developers only have the ability to create static libraries, or at best, trick Xcode into thinking it's loading a framework when it's actually loading a static library, this is known as creating a fake framework, some of the drag-and-drop convenience, but none of the dynamic loading benefits.

What is Apple's reasoning for keeping dynamic frameworks from app developers? It seems like it would ease using external libraries considerably, since developers wouldn't have to rely on finicky linker flags or open-source library dependency chains.

I see a common reason is security. Why then does Apple allow it on OSX and not iOS? Isn't security a requirement there as well?

EDIT: This is no longer relevant as of iOS 8. Apple has added support for dynamic frameworks.

Clearly Apple has the ability to create dynamically loaded libraries (known as frameworks) for iOS, as they ship several with XCode (such as UIKit). App developers only have the ability to create static libraries, or at best, trick Xcode into thinking it's loading a framework when it's actually loading a static library, this is known as creating a fake framework, some of the drag-and-drop convenience, but none of the dynamic loading benefits.

What is Apple's reasoning for keeping dynamic frameworks from app developers? It seems like it would ease using external libraries considerably, since developers wouldn't have to rely on finicky linker flags or open-source library dependency chains.

I see a common reason is security. Why then does Apple allow it on OSX and not iOS? Isn't security a requirement there as well?

Clearly Apple has the ability to create dynamically loaded libraries (known as frameworks) for iOS, as they ship several with XCode (such as UIKit). App developers only have the ability to create static libraries, or at best, trick Xcode into thinking it's loading a framework when it's actually loading a static library, this is known as creating a fake framework, some of the drag-and-drop convenience, but none of the dynamic loading benefits.

What is Apple's reasoning for keeping dynamic frameworks from app developers? It seems like it would ease using external libraries considerably, since developers wouldn't have to rely on finicky linker flags or open-source library dependency chains.

I see a common reason is security. Why then does Apple allow it on OSX and not iOS? Isn't security a requirement there as well?

EDIT: This is no longer relevant as of iOS 8. Apple has added support for dynamic frameworks.

3 deleted 6 characters in body
source | link

Clearly Apple has the ability to create dynamically loaded libraries (known as frameworks) for iOS, as they ship several with XCode (such as UIKit). App developers only have the ability to create static libraries, or at best, trick Xcode into thinking it's loading a framework when it's actually loading a static library, this is known as creating a fake framework, some of the drag-and-drop convenience, but none of the dynamic loading benefits.

What is Apple's reasoning for keeping dynamic frameworks from app developers? It seems like it would ease using external libraries considerably, since developers wouldn't have to rely on finicky linker flags or open-source library dependency chains.

Edit: I see a common reason is security. Why then does Apple allow it on OSX and not iOS? Isn't security a requirement there as well?

Clearly Apple has the ability to create dynamically loaded libraries (known as frameworks) for iOS, as they ship several with XCode (such as UIKit). App developers only have the ability to create static libraries, or at best, trick Xcode into thinking it's loading a framework when it's actually loading a static library, this is known as creating a fake framework, some of the drag-and-drop convenience, but none of the dynamic loading benefits.

What is Apple's reasoning for keeping dynamic frameworks from app developers? It seems like it would ease using external libraries considerably, since developers wouldn't have to rely on finicky linker flags or open-source library dependency chains.

Edit: I see a common reason is security. Why then does Apple allow it on OSX and not iOS? Isn't security a requirement there as well?

Clearly Apple has the ability to create dynamically loaded libraries (known as frameworks) for iOS, as they ship several with XCode (such as UIKit). App developers only have the ability to create static libraries, or at best, trick Xcode into thinking it's loading a framework when it's actually loading a static library, this is known as creating a fake framework, some of the drag-and-drop convenience, but none of the dynamic loading benefits.

What is Apple's reasoning for keeping dynamic frameworks from app developers? It seems like it would ease using external libraries considerably, since developers wouldn't have to rely on finicky linker flags or open-source library dependency chains.

I see a common reason is security. Why then does Apple allow it on OSX and not iOS? Isn't security a requirement there as well?

    Tweeted twitter.com/#!/StackProgrammer/status/429427120369332224
2 Added additional question.
source | link

Clearly Apple has the ability to create dynamically loaded libraries (known as frameworks) for iOS, as they ship several with XCode (such as UIKit). App developers only have the ability to create static libraries, or at best, trick Xcode into thinking it's loading a framework when it's actually loading a static library, this is known as creating a fake framework, some of the drag-and-drop convenience, but none of the dynamic loading benefits.

What is Apple's reasoning for keeping dynamic frameworks from app developers? It seems like it would ease using external libraries considerably, since developers wouldn't have to rely on finicky linker flags or open-source library dependency chains.

Edit: I see a common reason is security. Why then does Apple allow it on OSX and not iOS? Isn't security a requirement there as well?

Clearly Apple has the ability to create dynamically loaded libraries (known as frameworks) for iOS, as they ship several with XCode (such as UIKit). App developers only have the ability to create static libraries, or at best, trick Xcode into thinking it's loading a framework when it's actually loading a static library, this is known as creating a fake framework, some of the drag-and-drop convenience, but none of the dynamic loading benefits.

What is Apple's reasoning for keeping dynamic frameworks from app developers? It seems like it would ease using external libraries considerably, since developers wouldn't have to rely on finicky linker flags or open-source library dependency chains.

Clearly Apple has the ability to create dynamically loaded libraries (known as frameworks) for iOS, as they ship several with XCode (such as UIKit). App developers only have the ability to create static libraries, or at best, trick Xcode into thinking it's loading a framework when it's actually loading a static library, this is known as creating a fake framework, some of the drag-and-drop convenience, but none of the dynamic loading benefits.

What is Apple's reasoning for keeping dynamic frameworks from app developers? It seems like it would ease using external libraries considerably, since developers wouldn't have to rely on finicky linker flags or open-source library dependency chains.

Edit: I see a common reason is security. Why then does Apple allow it on OSX and not iOS? Isn't security a requirement there as well?

1
source | link