Category Archives: iPad

3 Tips for Making Sure an Ad Hoc iOS Build Will Work

If you build iOS apps and send the IPA to others to install, there are a few simple checks you can do before you send it that will make sure it will work.

  1. Go into your Build Settings and set the “Validate Built Product” to Yes — that way you won’t be able to build if your provisions are wrong. This is the default for new projects in recent versions of Xcode, but check it to make sure.
  2. Open the IPA that was created. It’s a bundle, so copy and rename the extension to .zip. Then look for the mobileprovision XML file.  You should see the device UDID that you intend to send it to.
  3. Always increase the version # of any build that leaves your machine.  If you don’t do this, iPhone Utility or anything else can decide to offer a cached version instead. If you have a good place in your app to show the version, do it.

If #1 above causes you not to be able to build, then use Apple’s Provisioning Troubleshooting guide.

If the device isn’t listed in the mobileprovision file, then make sure it’s added to the provision in developer.apple.com’s certificate area.  Regenerate it and download it once it’s right.

Even if you are using a system like TestFlight, (edit in 2020: TestFlight is part of Apple now, for AdHoc builds, try AppCenter instead) you should follow these tips. TestFlight can’t make an invalid app work, and it can’t fix an IPA that doesn’t have all of the device UDIDs in it.  All it does is automate over-the-air IPA installs (which is great), but it still operates within the confines of the app distribution system.

Don’t assume ARC solves all of your memory problems

You should absolutely be using ARC in your iOS projects, and if the project predates ARC, go ahead and use the refactoring tool to get it to ARC. It really doesn’t take long and you’ll end up with a more stable app that will be easier to maintain.

That being said, you can’t completely ignore memory management. You can still get EXC_BAD_ACCESS, Zombies, leaks, etc., even with ARC projects. Here are some things you should know

  1. ARC is not garbage collection. It statically analyzes your code and then puts in release and retain calls where they are needed. It’s still susceptible to a retain-cycle — two objects with references to each other. You can still have references to dead objects.
  2. If you have a retain-cycle, a common way to deal with that is to make one of the properties weak (which you should probably do), but now that reference is susceptible to becoming a Zombie. A weak property will not call retain on the object, so when the object is deallocated, it would then refer to a dead object. If you have weak properties and get EXC_BAD_ACCESS, go reproduce it under the Zombie instrument.
  3. Under ARC, you cannot use autorelease any more, but the calls into non-ARC libraries can (and do, especially iOS frameworks). This means that you sometimes need to use your own autorelease pool. Under ARC, use the @autoreleasepool keyword to wrap areas where autoreleased objects are created that you need released before you return back to the thread’s main pool.  If you see leaks of objects in Instruments that you don’t alloc or hold onto, and use threads, add in @autoreleasepool blocks.
  4. Don’t use non-ARC code in your project by copying the source in. Build them in their own Xcode projects and then use the resulting .framework or .a in your project. It’s likely you wouldn’t be able to anyway, but just in case. (if you happen to be MRC — then really don’t copy ARC source into your projects — this will usually be compilable code, but will leak like crazy)
  5. Test your code under the Zombie and Leaks instruments — especially if you use bridging, weak references, or are in any way managing retain-cycles (breaking them yourself without weak).
  6. It’s rare, but I ran into a bug in the iOS framework that didn’t retain Storyboard created Gestures correctly in a tabbed-app. It was my first big ARC project, and it didn’t even occur to me to check for Zombies, but that would have pin-pointed the issue right away. Rule of thumb, the underlying code is still normal retain/release/autorelease based — debug it the same way you would have with Manual Reference Counting.

Further Reading:

Get iPhone programming tips in your inbox with my Beginner iPhone Programming Tips newsletter.

 

XKCD Tooltip Bookmarklet

If you read XKCD on an iPhone and iPad, there’s no way to see the tooltip text on the comic (usually the funniest part).

Here’s a bookmarklet to pop-up the XKCD tooltip.

javascript:{var l=document.getElementsByTagName("img");for(var i in l)if(l[i].src.indexOf("xkcd.com/comics")>0){alert(l[i].title);}}

Here’s the process for adding it your iPhone

  1. Go to this blog-entry on your iPhone
  2. Select and Copy the bookmarklet above
  3. Go to XKCD, bookmark it, and save the bookmark
  4. Edit the bookmark, change the Title to “XKCD Tooltip”
  5. Paste the bookmarklet to the URL of the bookmark

To use it

  1. Go to XKCD,
  2. Choose the bookmarklet from your bookmarks — it will popup the tooltip

Favorite iPad apps

Here are some of my favorite iPad apps so far:

WordPress: If you have a WordPress site, this is pretty essential. The iPhone version is pretty good too, but obviously the iPad is perfect for this. I’ve found the WordPress admin to be wonky on Mobile Safari, so this is the best way to edit a WordPress site on iPhone OS.

MaxJournal: This app is a great example of an iPad app — it does one thing and it does it well. It looks great, has elegant date navigation, and strips a journal down to the bare bones. It needs a password feature, but apparently, the feature is done and waiting for approval. The developer is very responsive to feedback, which is a good sign.

Kindle: Kind of obvious. The advantage over iBooks is that the books you buy are available on the iPhone or your Mac or PC (some books have a limit, I hit that with one of my books)

Tweetdeck: Free and supports lists and other custom filters, which are essential for reading Twitter.

NewsRack: RSS reader that syncs with Google Reader. Well done, stable, with some nice touches.

And the disappointments:

CraigPhone: This is an iPad version of Craigslist. Tons of bugs. The app has an apology right on it (they put it in the AppStore without testing it on a real device). It’s free, so I guess that’s ok. Something about the interface just feels wrong though — I suspect that they are using HTML views with some JavaScript drawing parts of the UI.

Tweetdeck: It’s the only usable twitter client for me, but it is crashtastic. Tweet-boom, tweet-boom — move a column, buh-bye. Anyway, it’s free and I assume that they are working on it — they need to check out my post about debugging memory crashes on the iPhone and it probably wouldn’t hurt to run a Build and Analyze once and a while.

NYT Editor’s Choice: First, you can’t find this app by searching the store for “NYTimes” or “NY Times” because they named it with NYT. And, you don’t get the whole paper? But, I do if I go to the website? I don’t get that — just charge me.

No Google apps or Facebook: Pretty surprised that these big players with great apps are absent from the AppStore on day one. Google made GMail work great on an iPad, though — if they had done the same with Reader, I might not have bought an app.