But the time is perfect for a mobile conference in Brighton, and so I give you the Update conference: the human touch – iOS and beyond.

We have a stellar line-up of speakers from the worlds of iOS, web, and user experience gathering in Brighton at the beautiful Brighton Dome on September 5th, 2011, to present on and debate the hottest topics in mobile today (UX, platforms, and technologies). The talks range from iOS design, User Experience to mobile web, microcopy for mobile, education, and even a hands-on session where you'll be playing with physics engines and particles.

Also, following on the success of the Geek Ninja Battle Night earlier this year, we're going to have geek battles where representatives of different platforms (iOS, web, Android, Windows Phone 7, Blackberry, WebOS, etc.) and different development technologies (native, web, and cross-platform non-web solutions like Titanium, Corona, and Mono) have it out in geek battles.

These sessions will be punctuated by brief "tech beats" where the greats of iOS and web – including Jeff LaMarche, Marcus Zarra, Matt Gemmell, and Remy Sharp – will present their top tech tips.

Finally, the conference will end with an inspirational closing keynote from the multi-talented Mr. Brendan Dawes – who will remind us of things we've never seen. I can't wait!

Following the conference, on the 6th and 7th of September, we are holding in-depth, hands-on workshops on topics including HTML5 for mobile, iOS Design, Core Data, Core Animation, and OpenGL ES (with more to be announced soon, including a workshop on Appcelerator Titanium).

We also have a very special guest: one of the three founders of Apple (yes, there were three) – Ronald Wayne. In fact, we ran a contest last week and 5 lucky winners got free tickets to the conference by guessing our mystery guest.

In case you missed it, don't worry, for today, Friday, 24th June only, you can use the code WINNING to get 10% off the early-bird ticket price on any ticket.

Check out the Update 2011 web site (especially on an iPad or iPhone-tier device as it was designed iPad-first) and book your tickets today to get an additional 10% off the early-bird price!

See you in Brighton in September!

