By Nicolas Thomsen (@apporacle) of ShapeHQ.com

Ever since man went from caveman to something more advanced he has had a need to keep track of his values. At first “money” were merely big chunks of shiny material and had to be kept in a big bag, later actual coins were made and they got lighter, smaller and easier to carry. Still people kept them in a bag or their pockets. When they went to the market they could easily see how much they had left to spend. When credit cards were introduced things got more complicated because now your money is kept in the bank and you don´t have the same overview of your balance when you are around and about.

But even though you no longer have all your money in your pocket, there is something else you always have with you – your iPhone. In my opinion the iPhone is the perfect tool to track your expenses. The truth is, tracking expenses, while extremely ordinary, is a very useful utility for many people. And while there are countless expense trackers for the iPhone, none of them hit the sweet spot between ease of use and a polished UI. So it really was the perfect first app for us to build as a team. I just wanted to spend a little time writing about how Expenditure came to be.

Picking your spot

The audience for the app was an important factor. After looking at the different apps in the finance category we felt that we could divide them into three groups.

Group 1

Apps that are easy to use, with a simple functionality but not a great focus on the interface and the user experience. Usually priced at 0,99$ – 1,99$

Group 2

Apps that focus on a polished interface and a nice user experience. The functionality of these apps tends to be more advanced, which means that they can be less easy to use. Usually priced at $3,99 – $4,99

Group 3

Apps with lots of functionality. Tends to target the more hardcore users. Very little focus on the interface and the user experience. Usually priced at $4,99 – $7,99.

We concluded that we wanted to target casual users with Expenditure. We wanted it to be somewhere between Group 1 and 2, with a high focus on a polished interface and user experience but at the same time we wanted to make sure that the app was very easy to use. On top of that we thought that $1,99 would be a good price point for an app like this.

Designing the Interface

I wanted Expenditure to have a unique interface that was relevant for the purpose of the app. I went for a custom interface but I wanted to avoid that it looked like a toy. There is a fine line between when After a lot of brainstorming I settled on a design inspired by an ATM machine.

It didn’t take long to come up with a working solution for the interface. I thought that the most important information to show the user is how much money you have left. Therefore the biggest element ought to be a screen that shows the user´s balance. After I decided that the UI should be inspired by an ATM machine it was a given that most of the app should have a subtle metal feel to it. We thought it made a lot of sense to show each transaction as a receipt that you could tear off when you wanted to delete it.

The User Experience

Our primary goal for Expenditure was for it to be the most efficient expense tracker app there is. We wanted to get you from point A to point B with the least amount of taps. The most important function is obviously to be able to add a new transaction. I’ve used most of the expense trackers in the app store and from my own experience the factor that decided if I kept using it or not was how easy it was to add a new transaction. Being a GTD geek myself I am a big fan of getting things out of your head as quickly as possible, and that is the main idea behind the way you add transactions to Expenditure.

I wanted Expenditure to be a tool to help people to get an expense “out of their head” as fast as possible. That meant creating a new workflow than the one found in most expense trackers. I didn’t want Expenditure to force people to categorize their transactions when they added them unless they wanted to, instead users should be able to add a transaction while they carry a bag of groceries in one hand, before they hurry off to the next shop. The idea is that you can just add a transaction and worry about categorizing it later. Basically it’s a 3-step workflow where you tap the “New transaction” button, enter the amount and then tap “Save transaction”.

The Icon

Designing the icon caused me some difficulty. It was really obvious from the beginning that the two, I wanted a clear connection between the app and the icon, to have a miniature ATM machine on the springboard. But what about the little screen? Most people who saw the icon liked it, but they thought that there should be something on the screen. In the perfect world the icon would be active (like the Calendar.app icon) and you would be able to see your current balance on the tiny screen in the icon. However since that wasn’t possible I had to think of something else, first we thought of showing the price of the app, but there were two reasons not to do that.

Firstly it would be of very little importance to the user after they had bought the app, it wouldn’t make much sense to be reminded of how much they paid for an app each time they looked at their springboard.

Secondly it wasn’t really possible since Expenditure is available in various countries with different currencies so each country would need to have each own icon. Then I thought there should be some number on the screen that would seem random but a number that would actually be a reference to something, kind of like an easter egg. I picked the number 499 because the original iPhone was priced at $499. In the beginning of the design process I kept the number of the screen but eventually I decided to remove it. First of all because your eyes were drawn to the number, the icon stood out in a bad way and on top of that the number wouldn´t make sense to a lot of people so I ended up removing it. It turned out I like the icon better with a “clean” screen.

If you have any questions or comments related to the design of this app, feel free to write in the comments below. I’ll try to answer them as good as possible.

