For ThinkMessenger you can:

Open the app:

thinksms:

Send a text:

thinksms:5555555555?body=bodytext

Open the inbox:

thinkmessengerfolder:inbox

For ThinkDialer you can:

Open the App:

thinkdialer:dial

Call a phone number:

thinkdialer:+18005555555

What happened?

In December I started to transition my developer account from a personal one, which listed apps in the store under my name, to a business one. This is a fairly routine operation with a set procedure, however when the transition was suppose to start, I lost access to my account.

Shortly there after it became apparent that new push registrations were not going through to Apple’s server. So existing users continued to use the app without problems, but new users and anyone who uninstalled or disabled notifications, were not able to use notifications. Needless to say, I got a lot of emails from users who could not figure out what was going wrong. To avoid any more users experiencing problems, I chose to remove ThinkMessenger from sale until I could get the problem fixed.

I contacted Apple Developer Support, who nearly immediately took responsibility and labeled the issue as a bug on their end. However, after a month, they still had not found a solution. Eventually one support specialist recommended that I remove my access to all other developer accounts (other companies I have done work for). While this wasn’t easy, once I did Apple was able to push the change through and I once again had access to my account and, at least on new builds, notifications were working again.

What else is new?

ThinkMessenger 1.4.0 includes the following improvements:

• Added ability to send a message while another one was being sent
• If a reply is not added to the current conversation, the new conversation is shown
• Fixed unsent message saving
• Fixed bug that caused the notification sound from playing on launch
• Moved logout button to settings
• Fixed crash that would happen if the user received a empty text
• Feedback form now includes device info
• Made push notification registration more stable and reliable
• Added notice for Google Apps users to setup push notifications manually
• Added Voice Over support
• Fixed bug with the user’s contact photo
• Fixed issue with audio route in voicemail
• Fixed issues with proximity sensor
• Added call and contact buttons to the top of conversations

Download

Back when I was working at a mining company writing custom GIS software, I got very familiar with the dBase file format or DBF files since they are used along with shape files to store information about geographic data.

At the same time my dad was switching to the Mac and we were slowly pulling him away from his dependence on Parallels. One of the antiquated technologies he was hesitant to part with was a database of his sermons and illustrations that was in dBase (dating back to 1990).

So, as a loving son I put my knowledge of the format to work and created this little tool. It worked out for him until recently when he made the wise decision to purchase a real database program.

Apps, whether they are first party or third, have to use an API to connect to any online service. Twitter for example has a very good public API, which has caused many developers to write apps to use the service. This breaks down to a set of URLs for getting information and performing actions on the server.

Google Voice has no public API. None. Other Google Services do, like Gmail or Google Reader, but Google Voice has yet to officially support any third party software of any kind. Pretty shocking when you consider how many tools there are.

So how do all of these apps interact with the Google Voice server? Well while there may be no public API, the Google Voice website still has to connect to the server with a private API. Basically all the Google Voice apps except for Google’s own, use the Google Voice website in the background and show a clean interface to the user up front. That is trickier to do than it may sound.

The first step is to figure out how the website talks to the server. This takes some clever reverse engineering. I personally used Safari’s excellent web developer tools to monitor requests made. That looked like me pressing a button, looking at what got sent to the server when I did that, and then trying to reproduce that result.

This causes a lot of problems because while I may be able to get it to work, there are still a lot of things about the API that I just do not understand, especially when it comes to the authentication process (logging in). It was that reason that made me switch to using a web login a la OAuth in 1.2. The number one complaint for the app is login problems, probably caused by something I don’t understand or missed about the API.

However, even once I had figured out how to connect to the server, there was still a very big problem, one that to some extent does not have a fix. That is, the API that the website uses is only used by the website, and was only meant to be used by the website. So you are limited to what the website does.

There are 2 different websites for Google Voice (well 3, but the old mobile version is useless for third parties), the desktop version and the mobile version. Think Messenger used the desktop version prior to 1.2, and the mobile version from that point on. Both have limitations.

