Add @jcanizales to comment.

Right now in gRPC we're telling users to install protoc via homebrew, and we give them this template podspec they can copy/paste to have their protos compiled on pod install.

It's true that one step nicer would be if a protoc built for OS X was downloaded when installing the Protobuf pod. Feng, can protoc be built so that it can be just copied to a local directory and run from there? If so, would you consider putting such a binary in your releases?

A further step is to have XCode recompile the protos when they change, instead of just using the generated files. For that, I was looking into doing something like this, but haven't started yet. Is that what you have in mind, Steven?

I can put one in the release page.

The podspec can only specify one source URL for the stuff it will download, so the compiled binary would need to be on the same compressed file as the sources of the Objective-C runtime. Is that possible?

(Right now the podspec points to GitHub for the runtime sources, but I'm assuming you guys don't want to put the compiled binary in the repo).

Alternatively, we could have the compiled runtime library + its headers, and the compiled protoc together in a compressed file.

About distribution of the protoc binary, yes, the protoc binary can be built (staticly linked) and copied to a local directory and run from there. We already have a protoc-{version}-win32.zip put up for windows users in each release (see the release page: https://github.com/google/protobuf/releases) and in the future I think we should provide such built protoc binaries for other platforms as well.

Besides providing protoc binaries in the github release page, we should also consider uploading protoc binary to language-specific package managing repos if that makes it easier for users of that langauge to use it. Each language can make its own decision on whether to provide such binaries. I know that in Java, we already upload protoc binaries to maven central repo (see: http://mvnrepository.com/artifact/com.google.protobuf/protoc) and the maven plugin can make use of it without requiring Java users to install protoc first. The situation in objective-c might be different, but you probably know much better than me.

Cocoapods won't store files for us, unlike other package managers. It only stores the specs that say where to find stuff. I can see three alternatives:

1. Protobuf.podspec to have two subspecs: /Runtime and /Compiler. The Runtime subspec points at this git repo for the sources; the Compiler subspec points at the prebuilt protoc of the appropriate release page. I don't think this is allowed by the Cocoapods syntax, but I can test it to confirm.
2. Have Protobuf.podspec for the runtime, and ProtoC.podspec for the compiler. This could work, but adds a OS X-specific file to the root of this repo.
3. Release a compressed file that includes (at least) the ObjC runtime sources and a protoc prebuilt for OS X. I.e., add the prebuilt protoc to protobuf-objectivec-x.y.z.tar.gz. We change Protobuf.podspec to download that instead of the sources from git.

(Well, and 4. put the prebuilt protoc in the git repo. Ew.)

How about a compressed file including prebuilt protoc, well known protos, prebuilt objc runtime library and objc hearder files?

Yeah, that works too. I just thought it would be more trouble to prebuild a fat binary of the runtime library, as today XCode builds it so fast it isn't noticeable. But it certainly works and is your call.

Thanks for all the quick feedback. It sounds like there are a few options and you guys are still trying to figure out the internal process / implementation on your side. Any of these options sound great to me.

@jcanizales about the automatic compilation, I was thinking it'd be as easy as adding a "New Run Script Phase" within the "Build Phases" tab. I just tried the following and it seemed to work beautifully:

@jcanizales, I prefer to just have a protoc pre-built in the release page. Do we need another podspec for that?

Yes. And that actually might be better, if we want the version of the compiler to be decoupled.

@dmaclach since he also looked at better Xcode integration.