Skip to main content

Apple and the Google Voice app, surprise in store?

Awhile back Apple decided it was going to reject the native (as in "non-web-app") app for Google Voice from Google, citing that it "duplicated functionality the iPhone already had". Which, by the way, is against the developers terms of service for developing iPhone apps. Now, I have heard a bunch of blowback against Apple about this, and I'd like to throw my conspiracy theory into it. I'm also writing this in hopes, that basically Leo Laporte from TWiT and MacBreak Weekly see it, and Kevin and Alex from Diggnation see it. As these podcasts have just been going at it saying how Apple is an evil empire. My point is, maybe everything isn't as it seems. (as well as all the other podcasts that have been lambasting Apple since the rejection).

First, if you haven't heard of Google Voice, Google Voice allows you to have one phone number that you give to people and that phone number can be assigned "Back-end" phone numbers that the Google Voice (GV from now on) phone number calls. So, for example, if you call my GV number, it will, depending on who you are, call my home phone, my cell phone, and Gizmo (VOIP Program) all at the same time and I can pick up any one of the three. Furthermore, if you leave a voicemail on my GV number, your voicemail goes through voice to text transcription and gets SMSed and Emailed to me. I use GV for several reasons.

One, I can give it to ANYONE and I can assign what phone number you ring when you call me.
Second, I can give the number to anyone, and I can change my backend phone numbers as well. One phone number for the rest of my life basically. I give you my GV number, and you don't have to worry about what my current cell number is. It's on ME to change it on the backend of GV.
Third, People don't know my actual cell phone number. But there really is no advantage to that.

GV works like this, (well at least on mine), if I get a phone call to my GV number, it rings through to the backend phones. Using minutes. It's not like Skype or Gizmo or anything like that. It's an actual phone call. It's using AT&T's minutes.

When someone sends an SMS to my Google Voice number, it gets sent to my cell phone. Just as if you were sending a text message directly to my cell phone. It costs the same.

There are a lot of conspiracy theorists out there on the internet that think that you can make calls for free, therefore AT&T is preventing the app from getting on the app store. The only reason that I could see AT&T bitching about this is that it would be easier for people to give out the Google Voice number, so at some point users who would switch off of AT&T, since changing the GV number on the backend is trivial, they'd be able to just switch numbers and not take their cell phone number with them. But this argument doesn't even make any sense. Actually it's hard for me to articulate what I am trying to explain as it doesn't make any sense. Since taking your phone number with you to a different carrier is a trivial exercise.

Now, all that being said, I think I've said what everyone on blogs that I read and podcasts that I listen to are saying, so here's my take:

Apple turned the GV app down because it "duplicated iPhone functionality". Which, as I said earlier, is against iPhone Dev agreement. What people aren't remembering is that awhile ago Apple did the same exact thing. Remember?

It was a podcast application. Podcaster. Podcaster was also rejected because it duplicated functionality on the iPhone. (or in iTunes depending upon which article you read). What happened to that application? Well, it disappeared into the sunset, because later, if you remember, Apple gave you the ability to download and play podcasts directly from the iTunes store on the iPhone itself. Yes, AFTER. So Apple has pulled this trick before. Most likely because the functionality to download podcasts via the native iTunes store on the iPhone itself was already in development at the time of the rejection of the app.

So, here's my thought.

If Apple did the same thing to Podcaster that it's doing to Google Voice, then that tells me that in a future release of the iPhone software, the Google Voice functionality will be native. NATIVE. Like, built into the iPhone.

For this to happen, Google and Apple would have to partner up. Much like they did for Google Maps. The team that would develop the iPhone app and the the team on the Google Voice side, quite possibly be on different teams, aside from that, the people involved with working with Apple on the "native" Google Voice functionality would probably be under a very strict NDA. Which is why the developers of the "current" GV wouldn't know that it was being worked on for native functionality inclusion. Apple is famous for it's secrecy. This isn't a stretch of the imagination by any sense of the word.

I have no insider knowledge of the iPhone division of Apple, so I can't verify this.

Imagine this, go to Preferences on the iPhone you log into Google Voice through a Preference, and then, you have a slider. Left for Native iPhone phone number, Right for Google Voice Number. The Google Voice number, of course, acts a little differently as the call has to be sent up to GV for GV to initiate the call and call both parties back. (There are apps that did this in the past, GVMobile is one, which I was smart enough to get a hold of before Apple pulled it from the store.) But what if the iPhone could work it so that you never knew about the "call back" from GV. What if it just looked like a native phone call, it just took a bit longer to connect, and the iPhone just background-auto-accepted the call. You'd never know it. It would act and look like a phone call from the native iPhone number.

SMS would be routed through GV's special SMS connectors so that they would appear to come from you GV number. All the while, you are still being charged "standard text messaging rates" and cell phone minutes from your calls. The only difference in the user experience is, people are seeing your GV number on their caller ID's and that's it.

I'd like to hear your thoughts on this one. Please leave comments below.



Comments

Popular posts from this blog

Offset, Depth, Distance, and Within

Without going off the deep-end here and discussing every single Snort rule keyword, I just wanted to touch on a few modifiers that people sometimes misunderstand.  They aren't difficult, and hopefully after this explanation and a few examples, I can clear some of the air around these five modifiers.

The five modifiers that I am talking about are
OffsetDepthDistanceWithinnocaseThese five modifiers are not keywords of themselves, but rather they apply as modifiers to another keyword.  That keyword is "content". The content keyword is one of the easiest pieces of the Snort rules language as all it does is look for a particular string.  So for instance if I wanted to look for the word "joel" within a packet.  A simple:
content:"joel";Would allow me to do that.  The interesting part comes into play when you want to specify where inside of a particular packet you want the string "joel" to be looked for.  If you are running just a plain content ma…

Writing Snort Rules Correctly

Let me start off by saying I'm not bashing the writer of this article, and I'm trying not to be super critical.  I don't want to discourage this person from writing articles about Snort rules.  It's great when people in the Snort community step up and explain some simple things out there.  There are mistakes, it comes with the territory.  If you choose to be one of the people that tries to write Snort rules, you also choose to be someone who wants to learn how to do it better.  That's why I write this blog post, not to bash the writer, but to teach.

I noticed this post today over at the "Tao of Signature Writing" blog, and to be honest I glanced over most of it figuring it was a rehash of things I've already read or things that have already been written from countless people about "Here's how you write Snort rules!".  I scrolled down quickly skimming, not reading at all really, and noticed this part:
Now, let us look at the second questio…

Safari 5.1.4 now available

Safari 5.1.4 now available, fixes issues and improves performance | TUAW - The Unofficial Apple Weblog:


Improve JavaScript performanceImprove responsiveness when typing into the search field after changing network configurations or with an intermittent network connectionAddress an issue that could cause webpages to flash white when switching between Safari windowsAddress issues that prevented printing U.S. Postal Service shipping labels and embedded PDFsPreserve links in PDFs saved from webpagesFix an issue that could make Flash content appear incomplete after using gesture zoomingFix an issue that could cause the screen to dim while watching HTML5 videoImprove stability, compatibility and startup time when using extensionsAllow cookies set during regular browsing to be available after using Private BrowsingFix an issue that could cause some data to be left behind after pressing the "Remove All Website Data" button