New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CocoaPods 0.36 #59

Merged
merged 16 commits into from Mar 11, 2015

Conversation

Projects
None yet
8 participants
@mrackwitz
Member

mrackwitz commented Dec 16, 2014

Initial Draft for the blog post about the upcoming release.

TODOs

  • Review, stylistic improvements, fix typos, …
  • Add the assets
  • Update pygments.rb to a version, which brings a lexer for Swift
Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
Dynamic frameworks have always been available on OS X. That's different for iOS. Apple's mobile platform does support dynamic frameworks initially with iOS 8.0. So the least common denominator was found before with using static libraries, which are supported on both platforms.
To the same time when Dynamic Frameworks were introduced, Apple also introduced Swift. If you have third-party dependencies in Swift, you have only two choices: Either throw them in your project and compile one fat binary, which is no practical solution as this increases build times by the lack of incremental compilation and makes it hard to generically manage very different dependencies, which could require different build settings etc. Or you can facilitate frameworks. Static libraries are not an option anymore.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

At the the same as Dynamic Frameworks were introduced, Apple introduced Swift.

@orta

orta Dec 16, 2014

Member

At the the same as Dynamic Frameworks were introduced, Apple introduced Swift.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

The second sentence here is really long. This is a chopped up version:

If you have third-party dependencies in Swift, you have only two choices. Either throw the source files directly in your project and compile one fat binary. This is not a practical solution as this increases build times by the lack of incremental compilation and makes it hard to generically manage and update different dependencies, which could require different build settings etc. Or you can use frameworks.

@orta

orta Dec 16, 2014

Member

The second sentence here is really long. This is a chopped up version:

If you have third-party dependencies in Swift, you have only two choices. Either throw the source files directly in your project and compile one fat binary. This is not a practical solution as this increases build times by the lack of incremental compilation and makes it hard to generically manage and update different dependencies, which could require different build settings etc. Or you can use frameworks.

This comment has been minimized.

@AliSoftware

AliSoftware Dec 19, 2014

Contributor

A bullet-point list for the two choices might be easier to read

@AliSoftware

AliSoftware Dec 19, 2014

Contributor

A bullet-point list for the two choices might be easier to read

This comment has been minimized.

@AliSoftware

AliSoftware Dec 19, 2014

Contributor

@orta note that by removing the last sentence "Static libraries are not an option anymore" you break the transition to the next paragraph. Either we keep it (using a bullet-point list makes it still readable so I believe we should) or we change the beginning of the next paragraph.

@AliSoftware

AliSoftware Dec 19, 2014

Contributor

