Chirpie 1.2 is now available in the App Store! First off, Chirpie now supports iOS 4.0 fast application switching, so sending a Twitter or Facebook status update has never been quicker.

In addition to this, Chirpie has had all of its UI updated to support the new iPhone 4 Retina Display for an amazing high definition experience:

Chirpie 1.2 High Resolution

On top of this we’ve also added:

• “Listening to…” iPod functionality added to Chirpie Pro enabling you to tweet what you’re listening to in the iPod app.
• Fixed iOS 4.0 bug with copy and paste.
• Fixed crash bug when adding a new Twitter account
• App no longer enables the ability to send blank tweets/status updates
• Image Compression % slider added to Settings

We’re working on 1.3 to extend the functionality we have, including video, Twitlonger support and more. Can’t wait to share it with you.

Check out Chirpie: http://chirpieapp.com

Back in February of this year I developed a small Twitter app for iPhone called Chirpie. Frankly, being a n00b in this area it was a little taxing, and that’s just the development I’m talking about. What I was even less prepared for was the App Store approval process, so I thought I’d give some tips to developers hoping for a successful submission.

Device Support

My first failure at App Store approval was because of device support. I had built in functionality that enabled the user to take a photo with the camera, or select a photo from their library and attach to a tweet. It gave users the option to choose the source from a menu. Great times.

What I hadn’t thought about, and should have realised throughout, was that an iPod Touch doesn’t have a camera, yet they’re given the same software and same camera option in my app. This is made clear in the iPhone Human Interface Guidelines – Go over it with a fine tooth comb!

Write code that validates the device/availability of hardware to support your software!

Don’t Assume Reviewer knowledge of 3rd party products

So this was an interesting one. Like I said before, I was giving the option to attach photos, the device grabs an image, compresses it and then uploads it to a third party service like Twitpic.

As a regular Twitter iPhone app user I realised that I had to wait x amount of time for that to take place before I submitted the tweet, in order to let the upload finish and to get back a Twitpic URL. That assumption was clearly wrong. My app was again rejected because the reviewer didn’t wait, and classed that as a critical bug and against the sales description as the image wasn’t attached, assuming it was attached instantly.

Another rejection also came during a 1.x release, so after the app was in the store. The reviewer didn’t have Facebook or Twitter credentials to use the application with, therefore the app update was rejected.

So, do make sure any 3rd party integration credentials are supplied, and try not to assume any kind of user behaviour! (This should be a given, but as a regular iPhone user, you may become dull to certain aspects).

Email Apple to complain your app is taking too long

This was an interesting one. I could see my app was taking longer than other people’s new submissions, and it bugged me that Chirpie was going nowhere. So I emailed Apple to find out why. They replied within an hour, and the app went into review within a couple more.

The app was rejected ultimately for one of the issues above, but it worked!

Don’t email Apple to complain your app is taking too long

The flipside to emailing Apple is that it usually does nothing for your cause. During my prolonged initial 1.0 submission (and after my initial chaser email that seemed to speed up Apple), I again email them as my app appeared to be stuck in limbo land again. This time Apple were less helpful and told me to wait like the rest, and that some apps take longer to go through than others.

Point taken, I never emailed them again.

New apps take longer than Existing App updates to approve

Something you will quickly learn is that .x releases of your application will take a very short time, usually 24 hours turn around. For new apps it’s longer, how long is down to the size and complexity of your application.

What would infuriate me is that I knew for certain that a developer had submitted his twitter app the exact same time as me (Feathers), had very similar functionality, and was approved within 2-3 days, vs mine which was stuck in limbo for 5 days until I got a response from Apple.

Which leads me to my next point…

Existing “Trusted” Developers appear to be fast-tracked

Feathers developer @Aral had previously developed applications that were live in the store. I can only summise that this fact gave him a kind of “trusted developer” status, which meant that his application could go through first submission a little easier than my noobie one.

I have no idea if this is true, but it’s the only way I can understand why Feathers was approved really quickly for a 1.0 release, and mine was stuck.

Memory Leaks don’t matter

This was an unknown to me, I had assumed that my submissions should be 100% memory leak free. In actual fact, this isn’t true. Whilst it should be best practice for any developer to ensure they have no memory leaks in their code, you can happily submit your app (and get it approved) with memory leaks.

Conclusion

I hope this brief summary helps some developers with their submissions. Some of the mistakes above are easy to make – and shouldn’t happen for seasoned pros, but sometimes you have to make them to realise.

Feel free to add any of your own learnings to the App Store submission process in the comments section. I don’t think this is against my NDA… we’ll soon see!

In the last week Twitter did something interesting in order to quell the increasing noise from mobile and desktop app developers, that was – introducing xAuth to the wider web. Back in early February the Twitter API team announced the new xAuth authentication mechanism. Twitter hope it will fill the void of terrible user experiences mixed with web contexts into desktop and mobile apps experienced when using current authentication preference, OAuth.

