This library needs an overhaul and more visible support.

[GoogleCodeExporter]

A lot of us use at least one of Google's public data APIs. It's unavoidable. 
From YouTube to Google+ to even the URL Shortener, it is inevitable that we 
will use one of Google's APIs because they are so useful. Those of us using 
Cocoa and Cocoa Touch to access those APIs are directed by the APIs' 
documentation to the open-source Google APIs Objective-C Client for 
implementation help. But now it's out of date, and Google hasn't done anything 
about it.

Some things in life age well; this library is not one of them. And Google 
hasn't helped by basically ignoring their client library in these ways. 
Google's API client for Objective-C was good for what it was in 2011, but that 
was before Swift, modern Objective-C, CocoaPods, and even Automatic Reference 
Counting! Here are some specifics:

-Only recently have property definitions been updated to use the nonatomic 
keyword.
-Automatic Reference Counting is an afterthought, and only used in the 
service-specific files. The base classes use Manual Reference Counting.
-The repository uses SVN for source control, so it's almost impossible to 
contribute as it is so dated.
-It is so complex that it's a challenge just to import the library into your 
project, and there are so many hacks one might need to perform to achieve just 
that.
-There is no support for clang modules in this library (even in its 
severely-outdated CocoaPod), which means more work for Swift developers just to 
be able to use this library in adding a Bridging Header etc.
-The podspec, not even maintained by Google, that does exist is horribly 
out-of-date. They don't even support this library in their new CocoaPods-based 
library distribution system! (Don't be fooled: "Google APIs for iOS" is just an 
aggregation pod for all the other "modern" libraries that Google supports with 
this distribution flow, obviously not including this API Client)
-Google Code is shutting down very soon (in a matter of weeks it will become 
read only!)

So what do we as developers do? This library is still a VERY helpful way to 
immediately have access to all those great APIs without a lot of boilerplate 
and setup, and the documentation STILL points us here. However, it is really 
old, and has lost effective support from the majority of Google, besides the 
people who have actually been maintaining it for the past few years. If it 
weren't for the few maintainers who kept the project up and running and still 
as useful as it currently is, we would be in a much worse situation than we 
have now.

So I have a simple list of requests -
1) Resume visible support for this library
2) Modernize this library (especially the core) to work with ARC and other 
Objective-C modernizations.
3) Support clang modules so the library can be imported into Swift, or make a 
framework.
4) Add this library to your repertoire of Google CocoaPods libraries that you 
celebrate. 
5) Move this library to GitHub before Google Code turns read-only, which would 
also be seen by us as a sign of visible support.

In the meantime, I've decided to, on my own, try to make a new library. It's a 
new take on the Google API Objective-C Client. It's even written in Swift! For 
now it includes the base classes and the Discovery API, so that I (or anyone 
else) can implement a Service Generator for it. Here's the link: 
https://github.com/mattwyskiel/GoogleAPISwiftClient

So please, show us that Google as a company still supports this library that is 
so useful to so many of us!

Thanks,
Matt

Original issue reported on code.google.com by mwwysk...@gmail.com on 14 Aug 2015 at 6:02

[GoogleCodeExporter]

Some quick answers for you -

We've been pushing regular updates to the sources (new services, internal 
changes, etc.).  We also answer questions on the group for it.  What 
specifically did you mean by "visible support for this library' that that 
didn't cover?

The ARC question is an interesting one.  Apple has never said all code must be 
ARC, and in talking to them, they have agreed there are cases where ObjC with 
manual retains/releases ends up better/faster because of the ones ARC inserts 
to be complete.  For that reason, we haven't worried much about it, it could 
actually slow the code down a slightly.

Some of the folks that work on this also work on the supporting libraries, and 
we've slowly been starting to add the markers for Swift, we've hit some 
interesting hiccups on how older and newer codes autocomplete in their 
presence, so we've been slow to do it since they also hurt folks that hadn't 
been able to adopt new Xcode's due to their release cycles, etc.

CocoaPods - coming.  This library is a tricky one because we're not sure what 
to do with the services.  Since ObjC doesn't dead strip, so you don't want one 
library/framework with every possible service as it would bloat your app; but 
having a target for each also has downsides.  Anyway, yes, we avoided the Pod 
side of things for a while, but we're getting there.

code.google.com - We're moving.  We have/had to get the sub projects moved, and 
we've stalled a little internally as svn:external allowed us to easily pull in 
the sub projects this uses, and there doesn't seem to be a good replacement for 
git.  Anyway, it is in progress.

Original comment by thomasvl@google.com on 14 Aug 2015 at 6:25

[GoogleCodeExporter]

Hello. Thanks for the response. 

On the issue of visible support, that has been answered in your response 
overall. It seemed that as your company was doing more and more new stuff with 
newer libs and using all these niceties such as Github and Cocoapods and using 
simple bases etc. it doesn't seem that this library is getting as much love. 
Thanks for clarifying these things.

On Cocoapods - I think you can use sub specs for your individual services and 
one for the base, and then set the default subspec to be the one for the base. 
Then by default a pod install without a specified subspec will be just the base 
classes. You can see the podspec reference on Cocoapods.org for more info on 
that. 

On Swift and the new Obj-C attributes - Parse recently open sourced their SDKs 
and the iOS/OS X repo includes macros they created to use the new modifiers 
(nullability etc.) while compensating for older versions that don't support it. 
It's very ingenious- 
https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/blob/master/Parse/PFNullabili
ty.h

I will still continue to work on my Swift library as an alternative for Swift 
programmers who want a fully Swift experience, but THANK YOU for getting back 
to me so quickly. 

Thanks,
Matt

Original comment by mwwysk...@gmail.com on 14 Aug 2015 at 7:10