Expenditure is available on the App Store.

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

Surprisingly, there is alot of evidence out there to suggest a major improvement to the iPad by the end of 2010. This timeline may seem a little quick for some (especially those that have recently bought a new iPad), however if we look at what we know about what technologies Apple is employing in it’s mobile hardware (namely the iPhone 4), it spells a hefty update to the iPad.

iOS 4.0

One of the major changes to the existing iPad, and future models is iOS 4.0. Currently 4.0 is only available in the iPhone 4, supporting technologies such as the gyroscope, retina display, and most importantly to this, the front facing camera.

Many have wondered why iOS 4.0 is not available for the iPad until Autumn 2010, most believe it is because Apple are focussing on bringing the software to the iPhone/iPod, however is that really valid? Think about the timelines… iPad launched in early April 2010, that came with iPhone OS 3.2, and merely 3 months later we have iOS 4.0 which isn’t ready for the iPad.

Apple iPad 1

Call me old fashioned, but I find that a little unusual. I’m sure 4.0 could run on an iPad, but unfortunately the current iPad model is missing some key hardware which makes 4.0 squeel.

People were also surprised by the lack of camera in the original iPad. Think about it though, Apple wouldn’t add a front facing camera to the iPad, launch FaceTime and jeopardise their “killer” featureset for their flagship mobile phone product. I’m sure this hardware was delayed from appearing on the iPad 1 for this very reason. Critically also, the only way to connect FaceTime chats is via a mobile phone call – the iPad, cannot make calls.

iPhone RAM

On top of this, the iPhone 4 comes with 512MB RAM, compared to the 256MB RAM that is in the current iPad (version 1). With multitasking a key feature of iOS 4.0, we should see an increase in the default amount of RAM in the iPad, upgraded to 512MB to bring it inline with it’s smaller cousin.

iPad 2

If I was a betting man, I believe we will see new iPad models in the near future, smoothly aligned with the iOS 4.x release later this Autumn. I’m expecting a front facing camera only, FaceTime, upgraded RAM, as well as gyroscope functionality. I’m less inclined to believe that a retina type display will come to the iPad so soon. It’s far easier for Apple to get that onto the new iPod in September, and I remain unconvinced that the larger display area needs that just yet.

And I thought it was just me, turns out – it’s not. After installing many a beta for iOS 4.0 my 3G was under performing massively. I thought to myself that it’s just the beta software blah blah blah, and got over it. That was until Mr Steve Jobs announced at WWDC that Apple would be shortly making available an iOS 4.0 gold candidate.

What I can happily report is that it’s not just me, as this video from flickr clearly shows (to reiterate, this video is not mine). It’s a great demonstration of an iPhone 3G running iOS4 and iOS3 side by side – the performance hit on 4.0 is significant:

Video showing iPhone 3G running iOS 4 and iOS 3

I shuddered to think what that a gold candidate at WWDC would be like. Beta 4 was performing pretty bad on my 3G, and to have a gold candidate ready (I thought) was a big surprise.

Symptoms I’m experiencing with the current 4.0 are:

• Slow performance on pretty much all applications
• Phone slows to a crawl after +1 day use, applications fail to open and crash to the home screen.
• Battery life on 3G has dropped significantly
• Text input applications frequently lag due to (what I assume) is spell check.

These are all moot points though for me, as I will hopefully be a proud owner of a iPhone 4 in two days time. Thank the Apple gods, as I’m close to throwing my new brick of a 3G at the wall.

Update

Something else I’d like to add is that in order for me to cope better with the speed decreases in software performance, I turned off 3G. The response from the iPhone 3G was much improved after this.

Also, iBooks is a slow dog on the 3G. Takes 15 seconds to load the app with 1 book in it, then another 15 secs to attempt to open a book (if the app doesn’t crash).

Bad times all round for iPhone 3G users (IMO).

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!

I don’t know about you, but my home is wireless. I have various devices hooking up to my home network: Macbook Pros, iPhones, Apple TV, PS3, hard drives etc… It’s great. The Apple TV is a good example actually of what I want to talk about here…

When you setup your AppleTV, you hook it up to your network (ethernet or wireless), go back to your Mac and “discover” it, and start synchronising your music, videos, photos with the device. From that point onwards the device has the ability to synchronise completely cable free between Mac and AppleTV over wireless.

So why, I wonder – after a few years now does the iPad, iPhone and iPod Touch continue to require a USB cable to sync up between the Mac and the device? They all have wireless cards in them. Sure you get some power charge for your device – but that should be optional.

Apple should be thinking beyond the cable on mobile devices – they are mobile after all. My iPhone for example, hooks upto my wireless network as soon as I enter my house – it knows the network is available, and uses it. For starters, Apple really need to look at this – I want my iPhone to call my Mac when it gets back home, see if anything is new (apps, music etc), and just sync them up.