Basic Authentication

Back when Twitter first launched it’s API they had what’s called Basic Authentication. A user of the API had to make all API calls directly with their username and password. iPhone apps such as Tweetie, Twitterrific and Birdfeed all use basic authentication. I myself used basic auth in Chirpie when I launched it 1 week ago.

From a dev perspective, basic auth is really simple – just make sure you store the username and password for an account, and re-use on every API call. However, Twitter deemed that from a security perspective, it wasn’t a great idea to be using the user’s credentials every single time they interacted with the API, they therefore decided to use OAuth. In addition, it’s required for any application that uses basic auth to store the username and password for re-use between sessions. Another no no apparently…

Twitter are now about to kill of basic authentication. Check out http://www.countdowntooauth.com/

Twitter Basic Auth Death Clock

OAuth

I won’t go into the deep details of OAuth, but the basic premise is this, an application gets a request token, and sends the user off to the source website (in this case Twitter) for a set of authorized tokens which it gives back to the application, and subsequently uses to exchange with the API instead of the user:pass :

OAuth Process

The problem with this is the “via web” part. For mobile and desktop apps, you have to leave the comfort of your application, and into a web interface in order to authorize the request. In addition to this, Twitter penalised anyone using basic authentication by stopping them from publishing their application name unless using OAuth (hence the developer outcry for some months). Example:

Twitter Basic Auth Vs OAuth/xAuth

It’s worth noting here, that in the old days basic auth apps could publish tweets using “via application name“, however early in 2009 Twitter stopped accepting registrations for basic auth applications, which is why some basic auth apps still come from their app name, like Tweetie, where more recent ones come from “web”.

On iPhone, leaving the comfort of a native app into a web interface (which was until recently not optimized for mobile) was a huge loss – therefore most iPhone devs from recent times opted for basic auth in order to keep a good user experience.

Enter xAuth

So xAuth is here to save the day… xAuth takes some fundamentals from OAuth in the sense that you still use your authorised tokens to interact with the API, however it’s the process of getting that set of authorised tokens that has changed. Basic auth developers can now exchange the username and password of their users for an authorised token set in one API call. No web interface required. Essentially:

xAuth Process

This stumps alot of people at first, there’s no process involved to get a request token, that’s all out of the door – it’s simply get the user’s credentials, make an API call, receive authorised tokens in return.

The downside of this is that the application is interacting directly with the username and password (in the same way basic auth did), so in essence is losing a large chunk of the security effect of OAuth (OAuth apps never see the username and password of the user directly, only the tokens).

There are alot of arguments around the web on the effectiveness of xAuth – to me it seems like its just basic authentication with a bit of extra security because each API call isn’t using the user:pass every time – in fact, to even associate it with OAuth for me is a little bit crazy.

That said, I am extremely happy. As a recent iPhone app developer, I was gutted to find that I could no longer register Chirpie as a basic auth app with Twitter, and subsequently couldn’t promote the use of it within Twitter unless I used OAuth.

Using xAuth

Using xAuth couldn’t be simpler actually. First off though, you need to send an email to api@twitter.com and ask them to register your OAuth application to use xAuth. Once approved (you’ll get an email at time of writing) you make a call to the API method “https://api.twitter.com/oauth/access_token” and simply send it 3 parameters:

• x_auth_username -  The username of the user.
• x_auth_password – The password of the user
• x_auth_mode – Set this value to “client_auth” (without the quotes).

This one method then returns you the authorised access tokens in the same way the same method does for OAuth. You should store the tokens as they do not expire, and reuse the tokens for any subsequent API calls. The password can effectively be forgotten after the authorised access tokens are received (unless you need them for third party sites such as TwitPic etc..).

It really is that simple, just one step. As long as you remember this key point (that it’s one API call, no request tokens needed etc), you will be setup really quickly. The Twitter documents aren’t so clear on this, and hopefully they will clarify a bit better shortly.

I managed to get xAuth implemented into Chirpie in about an hour, and submitted to the App Store. Such a small change, which I hope will make a huge difference to the effectiveness of Chirpie in Twitter.

Update – xAuthTwitterEngine

For those hoping to get xAuth working on an iPhone, Aral Balkan has just launched xAuthTwitterEngine, which is an update to the excellent MGTwitterEngine from Matt Gemmell, via an OAuth implementation of that by Ben Gottlieb.

I haven’t used xAuthTwitterEngine in Chirpie, however my implementation was exactly the same, a re use of Ben’s OAuth code, removing the web authentication interface and replacing with a user:pass API call. I just wasn’t brave enough to release it to the world as I’m still learning! Anyway, have fun!

Yes folks, one week after the launch of Chirpie 1.0, version 1.1 is now in the App Store to download. This update brings a few nice features and fixes:

