it’s time to expand your iphone app and introduce it on the ipad. that is an interesting move for any product as the ipad is not an iphone – it is used for different things at different circumstances. yeah – you are going to practically re-think your app… which is great because you get to revisit your code and make sure your pipeline is tight, secure, fast and reliable. all that with the elegance of the ipads – split view controllers

where do one starts? well, you can start be designing your app for the ipad and take by thinking about the following:
orientation, layout and gestures. all of which vary significantly from the iphone (unfortunately). side note: one thing i really like about webOS is that you develop your mobile app once and the system takes care of adjusting the interface to a slated device.

next thing to learn about the ipad is it’s split views, popovers and specific hardware features – all of which are ipad unique. you will need to use conditional coding to learn if a specific hardware feature you are looking for is available. this is necessary as you will need to load the right resources to handle that hardware. more specifically one should write conditional coding for:

resources: in your code, recognize which platform is running and load the right nib files. you will also need to load the right graphics that match the screen size and resolution.
classes: check for class availability based on the device you are running on as some are iPad/iPhone specific.
methods: weak-link any device specific methods and perform a check at runtime for the availability of that method and wether the object responds to a specific selector.

hardware: test for cmarea/gps/gyro support before utilizing it.

okay – we are done with the overview. let’s roll up our sleeves and dig right into it.

first thing’s first – lets let xcode help us start the process by duplicating the current target (an iphone target) into an ipad one.
right click on your target and choose “duplicate”. two options here – duplicate only and duplicate and transitoin to ipad. let’s go with the later.
what xcode does here is create a new virtual folder (i.e. group) called “Resources-iPad” and copies the main nib file there. xcode really takes care of the main nib file and creates it for us. no other nib files to be touched. why? because the rest of the nib files are usually tied right into apps view controller so xcode leaves it up to us to define both the view and it’s controller. xcode sets the targeted device family (TDF) build settings to iphone/ipad and modify the base SDK of the project which will support both device types. no need to touch nor worry about the deployment target. you will see a new plist for the ipad app with it’s relevant settings.

in order to see it in action – run the app using the ipad simulator. what you will see is the iphone app running inside the ipad simulator and you can x2 time it to fit. boooo. one more step necessary (thanks apple for leaving it up to us) is to update the scheme to use the new and shiny ipad target. so go ahead and duplicate your iphone scheme (or create a new one) and under run  - choose the ipad executable. boom. wait – it really looks bad here.

well – as you may know iOS uses the MVC design pattern heavily. you may not know that MVC is actually a compound design pattern which includes 5 patterns. luckily this abstraction makes the process of porting an iphone app to an ipad a bit easier, as potentially one needs to take care of the view – making sure the right outlets are updated based on the design of the UI, and also heavily touch upon the controller to see which device is used and then follow a specific code path to match. the good news is the model can stay untouched

if you are happy with the IBOutlet you currently have on the iphone and would like to only use those (i cannot image why, but yeah…) all you need to do at this point is adjust the springs and struts in the size inspector when loading up your nib in IB. you should also make sure to support the orientations required for the app. in order to do this you will need to  implement shouldAutorotateToInterfaceOrientation:  and test for the device running the code and allow rotation. if you have singleton object place this code in it’s header file:

#define IS_IPAD   (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
#define IS_IPHONE (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone)

ipod touch returns UIUserInterfaceIdiomPhone. FYI.

or place it wherever works for you, as long as you have access to this macro from wherever. this is useful as you will need to update your controllers to test for the hardware running and follow a specific code path to update your view and outlets.

one example of using this code and auto rotating is this:

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {

	 if (IS_IPHONE)
	 {
		 if (interfaceOrientation == UIInterfaceOrientationPortrait ||
			 interfaceOrientation == UIInterfaceOrientationPortraitUpsideDown)
		 {
			 return YES;
		 }
	 }

	 if (IS_IPAD)
	 {
		 if (interfaceOrientation == UIInterfaceOrientationLandscapeLeft ||
			 interfaceOrientation == UIInterfaceOrientationLandscapeRight)
		 {
			 return YES;
		 }
	 }

	 return NO;
 }

pretty easy and straight forward right? moving along.

cautionary tale:
the app now must be careful with the symbols it uses. if you want to use UISplitViewController while running on iOS 3.1 – your app will crash as there are no split VCs on 3.1.
the way you should be thinking about this is by mentally tuning into the ‘runtime checks’ zone, where you will test if a particular symbol exists. more about that later.

