• iPhone SDK 3.1 with XCode 3.2.1
• iPhone SDK 3.1.3 with XCode 3.2.1
• iPhone SDK 3.2 with Xcode 3.2.2
• iPhone SDK 4.0 with Xcode 3.2.3

It seems the industry wires and the social media are ablaze with the supposedly breaking story that iOS devices are tracking your every movement

Alasdair Allan and Pete Warden announced this at Where2.0 and also made a nifty little application that will visualise the data that is stored in this sqllite database, mine for the UK is above.

One point on the big brother aspect of this scare mongering, that some of the press have taken to, is that the network operators have had access to this information for years and as they know exactly where their cell towers are will be able to locate any phone simply. This is why Google, Skyhook wireless and Apple are going through growing pains as they map this information out via vans, mobile handsets etc, when really the network operators should have cashed in their position and sold it to these parties, that are now building up better databases and it just takes a little time before the network operators value in this location information becomes a footnote.

What I do think is incorrect is that Apple have left this information unencrypted, it shouldn’t really come as a surprise this information exists on the phone, all the tutorials and information Apple release about CoreLocation hint to its existence to achieve course cell positioning and fast location lookups.

MBProgressHUD is an iPhone drop-in class that displays a translucent HUD with a progress indicator and some optional labels while work is being done in a background thread. The HUD is meant as a replacement for the undocumented, private UIKit UIProgressHUD with some additional features.

Sharekit

If you only need to post updates to Twitter or Facebook or any of the other supported services, then Sharekit is almost drag and drop  and works extremely well on both the iPad and iPhone

Facebook iOS SDK

If you need to do more with your application than simply just posting to Facebook, then you are likely to want to go deeper and make use of the Facebook iOS SDK, which provides support for both the older Facebook connect API and the latest Graph API

MGTwitterEngine

Again as with Facebook if your app needs to go that bit further with its Twitter integration take a look at Matt Gemmells excellent twitter library. This library will work equally as well for a Cocoa app for the Mac app store

JSONKit

A very high performance JSON parsing library for Cocoa apps

ASIHttpRequest

ASIHTTPRequest is an easy to use wrapper around the CFNetwork API that makes some of the more tedious aspects of communicating with web servers easier. It is written in Objective-C and works in both Mac OS X and iPhone applications.

Some of the main advantages of ASIHttpRequest is its ability to cache responses, have multiple delegates for differing web calls, throttling of connections and easy web form data submission.

Google Data APIs

Integration with Google services made easy, it includes support for

• Google Analytics
• Google Base
• Blogger
• Book Search
• Calendar
• Code Search
• Contacts
• Documents List
• Finance
• Health
• Maps (deprecated)
• Picasa Web Albums
• Spreadsheets
• Translator Toolkit
• Webmaster Tools
• YouTube

Flurry

Rolling your own analytics can be tedious so make use of this library and you can have meaningful stats in your application quickly, it is as easy as integrating with Google analytics

gtm-oauth

The Google Toolbox for Mac OAuth Controllers make it easy for Cocoa applications to sign in to services using OAuth for authentication and authorization.

Features include:

• Complete embedded user interface using WebKit
• Works with Google APIs and with any standard OAuth provider
• Handles sign-in, keychain storage of authorization token, and signing of requests
• Independent of other projects

CHCSVParser

For those times when you were told there was an API only to wake from your beautiful RESTful dreams to discover you have to parse a monster csv file, still it could be worse it could be SOAP

SudzC

In which case SudzC can sometimes help when you really do have no option but to integrate with a SOAP service

Tapku and three20

Both of these libraries provide very useful UI components that either mimick existing Apple applications or provide easy UIComponents to make use of

MTLogging

Whilst the debugger is always preferred, having a console log of whats happened is both useful and quick, MTLogging combines three popular projects to super charge your console window

MapKitDragAndDrop

iOS/iPhone OS MapKit sample for draggable AnnotationView with CoreAnimation pin lift/drop/bounce effects.

I am sure there are loads of popular ones that I have missed out, if theres any you find really useful please let me know!

Romain Nurik posted an excellent article today on why you need to hand edit layouts for Android rather than using a WYSIWIG tool

First off, there will be some obvious bias in this post. I have been very fortunate in my working career to work with some truly great product managers, designers and artists on mobile applications and so for the benefit of the app consuming public none of my frankly brilliant crap UIs have ever seen the light of day. I do however still look forward to the day where by I can put a cheat mode into one of our own applications that resorts to developer place holder graphics! Some great examples of what games look like before an artist breathes on them can be found on this thread at Toucharcade