Don’t ask me to sync – Just do it.

This is the one massive pain I have with the whole iTunes, iDevice thing. I have to physically connect the two together in order to get my content synced up. That is so last decade!

Cloud it up!

Let’s go further than that. If rumours are true, Apple are looking at cloud solutions for your iTunes catalogue – effectively storing your music and maybe video collection in the cloud. What we would see is a scenario where all of our iTunes centric devices call the cloud instead of calling Macs/PCs to sync up data.

Content sync over any network, wireless or mobile.

Your Mac/PC effectively steps away from being the central storage point for your content, the cloud takes that role – and all iTunes is is the content management system. Your iPad, iPod or iPhone then hooks into the cloud anywhere, and keep the data in sync.

I think music, photo and app synchronisation has a strong possibility of going in this direction, both on mobile networks and on wireless, but I highly doubt we’ll see video sync over anything other than wireless.

Again – Don’t ask, Just do!

This is the key point – especially for a so-called “user friendly” company such as Apple – Take the action of syncing away from the user. I shouldn’t have to care about that, I shouldn’t have to figure out if x piece of content is on Y device, and whether or not I can do something until they are synced.

It should all just happen. Kind of like when OS X knows a piece of data has changed on your Mac and adds a change point in Time Machine – it just does it. It doesn’t ask you.

The important thing is to give the user some flexibility to configure what they want to sync, and not let the user worry when they need to sync.

Apple has taken it upon themselves to do a number of things in the new developer agreement for iPhone OS 4.0 – you’ll have heard of one probably (that Apple Vs Adobe thing…), but in addition to cutting off the life blood of Adobe’s flash -> iPhone app, Apple have told developers that sharing user data for anything other than the specific services/functionality of the application itself is now strictly prohibited.

Interesting news indeed for iPhone developers. What this effectively means is that any applications that use third party APIs to send/receive data on behalf of the user need to reassess their applications. A few things this article says Apple state are:

1. All user data captured by an application must be for the sole use of that application only (like the Facebook app for example). The use of location based data for targeted advertising is strictly prohibited
2. You may only send user data to a third party which is specific to the services/functionality of your application and also only if the user has given consent. Example: User updates status on Twitter, presses a “Send” button to confirm sending of said tweet.
3. Sending device data to any third party for analysis is now strictly prohibited. Think mobile analysis services such as Flurry here. Presumably you can send this to yourself as the developer though.

So what does this all mean? Well there’s a few reasons for it.

iAds

When Apple launched the iPhone 4.0 OS they also launched a new developer API/service called iAds, which is mobile advertising from Apple. It appears that despite the fact Apple think that current mobile advertising “sucks”, they’re not going to stop the use of it from other services, but they will try and make them useless to ensure use of their service.

With the above in place, you as a developer can effectively only ever show ads from another service that rely on no user data at all. So non-targetted advertisements.

User Privacy

The above new restrictions actually works in favour for the consumer ultimately. It prohibits any kind of usage data being broadcast to anyone other than the developer themselves.

What you effectively have right now are a whole bunch of applications using third party services to analyse how you use your applications, and can share pretty much anything they wish with them. The above now stops that completely.

This does seem over extreme though. If we look at web applications, developers are free to integrate things such as Google Analytics to analyse device data such as browser used, OS, etc etc without individual user consent. Apple are effectively saying this is a no no, and only you yourself as the developer of the application can provide that service to yourself.

It also means thwarts companies like Flurry from leaking information about future Apple products. If no applications provide device data to third parties, no third parties can provide generic data back to the world, and find potential “new” or “unrecognised” devices.

If Apple are going to stop this though, they need to help developers out a bit in order to understand application usage. Right now, if you use no third party APIs to analyse usage of your application, you effectively know nothing. You get your download numbers from Apple, and that’s it.

Where’s the middle ground on this one? It seems mental that every developer individually will have to develop their own way to understand application usage. A definite gap here that needs to be filled.

Impact on Social Media applications

Apple specifically states in the new user agreement:

You may only provide or disclose User Data to third parties as necessary for providing services or functionality for the Application that collected the User Data, and then only if You receive express user consent.

Whilst their example around this is around posting a message to a third party, this could have other ramifications. Think about applications that on launch refresh a list of messages, or tweets for example. When an application does this, it has to exchange your user credentials with an API, therefore this could be classed as user data.

The impact of that therefore is applications that auto refresh data on load, or every x mins may now be restricted in doing that unless prior consent has been given by a user? It’s a minimal dev effort to add a consent in the app preferences, but it’s a hurdle which is not immediately apparent.