updating VC and views:
this is where the bulk of the work really is – redoing your views and adding code (or creating new) view controllers. what can we do – the view size varies between the iphone and the ipad and that certainly needs to be taken into consideration. so start off by redesigning the views for the ipad. if you plan on scaling the existing view could work okay, but more often than not will not be the result you are hoping for. think of it this way – the new ipad interface should make use of the new available space and the elements which only exist on the ipad (splitVCs and popovers for example). the outcome is good UI and top UX.

also consider the following. for view controllers:
a) create new nib files for each device (if you use nib files that is).
b) if you code your views – make sure you support both devices when you do so.

for views:
a) if you override drawrect: make sure the method can draw to different view sizes.
b) if you implemenet the layoutSubviews method, the code must adapt to different view sizes.

symbol checking during runtime:   if deep down inside you had hoped that this step will somehow be avoidable – fear not runtime checks for newer symbols is easy as pie and is the type of topic you can discuss with your boss and sound really clever.
all of this is under the assumption you support different versions of the OS. just like a good soldier – you MUST protect your code from using symbols that do not exist. this happens all the time when you update an app to use new features and want to continue to support previous versions running on older OSs. all you need to do is create different code paths to follow, based on the OS currently running on the device executing your app. if you don’t do that your app is guaranteed to crash and that is not something us pros do, so let us quickly look into an example of how one goes about creating a code path when checking for newer symbols during runtime:

if you are linking against iOS 4.2 you are in luck my friend. that version has a weak linking support built right in, which allows you to check for the existence of a given class object and determine if it’s usable to you. like so:

if ([UIPrintInteractionController class]) {
   // Create an instance of the class and use it.
}
else {
   // The print interaction controller is not available.
}

seriously now – how simple was that?
bare in mind that if you want to use this feature of the OS you must build your app with LLVM and Clang.
deployment target should be 3.1 or later. sorry.

if your app links against < 4.1, use NSClassFromString to see if a class is defined. if nil is returned – you’re shit out of luck.

for example:

Class splitVCClass = NSClassFromString(@"UISplitViewController");
if (splitVCClass)
{
   UISplitViewController* mySplitViewController = [[splitVCClass alloc] init];
   // Configure the split view controller.
}

for testing if an object  can be sent a specific message (i.e. has implemented that method), use the oh so convenient instancesRespondsToSelector: class method (yes, it is a class method, it’s not a type).

if you are a registered iphone developer and have not done so – check out the SDK compatibility guide by apple.

runtime checks –> conditional code paths:
based on the interface idiom described earlier – let’s start creating cool code paths to support both devices. a simple if-else statement will do just fine thank you very much. moving right along.

This concludes this first steps required to port your app from iphone to an ipad. next is a quick rundown on how to use split view controllers in your ipad app.
 

update: this post was written thursday of last week. it is now semi confirmed the developer of mobileNotifier is hired by apple and that iCloud will be presented by jobs tomorrow.

one major revamp is the bare minimum as there are areas lacking where either android or cydia leaves the current OS lagging. and no doubt we will get what we are expecting.. just a gut feeling… here is my short list of enhancements that i’d like to see:

1. improved notification system: bar non that most important and required change to iOS. face it, the current notification system sucks big time. in the past, the real incentive to jailbreak your phone was mywi, my3g and going even further back, multitasking and naturally the most important feature – sim freeing your phone (Screw you apple and ATT for violating FCC regulations). now-a-days, mobileNotifier is THE reason why my phone is jailbroken. aggregate all notifications into a single window utilizing the empty space created when you double click the home page. apple – pls take note, this guy has done a great job.

2. dynamic home icons: ala windows8. yes you heard right. big chunky icons that actually display content and not just a static image. one good example is available on cydia and is called ‘weather icon’. it changes the degrees on the weather icon to display the current temperature. it also allows the temperature to be displayed on the status bar. really useful stuff. apple, please expose an API to do so.

3. OTA updates: not likely but definitely nice to have… over the air updates makes lots of sense. please – no more plugging in to itunes and backing it all up. this ties up to the next item that is most definitely making an appearance on monday:

4. iCloud content sync: this will probably make a big eco. iCloud can and will take cloud services to the next level. apple doing what they do tiered up, may see music sync and later down the road app sync.. so iCloud will probably allow you to purchase music from iTunes and stream it directly from your cloud storage. no need (or an option) to download and sync stuff. fantastic. one viable option is to open a US front against spotify, the EU-stream-the-song-you-want kind of service in the US. imagine a yearly/monthly plan ($20-$50/year) where you can listen to what you want… that’s a nice one.

WHAT’S MISSING? iphone5 with 4G, NFC and iWallet, A5, double down on RAM, larger display and IR.

