Over 2 years ago I launched Magic Bean for iPhone, which has since then become Universal for both iPhone & iPad. Along with that the core functionality was included in a Mac application which became just as popular than it’s iOS counterpart.
Magic Bean allows you to stay up to date with you or your teams Beanstalk account. Beanstalk is a hosted provider for Git, SVN, Mercurial repositories and allows you to easily deploy sites using their rather nifty deployment features.
For a long time Magic Bean has been sat on the back burner while i’ve cracked on with developing Buffer for iPhone & Globbert. It was the main project I used to learn iOS development, since then I have gone on to create Buffer for iPhone v1 & v2 which have both given me a tonne more knowledge. Now it is time to go full circle and apply what i’ve learnt from building Buffer for iPhone to Magic Bean.
I started by making tweaks to the current Magic Bean project to bring it up to speed and into 2013. The main thing was squishing any of the existing bugs that had started to occur more frequently as iOS got updated as did the Beanstalk API.
I was starting to think about design and more major updates. They weren’t going to be easy tasks within the current project so I decided to release a bug fix release to the App Store with all of the tweaks up until that point. One of which is awaiting review for the App Store.
Rather than try and mold the current project into the vision I had in my head for Magic Bean v2 I decided to start from scratch. Giving myself a clean slate in which to craft Magic Bean into a much improved application than that of version 1.
I started this process a couple of months ago using the latest tools and using iOS 6 as the base design. I was very happy with the progress and the design of the app up until WWDC.
Since WWDC I have decided to focus on iOS 7 for Magic Bean using the same minimal design as iOS 7 and minimising the amount of customisation within the app unlike previous versions of Magic Bean. There’s a few reasons for me recoding Magic Bean and focussing solely on iOS 7, most of which are listed below…
Developers tend to update earlier
Beanstalk is a tool used by developers to manage their version control systems and server deployments. Most developers I know who own iOS devices will happily update as early as possible. Some may have already done so via the iOS Developer Program or by other means.
With that said Apple’s stats on the number of users using iOS 6 as of WWDC were great compared to other platforms but it has been a year since iOS 6’s release so you can expect it to be the highest portion. iOS 7 will most likely be at the same levels this time next year.
I could be totally wrong about this but once it’s released I’ll be able to guage how many people would like me to work backwards and add iOS 6 support.
Years have passed since some of the core code in Magic Bean has been developed or even touched. Since then I have learnt so much about iOS Development and I can honestly say taking a look at some of the older Magic Bean code makes me shudder and want to re-write it all.
Magic Bean v1 was built using Beanstalk’s XML API rather than the lovely JSON API which is available now. XML was the only option back then and now some of the endpoints that are becoming available are JSON only. I could rip up the networking and API code to move over within the current codebase but it feels much nicer to be starting from scratch.
Magic Bean also used ASIHTTPRequest for networking, AFNetworking hadn’t been released so it’s also a good time to migrate over to the awesomeness of AFNetworking.
Back when Magic Bean was developed I honestly wasn’t all that great with keeping code organised, which has meant that updating the app more recently hasn’t been an easy task. Having the opportunity to revisit and recode all of the code behind Magic Bean has allowed me to tidy up everything. Add more commenting and #pragma mark‘s.
Refocus & Remove Bloat
Like with any app that you update overtime, various features are added that just don’t get used by the majority of the users. These become troublesome as you have to continue to ensure they work for those couple of users that do.
Bumping up the version number and re-writing Magic Bean from the ground up allows me to mull over all of the features in v1 and figure out which ones are worth focussing on. Luckily I integrated analytics into the app from the start so I can see just how many times each feature has been used.
iOS 7 is a big opportunity for iOS Developers, not one that comes around very often. An opportunity to refresh your app from the ground up just as iOS has been. Apps that don’t update for iOS 7 are likely to look and feel dated after a couple of months of iOS 7 being out. Magic Bean already feels dated and old, despite minor design tweaks since the first version.
As Marco Arment said in his blog post about iOS 7 titled “Fertile Ground“…
“One of my favourite patterns in our industry is when the old and established are wiped out by disruption, irrelevance, or changing fashions. Like a forest fire, clearing out the old is very destructive and shouldn’t be taken lightly. But what’s left behind is a clean slate and immense opportunity.”
If you have a couple of minutes then Marco’s blog post is well worth the read if you’re pondering focussing on iOS 7.
Not all is lost
Fortunately not all of the code that was written for v1 of Magic Bean has been lost. Various sections of code have been salvagable for v2 with only a couple of tweaks to bring it up to date and into the new layout.
One thing I have been striving to do is to ensure that each thing that is re-built is better in some form. Not just a carbon copy of the original with a new skin. Whether thats a better more intuative interface or a new feature that was missing before that makes it more useful.
Journey into the unknown
iOS prior to iOS 7 had developed a set of standards and UI elements that apps used, while some of those are easily ported across to iOS 7 others require a bit of a rethink.
Right now it is somewhat of an unknown what designers are going to do to make their apps stand out within the design queues Apple have given everyone with iOS 7. Will gradients become a rarity and will everyone adopt the full screen look and feel Apple is striving for.
Dribbble and iOS 7 App Designs gives us an early idea of what designers are thinking but it will be some time till we know what the majority of designers are planning within this new canvas.
Moving onto Mac
Theoretically there are a few months until iOS 7 makes its public debut and right now Magic Bean for iOS is in a good state, i’m fairly close to being able to call it “launch-able”. With that said it’s obviously wise to make sure you don’t leave anything till last minute to finish up and to then realise you’re going to miss the first iOS 7 app submission date.
I have also been working on updating Magic Bean for Mac. Most of the code between the two is sharable between projects so it made sense to give the Mac application a rewrite of its own.
Magic Bean for Mac v1 was developed using Chameleon, a UIKit drop in for AppKit. Allowing Mac apps to be developed using iOS’ UIKit framework, which made developing the app much easier back then. However Chameleon hasn’t been kept up to date with UIKit and has its quirks.
Using the same approach taken with iOS, I created a brand new project and have been working on it using basic AppKit. In my opinion the results are a much nicer, speedier app which still sits at the top of your screen in the status bar.
Code between iOS and Mac is shared with only a few minor modifications due to the structure differences in the apps. iOS allows you to keep up to date with everything while Mac is focused on requesting deployments alone. As with iOS I have tried to make sure each element of the app has at least one improvement or feature addition.
I hope this proves to be a good insight for someone who is thinking about taking on iOS 7 or a recode of their app. If you have any comments or questions feel free to post them or drop me an email via my contact form.