I can think of dozens of apps that I use myself which use my credentials to refresh various bits of data in apps without me saying “Yes, do it”. In addition though, will developers need to be granular on this, and specifically get consent for all different reasons why specific data is sent/received in an application? Or can a developer provide a catch all consent?

Existing Applications

I do wonder though about how this can be put into practise effectively for applications which currently exist, and may not necessarily update for 4.0. For example, if you have an app which uses third party services, and don’t update it to 4.0, it therefore doesn’t pass the noses of Apple again – can it remain on the store?

Are Apple going to goto a major effort to re-screen all existing applications? I doubt it. So they’re banking on all developers updating their apps, which is unlikely.

So I woke up today to the news that Twitter had acquired iPhone app Tweetie. Tweetie is probably the most successful Twitter client for iPhone out there, arguably the best depending on what you need, so it wasn’t really a surprise that Twitter chose Tweetie to purchase, and rebrand to “Twitter for iPhone”. In addition to this, it should also be no surprise that this happened after Twitter recently launched an official app for the Blackberry too.

A few things irk me about this whole deal though.

Twitter’s business model

I just don’t get it. They purchase an application from atebits which no doubt cost them a pretty penny (Twitter minus $$$), they hire the developer onto their mobile team (Twitter minus more $$$), and they reduce the cost of Tweetie from $2.99 to $0.00 (Twitter minus any future income from said purchase).

There’s something just not quite right about all that. The only way I can see this working is by Twitter somehow hoping that having official apps ultimately ensures Twitter usage, which allows them to resell stats/data from that.

The only other way they can possibly start earning from all of this is to stick ads in there.

Acquire Market-share App + Insert Advertising = $$$

That’ll be fine for a minute, until everyone hates the ads, and wants an ad-free experience like the good ol’ days, jumps ship to an ad-free third party app that they paid $2.99 for.

Of course, then they could include a subscription model, but that’s just a mental scenario right? … Right?!?!

If you ask me Twitter have waited far too long to introduce advertising, if that is their plan. As the days go by, more and more people come onto the service, and see an ad-free environment. Introducing that sometime in the future is going to be a bitter pill to swallow for a lot of users.

Look at Facebook, they have ads, most people don’t give a heck – because they did it ages ago when their user numbers were lower. I guarentee if they started over and did it tomorrow there would be a massive outcry. Whilst Facebook get a huge bashing this way and that, they’ve made some sound decisions from a business perspective in many areas, and continue to make it work.

Twitter however, is running out of time.

Twitter Ecosystem

In addition to doing all this, they’ve effectively sent a smashing tidal wave into the Twitter mobile app eco-system which they’ve helped so much in the past 2+ years. You know, that same eco-system which they thanked for helping Twitter become the service it is today.

By taking an app which easily is the most feature rich, has the best UX, and making it free, they’ve made third party developer’s biggest competitor an out right winner. Sales in apps like Twitterrific, Echofon et al are inevitably going to dwindle now, leaving them with no choice other than to get using advertising themselves in their apps to keep up, or to go elsewhere and find another source of revenue.

I know I’ve made my choice. For a couple of months I’ve pondered on whether or not to make Chirpie a full Twitter client for iPhone. Heck, I even started some development on it – but not any more. This deal by Twitter has put that fire out in a pinch. There’s literally no point in trying to compete with that – you can’t compete with great + free.

Exodus

This whole thing seems really badly timed. Twitter’s developer conference “Chirp” kicks off next week. What no better way to say a big “Thank You” to those developers than to cut their revenue stream in a matter of weeks. (Yeah, I said Thank You…. )

Like Fred Wilson said, maybe it’s time for developers to stop developing for Twitter, stop plugging gaps, as those gaps are gonna disappear! I think those gaps already started to go!

We’re going to see an exodus. We’ll lose competition from other Twitter clients, and ultimately Tweetie (or Twitter for iPhone/iPad) may suffer as a consequence. Only then can viable competition re-emurge. Like I said earlier, it’s pretty difficult to beat something that is great and free at the same time, but as soon as it’s not great anymore, it’s hello gold rush time!

In the meantime though, expect third party developers to go a bit quiet whilst they reassess how they move forward, and whether or not they continue developing Twitter clients for an eco-system which is slowly dying.

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!

Apple has today released the iPhone 3.1.2 version of their OS.

Details of the release included:

- Resolves sporadic issue that may cause iPhone to not wake from sleep
- Resolves intermittent issue that may interrupt cellular network services until restart
- Fixes bug that could cause occasional crash during video streaming

In addition to this there is also a AT&T carrier update file.

I’ve just installed it, there doesn’t seem to be much difference to anything else – maybe it’s snappier