dealing with memory leaks and zombies is an important issue, and below i will provide a couple of useful tips to setting up xcode in such a way, and arranging your code, so you have more control and understanding of what’s going on under the hood.

first up, i assume you are familiar with:

- reading a call stack
- play around with the expression window
- use the memory browser when needed

if you are not, you probably should read up on those and play around with them. very useful tools to get the gist of what is going on with your app.

tip #1:
- always archive your dSYM (short for debug symbols) along with the app you send for your QA guys (the “testers”). this is really useful, as once they email you back crash logs (which they will), the data in the log will actually make sense, i.e. the symbols are mapped correctly and you will see actual method names rather than HEX addresses.

tip #2:
use the symbolicatecrash script and pass it the .crash file and .dSYM file. this will allow you to mesh the two together and review what had happened. from the command line, execute ‘find /Developer/ -iname symbolicatecrash’. grab the path and add it to your ~/.profile (if you are a bash kind of a guy). add this line: “PATH=/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/ \
Versions/A/Resources/:$PATH” and don’t forget to “source ~/.profile” before you try and access the script.

tip #3:
enable malloc_error_break so xcode will halt when you double release an object or release a stomped memory. this directive for the debugger is actually a breakpoint. think about it, what we are asking xocde to do, is break on a memory allocation error as if it were a breakpoint (rather than crashing). this is very useful as the program will halt on the line of code that tried to perform the illegal action. add this to your project from the breakpoint view. easy as pie.

tip #4:
party with the zombies. edit your schema (xcode4 people can you hear me?) and add NSZombieEnabled = YES to the “environment variables” list. what happes here is fun. xcode will not release your objects when their reference count is zero, but will keep them for safekeep within the framework of the app. if any of the pseudo released objects is being sent a method, xcode will halt your application, load the debugger and point you to the line of code that tried to access what is suppose to be a zombie. how cool is that? caution! this method is a heavy memory foot print so take it under consideration when you enable them zombies to roam your lands.

on my next post i will show you a nifty header file that allows for fast turning on and off of debug calls from within your app.

good luck!

AmpliTube iRig may have solved this problem by creating a digital instrument encapsulated in an app, that holds various effects and amps, and it runs on your iphone. to make things sweet, you purchase what they labeled the iRig: a small device that allows you to plug in your guitar to the iphone, and then have the wet sound routed out to your headset or home stereo system (wet means sound with the effect and/or amplification applied to it).

how fantastic is that? for a fraction of the cost you now have minimized your setup to the iphone and the iRig. i love it!

some questions before the video:
1. what about latency? it is fair to assume it is not an issue, otherwise the app would fail and there is no room to create it from the get go.
2. how quality is the quality of the sound? yet to be seen (or heard). as far as the audio samples on their website – it sounds freaking awesome and top notch.
3. where is the competition? seriously, hats off for the vision and innovation of this company.
4. what’s missing? battery power that will have the iphone last longer than several hours of playing around. maybe it will run better on the iPad

video time:

all around me i see the matrix moving all around – where ever i look…

examples? aplenty.

digital media consumption: slate devices are here to rule the world. the more i play around with my ipad the more i realize how wonderful a 12h battery can serve humanity on the go. and that is key here – on the go. consider it a platform and not a gadget. mobile devices are here to stay. desktop computers? time to turn them into art. they are out the door in terms of dominating the market. face it – we consume, and we consume a lot. in 2010 who is not HDD? seriously… having all media streamed and centralized in a long hour operating device with a crisp device and intuitive interaction will break all barriers. from kids to astronauts. it is just a matter of time.

learning: kids will benefit much from slate devices (BTW, there are over 8 competitors about to launch their products and compete head to head with apple’s ipad). i see kids carrying a huge school bag on their small backs, all these massive books – i say no more! soon enough all the material will be available as a digital book, that will fit within the pound a a half a salte device weighs. with many hours of operation it is a no brainer for schools. moreover, the content can be layered with videos AND become interactive. how about that for creating interesting course material, tests, quizzes and home work?

the kitchen: yes my friends, the kitchen. one of the most important and fun rooms in any house hold – the room where we feed our body, the room where mostly women spend time (excluding metrosexual guys who care for their bodies like myself) to prepare meals for their families. how come there is no digital help there in 2010? sure, we have DVD players etc, but that is used to consume media. how about enhancing the experience in the kitchen? from social media, videos of recipes, timers, integration and interaction with consumer products, baby monitoring and much more. times are shifting my friends, didn’t i mention that?