If you take the same view point as me, that to make a truly decent user experience for a given platform especially on mobile,  then you need to understand the technicalities and nuances of developing for that platform. A great example of this would be the difference in the back metaphor on various devices,  on Blackberry and Android you have a dedicated back button, iOS the use of UINavigationController and for Java mobile devices the use of soft keys and context menus.

Knowing these interface cues is why there needs to be a close interaction between developer and designer. It makes sense if a fast utility application is required to make  sure standardised controls of the platform are used where possible  (ie ContextMenus on Android vs UIActionSheet on iOS vs Softkey driven menus on Java based devices) otherwise a lot of development time can be expended on making custom UI controls that may or may not be necessary, if all stakeholders are aware of what components are available on a given platform. For this reason alone it is worth at least having a WYSIWIG  editor so that designers who may be new to a platform (Java MIDP2 is younger than publishing to the web, and Android, iOS, WebOS are relatively new, let alone the even newer platforms mobile designers will have to contend with in the future ie Meego, Bada etc etc) have the ability to experiment with the UI widgets that are available for a platform and produce mockup guis that a developer can then bring to life!

The other area where at least having a fast preview of changes to the UI code is where a WYSIWIG editor can really help, or at the very least a very fast way of previewing on a decent simulator, in fact it has to be said MicroEmu perhaps leads the way here when it comes to very rapidly changing screen sizes

Where both Android and iOS have succeeded in my view is that they have made the information on what designers have to work with is far more readabily accesible. A simple Google search for icon design guidelines for three popular platforms will tell you a lot, bearing in mind with the current trend of app stores the icon is the first piece of information that you are likely to convey to your user therefore it pays to have the perfect dimensions. For example try the following searches

“Blackberry icon sizes”

“iOS icon sizes”

“Android icon sizes”

“Nokia icon sizes”

Having to dig for this sort of information is what in the future will infuriate both developers and designers as new devices, screen sizes and user interactions are released into the market

Therefore until Android becomes as set in stone as HTML/CSS I don’t believe many designers have the time to teach themselves another XML based layout manager and need to work closely with developers and hopefully have some sort of ability to experiment with UI metaphors without a developers assistance. This is something which a WYSIWYG tool whilst most likely constrained to a single resolution at least provides. Once this point is reached, much like a sane server admin will never let a developer loose on production infrastructure without supervision, a designer will not let the developers near the UI without their guiding light

However until that day I concur with Roman a hand coded UI will be superior this is still true even with WYSIWIG tools such as Interface builder on iOS

• Icon.png – Home screen icon for iPhone 3 (57×57)
• Icon@2x.png – Home screen icon for iPhone 4 (114×114)
• Icon-72.png – Home screen icon for iPad (72×72)

• Icon-Small.png - Settings/Spotlight icon for iPhone 3 (29×29)
• Icon-Small@2x.png – Settings/Spotlight icon for iPhone 4 (58×58)
• Icon-Small-50.png – Spotlight icon for iPad (50×50)

• iTunesArtwork – Icon for iTunes AdHoc distribution (512×512)

Had a request to make the work flow a little easier heres those icons in descending size order

• iTunesArtwork – Icon for iTunes AdHoc distribution (512×512)
• Icon@2x.png – Home screen icon for iPhone 4 (114×114)
• Icon-72.png – Home screen icon for iPad (72×72)
• Icon-Small@2x.png – Settings/Spotlight icon for iPhone 4 (58×58)
• Icon.png – Home screen icon for iPhone 3 (57×57)
• Icon-Small-50.png – Spotlight icon for iPad (50×50)
• Icon-Small.png - Settings/Spotlight icon for iPhone 3 (29×29)

http://android-developers.blogspot.com/2010/06/future-proofing-your-app.html

The aapt tip for dumping out what features your app requires was certainly new to me!

For anyone who is not aware or newer to Android, I always feel the need to highlight the Draw 9-patch technique as something that  will help immensely when dealing with differing screensizes, and I am sure those that are using vanilla UIImage on iOS devices will come to envy in the future when supporting multiple screen sizes in an easy way that does not require code changes.

