Last Thursday at 5pm I joined around 100 other geeks at Parse By The Sea – an all night ‘hackathon’ and part of the Brighton Digital Festival.
Parse by the Sea Hackathon
What is a ‘Hackathon’?
The idea behind a hackathon is to work with other developers to code/hack new digital features or product prototypes in a short (and intense) period of time. Hackathons will often run overnight and developers work together to maintain their focus and momentum with the help of caffeinated and alcoholic drinks! Not all that healthy but strangely productive. After a night of coding all teams present their hacks the next morning.
Caffeinated drinks!
Parse By The Sea
Parse By The Sea was organised and hosted by Facebook and took place inside the Brighton Dome last Thursday and Friday. The event was sponsored by Parse, Unity, Pusher, Deezer and Withings. There was no fixed brief for the hack apart from a mobile theme. But all of the sponsors were offering great tech prizes to the best hacks that used their APIs with an overall winners prize from Facebook and Parse.
I’ve never attended a hackathon before but have recently discovered just how popular they are. Internally Facebook hosts a hackathon every 6 weeks and gives it’s in-house software engineers a chance to hack away on new ideas that apparently often end up becoming fully fledged features on Facebook.com or in their various mobile apps.
With Parse By The Sea Facebook decided to open up their regular hack to external Developers: Developers from all around the UK and Europe, Computer Science Students and in-house Facebook Software Engineers.
There was a fairly even mix of iOS, Android, Unity, Web and Server-Side Developers. In advance of the Hackathon Facebook setup a group for us all where we could start to share ideas and build teams. The ideas started to flow in and initial teams started to form.
An Idea and a Team
Initially I had an idea to build a multiplayer iOS word game using Parse and Pusher where four players would all compete with the same set of letters to form the longest words. All players would see each others game points in realtime creating a very competitive and fun multiplayer game. I was initially quite fixed on this idea. But you’ve only got about 14 hours of code time so an idea like this was optimistic/ambitious.
After the various sponsors had presented their APIs it was 7pm and dinner was served. I started to mingle with other developers at the Hack and met fellow iOS Developer Ben and Android Whizz Jose – also a big thanks to Adam from Pusher who knocked up a simple Node.js server-side for us in about 5 minutes!
Ben and Jose (taken from/by our app!)
We were chatting about our various hack ideas and one of Ben’s ideas was to create a photo app where multiple users could contribute photos to shared albums. This idea really resonated with me. I’m half American and every few years I travel the the US to catch up with my extensive US family. At these family reunions there are often 50 or more family members. Everyone is taking snaps on their smart phones and capturing these special moments. But then what? How do we share these photos just with the family members? There are a number of ways to do this with tools like Dropbox or uploading the photos to Facebook and assigning access permissions. But both of these methods requires all members of the family to sign up to the respective service and both methods require a certain amount of effort by all the photographers to share.
So the idea then developed into an app that would work on both iOS and Android. An app which would connect multiple users and enable them to create and contribute to multiple shared photo albums. As users took photos those photos would update across all connected user’s devices in realtime (instantly).
And that’s just what we built in 14 hours. 2 native apps (iOS and Android) that shared data via Parse and hooked into a simple Pusher backend to instantly stream in new photos as soon as they were saved to Parse. We initially named the app Shared Photos which then became Frictionless Photo Sharing – neither were particularly inspiring names but hey it was 5am FFS!
Frictionless Photo Sharing running on iOS
I’d never met Ben and Jose before the Facebook Hack but we really connected and gelled as a team. It was amazing to work with such talented Developers and the enthusiasm for our product stayed alive throughout the night. None of us got a wink of sleep! There were beds to sleep in and as we passed 4am, 5am, 6am the urge to sleep got greater. But there was a communal sense that we were building something super cool and we all wanted to make it as good as it could be by day break. So we just kept on ploughing on, beer, Redbull and jokes aflowing 
4am…
At one point Jose chucked some tenuous(!) link to the Deezer API into the Android version of the app – connecting a music track to each photo just for kicks – well anything to add a shot at more API prizes! The guys next to us were building something in Unity and we considered adding a few pics of their app into ours just to make the Unity connection… lol
Presentation Time
There were some really cool hacks and such a variety of ideas. Here are a few examples:
- Too uber geeks decided they’d write a compiler – well why not!
- The team next to ours created a 3D sound game in Unity for blind users.
- One developer created a drag’n'drop music game that split Deezer tracks into multiple segments, randomised the order and players had to rearrange and rebuild the tune – awesome idea!
- Flapdoodle was another memorable hack – an app for party hosts that used Facebook and Deezer APIs to auto-build party playlists from your friend’s music tastes. An especially nice touch was the friend’s face rotating on a record during playback – so that everyone would know just who was responsible for choosing Justin Bieber!
Our Turn
Each team only had just 2 minutes to present. With our hack it was all about the demo. The idea was simple but seeing as we’d used Frictionless in the title of our app I was hoping that the presentation would follow suit!
While Ben and Jose presented the idea and UI on screen I wondered around taking snaps of the audience on my iPhone which instantly streamed into Ben’s version of the app hooked up to the monitor. It’s not that tricky to implement this sort of thing but it makes for a really cool live demo
Our Presentation
Initially we were a bit gutted not to pick up any of the sponsor prizes but our dissapointment was short-lived when Jim announced that the overall hack winners were Frictionless Photo Sharing! It took us a minute or 2 to remember that was us!!
Prize Winners!
We won Parse and Pusher Pro accounts which is super-cool as it ultimately means that we can potentially develop our prototype into a product and ship it without incurring hosting costs for the foreseeable future.
Hacking the Future
I had such an amazing first hackathon experience and working with such talented and enthusiastic teammates enhanced the experience even further. Bring on the next one!
Introducing Poker Royale
Poker Royale is a FREE, stylish and easy-to-play Texas Hold’em multiplayer game for iPhone, iPad and iPod Touch. Challenge Game Center and Facebook friends to join you and climb your way up through the high stakes tables to win millions of virtual poker chips!
Poker Royale is an app that I created with 2 other developers – Ben Dowling and Mike Ross. It’s a project that’s been in development for about six months but we are finally live in the App Store and going strong!
Building a multiplayer game that can host thousands of simultaneous real users playing against each other anywhere in the world on their iPhones and iPads is no easy task! We’ve built something that really stands out from the competition and our users seem to be loving the results.
I jumped at the chance to be involved in developing a Poker app as for me this kind of project is a real mix of business and pleasure I play a weekly poker game with friends and have been known to dabble online occasionally. As well as being a game of skill, probability and maths, poker can be a great sociable game. We’ve worked hard to ensure it’s really easy to play and invite your friends to tables in the game and developed a fun chat experience so that you can banter with players around the poker table. It’s kind of funny when you find yourself chatting to a Russian or Japanese player though – thankfully, Poker’s a global language!
Check out the promo video we made for the app:
What Makes us Unique?
♦ Have You Made The Rich List?
Poker Royale features the most successful poker players and friends in The Rich List – a chart of the top 100 highest rollers in the game based on real-time chip counts.
♥ Social
Poker Royale leverages Facebook and Game Center social networks to instantly connect players with their friends and family by inviting friends to join virtual poker tables. Find your online friends, join their tables, send them challenges, chat messages and compare scores.
♣ Multi-table
Poker Royale is the only iOS Poker game to enable players to compete on more than one table simultaneously. Win more hands on up to 4 tables at once!
♠ Chip Rewards
Win free chips for inviting friends and playing regularly.
What Players Say…
Here are a few of the five star reviews we’ve been getting on a daily basis:
This brings back the enjoyment I got from iOS Poker before the AppStore got saturated with clones…
If you want a higher brow alternative to the popular but annoyingly slutty Zynga poker, this is a great option!
Amazing setup with multiple tables that each have their own blind value and buy in amount from 1/2 all the way to 500M/1B
Wonderfully smooth easy to use game
Works really well, clearly lots of thought has been put into this, really slick design, fast animations, and speedy between games! And looks amazing on iPad! Great job.
The best poker app I’ve found with great graphics and so easy to use. I’m addicted!
If you love poker you’re gonna love Poker Royale. Download it for free from the App Store and don’t forget to tell your friends!
A few weeks ago, my new book was published by Apress – Foundation iPhone App Development: Build An iPhone App in 5 Days with iOS 6 SDK
It’s been wonderful hearing from readers and receiving great feedback. It’s my first book and it took about 8 months to write alongside the day job so not an insubstantial project for me!
Build an iPhone App in 5 Days covers a very broad range of iOS topics such as Storyboarding, Skinning, Core Data and interacting with the iOS Address Book and Facebook.
Since going to print Facebook have made a couple of tweaks to the way native iOS Apps can integrate with the Facebook Graph API using the new iOS 6 Social Framework. As such some of their changes have broken the Facebook integration code found in Chapter 11 of my book. But fear not, I have a fix – the main reason I’m writing this blog post.
The original source code for my book can be downloaded directly from my book’s page on the Apress website.
But you’ll want to replace Chapter 11 source code with the new source code for this chapter that you can download here.
Within the new source code the only file that I’ve updated is in the Completed Code project folder – BRDModel.m – and I’ve highlighted my tweaks and changes in the file adding NEWCODE in the comments.
The Issue
If you’ve run into the follow printed error from Facebook servers when working with the original Chapter 11 source code then this blog post should get you back on track:
{NSLocalizedDescription=The Facebook server could not fulfill this access request: The app must ask for a basic read permission at install time.}
Facebook now require iOS apps to first request the minimal read permission before requesting extended permissions like friends_birthday and publish_stream. This means that apps using Apple’s Social Framework to interact with Facebook will need to fire multiple account store access requests rather than just one. This is annoying to program but does make sense IMHO. ie we can’t just ask for an endless list of permissions when our users first authenticate, signing their privacy away to our evil plans
The Fix
So here’s how to do it. We should only start requesting Facebook access permissions from our users when and if they actually try to use a Facebook feature of our app. So the Facebook authentication process will still be lazily called when an if it’s required in Birthday Reminder.
The main change to the source code is in the authenticateWithFacebook method. What we do is call this method twice: once to request get the minimal Facebook permissions, and when granted we call loop back into the authenticateWithFacebook method and this time ask for the required extended permission. Here’s the full updated method:
//Centralized iOS user Twitter, Facebook and Sina Weibo accounts are accessed by apps via the ACAccountStore
ACAccountStore *accountStore = [[ACAccountStore alloc] init];
ACAccountType *accountTypeFacebook = [accountStore accountTypeWithAccountTypeIdentifier:ACAccountTypeIdentifierFacebook];
//NEW CODE start
NSArray *permissions;
NSString *facebookAudience = ACFacebookAudienceFriends;
if (self.facebookAccount == nil) {
//we need to deal with very basic authenication first
permissions = @[@"email"];
facebookAudience = ACFacebookAudienceOnlyMe;
}
else {
switch (self.currentFacebookAction) {
case FacebookActionGetFriendsBirthdays:
permissions = @[@"friends_birthday"];
break;
case FacebookActionPostToWall:
permissions = @[@"publish_stream"];
break;
default:
return;
}
}
//Replace with your Facebook.com app ID
NSDictionary *options = @{ACFacebookAppIdKey: @"125381334264255",
ACFacebookPermissionsKey: permissions,ACFacebookAudienceKey:facebookAudience};
//NEW CODE end
/* OLD CODE
//Replace with your Facebook.com app ID
NSDictionary *options = @{ACFacebookAppIdKey: @"125381334264255",
ACFacebookPermissionsKey: @[@"publish_stream",@"friends_birthday"],ACFacebookAudienceKey:ACFacebookAudienceFriends};
*/
[accountStore requestAccessToAccountsWithType:accountTypeFacebook options:options completion:^(BOOL granted, NSError *error) {
if(granted) {
//The completition handler may not fire in the main thread and as we are going to
NSLog(@"Facebook Authorized!");
NSArray *accounts = [accountStore accountsWithAccountType:accountTypeFacebook];
//NEW CODE start
//now repeat the authenticateWithFacebook call and get the next required permission
if (self.facebookAccount == nil) {
self.facebookAccount = [accounts lastObject];
[self authenticateWithFacebook];
return;
}
//we store the facebookAccount property again as this code may be called in a a different thread
self.facebookAccount = [accounts lastObject];
//NEW CODE end
//By checking what Facebook action the user was trying to perform before the authorization process we can complete the Facebook action when the authorization succeeds
switch (self.currentFacebookAction) {
case FacebookActionGetFriendsBirthdays:
[self fetchFacebookBirthdays];
break;
case FacebookActionPostToWall:
[self postToFacebookWall:self.postToFacebookMessage withFacebookID:self.postToFacebookID];
break;
}
} else {
if ([error code] == ACErrorAccountNotFound) {
NSLog(@"No Facebook Account Found");
}
else {
NSLog(@"Facebook SSO Authentication Failed: %@",error);
}
}
}];
}
Here’s how the above process works. When the authenticateWithFacebook method is first called self.facebookAccount is nil. So we first ask for basic access by setting the permissions array to email and facebook audience just to me:
if (self.facebookAccount == nil) {
//we need to deal with very basic authenication first
permissions = @[@"email"];
facebookAudience = ACFacebookAudienceOnlyMe;
}
This results in the basic profile access alert show here. If the user taps ‘OK’ then the request access completion handler code will run. If self.facebookAccount is still nil then we can assume that we’ve been granted basic access to the user’s Facebook data. So we set self.facebookAccount to the newly granted access account and recall authenticateWithFacebook:
//NEW CODE start
//now repeat the authenticateWithFacebook call and get the next required permission
if (self.facebookAccount == nil) {
self.facebookAccount = [accounts lastObject];
[self authenticateWithFacebook];
return;
}
This time, when our authenticateWithFacebook method runs it checks that self.facebookAccount is not nil and then picks the relevant extended permissions:
case FacebookActionGetFriendsBirthdays:
permissions = @[@"friends_birthday"];
break;
case FacebookActionPostToWall:
permissions = @[@"publish_stream"];
break;
default:
return;
}
In the case of retrieving the user’s Facebook friend birthdays we now need to request access to the friends_birthday Facebook permission which will result in the following iOS alert:
The user grants access to the extended permission and then bingo, we can now call fetchFacebookBirthdays which will in turn use the iOS 6 Social Framework to call the Facebook Graph API and retrieve an array of the user’s friend birthdays.
The only additional line of code we need to add is to nil out the self.facebookAccount reference when we’re done with it to ensure that our changes to the authentication flow will be repeatedly called. ie, we also call the Facebook Graph API to post directly to user’s Facebook walls so we need the authentication to rerun and request the publish_stream extended permission.
Does that all make sense? Hope so!
Enjoy the rest of the book
Find me on twitter.
60secondreviews are a new UK-based startup offering a simple and engaging proposition: concise, interesting 60 second video reviews of Movies, Restaurants, Books and Wine on your iPhone, iPod Touch or iPad. The video reviews are delivered by industry-leading expert critics and was founded by Euan MacDonald and Nick Duncalf.
I was hired by 60secondreviews as a Consultant and iOS Developer to build an e-commerce iOS app that could deliver the video reviews, giving users a free taster of the content before enticing them to subscribe using Apple’s in-app purchase subscription model.
The content covered by 60secondreviews (Movies, Restaurants, Books and Wine) is quite broad and whereas it makes sense for Movie content to appear in the App Store’s Entertainment category, Food and Drink are more appropriate the Wine and Restaurant based content. It was these differences which led us to conclude in an early brainstorming session that by creating 4 apps, one for each product, we could divide up the content nicely across a suite of apps. Those only interested in Wine (no wino jokes please!) would be presented with only Wine reviews.
However, we’ve also connected the 4 apps by creating a custom toolbar that enables users to flip between the apps using multitasking in iOS. If an app find that you have also installed additional 60secondreview apps on the same device then it displays a launch icon for each. If you haven’t already installed the other apps then we display a download icon to enable users to download the other apps for free, making great use of in-app cross-promotion.
All of the 60secondreview apps have been built in iOS 6 and make extensive use of the new Apple components and APIs such as collection views, appearance skinning and native Facebook and Twitter sharing.
Want to know more? I’ve even got my own 60secondreview video about the development of the iOS apps and the use of iOS 6. Check it out below.
I’m currently on a flight to San Francisco to attend Apple’s WWDC 2012 Conference – with 10 hours of time to kill I thought I’d spend a few hours writing a post about a CoreData bug I discovered recently. I’m also planning on showing the bug to Apple engineers next week so with a bit of luck this issue may get fixed in iOS 6. Fingers crossed.
Apple’s Binary Data attribute type
In iOS 5 Apple introduced a great new Core Data attribute type, Binary Data. This was a great new attribute – prior to iOS 5 it was typical to manage and store images and other binary files to disk outside of Core Data and store references to the files from Core Data entities – not ideal.
Use Case Scenario
A lot of the apps I build make extensive use of caching images so that users of my apps can continue to use my apps even when they’re offline. A good example of this is my latest iPad App, Portfolio Pro. Portfolio Pro is an app for Photographers and Designers to import their photos and videos into the app and then be able to present those binary files to clients in a coffee shop for example. The images need to be cached by the app for offline use.
The Problem
I’ve been using Apple’s Binary Data attribute type to store both the large photographs imported by users of my app and thumbnails for the photos. I’ve updated the app a few times without experiencing any problems accessing the previously cached Core Data binary attributes. Until that is, I tried to attempt a very simple automated Core Data model migration in a recent update. A strange bug occurred. Cached Core Data binary data started disappearing!
What was odd was that all of the cached thumbnails remained after an automated migration but the larger binary data attributes containing the original large sized photographs (2048 pixels long side) became nullified.
I was using exactly the same approach to store the thumbnail binary data and the large photo binary data. So why was one migrating and the other not? In both cases in addition to setting the Core Data attribute type to Binary Data I’d also selected Allows External Storage option. It seemed like the sensible choice, as I’d expect an optimized database framework to read/write large binary files to disk.
Allows External Storage
While investigating the migration issue I was experiencing in Portfolio Pro I discovered that Core Data writes large binary data to disk but not smaller binary data. Exactly what size it uses as the cut-off limit I don’t know but with large photo data I found that Core Data had created external binary files on disk in a subfolder of my app’s documents folder named “_EXTERNAL_DATA” within another folder named “.[MyProjectName]_SUPPORT”. So if your Xcode target is named MyCoolApp then the path to Core Data’s external storage will be [DocumentsFolder]/.MyCoolApp_SUPPORT/_EXTERNAL_DATA
Goodbye External Storage
Once I’d discovered this hidden storage folder I then found the cause of my disappearing photos. When Core Data performs an automated model migration it deletes/resets the _EXTERNAL_DATA folder – goodbye photos! All of my entities were being migrated just fine but the large, externally stored binary attributes were just disappearing because the storage directory was getting nuked in the migration process.
So that’s the bug with migrating a CoreData model that uses Binary Data attributes with Allows External Storage switched on.
See for yourself
I’ve put together an example project to demonstrate the bug. Download the source files here:
Begin by opening up the Xcode project within the Before Migration folder. Run the project in the iOS Simulator. You should get similar results to figure 1.
Figure 1: Before CoreData Migration
The 2 image views are being populated by a single Core Data entity. The entity contains 2 identical Binary Data attribute types. 1 named smallImage and one named largeImage. Both have been set up to Allow External Storage. In the view I’m rendering the smallImage binary data into the first image view and the largeImage binary data into the second image view. Both image views have content mode set to aspect fit.
Close the Before Migration version of the project. Now open After Migration (Bug) version of the same project. The only difference between this version of the project and the first is that I’ve migrated the CoreData model by adding a model version and adding a new unused string attribute named newAttribute to the Core Data Entity.
The project is already set-up correctly for automatic Core Data migration. Build and run. This should replace your previous version of the example app and perform the automatic model migration. But what happens to the binary data attributes of our entity? Here’s what happens, the small image remains and the large image is deleted (see figure 2)!
Figure 2: After CoreData Migration
Ok, point proven. Delete the demo app from your iOS Simulator. Run the original Before Migration version once more – you should now have both images displayed as before. Now for the solution…
The Solution
Now build and run the third version of the example app within the After Migration (Solution) folder. You should still have 2 images displayed after migration – hurray!
The solution I’ve come up with is when your code initializes a persistent store coordinator for your Core Data model run a few checks before attempting automatic migration. Check whether the new model is compatible with the current stored model. If it’s not then you know that Core Data is about to migrate your old model to your new version and in doing so will wipe the external storage folder. Before it does so simply move the external storage folder to a temporary location. Once the migration has completed replace new empty external storage folder generated by Core Data. Here’s the code that you’ll also find in the Model class of the example project within the After Migration (Solution) folder:
{
if (_persistentStoreCoordinator != nil) {
return _persistentStoreCoordinator;
}
NSURL *storeURL = [[self applicationDocumentsDirectory] URLByAppendingPathComponent:@"CoreDataBinaryBug.sqlite"];
NSError *error = nil;
NSDictionary *sourceMetadata = [NSPersistentStoreCoordinator metadataForPersistentStoreOfType:NSSQLiteStoreType
URL:storeURL
error:&error];
//Check if the new model is compatible with any previously stored model
BOOL isCompatibile = [self.managedObjectModel isConfiguration:nil compatibleWithStoreMetadata:sourceMetadata];
BOOL needsMigration = !isCompatibile;
NSFileManager *fileManager = [NSFileManager defaultManager];
//Prepare a temporary path to move CoreData's external data storage folder to if automatic model migration is required
NSString *documentsPath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) lastObject];
NSString *tmpPathToExternalStorage = [documentsPath stringByAppendingPathComponent:@"tmpPathToReplacementData"];
NSString *pathToExternalStorage = [documentsPath stringByAppendingPathComponent:@".CoreDataBinaryBug_SUPPORT/_EXTERNAL_DATA"];
if (needsMigration) {
if ([fileManager fileExistsAtPath:pathToExternalStorage]) {
//Move Apple's CoreData external storage folder before it's nuked by the migration bug
[fileManager moveItemAtPath:pathToExternalStorage toPath:tmpPathToExternalStorage error:nil];
}
}
NSDictionary *options = [NSDictionary dictionaryWithObjectsAndKeys:
[NSNumber numberWithBool:YES],NSMigratePersistentStoresAutomaticallyOption,
[NSNumber numberWithBool:YES], NSInferMappingModelAutomaticallyOption, nil];
_persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[self managedObjectModel]];
if (![_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:options error:&error]) {
NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
abort();
}
else {
if (needsMigration) {
//Apple's automatic migration is now complete. Replace the default external storage folder with the version pre upgrade
[[NSFileManager defaultManager] removeItemAtPath:pathToExternalStorage error:nil];
[[NSFileManager defaultManager] moveItemAtPath:tmpPathToExternalStorage toPath:pathToExternalStorage error:nil];
}
}
return _persistentStoreCoordinator;
}
Once more, here are the source files for the example project:
Interested in iOS Development and Core Data? Follow me on Twitter for more tidbits
My wife is a photographer and when she meets clients she lugs about a very large portfolio case holding a selection of suitable prints for each client. The case is heavy and cumbersome. Sure, the prints are ordered but it can be a pain for her to sift through her portfolio to find particular photographs during a meeting. The situation is a similar problem for thousands of photographers and designers. Far from ideal.
The iPad
The iPad is the perfect device for photographers to present their portfolio to clients. Swiping and zooming through photos on the iPad not only looks amazing on it’s HD display, it enables professional photographers to take their entire portfolio to client meetings in a lightweight device that fits inside an A4 envelope.
Apple’s Photos App
But Apple provide a great Photos App for the iPad already so why not just use that? Here are a couple of reasons.
- What about when your private pics get mixed in with your professional ones?
- What if you want to add a title and description to each of your photos?
- What if you want to import your photos from Flickr or Dropbox and not have to rely solely on iTunes and iPhoto syncing?
iPhoto is a great app for viewing photos and videos of family and friends but when it comes to the professional photographer, you want a bespoke looking app that that looks like it belongs to you. Your Brand. Your Portfolio. Your App.
Introducing Portfolio Pro
Portfolio Pro for iPad, my latest project, is a brandable photo & video presentation app built for photographers, designers & creatives.
With batch import from Flickr, Dropbox and your iPad, Portfolio Pro gives professional users an extensive collection of ways to get their work onto the iPad. The app consists of 3 main sections: home screensaver for featured work, galleries and flippable fullscreen slideshow mode.
Portfolio Management
While Portfolio Pro imports your high res JPGs, PNGs, TIFs, GIFs, MOVs, MP4s and M4Vs you are free to simultaneously drag and drop to rearrange galleries, add names and descriptions to your work (also automatically imported from Flickr and Dropbox).
An Intuitive Experience
Having tried and tested pretty much every portfolio app for iPad in the App Store I can honestly say I think it’s rare to find a portfolio app that is both beautiful to present with and easy to use and configure. That’s exactly what I’ve set out to achieve with Portfolio Pro. Not only does Portfolio Pro look beautiful when presenting your work to clients, making changes to galleries and media is also super-simple and intuitive. Triple-tap any screen to switch between client and edit modes. Check out the video to see it in action.
I’ve set-up a dedicated website for Portfolio Pro here showcasing screengrabs of the app in action and many further details but if you’re already sold already here’s a direct link to Portfolio Pro on the App Store:
LoveThis is a Startup founded and conceived by Alexis Dormandy who won the company 2 million dollars of Series A funding before they even launched their main product, an iPhone App for sharing recommendations with your friends. Pretty impressive!
The LoveThis iPhone App enables users to share product and venue recommendations with their friends. Even friends not using the app via Facebook and email.
I was contracted by LoveThis to build the majority of the iOS app and to consult on various aspects of the App Store marketplace, native Facebook integration, online/offline Core Data syncronisation and a whole lot more.
After a lot of hard work the LoveThis team finally launched version 1 of their iPhone App a couple of weeks ago and it already appears to be stacking up a lot of 5-star reviews.
The LoveThis app makes it very easily to quickly add and share recommendations and tightly integrates with Google Places API to automatically find relevant locations to your recommendation such as nearby restaurants and bars.
The app is nice and simple to use on the surface but behind the scenes it’s powered by a complex server application that connects multiple social network identities and activity and aggregates the data right into the app. So if a recommendation is shared on Facebook both Facebook comments, LoveThis user email comments and in-app comments are all brought together into a single activity stream within the iPhone App.
It’s early days for LoveThis but I think they have an exciting 2012 ahead and I wish the team the best of luck. I really enjoyed working with them all!
Birthday Reminder for Facebook is a beautiful and useful iPhone App that will stop you from forgetting your friend and family birthdays ever again!
I built Birthday Reminder over a period of 5 development days as part of a new book that I’m currently writing for Apress/Friends of Ed publishers. The concept of the book is to teach new iOS programmers how to develop iPhone Apps by building an app from start to finish! It’s very hand-on and a great way to learn Objective C programming for iPhone.
The book (which you can pre-order here) is titled Foundation iPhone App Development: Build an iPhone App in 5 Days with iOS SDK and will be published in September 2012. It covers all kinds of iOS and Xcode features from Storyboarding to Core Data. At the moment it’s all iOS 5 but assuming WWDC announces iOS 6 this summer you can bet that the book will also cover new iOS 6 APIs.
Birthday Reminder works even when you’re offline and will fire local birthday reminder notifications based on your settings.
Import friends birthdays straight from Facebook or the iPhone’s native address book. It’s really fast and intuitive to use.
I’ve featured the app’s birthday cake user-interface and icon design in a number of presentations recently on How to Make Lickable Apps! I’m right in the middle of writing chapter 9 of my book which is all about iOS skinning techniques including the iOS 5 Appearance APIs which are a really awesome new addition to iOS SDK.
Working for Grapple Mobile, I was contracted to develop Macworld Express iPad App for IDG. IDG provided the designs, Grapple project managed the development and I provided the iOS development expertise.
Macworld is the world’s best-selling Apple magazine and creating a native iPad app enabled their users to read, save and digest Apple news and reviews even when they’re offline.
Macworld Express allows users to customise their own app homescreen, selecting and prioritising between Macworld news, reviews, blogs and master classes.
Spot a Macworld article you want to read later? Tap and save your favourite tips, reviews and news. Perfect for train journeys even when 3G fails you!
After 3 very intense weeks of development and design Tap to Chat 2 has finally launched!
Chris Ross and I started the Tap to Chat adventure back in November last year. As two Indie iPhone Developers we decided to team-up and build an Instant Messenger app for Facebook users on iPhone and iPad. The original version launched just before Christmas 2010. Since then Tap to Chat has seen over half a million downloads!
On the back of our success with Tap to Chat, Chris and I have formed a new company – Osmosis Apps – the primary goal being to make software that focuses on great user experience.
Tap to Chat 2 has been written from scratch and includes a brand new, beautiful, pixel-perfect interface. Tap to Chat 2 is: super-simple to use and blisteringly fast to connect all your Facebook Chat and Google Talk friends. We’ve laboured over every detail and included accessibility support for visually impaired users and VoiceOver support. An all-round great user experience.
As part of our launch, I had a lot of fun creating a demo video of the software with a well-known love story theme. Take a look:
Tap to Chat 2 was approved by Apple on Friday night (20th May). In just a few days it has already climbed into the top 25 Social Networking apps in the UK, the US and many other countries.
For all the features and details about Tap to Chat 2 head over to our new company site – www.osmosisapps.com.
Here are a few screen-grabs of Tap to Chat 2 in action on iPhone and iPad:
