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.

I’ve read a bit recently in the press around Foxconn and how some 12 (Note – this appears to change depending on your source of info, but I’m going with it from here) people have killed themselves so far this year (6 months at time of writing) at one factory alone in China. Being one of the major suppliers of hardware for Apple and others this was big news. It’s echoes of the GAP days where they were accused of running sweat shops to make those skinny jeans.

Suicide Average

Two days ago, Steve Jobs discussed at the All Things Digital conference that the suicide rate at a factory that large (some 400,000 workers) was actually lower than the U.S. average… good news indeed (for him and Apple). But how do they compare to other countries?

The stats above show the average annual suicide rate per 100,000 people. Foxconn’s stat works out at around 6 suicides per 100,000 people per year. Jobs was right in his statement that the rate of suicides at the Foxconn factory are below the U.S. average, and far below many other developed nations. Looking at it from this statistic alone is a positive response to the outcry, but is it that cut and dry?

Whilst Jobs is correct that for a factory with 400,000 employees has a low suicide rate compared to many nations, he needs to remember one thing – they’re all killing themselves at the same place – at the Foxconn campus. They’re not going home in despair and ending it all there, or elsewhere. This fact in itself should lend some weight to the argument that all is not happy at the factory itself.

Foxconn Facilities

Jobs other fact about Foxconn was around it’s facilities – they boast a swimming pool, hospital, cinema, multiple restaurants which again appears to prove Foxconn care about their employees. My argument here again though is that it’s not about that – I’ve been in jobs where we’ve had loads of so called “facilities” available to us, but I still hated the job, hated my boss, hated the company. I was in no way suicidal, but the facilities didn’t make my job any more enjoyable.

Investigators need to take a step back and look at employee treatment by management in a situation like this, and look at interpersonal issues. This isn’t about statistics, or facilities, or perks, or money it’s probably about employee treatment – by their managers and by their fellow employees.

Bullying

Is there an environment of bullying where the consequences of not meeting your targets is severely punished? With a factory population of 400,000 are groups, factions or gangs brewing? Are there so-called wars happening between groups? Perhaps it’s how you deal with issues like that that may stem the tide of copycat suicides?

I’m not saying that this is happening, but for me it’s just not as simple as saying they get paid more than average, and have a swimming pool so they should be happy! Something deeper could be happening that needs to be addressed.

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!

Today I received a brilliant email from an Indian consultancy firm – I assume to help me sell more copies of Chirpie for iPhone.

Here’s my response, I hope they like it:

My Email Response

So after the news broke this week that Apple’s new technology to seemlessly choose which graphics card to use in various situations on your 2010 MacBook Pro was not as great as we hoped, I figured I needed an app to tell me what graphics cards is active so that I can kill off the dedicated card when I’m on the move via finding out which app is potentially using it.

The problem users have, is that various applications, depending on the frameworks they use – may or may not fire off the dedicated graphics card, and therefore using more battery power than you want. For example, I highlighted yesterday that a small status bar application called CloudApp had OS X selecting the dedicated card, despite not doing anything with it. I had no way to tell other than by opening/closing the app and refreshing system profiler.

The impact of this ultimately is that your battery is being drained faster when it may not need to whilst dedicated graphics are enabled. So until Apple tweaks this functionality, we as users need an easy way to verify what graphics card is active. Enter GFXCheck.

GFXCheck In Action

GFXCheck is a simple status bar application (which doesn’t cause the dedicated graphics to be used btw…), it states “Integrated” or “Dedicated” in the status bar, and auto updates (currently at 10 second intervals).

As this is a 0.1 release, it should be treated as such, an early beta – with little functionality/flexibility at this time.

Ideas for the future are some indication in the menu which applications caused the dedicated card switch on, interval toggles etc.

I’d love your feedback if this is useful to you. It’s available to download here, and of course it’s free.

Compatability Notes: Snow Leopard 10.6 with Early 2010 MacBook Pro 15″ or 17″.

Yes, this is sad news indeed for me to have to report. My glorious new MacBook Pro i5 looks like it’s going back to the store tomorrow, after what seems like an imminent hard drive failure.

The machine was fine for the first 7ish days, random clicks from the hard drive every now and then (as noted here), but other than that there were no issues (oh, other than the battery life sucking because of Apple’s discreet graphics choices). But this morning, everything changed. Now the hard drive has started to grind, it’s very audible. Sure, it sounds like a hard drive, but not a hard drive in a MacBook Pro. This is my third MBP, and I know something is wrong.

Check out the video below to hear how it sounds right now. Wait until mid-way through when I open up iTunes… you can hear it grinding away on open, and close of the app. Up until today, the hard drive was silent when I did anything. Now it’s grinding when I simply switch tabs in a browser, or click a link on Twitter…

Sad times indeed. Back to the store tomorrow for a replacement.

[Update] I’d like to be clear right now what this article is about. It’s about Apple’s choice to get frameworks such as Core Image and OpenGL to direct which graphics card the Mac should use, and how by doing this, there have been some unusual cases whereby some applications cause the dedicated graphics card to be enabled, and continue to be enabled. This leads to a detrimental effect on battery life which is the exact opposite for putting this in place. With this in mind… read on.