The desktop version serves the data in a very odd fashion. It’s HTML fragments in JSON inside of XML. Christopher Nolan would be proud. I on the other hand couldn’t be more frustrated. Parsing XML and JSON isn’t too bad, but pulling data out of HTML is messy. There is a lot of extra parts to it for layout, and it can change with little notice. What’s more, that is 3 different parts I have to parse, which means 3 different libraries my code has to link to and 3 different libraries I have to learn how to use. And on top of all that, it takes forever to parse. The time it takes to load is 80% parsing on the phone and only 20% download time. I had to use multithreading to keep the interface responsive (which on a brighter note, makes Think Messenger ready to take advantage of the iPad 2′s dual core processor). It also lacks certain data; individual times for each message are not in a readable format.

So why would Google use such a cumbersome interface to their server? Because for what they are using it for, it is actually faster. The website doesn’t have to convert data into a view, it just puts the response from the server right on the page. The people who designed it never planned on any other use for it.

The mobile API is a lot nicer to work with. It returns data in a well formatted JSON document. When I switched to using it in 1.2, I was able to remove hundreds if not thousands of lines of code. And less code means less bugs.

But the mobile API has problems of it’s own. For instance, when you do an action, like archiving a conversation or sending a message, it doesn’t send you back the results of what you have done. You can see this on the mobile website. If you send a reply you have to hit refresh to see the message. The fix is to refresh after everything that could make a change, causing an increase in data usage and battery consumption (it’s still quit minimal compared to something like watching a video).

Another limitation that was easy to overcome is that the mobile website won’t let you send a message to multiple recipients. The fix? Send to each recipient individually. Rather than tell the server to send to John, Frank and Matt, you tell the server to send to John, then send it to Frank, then send it to Matt. Again extra data usage but fixable.

One problem that I have yet to overcome is that the mobile website does not really support replies. If you hit the text button on a conversation, you open the new message interface with the person’s info filled in the to field. What this means is that occasionally when you send a reply in the app, it won’t show up. Instead it will be added to the most recent conversation with that person or to a new conversation. I have already had several complaints from beta testers that they thought that the message didn’t get sent. Again, there isn’t much I can do without official support from Google.

Then there are the feature requests I get that I have no control over. Things like people wanting messages grouped by sender rather than conversation. I actually agree with this one, but it would not be very wise to go against the core of how Google Voice works.

Another common request is support for sending pictures. Google Voice does not support this at all. If you try to send a picture to a Google Voice number, it will tell you that it sent just fine, but the recipient will never have any indication that someone even tried to send them anything. Likewise there just isn’t any way to send a picture to someone. However, Sean Kovacs of GV Mobile+ did find a workaround similar to Twitter by uploading the image to a photo sharing site and including the link in the message. Admittedly, it’s something I never thought of doing. It still has it’s downsides, like only being viewable by people with smart phones, and you still can’t receive regular MMS, but it is a good example of how developers have to think outside of the box to make a good Google Voice app.

Push notifications are another beast entirely. Most service providers don’t provide support for notifications anyway. The only two examples I can think of are Facebook and Twitter. But Google Voice ads the additional caveat that you don’t have official access to your users accounts. I will write more about Push Notifications at another time.

With all the problems though, it has been a rewarding experience. I have also had to reverse engineer for iPhone Video Screen Capture. You tend to learn a lot when you look deep into the workings of a professional product.

• Added native support for iPad
• Changed minimum iOS version to 3.2
• Changed base SDK to 4.2
• Fixed bug that caused music to stop playing when a message was sent or received
• Replaced Three20 message controller to a custom message controller fixing several bugs related to starting a new conversation and allowing Three20 to be removed completely from the app, cutting the size in half
• Fixed error handling when starting a new reply
• Fixed a bug that caused saved replies to keep showing up
• Changed the names in the inbox to take up as much room as possible without overlapping the date and resize when it runs out of room
• Added vibration when receiving push notifications when the app is open
• Made opening conversations faster
• Made scrolling through the inbox faster