@orta note that by removing the last sentence "Static libraries are not an option anymore" you break the transition to the next paragraph. Either we keep it (using a bullet-point list makes it still readable so I believe we should) or we change the beginning of the next paragraph.

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
To the same time when Dynamic Frameworks were introduced, Apple also introduced Swift. If you have third-party dependencies in Swift, you have only two choices: Either throw them in your project and compile one fat binary, which is no practical solution as this increases build times by the lack of incremental compilation and makes it hard to generically manage very different dependencies, which could require different build settings etc. Or you can facilitate frameworks. Static libraries are not an option anymore.
Why is that the case? Because Swift is still very open in design and subject to heavy changes. Unlike Objective-C, Apple doesn't ship the Swift standard runtime libraries with iOS. This decouples the language version from the platform version. When you build an app with Swift, you're responsible yourself to ship them. The toolchain provides at this place `swift-stdlib-tool`, which [covers the common use cases](http://samdmarshall.com/blog/swift_and_objc.html). As those libraries can't be statically linked multiple times, and not at all in different versions. Furthermore it is desirable to embed them only once and not embedded multiple times, because of constraints to memory size and network speed, which are relevant for distribution.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

you're responsible yourself to ship them

it's your responsibility to ship the swift runtime.

@orta

orta Dec 16, 2014

Member

you're responsible yourself to ship them

it's your responsibility to ship the swift runtime.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

The toolchain provides at this place swift-stdlib-tool

Apple's toolchain provides a command line tool swift-stdlib-tool which covers the common use cases around embedding. Which Xcode calls under the hood.

@orta

orta Dec 16, 2014

Member

The toolchain provides at this place swift-stdlib-tool

Apple's toolchain provides a command line tool swift-stdlib-tool which covers the common use cases around embedding. Which Xcode calls under the hood.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

I don't feel like I get this line

As those libraries can't be statically linked multiple times, and not at all in different versions.

Is this that a single framework shouldn't contain the swift runtime included multiple times?

@orta

orta Dec 16, 2014

Member

I don't feel like I get this line

As those libraries can't be statically linked multiple times, and not at all in different versions.

Is this that a single framework shouldn't contain the swift runtime included multiple times?

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
Why is that the case? Because Swift is still very open in design and subject to heavy changes. Unlike Objective-C, Apple doesn't ship the Swift standard runtime libraries with iOS. This decouples the language version from the platform version. When you build an app with Swift, you're responsible yourself to ship them. The toolchain provides at this place `swift-stdlib-tool`, which [covers the common use cases](http://samdmarshall.com/blog/swift_and_objc.html). As those libraries can't be statically linked multiple times, and not at all in different versions. Furthermore it is desirable to embed them only once and not embedded multiple times, because of constraints to memory size and network speed, which are relevant for distribution.
With this release, we initially allow to use both in combination with CocoaPods. Your project will automatically migrated or integrated, if you depend on a pod which includes Swift source code.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

With this release, we are supporting both frameworks and static libraries in CocoaPods. Your project will be automatically migrated to frameworks if you depend on a pod which includes Swift source code.

@orta

orta Dec 16, 2014

Member

With this release, we are supporting both frameworks and static libraries in CocoaPods. Your project will be automatically migrated to frameworks if you depend on a pod which includes Swift source code.

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
Why is that the case? Because Swift is still very open in design and subject to heavy changes. Unlike Objective-C, Apple doesn't ship the Swift standard runtime libraries with iOS. This decouples the language version from the platform version. When you build an app with Swift, you're responsible yourself to ship them. The toolchain provides at this place `swift-stdlib-tool`, which [covers the common use cases](http://samdmarshall.com/blog/swift_and_objc.html). As those libraries can't be statically linked multiple times, and not at all in different versions. Furthermore it is desirable to embed them only once and not embedded multiple times, because of constraints to memory size and network speed, which are relevant for distribution.
With this release, we initially allow to use both in combination with CocoaPods. Your project will automatically migrated or integrated, if you depend on a pod which includes Swift source code.
Furthermore you can use it, if your deployment target on iOS is greater then 8.0 or you're targeting the OS X platform, by specifying `use_frameworks!` in your Podfile.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

Furthermore you can opt-in if your deployment target on iOS is greater then 8.0 or you're targeting the OS X platform by specifying use_frameworks! in your Podfile.

@orta

orta Dec 16, 2014

Member

Furthermore you can opt-in if your deployment target on iOS is greater then 8.0 or you're targeting the OS X platform by specifying use_frameworks! in your Podfile.

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
With this release, we initially allow to use both in combination with CocoaPods. Your project will automatically migrated or integrated, if you depend on a pod which includes Swift source code.
Furthermore you can use it, if your deployment target on iOS is greater then 8.0 or you're targeting the OS X platform, by specifying `use_frameworks!` in your Podfile.
This is an all or nothing approach per integrated target, because as we will later see, we can't ensure to properly build frameworks, whose transitive dependencies are static libraries.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

This is an all or nothing approach per integrated target. Because, as we will later see, we cannot build frameworks whose transitive dependencies are static libraries.

@orta

orta Dec 16, 2014

Member

This is an all or nothing approach per integrated target. Because, as we will later see, we cannot build frameworks whose transitive dependencies are static libraries.

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
With this release, we initially allow to use both in combination with CocoaPods. Your project will automatically migrated or integrated, if you depend on a pod which includes Swift source code.
Furthermore you can use it, if your deployment target on iOS is greater then 8.0 or you're targeting the OS X platform, by specifying `use_frameworks!` in your Podfile.
This is an all or nothing approach per integrated target, because as we will later see, we can't ensure to properly build frameworks, whose transitive dependencies are static libraries.
So this release goes along with probably one of the most drastic change set on the whole project, which makes no stop on CocoaPods itself, but also required similar changes to Xcodeproj as well.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

So this release goes along with probably one of the most drastic change set on the whole project, which makes no stop on CocoaPods itself, but also required similar changes to Xcodeproj as well.

I think I get the feeling behind this sentence. "This is the largest singular changeset to CocoaPods, as well as the other gems we use." if I'm correct, then I think this should go in the opening TLDR at the top, as it's a really cool intro stat.

I will make a comment up at the top around this.

@orta

orta Dec 16, 2014

Member

So this release goes along with probably one of the most drastic change set on the whole project, which makes no stop on CocoaPods itself, but also required similar changes to Xcodeproj as well.

I think I get the feeling behind this sentence. "This is the largest singular changeset to CocoaPods, as well as the other gems we use." if I'm correct, then I think this should go in the opening TLDR at the top, as it's a really cool intro stat.

I will make a comment up at the top around this.

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
The CocoaPods 0.36 brings long-awaited functionality: it initially supports dynamic framework and by that it also brings enhanced support for Apple's new programming language Swift.
## And there were Swift & Dynamic Frameworks on iOS

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

And there were Swift & Dynamic Frameworks on iOS

This doesn't read too well in English, it almost sounds like a olde worlde bible quote ;)

Swift & Dynamic Frameworks on iOS

@orta

orta Dec 16, 2014

Member

And there were Swift & Dynamic Frameworks on iOS

This doesn't read too well in English, it almost sounds like a olde worlde bible quote ;)

Swift & Dynamic Frameworks on iOS

This comment has been minimized.

@AliSoftware

AliSoftware Dec 19, 2014

Contributor

it almost sounds like a olde worlde bible quote ;)

I though this was intended ^^

@AliSoftware

AliSoftware Dec 19, 2014

Contributor

it almost sounds like a olde worlde bible quote ;)

I though this was intended ^^

This comment has been minimized.

@orta

orta Dec 19, 2014

Member

it was, we talked about this, said he's fine to keep it in 👍

@orta

orta Dec 19, 2014

Member

it was, we talked about this, said he's fine to keep it in 👍

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
categories: cocoapods releases
---
TL;DR: _CocoaPods 0.36_ has been released, with the long-awaited support for Frameworks and Swift.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

Lets expand the before the fold:

TL;DR: CocoaPods 0.36 has been released, with the long-awaited support for Frameworks and Swift.

This initially supports dynamic framework and by that it also brings enhanced support for dependencies using Apple's new programming language Swift. This has been one of the largest singular projects for CocoaPods, affecting almost all of CocoaPods' subsystems like Xcodeproj.'

( something like this )

@orta

orta Dec 16, 2014

Member

Lets expand the before the fold:

TL;DR: CocoaPods 0.36 has been released, with the long-awaited support for Frameworks and Swift.

This initially supports dynamic framework and by that it also brings enhanced support for dependencies using Apple's new programming language Swift. This has been one of the largest singular projects for CocoaPods, affecting almost all of CocoaPods' subsystems like Xcodeproj.'

( something like this )

This comment has been minimized.

@mrackwitz

mrackwitz Mar 11, 2015

Member

@mrackwitz
Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
![Xcode Template/Product Icons]()
So what's the difference between those both product types?

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

##### So what's the difference between those both product types?

May as well make it a small header as it's a sub-heading

@orta

orta Dec 16, 2014

Member

##### So what's the difference between those both product types?

May as well make it a small header as it's a sub-heading

This comment has been minimized.

@AliSoftware

AliSoftware Dec 19, 2014

Contributor

I don't know if it's in that paragraph that we should mention it or some other place, but I feel like we should also talk about @IBDesignable and @IBInspectable.

Using frameworks for pods allows us to use those directives, so that pods that provide UIKit components can now render themselves live in IB, so this is a great feature we also get by migrating CocoaPods to frameworks.

@AliSoftware

AliSoftware Dec 19, 2014

Contributor

I don't know if it's in that paragraph that we should mention it or some other place, but I feel like we should also talk about @IBDesignable and @IBInspectable.

Using frameworks for pods allows us to use those directives, so that pods that provide UIKit components can now render themselves live in IB, so this is a great feature we also get by migrating CocoaPods to frameworks.

This comment has been minimized.

@mrackwitz

mrackwitz Dec 20, 2014

Member

Good point! 👍 We should definitively mention that.
Afaik only @IBDesignable requires frameworks, but perhaps this even changed between Xcode 6 betas, GM or in the minor versions.

@mrackwitz

mrackwitz Dec 20, 2014

Member

Good point! 👍 We should definitively mention that.
Afaik only @IBDesignable requires frameworks, but perhaps this even changed between Xcode 6 betas, GM or in the minor versions.

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
![Screenshot of BananaKit]()
They bundle some further data besides a binary, which is in that case dynamically linkable and holds different slices for each architecture. But that's only part, which static libraries covered so far. Belong the further data, there are the following:

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

Perhaps it's the lack of a screenshot, but I'm a tad lost on this line.

They bundle some further data besides a binary, which is in that case dynamically linkable and holds different slices for each architecture. But that's only part, which static libraries covered so far.

My interpretation is that it has a binary, but it also contains different files for different architectures?

@orta

orta Dec 16, 2014

Member

Perhaps it's the lack of a screenshot, but I'm a tad lost on this line.

They bundle some further data besides a binary, which is in that case dynamically linkable and holds different slices for each architecture. But that's only part, which static libraries covered so far.

My interpretation is that it has a binary, but it also contains different files for different architectures?

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
They bundle some further data besides a binary, which is in that case dynamically linkable and holds different slices for each architecture. But that's only part, which static libraries covered so far. Belong the further data, there are the following:
* The public headers, which are stripped from the bundle for application targets, as those are only important to distribute the interface of the code for compilation. The public headers also include the generated headers for public Swift symbols, e.g. `Alamofire-Swift.h`.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

Might be good to bold + title case the bit that are "in" so:

* **The Public Headers** - These are stripped for application targets, as they are only important to distribute the framework as code for compilation. The public headers also include the generated headers for public Swift symbols, e.g. `Alamofire-Swift.h`.

( could Alamofire-Swift.h be linkable to one in the repo? )

@orta

orta Dec 16, 2014

Member

Might be good to bold + title case the bit that are "in" so:

* **The Public Headers** - These are stripped for application targets, as they are only important to distribute the framework as code for compilation. The public headers also include the generated headers for public Swift symbols, e.g. `Alamofire-Swift.h`.

( could Alamofire-Swift.h be linkable to one in the repo? )

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
They bundle some further data besides a binary, which is in that case dynamically linkable and holds different slices for each architecture. But that's only part, which static libraries covered so far. Belong the further data, there are the following:
* The public headers, which are stripped from the bundle for application targets, as those are only important to distribute the interface of the code for compilation. The public headers also include the generated headers for public Swift symbols, e.g. `Alamofire-Swift.h`.
* A code signature over the whole contents, which has to be (re-)calculated on embedding a framework into an application target, as the headers are stripped before.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member
  • A Code Signature For The Whole Contents - This has to be (re-)calculated on embedding a framework into an application target, as the headers are stripped before.
@orta

orta Dec 16, 2014

Member
  • A Code Signature For The Whole Contents - This has to be (re-)calculated on embedding a framework into an application target, as the headers are stripped before.
Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
* The public headers, which are stripped from the bundle for application targets, as those are only important to distribute the interface of the code for compilation. The public headers also include the generated headers for public Swift symbols, e.g. `Alamofire-Swift.h`.
* A code signature over the whole contents, which has to be (re-)calculated on embedding a framework into an application target, as the headers are stripped before.
* The resources, which are used by e.g. UI components, which the frameworks brings with it

This comment has been minimized.

@orta

orta Dec 16, 2014

Member
* **Its Resources** - The resources used e.g. Images for UI components.
@orta

orta Dec 16, 2014

Member
* **Its Resources** - The resources used e.g. Images for UI components.
Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
* The public headers, which are stripped from the bundle for application targets, as those are only important to distribute the interface of the code for compilation. The public headers also include the generated headers for public Swift symbols, e.g. `Alamofire-Swift.h`.
* A code signature over the whole contents, which has to be (re-)calculated on embedding a framework into an application target, as the headers are stripped before.
* The resources, which are used by e.g. UI components, which the frameworks brings with it
* It can carry further dynamic frameworks and libraries, like e.g. the Swift runtime library. But since Xcode 6-beta7 dynamic frameworks don't include anymore the Swift runtime, they were compiled with, because this would led to duplication, if multiple frameworks are used. [We had to care about]() embedding all needed Swift runtime libraries only once into the application project.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

opted for "host" instead of "carry". It has stronger connotations around the linking.

*  **Hosted Dynamic Frameworks and Libraries** - e.g. the Swift runtime library. But since Xcode 6's release dynamic frameworks don't include anymore the Swift runtime they were compiled with. This would lead to duplication if multiple frameworks are used. [We have to care about]() ensuring  the Swift runtime libraries are embedded only once into the application project.
@orta

orta Dec 16, 2014

Member

opted for "host" instead of "carry". It has stronger connotations around the linking.

*  **Hosted Dynamic Frameworks and Libraries** - e.g. the Swift runtime library. But since Xcode 6's release dynamic frameworks don't include anymore the Swift runtime they were compiled with. This would lead to duplication if multiple frameworks are used. [We have to care about]() ensuring  the Swift runtime libraries are embedded only once into the application project.
Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
* A code signature over the whole contents, which has to be (re-)calculated on embedding a framework into an application target, as the headers are stripped before.
* The resources, which are used by e.g. UI components, which the frameworks brings with it
* It can carry further dynamic frameworks and libraries, like e.g. the Swift runtime library. But since Xcode 6-beta7 dynamic frameworks don't include anymore the Swift runtime, they were compiled with, because this would led to duplication, if multiple frameworks are used. [We had to care about]() embedding all needed Swift runtime libraries only once into the application project.
* The clang module map, which is mostly an internal toolchain artifact, which carries declarations about header visibility and module link-ability.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member
* **The Clang Module Map** - This is mostly an internal toolchain artifact, which carries declarations about header visibility and module link-ability.
@orta

orta Dec 16, 2014

Member
* **The Clang Module Map** - This is mostly an internal toolchain artifact, which carries declarations about header visibility and module link-ability.
Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
* The resources, which are used by e.g. UI components, which the frameworks brings with it
* It can carry further dynamic frameworks and libraries, like e.g. the Swift runtime library. But since Xcode 6-beta7 dynamic frameworks don't include anymore the Swift runtime, they were compiled with, because this would led to duplication, if multiple frameworks are used. [We had to care about]() embedding all needed Swift runtime libraries only once into the application project.
* The clang module map, which is mostly an internal toolchain artifact, which carries declarations about header visibility and module link-ability.
* An Info.plist, which specifies author, version and copyright information.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member
  • An Info.plist - This specifies author, version and copyright information.
@orta

orta Dec 16, 2014

Member
  • An Info.plist - This specifies author, version and copyright information.
Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
### Caveats
One caveat about bundling resources is, that until now we had to embed all resources into the application bundle. This is referenced programmatically by `[NSBundle mainBundle]`. You as Pod author were able to use that kind of referencing to include resources you brought into the app bundle. But with frameworks, you have to make sure, that you reference them more specifically by getting a reference to your bundle like that:

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

This is referenced programmatically by [NSBundle mainBundle].

The resources were referenced programmatically by [NSBundle mainBundle]

@orta

orta Dec 16, 2014

Member

This is referenced programmatically by [NSBundle mainBundle].

The resources were referenced programmatically by [NSBundle mainBundle]

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

Pod authors were able to use mainBundle referencing to include resources the Pod brought into the app bundle. But with frameworks, you have to make sure that you reference them more specifically by getting a reference to your framework's bundle e.g.

@orta

orta Dec 16, 2014

Member

Pod authors were able to use mainBundle referencing to include resources the Pod brought into the app bundle. But with frameworks, you have to make sure that you reference them more specifically by getting a reference to your framework's bundle e.g.

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
NSBundle(forClass: <#ClassFromPodspec#>)
```
This will then work for both ways of integration.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

This will then work for both frameworks and static libraries.

@orta

orta Dec 16, 2014

Member

This will then work for both frameworks and static libraries.

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
This will then work for both ways of integration.
There are only very rare cases, where you want to reference the main bundle directly or indirectly, e.g. by using `[UIImage imageNamed:]`.
The advantage, we have now with the improved resource handling is, that resources wouldn't conflict when they have the same names, because they are namespaced by the framework bundle. Furthermore we don't have to apply anymore the build rules ourself to the resources as e.g. asset catalogs and storyboards need to be compiled.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

The advantage to the improved resource handling is that resources won't conflict when they have the same names. They are namespaced by the framework bundle. Furthermore we don't have to apply the build rules ourself to the resources as e.g. asset catalogs and storyboards need to be compiled. This should decrease build times for project using Pods that include many resources.

@orta

orta Dec 16, 2014

Member

The advantage to the improved resource handling is that resources won't conflict when they have the same names. They are namespaced by the framework bundle. Furthermore we don't have to apply the build rules ourself to the resources as e.g. asset catalogs and storyboards need to be compiled. This should decrease build times for project using Pods that include many resources.

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
### More about Frameworks
If you want learn more about Frameworks, take a look into the [Framework Programming Guide](https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Frameworks.html#//apple_ref/doc/uid/10000183-SW1). Even when this was not written specifically for the new Cocoa Touch Frameworks, how Apple calls them in their Xcode target template, those are mostly the same to the classic OS X frameworks, so this document is still a helpful introduction.

This comment has been minimized.

@orta

orta Dec 16, 2014

Member

Even when this was not written specifically for the new Cocoa Touch Frameworks

Even though this was not ...

@orta

orta Dec 16, 2014

Member

Even when this was not written specifically for the new Cocoa Touch Frameworks

Even though this was not ...

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
Public Headers in Podspecs are declared by `s.public_header_files = ["Core/*.h", "Tree/**.h"]`.
If you don't include this specification, then all your headers are public.

This comment has been minimized.

@neonichu

neonichu Dec 16, 2014

Member

Would qualify the "all" a bit:

all headers from your source_files are public.

@neonichu

neonichu Dec 16, 2014

Member

Would qualify the "all" a bit:

all headers from your source_files are public.

@ashfurrow

This comment has been minimized.

Show comment
Hide comment
@ashfurrow

ashfurrow Dec 16, 2014

Content-wise this is great. Orta's feedback will make it even stronger.

ashfurrow commented Dec 16, 2014

Content-wise this is great. Orta's feedback will make it even stronger.

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
## And there were Swift & Dynamic Frameworks on iOS
Dynamic frameworks have always been available on OS X. That's different for iOS. Apple's mobile platform does support dynamic frameworks initially with iOS 8.0. So the least common denominator was found before with using static libraries, which are supported on both platforms.

This comment has been minimized.

@segiddins

segiddins Dec 20, 2014

Member

Apple's mobile platform does support dynamic frameworks initially with iOS 8.0.
->
Apple's mobile platform introduced third-party dynamic framework support in iOS 8.

@segiddins

segiddins Dec 20, 2014

Member

Apple's mobile platform does support dynamic frameworks initially with iOS 8.0.
->
Apple's mobile platform introduced third-party dynamic framework support in iOS 8.

@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy Dec 23, 2014

Member

@mrackwitz Please mention the resource caveat in the TL;DR. They should not skip that as a lib author.

Member

alloy commented Dec 23, 2014

@mrackwitz Please mention the resource caveat in the TL;DR. They should not skip that as a lib author.

@kevincon kevincon referenced this pull request Jan 5, 2015

Closed

Tesseract OCR iOS release 4.0.0 #123

12 of 12 tasks complete
Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
TL;DR: _CocoaPods 0.36_ has been released, with the long-awaited support for Frameworks and Swift.
This initially supports dynamic framework and by that it also brings enhanced support for dependencies using Apple's new programming language Swift. This has been one of the largest singular projects for CocoaPods, affecting almost all of CocoaPods' subsystems like Xcodeproj.

This comment has been minimized.

@segiddins

segiddins Mar 10, 2015

Member

frameworks

@segiddins

segiddins Mar 10, 2015

Member

frameworks

This comment has been minimized.

@segiddins

segiddins Mar 10, 2015

Member

programming language, Swift

@segiddins

segiddins Mar 10, 2015

Member

programming language, Swift

This comment has been minimized.

@segiddins

segiddins Mar 10, 2015

Member

subsystems, such as Xcodeproj

@segiddins

segiddins Mar 10, 2015

Member

subsystems, such as Xcodeproj

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
Dynamic frameworks have always been available on OS X. That's different for iOS.
Apple's mobile platform introduced third-party dynamic framework support in iOS 8.
So the least common denominator was found before with using static libraries, which are supported on both platforms.

This comment has been minimized.

@segiddins

segiddins Mar 10, 2015

Member

which have always been supported on both platforms

@segiddins

segiddins Mar 10, 2015

Member

which have always been supported on both platforms

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
Apple's mobile platform introduced third-party dynamic framework support in iOS 8.
So the least common denominator was found before with using static libraries, which are supported on both platforms.
To the same time when Dynamic Frameworks were introduced, Apple also introduced Swift.

This comment has been minimized.

@segiddins

segiddins Mar 10, 2015

Member

At the same time

@segiddins

segiddins Mar 10, 2015

Member

At the same time

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
Either throw them in your project and compile one fat binary, which is no practical solution as this increases build times by the lack of incremental compilation and makes it hard to generically manage very different dependencies, which could require different build settings etc. Or you can facilitate frameworks.
Static libraries are not an option anymore.
Why is that the case? Because Swift is still very open in design and subject to heavy changes. Unlike Objective-C, Apple doesn't ship the Swift standard runtime libraries with iOS.

This comment has been minimized.

@segiddins

segiddins Mar 10, 2015

Member

Because Swift is still very open in design and subject to heavy changes Because Apple doesn't let you build static libraries that contain Swift.

@segiddins

segiddins Mar 10, 2015

Member

Because Swift is still very open in design and subject to heavy changes Because Apple doesn't let you build static libraries that contain Swift.

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
Why is that the case? Because Swift is still very open in design and subject to heavy changes. Unlike Objective-C, Apple doesn't ship the Swift standard runtime libraries with iOS.
This decouples the language version from the platform version.
When you build an app with Swift, you're responsible yourself to ship them.
The toolchain provides at this place `swift-stdlib-tool`, which [covers the common use cases](http://samdmarshall.com/blog/swift_and_objc.html).

This comment has been minimized.

@segiddins

segiddins Mar 10, 2015

Member

the grammar in this sentence is really wonky

@segiddins

segiddins Mar 10, 2015

Member

the grammar in this sentence is really wonky

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
This decouples the language version from the platform version.
When you build an app with Swift, you're responsible yourself to ship them.
The toolchain provides at this place `swift-stdlib-tool`, which [covers the common use cases](http://samdmarshall.com/blog/swift_and_objc.html).
As those libraries can't be statically linked multiple times, and not at all in different versions.

This comment has been minimized.

@segiddins

segiddins Mar 10, 2015

Member

sentence fragment

@segiddins

segiddins Mar 10, 2015

Member

sentence fragment

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
As those libraries can't be statically linked multiple times, and not at all in different versions.
Furthermore it is desirable to embed them only once and not embedded multiple times, because of constraints to memory size and network speed, which are relevant for distribution.
With this release, we initially allow to use both in combination with CocoaPods.

This comment has been minimized.

@segiddins

segiddins Mar 10, 2015

Member

With this release, we've kept the option to integrate Pods as static libraries, while introducing the ability to integrate as a proper Framework.

@segiddins

segiddins Mar 10, 2015

Member

With this release, we've kept the option to integrate Pods as static libraries, while introducing the ability to integrate as a proper Framework.

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
Furthermore it is desirable to embed them only once and not embedded multiple times, because of constraints to memory size and network speed, which are relevant for distribution.
With this release, we initially allow to use both in combination with CocoaPods.
Your project will automatically migrated or integrated, if you depend on a pod which includes Swift source code.

This comment has been minimized.

@segiddins

segiddins Mar 10, 2015

Member

no longer true

@segiddins

segiddins Mar 10, 2015

Member

no longer true

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
## Dynamic Frameworks vs. Static Libraries
![Xcode Template/Product Icons]()

This comment has been minimized.

@segiddins

segiddins Mar 10, 2015

Member

missing image?

@segiddins

segiddins Mar 10, 2015

Member

missing image?

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
Dynamic Frameworks are bundles, which basically means that they are directories, which have the file suffix `.framework` and Finder treats them mostly like regular files. If you tap into a framework, you will see a common directory structure:
![Screenshot of BananaKit]()

This comment has been minimized.

@segiddins

segiddins Mar 10, 2015

Member

missing image?

@segiddins

segiddins Mar 10, 2015

Member

missing image?

Show outdated Hide outdated _drafts/CocoaPods-0.36.markdown
Until version 1.0 we strongly encourage you to keep CocoaPods up-to-date.
For all the details, don’t miss the
[Changelog](https://github.com/CocoaPods/CocoaPods/blob/master/CHANGELOG.md)!

This comment has been minimized.

@segiddins

segiddins Mar 10, 2015

Member

link to the 0.36.0 tag?

@segiddins

segiddins Mar 10, 2015

Member

link to the 0.36.0 tag?

This comment has been minimized.

@mrackwitz

mrackwitz Mar 11, 2015

Member

We always linked to master for the other release blog posts.

@mrackwitz

mrackwitz Mar 11, 2015

Member

We always linked to master for the other release blog posts.

This comment has been minimized.

@mrackwitz

mrackwitz Mar 11, 2015

Member

The most helpful variant would be probably to add #0360 to the link.

@mrackwitz

mrackwitz Mar 11, 2015

Member

The most helpful variant would be probably to add #0360 to the link.

kylef pushed a commit that referenced this pull request Mar 11, 2015

@kylef kylef merged commit afca328 into master Mar 11, 2015

@kylef kylef deleted the cocoapods-0.36 branch Mar 11, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment