Xcode

Coding on My iPad Pro

Posted on by thall by Tyler Hall
2 minute read

Last month, my 9-5 job was kind enough to gift me an iPad Pro and its new keyboard. I’ve had a few iPads in the past, but they’ve always ended up stashed away, unused, in a drawer somewhere. I simply never got hooked on their utility. I never found that killer app, which, for me, would be the ability to code anywhere. This Pro model, however, has changed all of that.

I’ve always had two Macs. One to take places and another to get “real work” done. In the past that meant a spec’d out iMac and an 11″ MacBook Air. More recently, it’s been a work-issued 15″ MacBook Pro that stays plugged into my cinema display 99% of the time and a MacBook (One) when I travel. The new MacBook is certainly the most portable Mac I’ve ever owned, but it’s slow and lacks the screen space to do any UI intensive work.

Now that I have an iPad Pro, I’ve sold my MacBook and only touch my MacBook Pro when I have serious work to do. The iPad has replaced nearly everything I use my laptop for. That may not be so unbelievable. Lots of folks like Viticci have moved to an iOS only way of life. As I do more and more tasks on my phone, I’ve been tempted to try going iOS primarily, but I could never make that jump because I code for a living.

Until now.

I was screen sharing from my iPad to another machine on my local network, when it dawned on me how great it could be if this particular Mac were always available to me – even from outside my house. So, I splurged and ordered a datacenter-hosted Mac Mini from MacStadium. Ten minutes later I was connected to my new Mac in the cloud. And ten minutes after that, I had Xcode open and started testing the waters.

I’m using Screens.app to connect. And with a good internet connection there’s virtually no lag when screen sharing with my new Mac Mini. I’m able to run a native Mac resolution of 1920×1200 on my iPad in full screen. That gives me plenty of room to run Xcode and the iOS Simulator. With Apple’s new external keyboard, all of my usual Xcode and OS X keyboard shortcuts work just fine. And since coding is primarily a keyboard driven activity, my arm doesn’t get tired from reaching out and touching the screen like a designer’s might.

All in all I’m thrilled with my new setup. It gives me the simplicity and benefits of iOS, while still allowing me to do real work outside of the house or from the couch.

ipad-pro-xcode

Automatically Reposition the iOS Simulator on Screen

Posted on by thall by Tyler Hall
1 minute read

If you work with two monitors of different sizes, Xcode has an annoying bug of launching the iOS Simulator partially off screen — forcing you to manually drag it into position using the mouse. It’s not that bad the first time, but after a full eight hour working day with hundreds of launches, it gets very tedious.

Luckily, we can solve this with Xcode 4’s new “Behavior” settings and a little AppleScript.

Open up your favorite text editor and create the following script:

#!/bin/sh
osascript -e 'tell app "System Events" to set position of window 1 of process "iOS Simulator" to {-864, 134}'

Where where {-864, 134} are the {X, Y} coordinates you’d like the simulator positioned at.

Save the script somewhere appropriate and select it as a new “Run” command in Xcode’s “Run Starts” behavior.

Xcode Run Behavior

Creating a Universal Binary With Xcode 3.2.6

Posted on by thall by Tyler Hall
1 minute read

Last week I released a minor update to VirtualHostX. Shortly thereafter, my inbox was flooded with reports of an “unsupported architecture” error on launch. After a quick lipo test I verified that somehow I had managed to build and ship the app as Intel only — no PowerPC support.

I went through my git revision history and was able to track down the error. From what I can tell, the Xcode 3.2.6 update removes the default universal binary option. That’s fine for new projects, but I was completely taken by surprise to see it modify the build settings of an existing project.

Regardless, now that the (once famous) universal binary checkbox is gone, here’s how to add PowerPC support back.

In your target’s build settings, change “Architectures” to “Other” and specify “ppc i386 x86_64”.

Universal Binary Settings

Note: It’s entirely possible this whole episode was my fuck-up and not Xcode, but there are a bunch of similar reports online. So who knows? It certainly wasn’t mentioned in the release notes.

Unsupported Architecture When Submitting to Mac App Store

Posted on by thall by Tyler Hall
1 minute read

For any Mac developers out there who are seeing the following rejection notice when submitting to the Mac App Store:

Unsupported Architecture – Application executables may support either or both of the Intel architectures

Make sure you verify that any included frameworks are Intel only. You can do this using the lipo command:

lipo -info /path/to/SomeFramework.framework/Versions/A/SomeFramework

If the output lists anything other than i386 or x86_64 you’ll get rejected.

This was particularly painful for me because it appears this check is only run when submitting a new version of your app — PPC framework binaries don’t cause a rejection during the original app submission process. I thought I was going crazy since I had made no project changes since the first submission and running lipo on the app binary didn’t return anything unusual. Hopefully this will save someone else the hour of head scratching I just went through.