I recently purchased on of the new MacBook Pro i5 models, one big reason was the lovely battery life of 8(ish) hours with the seamless graphics card switching from built-in to discrete. Apple’s theory being that you use the lower grade, lower power Intel graphics when you’re doing low graphics work on your Mac, like browsing, then switching to the full blow nVidia 330M card when you need to it to ratch out 3D graphics etc.

This all seemed like a massively great idea, and you can clearly see the benefits of it. However, it’s not perfect. As MacRumors and Engadget readers have reported, OS X’s decision on which graphics card to use in your new i5 or i7 MacBook Pro is far from ideal right now – and to back this up I have some rather alarming evidence.

OS X System Profiler Showing Integrated Graphics Running

Engadget gave some examples of where the OS seems to make poor choices around which graphics card to use, and showed some clear problems with it not switching back when that application was finished. The most unnerving observation of theirs was the use of discreet “power sucking” graphics for tiny desktop Twitter app, Tweetie.

Well friends, things are just about to get even worse.

When I read the Engadget article I though, hmmm lemme check out what the current active graphics card is, expecting the integrated on board chip to be the the graphics of choice. It wasn’t.

This lead me to confusion. I had literally just rebooted, and was browsing a couple of tabs with Chrome. I killed Chrome, but no change to the discrete graphics allocation. So I rebooted.

Cloud App

What I found when I rebooted my machine was really scary. I run this tiny status bar app called “CloudApp“, it’s a file sharing droplet. A brilliant little app, that only has a preference pane and a menu from the status bar. That’s gotta be integrated graphics right? No – OS X uses discrete graphics for this status bar application.

CloudApp's full interface

This isn’t the worst part I’m afraid. Because CloudApp is running all the time, discrete graphics are selected all the time. And because I run CloudApp from boot, I have discrete graphics selected pretty much 100% of the time.

OS X System Profiler after CloudApp is Launched

I cannot understand why Apple have made OS X choose discrete when this application

• A – Is hardly doing anything graphically intensive
• B – When it’s not doing anything, the discrete card is still selected.

Sure, it animates the cloud when I drag a file onto it (a two color silly animation), and also shows some progress indicators and delete icons within the menu itself, but that is it. I can hardly see where this app is using mucho Core Image or OpenGL to warrant the nVidia card and it’s full power!

So that’s where my 8 hours of battery life went, leaving the discrete graphics turned on, whilst my computer doesn’t need it. Come on Apple – you need to figure this one out!

[Update]

Interestingly, this is what @getcloudapp had to say on the matter:

CloudApp Twitter Response

A few days ago I purchased a new MacBook Pro 15″ Core i5. The machine is noticeably faster than my previous Core 2 Duo MBP, but I wanted to figure out just how fast compared to my 2 year old machine. To do this, I’ve run three pieces of test software, XBench, CineBench and GeekBench to get the clearest idea.

The Machines

My 2008 machine is as follows: 15″ Intel Core 2 Duo at 2.5Ghz, 4GB Ram, 200GB 7200RPM HD, NVidia 8600M 512 MB Graphics

My 2010 machine is as follows: 15″ Intel Core i5 at 2.53Ghz, 4GB Ram, 500GB 5400RPM HD, NVidia GeForce GT 330M 256MB Graphics. This machine is not the high resolution version.

Both machines ran Snow Leopard 10.6.3.

XBench Results

Clearly, as with all results you will see here – the 2010 MBP is faster. Specifically though, the thread and memory tests from XBench showed the biggest gains, with up to an 80% score improvement. Overall the score isn’t massively greater, but the upgraded CPU and Memory controller are obvious winners here.

GeekBench Results

With GeekBench the results were much the same as XBench, with CPU and Memory tests running away, with roughly 40% improvement over the 2008 model.

Cinebench Results

The 2010 MBP is obviously loving it’s new GeForce graphics card – the OpenGL results from Cinebench show a huge improvement in performance in that area, nearly 70%! The CPU test also showed massive improvement on the 2008 model, with the new Core i5 running at around 50% faster.

Conclusion

As with all Apple’s stated speed improvements you have to take the numbers with a grain of salt. The new Core i5 is clearly a faster more superior machine in many ways. Some other things to note about the 2010 model (which may have been there for the previous unibody MBP):

• The Super Drive no longer makes that horrible whizzy noise every time you wake the computer up from sleep. It only ever does that on boot. When it does it’s extremely quiet – vast improvement over the 2008 model.
• The Magsafe power adapter is now at a right angle.
• The magnetic latch that hold the lid closed is super strong!
• I’m noticing little ticks and clicks on random occasions – unsure if this is a big issue or not, but I’m keeping an eye on it.
• The LCD colour depth is massively richer than the 2008 model.
• The iSight camera appears to be much better quality than the 2008 model – unsubstantiated.
• When running on full fans the 2010 machine is noticeably quieter than its 2008 predecessor.

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.