The following session video from Google IO on supporting multiple handsets almost goes into far too much detail and makes this problem space seem much harder than it actually is! However I and as am sure many, fully appreciate the highlighting of potential pitfalls that we may run into, rather than having to discover some of these hazards at some point through the development cycle of an application!

For those envious iPhone developers of NinePatch images you may wish to check out the following project http://blog.tortuga22.com/2010/05/31/announcing-tortuga-22-ninepatch/

Steve if you believe replied to emails sent stating

“We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.”

Far greater than how something has been written is the problem of shovelware, whilst it allows the store to quote very large numbers of applications compared to the competitors of the app store, how many companies are submitting multiple applications every day of debatable quality or at least that could be combined together. Some of the worst offending companies have been removed from the developer program

So ignoring the arguments on whether what Apple is doing with the new terms in the sdk agreement is right or wrong and what effect it has on native cross platform app development. I was thinking what else they could do for the submission process for their platform if the stated aim is simply to raise the standard of apps, regardless of how they are produced.

One of the reasons for me that the app store has been a success for developers, has been how much easier it is to make an application available to the paid market globally, unfortunately this has meant the friction barrier is so low, that it allows for shovelware to be a positive revenue generating tatic. Thankfully this is actually quite an easy one to stop by implementing a cost barrier like Palm have on their app catalog, quite simply if you wish to make an application available there is a $50 cost. This simple barrier to entry means if the developer doesn’t believe their application is going to return at least $50 they will be unlikely to submit it or burn through cash and be stopped that way.

Theres a great set of videos explaining buffer overflow attacks starting here
with a hands on demo of return to libc hacks here

Available on iTunes:

http://bit.ly/knowcolor

Amazing how after a few days away from the computer at Xmas can lead to inspiration for a small game, so after I had decided it had been too long since I had made a little fun game and as I wanted to play this myself! I got started, a few days later Know Color was born!

Subsequent posts will show the early stages of this game before there was any artwork and it looked very very different, and some notes on porting this game concept to other platforms.

The app store approval time was truly amazing, with this game being made available for sale 24 hours after submission, so thank you Apple!

For now though here is an app description and some visuals of the game:

Prove you’re smart and know color. Can you beat the Professor and your friends?

A game of speed and skill where you have to select the correct option matching the Professor’s instructions as quickly and accurately as you can. Post your high score to Facebook and Twitter and dare your friends to beat you! Who is the smartest of you all?

In 50 seconds score as high you can, you score one point for each correct answer but will lose 3 points if you answer incorrectly so be careful!

View a video on YouTube:

You can find some images of the game here

http://www.cocos2d-iphone.org/about

Features include

• Scene management (workflow)
• Transitions between scenes
• Sprites and Sprite Sheets
• Effects: Lens, Ripple, Waves, Liquid, Twirl, etc.
• Actions (behaviors):
  • Trasformation Actions: Move, Rotate, Scale, Jump, etc.
  • Composable actions: Sequence, Spawn, Repeat, Reverse
  • Ease Actions: Exp, Sin, Cubic, etc.
  • Misc actions: CallFunc, OrbitCamera
• Basic menus and buttons
• Integrated physics engine (both Box2d and Chipmunk)
• Particle system
• Text rendering support (variable and fixed width fonts)
• Texture Atlas support
• Tile Map support
• Parallax scrolling support
• Sound support
• Streak Motion support
• High Score server (Cocos Live)
• Touch/Accelerometer support
• Portrait and Landscape mode
• Integrated Pause/Resume
• Fast Textures:Supports PVRTC textures, 16-bit textures and 32-bit textures
• Language: objective-c
• Open Source: Compatible with open and closed source projects
• OpenGL ES 1.1 based

Once you have checked out the latest version from here like so

svn checkout http://cocos2d-iphone.googlecode.com/svn/trunk/ cocos2d-iphone-read-only

navigate to the directory cocos2d-iphone and run the following

. ./install_template.sh

This will install the cocos2d template into xcode for you, which makes setting up and using this framework even easier!
Great demos are available from within the project itself to learn from as well as the wiki documentation which can be found here

• Hello World
• Hello Actions
• Hello Events

Some full open source examples are available from the following links

• Tweejump
• Gorillas
• Thrown
• Grabbed

The greatest part for me personally is the heavy lifting that chipmunk can do for you regarding collisions and physics for your game, the best tutorial I have found for using it is available here

http://www.alexandre-gomes.com/articles/chipmunk/