If you are interested, send a list of your devices with UDID and the email address you use with Google Voice. You can find the UDID by connecting the device to your computer and clicking on it’s serial number in iTunes. If I choose to use you, I will then send you a copy of the beta.

Please only request to be a tester if you already use the app regularly and can commit to testing the app thoroughly. You will need to send me any crash logs and problems you encounter.

I am no longer accepting new beta testers. Thank you.

17 weeks 0 days 23 hours 28 minutes 0 seconds

Update September 22, 2010: Messenger for Google Voice, is now available in the App Store.

Most apps take about a week to get approved. This is what Apple claims, and my own experiences with Bubble Burster have been even better. However, I recently submitted an app that has taken a little longer. When I started it in January, I figured there was a very likely chance that Apple would not allow it. I started the project knowing full well it may never make me any money, because I wanted to be able to use it myself.

I submitted the app, Google Voice Messenger, to Apple on May 25, 2010. On June 2, 2010, the status went from “Waiting For Review” to “In Review”. That day, according to my analytics software, they opened the App twice on two different devices. That night, I received an email that read as follows.

Dear David Beck,

We are currently reviewing an app that you submitted for inclusion on the App Store, and want to let you know that the review process will require additional time. We apologize for the delay and will provide you with an update on the status of your app as soon as possible.

Application Name: Google Voice Messenger

Application Version Number: 1.0

Application SKU: 100012010

Application Apple ID:372709006

If you have any questions or concerns regarding this notice please contact us at appreview@apple.com .

Sincerely,

The iPhone Developer Program

This is a fairly common letter to receive from Apple, and given that it was the beginning of WWDC, their biggest event of the year where they introduced the iPhone 4, it’s no surprise that there were a surge of these letters. Following that there was the release of iOS 4.0 and the iPhone 4 itself. Needless to say Apple was a little bit busy. Nevertheless, while most apps were delayed about a week, I am still awaiting a reply.

On June 18, 2010, I sent the following letter to Apple.

Dear App Review Team,

I received a notice that you would require more time to review my App, Google Voice Messenger on June 2, 2010. That was more than 2 weeks ago and more than 3 weeks since I first submitted the App. Is there any specific problems that I should know about? Can you give me any time frame for when it will be approved?

David Beck

A few days later, I recieved a standerd reply.

Dear Mr. Beck,

Thank you for the email. We apologize for the delay. Your application is still in review but is requiring unexpected additional time. You will be updated with further status as soon as we are able.

We appreciate your continued patience.

Best Regards,

Melody
iPhone Developer Program

Apple is nothing but consistent.

On July 8, 2010, out of desperation and friends prodding me, I sent an email to Steve Jobs asking him for any information. In order to maximize my chances I kept it short, sweet and to the point.

I uploaded my app, “Google Voice Messenger” 6 weeks ago. What is taking so long? Do you have to approve it personally?

David Beck

As expected, I have yet to receive a response. Perhaps he couldn’t download the email because he was holding his phone wrong.

If you aren’t aware, Google themselves got their Google Voice app rejected a year ago. The reason Apple cited was that the app “duplicate features that come with the iPhone,” but many surmised that AT&T, the exclusive carrier for the iPhone in the US, had something to do with it.

Why did I even hope that my app would get approved? First and foremost, if you are to believe Apple, their reasoning was that the dialer looked and acted exactly like the built in phone. The problem here is that Google Voice is not a standalone phone service; it requires a phone to route calls through. This means that when you place a call in the Google Voice app, it opens the system phone app that looks just like the app you were just using. This obviously could get very confusing.

My app is a little different in this regard. First, it isn’t a dialer or a phone. It only focuses on text messages. Text messages don’t need to be routed through a phone and can be done completely over the internet, and more importantly, completely from within a single app. A user could hide the built in texting app and completely replace it with mine.