(Update is proud to be part of the Brighton Digital Festival and I'm very happy to be on the steering committee for the festival. September is going to be a great month to be a geek in Brighton!) :)

Mark had written a blog post about how his wife finds it difficult to use some iOS apps because they do not implement a means to increase text size:

I have a particular bee in my bonnet when it comes to accessibility, my wife is registered blind and I am constantly frustrated when she is unable see things (like text on a screen) especially when I know that this is avoidable… What I don’t understand is why there is no way to change font size system wide, or why app developers don’t provide that facility. Yes I know that you can switch on zooming, but honestly – have you tried using zooming on a phone?

So I dutifully retweeted Mark's tweet – as you do – and went on battling with cross-browser issues for the site (you really get to appreciate how wonderful an experience it is to develop for a single platform when you go back to battling with cross-platform development). I also told Mark that in Feathers, you can pinch-to-zoom the tweet text in the main text view. (Goodness knows, having as custom UI as it has, Feathers has a long way to go in terms of accessibility itself.) Mark responded with: "ha! so text scaling is doable. Thanks @aral! care to explain how so others can follow suite?"

OK, Mark (and other iOS devs), here goes: it's actually really easy.

You simply create a pinch gesture recognizer and attach it to a text view. Then you adjust the font size (and hopefully persist it for next time so the user doesn't have to keep doing it every time she uses your app).

It's about as much code as it is to explain in English, so here's a snippet from Feathers:

// Create a pinch gesture recognizer instance.
self.pinchGestureRecognizer = [[[UIPinchGestureRecognizer alloc] initWithTarget:self action:@selector(pinchGesture:)] autorelease];

// And add it to your text view.
[self.myTextView addGestureRecognizer:self.pinchGestureRecognizer];

// ... 

- (void)pinchGesture:(UIPinchGestureRecognizer *)gestureRecognizer
{
	NSLog(@"*** Pinch: Scale: %f Velocity: %f", gestureRecognizer.scale, gestureRecognizer.velocity);

	UIFont *font = self.myTextView.font;
	CGFloat pointSize = font.pointSize;
	NSString *fontName = font.fontName;

	pointSize = ((gestureRecognizer.velocity > 0) ? 1 : -1) * 1 + pointSize;

	if (pointSize < 13) pointSize = 13;
	if (pointSize > 42) pointSize = 42; 

	self.myTextView.font = [UIFont fontWithName:fontName size:pointSize];

	// Save the new font size in the user defaults.
        // (UserDefaults is my own wrapper around NSUserDefaults.)
	[[UserDefaults sharedUserDefaults] setFontSize:pointSize];
}

I hope this helps and I hope seeing how simple it is to implement will mean that more developers will implement this in their apps. Thanks for bringing it to my attention, Mark.

Twitter has been ablaze recently with revelations that iPhones and iPad 3Gs are secretly recording your every move, and have been doing so for about a year now.

According to Alasdair Allan and Pete Warden, the duo who made the discovery, the information is stored in a file that is backed up to your computer and survives handset upgrades:

What makes this issue worse is that the file is unencrypted and unprotected, and it's on any machine you've synched with your iOS device. It can also be easily accessed on the device itself if it falls into the wrong hands. Anybody with access to this file knows where you've been over the last year, since iOS 4 was released.

The duo also have an open source Mac app call iPhone Tracker that you can use to visualize your own location data. The screenshot at the top of this post is a portion of mine from this past year, limited to the area around the UK (the actual data ranges to the US and various Scandinavian countries).

According to Alasdair and Pete, there is no reason to believe that the data is being communicated to Apple. Still, though, the fact that Apple did not disclose that it was recording this information doesn't sit right with me even if it feels more like an oversight than a malicious act. I hope they will issue a statement on the matter to clear things up.

All that said, a lot of us do disclose our locations via services like Foursquare, Gowalla, and – for the masses – Facebook checkins. The difference, of course, is that you are aware of the fact and engage in it willingly.

Following my talks at the LOGIN, The Big M, NSConference, and Tweakers.net Developer Summit last month, .net magazine asked if I'd like to be the subject of their Reader Q&A section in their next issue and answer questions sent in via Twitter on life, UX, mobile, and everything. I informed them that yes, I'd be delighted to, and this whole adventure eventually resulted in a lovely email from Tanya at .net magazine with the questions that were tweeted in.

(Welcome if you're reading this from the link in the .net article, by the way. I hope you enjoyed it.)

Fast forward to this morning when I decided to write my replies using only my new iPad 2 to see how it holds up to some — albeit lightweight — real-world use. As I do, I will be writing this post, also on my iPad, using the free WordPress app.

The first hurdle (or "even the best web apps still have an uphill struggle when it comes to competing with native user experiences")

The first thing I had to do was to locate Tanya's email and copy the questions from it to Pages. After this, I would pick the questions I wanted to answer, delete the others, and start entering my answers after each of the questions. An easy enough task. Or so you would think.

The first problem was the Mail app on iPad when used with a GMail account via IMAP: it is horrible at searching for existing messages that it hasn't downloaded (ones on the server). So I had to do what I usually have to do, which is to fire up the GMail site in Mobile Safari. This let me find the message but — get this — I couldn't select the whole thing. There was just no way I could make the message scroll while selecting. A basic usability failure if ever there was one. I finally had to resort to using Send To Dropbox to forward the email to Dropbox where, using the Dropbox iPad app, I could select the contents to paste into Pages.

Pages for iPad

For the most part, Pages for iPad worked like a charm. My only complaint is that the word count feature is so well hidden that I actually thought it didn't have one (and cooked up a quick app to scratch my own itch before finding it).

How's that for radical contextualization? WordPress app issues.

Writing this post in the WordPress app wasn't entirely hassle-free either.

The first gotcha was a usability issue. When I started a new post, after entering the title, I tapped into the post body section and the header information entirely disappeared off the top of the screen. I would not have had a problem with that interaction — and, in fact, would have quite enjoyed the additional writing space it provided — if it had provided me with a cue — a landmark — to denote where the information went and a means by which I could get it back. Without either of those, I was left wondering whether it was a bug and I had lost the information altogether. It made me tap off of the text view to see if something had gone wrong. When the text view lost focus, the header information returned, and I was reassured that I hadn't lost it.

Another usability issue was more concerning: I wasn't sure, as I started typing my post, whether it was being auto-saved. This led me to feeling insecure and I started searching for a way to save. As I stumbled through the interface, I found the options screen where I set the status of the post to Draft and hit the save button. A quick test confirmed that the WordPress app doesn't auto-save as you're typing so I keep hitting the Update button every so often, which removes the editor and thereby interrupts my writing flow.

I would implement quite a rigorous auto-save since there's nothing worse than losing data (and it's an operating system expectation on iOS).

Adding images to my blog post

One other usability issue I had was with adding images to my post. The buttons for adding images are at the bottom of the compose window and are covered by the keyboard when you are typing. For one thing, this led me initially to question if the functionality existed at all since I hadn't noticed them prior to clicking in the text box to edit my post. Then, it meant that I had to once more interrupt my writing flow to add images by first manually making the keyboard lose focus, then adding the image, then tapping in the text box to return to editing the text.

Once I realised where to find and how to use the buttons, I was unimpressed by the functionality. It adds some horrible code either above or below your content (instead of where you are in the document).

I would redesign the interface so that the toolbar buttons were in a keyboard extension and so the writing area filled up the entire remaining space above the keyboard in both orientations.

Also, while taking screenshots on my iPad was simple enough (if a bit unergonomic due to the distance between the two buttons that have to be pressed in tandem), I found the simple task of annotating and cropping them to be a big issue. To cut a long story of several fruitless app purchases short, I ended up using the free PhotoPad app which was one of the few I could find that actually showed me the exact image dimensions I was cropping to.

A general UX gripe with the iPad: Undo

Shake to undo works like a charm on the iPhone. This is a tiny device that fits into the palm of one hand. Shaking it involves almost no effort at all and is an ergonomically-sound gesture. Not so with the iPad.

The iPad is the size of about six iPhone 4 placed side-by-side and thus has very different human factors considerations. Lifting this baby off your lap and shaking it wildly from side to side every time you want to undo a typo will, at best, make you look mentally unstable if carried out in a public space.

Apple must implement a better gesture for this important gesture in future versions of iOS for the iPad. I recommend a three-finger swipe to the left (with a three-finger right swipe as redo). It's currently not mapped to any universal gesture on the OS and is relatively effortless to perform and can be layered in as an alternative gesture while still supporting shake-to-undo to transition iPhone users to the iPad.

Since writing this, I've been alerted on Twitter that there is an Undo button on the iPad's symbol/number keyboard but it's not ideal; hidden away like that. I've had an iPad since the beginning and I never noticed it.

Blogsy

I finally gave up on the WordPress app and I'm typing this in Blogsy. Goodness knows it has its own limitations (for example, the code and "WYSIWYG" views look identical initially, making it impossible to know which mode you're in) but it is still light years ahead of the official WordPress app and has lots of potential (or is at least a step in the right direction).

A land of opportunity

So, is the iPad 2 fit for "real work?" Depends. On the app, that is. And what you call work.

On the one hand, you have awesome apps like Garage Band, Pages, Keynote, and Dropbox that you can be really productive with. On the other, there are lots of half-baked apps out there that may have potential but are, quite frankly, rather limited in professional features.

It feels to me like most apps on the iPad have a long way to go before users can be as productive as they are with a Mac. Far from being a negative aspect, this means that there is lots of opportunity here (for app developers who grok UX) to create successful apps.

Tweaky is my little Mac app that lets you enable the so-called "Super Secret preferences" in Twitter for Mac that are otherwise only available to people who purchased Tweetie for Mac via the MacHeist bundle (or who are comfortable with setting preferences manually via Terminal). You can download it via my web site but you won't be seeing it on the Mac App Store anytime soon.

The reasons? Twofold.

Firstly, it apparently "provides a limited set of features and functionality to users" and thus does not comply with section 2.8 in the App Store Review Guidelines which states:

2.8 Apps that are not very useful or do not provide any lasting entertainment value may be rejected

So, basically, Apple thinks that Tweaky is not useful. The 3,000 or so people who downloaded it off my blog based simply on my tweets probably disagree. But that's beside the point. It's Apple's playground and they can choose who they want to allow in. I'm cool with that. As long as there are still other ways of getting software onto your Mac, that is.

The second reason? The application "is creating files in the incorrect directories." This apparently violates section 2.30 of the App Store Review Guidelines, which states:

2.30 Apps that do not comply with the Mac OS X File System documentation will be rejected

So how was I violating the Mac OS X File System documentation?

The application is creating files or writing to <~/Library/…com.twitter.twitter-mac.plist>

In other words, by changing Twitter for Mac's preferences. Unfortunately, that is what Tweaky does! :)

The funny thing, of course, is that by allowing people full access to Twitter for Mac's features, Tweaky actually makes Twitter for Mac compliant with Apple's App Store policies (Twitter for Mac currently isn't in compliance since it has hidden features that are only available to a subset of users and unlocked via external means.)

Oh well, I never really expected them to approve it but I would have been positively surprised if they had.

Ultimately, though, I do hope that there will never come a time when the only way to install apps on your Mac is via the App Store. If that ever happens – as painful as it may be – I will switch to Linux.

Like a number of installers I've encountered, the Application Tools 1.1 installer fails if it cannot find Xcode in the /Developer folder. In my case, I already had a /Developer folder with a few system items in it but Xcode was in a separate folder off the root of my drive called /Xcode3.2.5iOS4.2.

To cut a long story short, I merely renamed /Developer to /Developer-temp and the Xcode folder to /Developer, ran the installer, and then named the two folders back again (you'll need to use sudo mv /Developer /Developer-temp and enter your system password).

Update 12 June, 2011: Version 1.3 released. Fixes the missing @ sign bug on original and /via slashtag quote tweet styles. Download now.

It's a little past 5AM and I've been working on this for quite a few hours so apologies in advance if this post sounds slightly groggy. Allow me to introduce you to, Tweaky for Mac…

Tweaky lets you use the Super Secret preferences in Twitter for Mac which are otherwise only available to people who purchased the earlier version (when it was called Tweetie for Mac) through the MacHeist nanoBundle.

These Super Secret preferences actually include a number of important usability enhancements and should really have been made available in the core app. Tweaky fixes that oversight.

Download

Download Tweaky (version 1.3, for OS X 10.6+, 848KB, .dmg).

History

• Version 1.3: Fixes the missing @ sign bug on original and /via slashtag quote tweet styles. Tested with Twitter for Mac version 2.1.1.
• Version 1.2: Supports the show full names and quote tweet style preferences in Twitter for Mac version 2.0.2.
• Version 1.1.5: Updated to support the changed link color preference in Twitter for Mac version 2.0.2
• Version 1.1: no functionality changes, just fixed a few typos in the Help to make my 5AM self seem slightly more articulate.

The settings

• User timeline avatar derepeater: Only shows a user's avatar once if they have a string of tweets on your timeline. Also means that you only see a user's avatar only once when viewing just their tweets.
• Scroll over window will bring to front: If the Twitter window is partially obscured under other windows and you scroll the Twitter feed, the Twitter window will be brought to the front.
• Type anywhere: when the Twitter app has focus, typing will begin a new tweet.
• Hide app in background: When the app loses focus, it's hidden in the background (instead of potentially being partially obscured by other apps).
• Compose windows float over all windows: the little windows your write your tweets on appear in front of all other windows at all times.
• ESC closes compose windows: does what it says on the tin. :)
• Link color: sets the color that links in tweets are displayed in. Personally, I like the default color but feel free to Bubblegum Pink if that floats your boat. :)

How it works

It's really not rocket science. The "Super Secret" preferences are just app preferences. You can easily set them using the defaults app in Terminal if you're not Terminal-phobic (e.g., defaults write com.twitter.twitter-mac ESCClosesComposeWindow 1). However, since many people are, and since these preferences really do make the app more usable, I thought it would benefit a lot of non-geeky folks to have an easy-to-use graphical interface.

That, and after two years of working on iOS apps, I wanted to make a Mac app :)

