Add instruction for submodules installation process.

[lolgear]

[READ] Step 1: Are you in the right place?

• For issues or feature requests related to the code in this repository
  file a Github issue.
  • If this is a feature request make sure the issue title starts with "FR:".
• For general technical questions, post a question on StackOverflow
  with the firebase tag.
• For general Firebase discussion, use the firebase-talk
  google group.
• For help troubleshooting your application that does not fall under one
  of the above categories, reach out to the personalized
  Firebase support channel.

[REQUIRED] Step 2: Describe your environment

• Xcode version: ???.0.0
• Firebase SDK version: ???.0.0
• Firebase Component: ???.0.0 (Auth, Core, Database, Firestore, Messaging, Storage, etc)
• Component version: ???.0.0

[REQUIRED] Step 3: Describe the problem

Please, add instructions for manual ( via submodules ) installation.

Also, could you add binaries /latest link which would contain latest binary?
It would be nice to have this link to update binary by simple git pull.

[paulb777]

@lolgear Please clarify your request with more details about what you'd like to see.

If you mean git submodules, we have no plans to structure the repo with git submodules. If you're looking for a binary download, it's available here or via Carthage.

[lolgear]

@paulb777

It is pity to hear that git submodules are out of the boat.

However, I would like to download ready-to-use framework without unzipping anything.

If this link is correct, it is great cause I would like to update framework when I want. It doesn't have any version, of course, however, It is bless and curse in the same time.

https://firebase.google.com/download/ios

You could add any accessors to specify version that I would like to download via curl.

VERSION:5.0 // HTTP header.
https://firebase.google.com/download/ios

Alternative approach:

https://firebase.google.com/download/ios/latest_in_major/5

I would be happy to use firebase without CocoaPods reign.

[paulb777]

@lolgear We're not likely to add a fourth distribution method anytime soon, after CocoaPods, zip distribution, and the still experimental Carthage.

Do the Carthage url's work for you? For example, if you look at the json files listed at https://github.com/firebase/firebase-ios-sdk/blob/master/Carthage.md#carthage-usage, you'll see that they include versioned links like https://dl.google.com/dl/firebase/ios/carthage/5.10.0/Auth-3f696827a526e8e2.zip

[lolgear]

@paulb777

I choose https://dl.google.com/dl/firebase/ios/carthage/FirebaseABTestingBinary.json as an example.

It has a json object with key-value version string-link to zip.

Does this object include all supported/existing versions?
If so, my wish would be something like:

curl -o tmp_file.json https://dl.google.com/dl/firebase/ios/carthage/FirebaseABTestingBinary.json
cat tmp_file.json | ruby -e "require 'json'; puts JSON.parse(STDIN.read).sort.last.last"

[paulb777]

@lolgear The json files include most but not all versions. All is contingent upon #1862.

We're also in the early stages of investigating if Rome would be a good way to provide configurable binary distributions.

[paulb777]

@lolgear Does Rome meet your requirements for downloadable ready-to-use frameworks?

[paulb777]

Closing for now. Can reopen with more discussion.

[lolgear]

@paulb777
I haven't check CocoaPods's Rome yet.
However, as I understand, it is something similar to 'CocoaPods's' Carthage.
Yes, it could fit downloadable ready-to-use framework niche.

But all manual work could be eliminated by using submodules or/and by drag-and-drop Firebase project into target project.

[paulb777]

If the goal is to get rid of manual work, CocoaPods is the best option.

Any solution involving dragging and dropping - whether its the zip distribution, Carthage, or Rome - requires several additional configuration steps to set up search paths, linker options, modules, etc.

[lolgear]

@paulb777
I have added, for example, CocoaLumberjack as submodule.
Everything works fine and what I only have done is editing "Link with framework" for several frameworks that use logging.

In your complex case with resources. Well, it is weird enough. I have a framework with nearly 200-400 localized strings (lol, count it - 389) and nearly 200 images - everything fit well into framework native bundle. ( -bundleForClass: )

Be honest, one item doesn't fit well in case of its nature - InfoPlist.strings which should co-exist with info.plist. But it is a nature of targets, it's a corner stone.

Of course, I have changed everywhere accessors to inBundle: counterparts.
Do not know why you need bundles for frameworks. I suppose that all your frameworks are used 'as-is' without cheating (ah?) with images and resources accessors. But, of course, you could split apart resources and binaries into different targets.

However, I would like to have your main project/workspace which contain all targets with correct settings that I could only drag and drop into my project without any whistle.

Why so? CocoaPods is not a standard until Apple decide to acquire it. Even this library, as I know, isn't prepared for replacement of Fabric now. Maybe here I am wrong. #2011 #2009

[paulb777]

@lolgear As far as I know, it's not possible to make static frameworks drag and droppable without any additional option configuration.

We can potentially revisit after the next major release with the combination of #2022 and Rome.