The other reason that Apple could have banned the app is if someone at AT&T dennied it. This is definitely a possibility as AT&T would be losing minutes and text messages to Google. Having said that, AT&T has started to loosen the restrictions on their network. In October of 2009, 4 months after Google Voice was banned from the App Store, AT&T lifted the ban on VOIP over the 3G network (Voice Over IP is the ability to make phone calls over the internet without being charged minutes). Likewise, it has started to lift limitations on video over their network.

There could be any number of reason my app is being delayed. Apple certainly hasn’t communicated with me about any problems or reasoning, so I am left to guess. What seems most reasonable to me is that it requires approval from a lot of big players. Realize that this single app concerns not only Apple, but AT&T and Google as well. Another possibility is that Apple knows something I don’t; perhaps Google is getting ready to release an official app and Apple is waiting for that to be ready to approve mine. It’s possible that they are trying to hold it as long as possible to avoid the PR hit when they denny it.

Even through all of this I am still a supporter of the “walled garden” approach to the App Store. While it is not without it’s faults, this instance certainly being one of them, the experience is, in my opinion, worth it. I like not having to worry about viruses as a user. I like not having to worry about payment processing and DRM as a developer. I like that when I tell someone about an app, big or small, no iPhone user ever has to ask how to get it because it’s the same for all apps. The App Store is a great equalizer for developers. Nowhere else would you find an independent developer facing the same problems as a multi-billion dollar company.

If you want to know the second (well day at least) that something changes, you can enter your email below:

It’s nothing to fancy, just a WebKit view in a simple window. The best part is that it will update the badge icon in the dock so you don’t have to keep the window open.

Refreshing from the menu will refresh like it does when you click the refresh link rather than reload the entire page.

Now in open source.

Download

It does not record audio at this time.

To install the plugin, place it in “~/Library/Application Support/SIMBL/Plugins”. create it if it doesn’t already exist. You will need to install SIMBL as well. Right now it is only for Snow Leopard but there isn’t anything major that is keeping it from working on Leopard other than some convenience methods.

If you end up using this plugin, please let me know in the comments.

Download

Update: Thanks to John Scott for getting it working with 3.2. It now works in 3.2 and 4.0. iPad, unfortunately, does not record correctly yet. The cosmetic settings, like setting a fake time, are not functioning either.

Update: Fake time, fake apps and fake carrier have been fixed for 4.0. A Github repository has also been created.

I can’t say I am too surprised by the low turn out. My low end estimate was a little higher though, at $20 in the first month. I knew going in that there were 75,000 apps (well 80,000 by the time it actually released) on the store already, and that because the only ones visible to most people were the ones in the top 20 and you couldn’t get there unless you sold a lot of copies and you couldn’t sell very many unless you were in the top 20.

To combat the problem of visibility I used some advertising promotions I had been saving. Google gave me $100 ad credit to sign up for AdWords and my hosting company, LunarPages, gave me a $25 credit for FaceBook. Unfortunately, those have not been very successful and I think I will pull them when the promotions run out.

One thing that is often suggested is to make a “lite” version of your app for free. I am working on this right now. It is difficult for me as a programmer to create a lite version because it means taking functions out that I have spent a lot of time putting in. When it is finished, the lite version will have all the functionality of the full version but will cut the player off when they score more than 50 points. A score that takes a while to accomplish.

The other suggestion is to get blogs like Touch Arcade to review your app. I plan to do this once I have released the lite version. Even still, most people don’t read these specialized blogs.

The original plan was to introduce what I had for $.99 and then, once I had updated the game with more features like saving score and games, I would raise the price to $1.99. I advertised that it was $.99 for “a limited time”. Well a few days ago I upped the price as planed when Apple approved version 1.2. So far no one has made a purchase at the new price, but that is not necessarily any different from when it was at $.99. We will se if I can make 3 sales next month to match the income (if you can call it that) of the app at $.99.