(And I'm pretty sure Loren and the other Twitter folk will make the features available to everyone soon enough anyway.)

More goodies

If you liked Tweaky, check out some of the other stuff I'm working on:

I've got a cute little iPhone app called Feathers for decorating your tweets with proper punctuation, symbols, emoticons, and different text styles.

If you want to learn how to make iPhone and iPad apps, check out the workshops I'm teaching in the UK with Geek Ninja Factory.

Get in touch!

If you have any questions or comments, feel free to leave a comment here or to follow me on Twitter.

Hope you enjoy playing with Tweaky!

Credit

The cute little bird is from the Fluzzy Twitter Icon Set and the arrow I used in the background image of the disk image is by Sander Baumann.

I love to teach and I had a blast this year while teaching my 3-Day iOS SDK course for iPhone and iPad at venues around the world. And, based on the feedback, the students had a blast too.

So, for 2011, I'm taking the training to a new level: introducing Geek Ninja Factory.

Via Geek Ninja Factory, I will be teaching two courses in 2011 (and I have some other surprises planned too). These are a new 1-Day course called the iOS Mojo Dojo and a 3-Day course titled iOS SDK Dojo.

The 1-Day iOS Mojo Dojo starts out by introducing the iOS platform, including the various devices/generations and lays out the design limits and features of each, tying them in to the various frameworks in the iOS SDK. You get handy design-related tips and tricks before we move on to hands-on examples that compare and contrast the major tools and technologies for developing iOS apps. These include web standards (HTML5, CSS3, JavaScript), web + iOS-specific frameworks (JQTouch), creating native apps using web technologies and PhoneGap, using JavaScript to create native apps with native components (Appcelerator Titanium and NimbleKit), other technologies (Corona, Unity3D, etc.) and a quick glance at native development with the iOS SDK (Objective-C and Cocoa Touch with the Xcode tools).

The aim of the 1-Day course is to introduce you to the iOS platform and give you a wide overview of designing and developing for it so that you can make intelligent design and technology choices when embarking on your next app.

The 3-Day iOS SDK Dojo, in contrast, aims to give you a solid foundation in developing native iOS applications for iPhone and iPad using the iOS SDK (Objective-C and Cocoa Touch, as well as the Xcode toolset, including Interface Builder and Instruments). By the end of the course, you will have the knowledge you need to build your first native app. Far more information on the 3-Day course is available on the Geek Ninja Factory web site.

The next courses are in January 2011 and seating is limited to 12 people.

Check them out today and sign up to become an iOS Ninja in 2011 at Geek Ninja Factory.

PS. As a reader of my blog, here are two special codes for you: use the magic code NINJAWIN to get £100 off the 3-Day iOS SDK Dojo and the magic code NINJAMOJO to get £25 off the 1-Day iOS Mojo Dojo.

But first things, first, here's the error I received while trying to compile one of the early projects from my iOS SDK workshop: "error: there is no SDK with the name or path 'iphoneos4.1'"

Also, when I looked under the Overview drop-down in Xcode, I noticed that the settings there were entirely wrong:

To fix the Base SDK Missing error (once and for all), I opened up the Project Settings (Project &rarrow; Edit Project Settings) and, under the Build tab, set the Base SDK setting to "Latest iOS (currently set to iOS 4.2)".

Closing the Project Settings, however, did not update the Overview drop-down and I could only build for the device, not the simulator.

To fix this, I had to restart Xcode.

Update: You don't have to restart Xcode: closing the project and reopening it also fixes it. Thanks to Amar Kulo for the heads up.

After restarting Xcode, the Overview drop-down displayed the correct information and I was up and running again.

I hope this helps you if you encounter the same issue after upgrading to Xcode 3.2.5 and iOS SDK 4.2.

Happy coding!

Update: The core frameworks will also appear to be missing initially. This, too, will be fixed after you re-open the project so don't go through the effort of re-importing them.

Update: Also, if in 4.1, you added the iOS SDK 4.1 workaround for the CGPDFContext.h:60:23: error: expected function body after function declarator error, you need to remove this or you will get a warning: '__IPHONE_OS_VERSION_MIN_REQUIRED' macro redefined.

If you get this warning, check whether you added the -D__IPHONE_OS_VERSION_MIN_REQUIRED=040100 flag to the Other C Flags in Project Settings or whether you added the two defines listed in my blog post, above, in the Prefix.pch file for your project. Remove the flag and/or the defines to remove the warning.

Update: I also had thousands of warnings on a project that uses the Google Toolbox for Mac HTTP Fetcher and had the -Xclang -fobjc-nonfragile-abi2 flag set in the project (this allows you to skip @synthesize statements and implicitly creates the, umm, implicit accessors). Removing the compiler flag removed the 20,000 or so warnings also. For the record, I consider this a WIN.

(Since I usually have several versions of Xcode on my machine at the same time, I've taken to installing them off the root in descriptive folders – e.g., Xcode3.2.4iOS4.1, etc.)

A cursory glance through the installer code revealed that the installer doesn't appear to need to do anything with Xcode, it just checks whether it exists (at the default location). Specifically, it checks if Xcode is installed by checking for the existence of /Developer/Applications/Xcode.app and if the iOS SDK is installed by checking for /Developer/Platforms/iPhoneOS.platform. So, as a workaround, I rebuilt the packager from source and removed the two requirements. Lo and behold, the installer ran beautifully.

It's a niche issue (most people have Xcode installed in the default location), and I know that the PhoneGap team are aware of it, Dave Johnson was looking into it, and Shazron Abdullah just posted a gist on the issue, so I'm sure that a fix will be out shortly.

In the meanwhile, if you're affected by the issue, you can grab my installer (.zip; 356KB), which doesn't have the two checks in it, and try using that instead.