• New clean and awesome Tweetview UI
• Added new control to switch status updates to Twitter, Facebook or Both.
• Application now remembers if you enabled/disabled twitter in tweet view.
• Added ability to paste an image and upload from the clipboard
• Added direct link to Chirpie Pro in the App Store from Chirpie (free) version.
• Added ability to follow @ChirpieApp from the about page.
• Fixed bug with mis-placed facebook button in turbo mode.
• Fixed memory bug when exiting out of camera would sometimes break tweet view.

New Interface

Chirpie 1.1 Interface

Chirpie has been updated with a really nice, clean interface with the help of Nicolas Thomsen. Nicolas runs apporacle.com, check out the site for some great examples of Nicolas’s work.

As part of the redesign, the bottom buttons have been given a brand new glassy look, with the scrolling avatars sitting nicely on top. We’ve also added a new central section with a brand new control, the service switch.

The service switch was an idea from @jonguntrip, allowing users to send to Twitter, Facebook or both. The app now remember where you left the toggle, except if you left it on Facebook only. This will always default back to both.

Paste Images form Clipboard

Also another brand new feature with Chirpie 1.1 is the ability to paste images from the clipboard. Either by setting the app to auto paste on launch, or by selecting the Photo button, you are now able to paste any PNG or JPEG image that is on the clipboard.

This means you can effectively copy any image from any application, and paste it into Chirpie. Once pasted, the app automatically uploads it to YFrog or TwitPic (depending on your prefs). All seamless, nothing for you to worry about!

Pimp Chirpie

Thanks to everyone for the support on Chirpie so far – and letting your friends know how awesome it is! We’ve had well over 1000 downloads already in the past 7 days – it’s been excellent to work with you all. As always, get in contact with us via @ChirpieApp on twitter for the latest news on Chirpie, and to let us know about features and feedback.

Chirpie 1.1 (free version) is available from the App Store here.

Chirpie Pro 1.1 is also available from the App Store here.

Cheers! – Chirpie Team

This is it folks, the day we’ve all been waiting for, the day Chirpie for iPhone makes it to the App Store!

Chirpie 1.0 comes in two versions, a free app simply called “Chirpie“ which is feature complete, but limited to 1 Twitteraccount and 1 Facebook account. The second version is called “Chirpie Pro“ which is exactly the same, however you can add as many Twitter accounts as you wish. Chirpie Pro is priced at $0.99/59p.

The Chirpie Interface

Chirpie for iPhone lets you dual update, meaning you can send a status update to both a Twitter and Facebook account at one time, or just Twitter if you’re that way inclined.

To coincide with the launch of the application, we’ve also launched a refreshed chirpieapp.com which features everything you need to know about Chirpie – including screenshots, feature list and FAQs.

Chirpie (free version) is available from the App Store here.

Chirpie Pro is also available from the App Store here.

Any problems, please contact us on support[at] chirpieapp.com or via our twitter account @ChirpieApp.

Chirpie 1.1 is currently in the works, with version 1.0.1 about to hit Apple sometime in the next day or so.

Followers of my Twitter feed will have yesterday seen that I am very close to launching a new Twitter client for iPhone, called Chirpie (see chirpieapp.com). So what is Chirpie? Will it beat the skitch out of Twitterrific, Tweetie or Echofon? The short answer is not just yet, the longer answer is this:

Chirpie has been developed with one simply idea in mind:

Empower the user to tweet quickly, do it simply, let it have flexibility.

With this simple notion as the backbone of the app, I’ve developed something which I find a bit of a gem. An app that lets me tweet pretty much instantly. No heavy waiting sessions whilst you wait for a Twitter timeline to load, no navigating through views to get to the tweet window.

Sounds simple right? Well, it kind of is, but it has some nice twists:

• An intuitive way to reply to friends, and handle new friends.
• Quick access to common functions such as the Camera, URL shortening, Geo Tweet etc
• Tweet Persistence, when switching accounts, and when leaving the app
• Pasteboard functionality to speed up your flow
• Advanced app settings, one being switching Chirpie into Turbo-Mode

You’ll be able to tweet straight off the bat, send, done. Or, you can take some time, play with the toolkit, send or just save for later.

Chirpie has a simple, clean interface when tweeting, no buttons all over the place for all the different functionality with icons that make no sense, just one simple way to reveal what you need.

But this is just the start, I want Chirpie break free of it’s little egg – build on these foundations to bring a Twitter client with a difference. Let’s see how we go.

Beta Testers Required

So when can you get your hands on it? Well my friends, very, very soon. We’re currently looking for Beta testers, so head on over and friend us up on twitter (@ChirpieApp), or keep an eye on our teaser site http://chirpieapp.com for more. Spread the word about Chirpie and you may find your way up that list

And the sweet spot?

Chirpie will be a free download to all. Coming Soon!