Category Archives: iPad

NerdSummit 2017 Workshop: Introduction to iOS Development through Apps

On March 18th, I’ll be giving a workshop to teach iOS development by looking at completed apps and customizing them.

If you are planning to attend, here’s what you should do to prepare

  1. To do the exercises, you need a Mac with Xcode 8.2+ installed. If you don’t have access to a Mac, I think we’ll have enough people with one and can pair you with someone.
  2. We’re going to be forking apps on GitHub, so having a GitHub account already would be good.
  3. You don’t need a device — we’ll be able to use the simulator for all of the examples, but if you want help getting apps on devices, sign up for a free Apple Developer account.

It’s a beginner workshop, so anybody with an interest in programming will get something out of it. It will help if you have some programming experience (in any language).

Here’s the plan

  1. Basic Swift (enough to be able to read the apps)
  2. The MVC pattern as implemented in UIKit
  3. Interface Builder (connecting outlets and actions)
  4. Then, we’ll fork an app and make some customizations
  5. Based on the group’s questions, we’ll cover as much iOS Development and Swift as we need.

The idea is that the apps we’ll fork are generally useful apps that people might want a custom version of. All of the code is open-source, and you’ll be able to continue to develop them after the workshop if you wish and release them to the App Store.

I’ll introduce the apps in subsequent blog posts here (I have to make them).

There will be handouts and some of us might move through them faster and I’ll try to spend the most time working with beginners. We’ll break for mini-lessons that are generally useful to the group.

Handling Pluralizations Correctly in Strings

Earlier this year, Trello launched in 21 languages. I worked on the i18n effort of the iOS apps, and I have been collecting thoughts for a series of blog posts. The first one, about plurals, was published today on the Trello Tech Blog. It begins

On page 52 of my copy of K&R, in a discussion of the ?: operator, is this line of code

printf("You have %d item%s.\n", n, n==1 ? "" : "s");

And thus began my decades-long proliferation of plural-unfriendly strings.

To see why, read the rest of Lessons from Internationalizing Trello, Part I: Plurals on iOS

As a follow-up, I found a Russian translation of K&R. Here is how that line of code is translated

printf("Вы имеете %d элемент%s.\n", n, (n%10==1 && n%100 ! = 11) ?
    " " : ((n%100 < 10 || n%100 > 20) && n%10 >= 2 && n%10 <= 4) ?
    "а" : "ов");

Which is another way to do it, I guess.

iOSDevUK Lightning Talk about Swift Playground Books

Links from the talk

  1. Playground Book package format
  2. WWDC 2016 talk about Swift Playgrounds
  3. My fix of Talking to the Live View
  4. Ash Furrow’s playgroundbook command-line tool
  5. My PlaygroundSupportMock framework for building an app from a book
  6. My pgbookc script for turning a Contents folder in a host app into one that you run as a book
  7. My ShapeSearch playground book and host app built using those tools

Read my previous post on authoring a Swift Playground Book for more information.

Authoring an iOS Swift Playground Book

I expect at some point Apple will have some kind of Playground Book authoring solution, but until then, I’ve hacked together something basic that I am ready to share.

Take a look at my previous post if you’re getting started with playground books. The important things to know are:

  1. The book is a package with a specific folder layout of chapters and pages.
  2. The left-hand side is a stateless playground with markdown and code.
  3. The right-hand side is a stateful live view that can host a View Controller and do pretty much anything you could do in an app.
  4. The playground view and live view can communicate via a simple asynchronous inter-process communication mechanism.
  5. The book is delivered as Swift source files, assets, and plist config files.

As I mentioned in the last post, Ash Furrow has a way to generate this format from a .yaml description and playground files. Even if you don’t ultimately use it as your book source, it’s a good way to generate your initial package structure. The same project also has a linter, which you should use no matter how you author playground books.

The drawback of trying to write an entire book this way is that some of the code lives in the .yaml file and is hard to write and check.

I wanted a way to:

  1. Write the code in Xcode (to get autocomplete, docs, etc)
  2. Build it there too
  3. Run it in a host app where I could test the LiveViews in the simulator
  4. Unit-test the playground and LiveView code

I started by putting a book’s Contents folder into a skeleton app and loading the first page’s LiveView as my rootViewController. The first problem is that on the iPad, there’s a framework called PlaygroundSupport with support for Swift Playground features like the messaging between the playground and LiveView. This framework is not currently available in Xcode.

To make it buildable in Xcode, I made PlaygroundSupportMock. This is a work in progress, and I will add more support of PlaygroundSupport as I need it. You can add it to a skeleton app via Carthage.

The second problem is that the format requires each page folder to have a Contents.swift and an optional LiveView.swift. But, apps cannot have two files with the same name in the same module.  To get around that, I wrote a script called pgbookc to copy the Contents folder from the host app and rename any Contents-*.swift or LiveView-*swift files (removing the -* suffix).

Finally, there are several places in the book where code that would work in the book could not work in an app (and vice versa). So, I added a feature to pgbookc to look for special comments in the Swift files that help it to alter it to work as a book.  For example, here is some typical code you might find in a book (to send a PlaygroundValue dictionary to the LiveView and call it from the playground itself)

func hasAttribute(shape: Shape, attribute: ShapeAttribute) -> Bool {
    let attributes: Set = shape.attributes
    return attributes.contains(attribute)

hasAttribute(shape: cloud, attribute: .IsGray)

The problem is the last line, which must be at the top-level in a playground (but cannot work in an app).  So, pgbookc will look for any line that ends with


and removes that entire line. This lets you write:

func Contents0102() -> Bool { return // REMOVE LINE
hasAttribute(shape: cloud, attribute: .IsGray)

The first and last line will be stripped from the book, but it’s there for the app build. It’s also there for tests, which lets me write:

func testContents0102() {

To make sure any playground code in a Contents.swift file works.

I have an (almost done) Playground Book that I am writing using this technique. It’s called Shape Search and has the reader build a simple guessing game that teaches how to do a binary search.

Swift Playground Books: 2-Sep-2016

I imagine a lot of the information here is going to go out of date fast, but if you are looking at playground books today, here is where to start.

  1. The WWDC 2016 talk, Introducing Swift Playgrounds, has a lot of technical detail about the .playgroundbook format and how the LiveView proxying works.
  2. The demo for that talk is available on Apple’s dev site, but it’s out of date. I’ve been updating it for each iOS 10 Beta (to track Swift 3). Go to my GitHub to get the fixed Talking to the Live View sample.
  3. The documentation for the .playgroundbook format can be found on the Apple Developer site.
  4. Erica Sadun, who has written the book on Xcode playgrounds did some early investigations of iOS Swift Playgrounds. You might want to read them — here is Part I, Part II, Part III, Part IV,  and Part V.
  5. Ash Furrow made a playground book linter and authoring tool (source). You can use the linter on any .playgroundbook (however you make it), and the authoring tool allows you to specify the parts of the book in a .yaml file, and it puts each piece in the correct file and folder for you in the .playgroundbook package.

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’s certificate area.  Regenerate it and download it once it’s right.

Even if you are using a system like TestFlight, 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("")>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