the living room: yes – last and definitely not least, the title of this post. the real cash cow of media and hardware companies. the area where we will notice aggressive and fierce competition. let’s start with what we have today: we have a one direction big screen and a cable company that decides what we can watch, when and at what cost. they shove commercial right where we don’t want them and make billions. all of that my friends will rapidly change. to date, youtube video uploaded in 2 months accumulate to more footage ever released by all major networks aggregated within the last 20 years. incredible isn’t it? the future is prime content mixed with user created content that will become more and more high end as we go along. check out gary vaynerchuk and winelibrary.tv for prime content centered around wine. and more people are doing their own home production while building brand equity.

so we have great content in our finger tips. what will shift is the hardware. more and more TVs will be released in the near future that will run an operating system. like android, windows and mac/iphone OS. what that means is that the TV will become interactive and essentially a new product. TV 2.0. not widgets a la samsung. but a real computer that has a huge and beautiful display, input and outputs that can allow decoding of HD video and audio signal etc. all we got to expect from a TV, but the control moves back to us – the consumer. and this will happen not a moment too soon.

how long will it take apple to create a beautiful 50″ backlit LCD that runs the iphone OS, which allows multi touch and can be turn into a table when u want a flat user interaction? there are a couple of android based TVs coming out very soon from japan. face it. the TV can and should do much more than it is doing today. screw the big networks – power to the people. consume media when u want it and how u want it. let me buy the episodes i like directly to my set top box, sync it with all my devices seamlessly and make sure i can collaborate around it with my close ones.

if so far we had seen a great and exciting new ecosystem rising – the appStores. from apple to android, blackberry and samsung. we will see apps made for the TV as well. and here is where i ask you – what kind of apps can u envision being used in the living room? how will the TV enhance the usage and integration with other devices around our living space? our phones, our slates, and in the future maybe our cloths and appliances.

worlds are shifting my friends – they are shifting…

men usually do not carry bags around. they try and utilize any available storage space (jean pockets mainly) to avoid the “trouble” of carrying a bag (common in israel).

the home/car keys goes in the front pocket (bulky), the other front pocket holds the cell phone, wallet goes in the back , or can squeeze in front and, and the list goes on… when visiting a cafe in Tel-Aviv for example, you will notice that the table has everyone’s items on display otherwise it will be painful to sit, right?

on a medical note, realize that carrying these items creates tiny imbalances that influence your posture and has microscopic effects on your spine. sound silly and you may dismiss it.. don’t say i did not warn you though…

to my point: there is something inherit about us men, genetic even, that our primal impulse is to refuse the usage of a bag in order carry stuff around.. it makes sense, it saves us lots of trouble and assists in keeping all our belongings safe and available. no… we will not use it. one may say it’s fashion related, that we don’t want to look feminine… or maybe (just maybe) it is the hunter within us that wants to be as light as possible.. you know, so we can responds to imminent attacks from wild animals – our lives are at stake here..

sometimes you will see a couple walking down the street holding hands. so romantic right? if you look closely you will notice that the guy is carrying a bag, which is not his own.. she packed all she will need (wallet, keys, makeup kit, emergency makeup kit, tissue paper, tampons, hand sanitizers and all you one she conceivably thinks may come in handy).. the poor guy looks defeated almost… why? because he planned on carrying pretty much nothing.. and he ends up carrying everything

guys are hunters, women are gatherers.. they go out to the fields for a while, pick berries and mushrooms, examine colors and compare notes. they need stuff (whatever that is) to get by. us men hunt lions, we need to move fast on our feet, carrying nothing but our weapons.

us guys can “get ready” quickly,  minimize what we carry on us, avoid a bag altogether right? we leave our homes happy. we have it all ON us, without any accessories..  and then the lady comes by, bats her eye lids and asks “can u please carry this for me?”… “sweetheart” he tells her, “i am hunting lions here! i need to be agile and responsive! the last thing i need is to carry a bag! .. what the hell?!”. and of course he carries it (if he is a gentleman) with an inherit feeling of defeat.

sounds familiar? i thought so… what does it all have to do with technology (this is a technology blog…) you are probably wondering by now…

here is my question: can the ipad change the game for men?one of the great things about the iphone is that it is quite small for what it can do. it can fit into your jean pocket or clipped to a  belt. the ipad is a versatile device that will require some sort of carrying (not the one portrayed in the image above for sure.. though some men would find it appealing). the right design and concept may start convincing more men that carrying a bag around is cool and masculine. we won’t have to feel like a girl walking around with a bag full of stuff we don’t need.

i personally think there is room for an ipad carrying bag that men would adopt and use. time will tell.